XaeroX писал: Ничего странного тут нет. Rotation - это число, которое показывается в редакторе, и более ничего.
Занятная концепция Странность в том, что UV-lock участвует в поворотах брашей, а должен работать только для морфинга
Очевидно, это и есть сбойное место
Цитата:
XaeroX писал: Насколько я разобрался, там сначала строятся таки ортогональные оси путём проецирования на плоскость фейса. А потом матрицей из браш-примитива доводятся до нужного положения.
Тоже попробовал разобраться, похоже так и есть
Код из компилятора
C++ Source Code:
1
/* brush primitive texturing */
2
else
3
{
4
/* calculate texture s/t from brush primitive texture matrix */
Garux
Ну так откуда texX и texY берутся? Это ж и есть сами оси.
Добавлено 26-04-2015 в 17:06:
Цитата:
Garux писал: Странность в том, что UV-lock участвует в поворотах брашей, а должен работать только для морфинга
Наоборот, предпочтительно пользоваться им только в режиме shear (третий режим выделения). Но в принципе он работает в любом режиме, однако т.к. "запирание" координат может привести к тому, что оси принципиально окажутся невосстановимыми (иными словами, текстурные координаты не будут корнями одной и той же системы линейных уравнений, как должно быть с осями), то лучше этот режим использовать как можно реже, когда точно известно, что и где нужно получить.
Добавлено 26-04-2015 в 17:07:
Цитата:
Garux писал: Занятная концепция
С введением формата 220 оно и в хаммере так.
По сути вращение выполняется не на заданный угол, а на разницу между предыдущим и текущим углом. Т.е. число там может быть любое, обрабатывается только приращение.
XaeroX писал: Ну так откуда texX и texY берутся? Это ж и есть сами оси.
Оси в компиляторе берутся из ComputeAxisBase( vec3_t normal, vec3_t texX, vec3_t texY ), что похоже на таки проекцию ортогональных осей на фейс
Не совсем понимаю техзадание. Надобно отклонить оси, исходя из матрицы? Пересчитать их относительно мира?
Просто, если б я был такой умный, то, пожалуй бы, уже сочинил свой black jack с автокалком и локами
Цитата:
XaeroX писал: предпочтительно пользоваться им только в режиме shear (третий режим выделения). Но в принципе он работает в любом режиме
Так для поворотов брашей UV-lock ничего полезного не делает, только баг вызывает
Отключить в коде его для поворотов, делов-то
ТЗ: объяснить мне, как получаются неортогональные оси в браш-примитивах.
ComputeAxisBase создаёт ортогональные, и я не понимаю, как матричная трансформация этих дотов позволяет добиться эффекта, как на гифке.
Я не очень силён в математиках, ибо по образованию биолог, а иначе уже сочинил бы свой унреал-5 с собственным удк.
Цитата:
Garux писал: Отключить в коде его для поворотов, делов-то
Кабы всё было так просто.
Архитектура редактора такова, что фейс не знает, поворачивали его или что другое похабное сотворяли. Ему просто матрицу дают, и всё. А матрица совсем в другом месте считается (в коде селекшен-тула).
Это дистанция плоскости с нормалью texX и содержащей точку vTranslated
Другими словами размер проекции вектора точки на вектор одной из ортогональных осей
Тут смотрим, будет ли s или t меняться по одной оси или по двум сразу и в каком соотношении
На примере простого случая с гиф исходное состояние с такой матрицей:
( ( 0.03125 0 0 ) ( 0 0.03125 0 ) )
s=x*0.03125, t=y*0.03125, offset = 0
Перекошенный вариант:
( ( 0.003125 -0.0010868 0 ) ( 0 0.003125 0 ) )
s=x*0.03125 - y*0.0010868, t=y*0.03125, offset = 0
В таком простом случае кажется, что можно реализовать UV lock без выковыривания алигна из st через систему уравнений
Кстатии, q3map2 при декомпиляции карт в brush primitives тоже так делает
Ага, теперь понятно, спасибо.
Как-то я не сообразил, что матрица применяется не к осям, а к проекциям, а там понятия ортогональности уже нет. Значит, теоретически действительно можно экспортировать текстурирование джека в формат браш-примитивов.
Другой вопрос, зачем вообще их придумали? В чистом ку3 оси нужны, чтобы грамотно присовокупить к фейсу лайтмапу. Если использовать неискажённые оси - лайтмапа будет не прямоугольником, а параллелограммом, и жрать ненужное пространство. Далее, оси нужны для касательного пр-ва для бамп-маппинга, что умеет считать ку3мап2. То есть, по сути, нам всё равно придётся восстанавливать искажённые оси в компиляторе. Ну почему же их сразу не писать в мап-формат, слегка доработав именно компилятор? Это же намного проще и логичнее, чем докручивать новый экспорт-формат джеку, где придётся решать хитрые уравнения для вычисления этой текстурной матрицы?
Ума не приложу, из каких корыстных соображений был выбран такой формат текстурирования
Посмотрел на формат карт Doom3 - там плоскости фейсов заданы, как нормаль + дистанция, а текстуринг через такую же матрицу
Что до уравнений - можно взять готовое решение отсюда: https://gitlab.com/xonotic/netradia...2/convert_map.c
функция ConvertBrush
Этот код заражён GPL-вирусом.
Ну не важно, принцип понятен.
Вопрос - а кому именно-то нужен экспорт в формат браш-примитивов? Я не знаю ни одного пользователя джека, работающего с ку3, а компиляторы ку1/ку2/хл1 всё равно брашпримитивы не понимают.
XaeroX писал: Я не знаю ни одного пользователя джека, работающего с ку3
И я
Поддержка q3 в джеке это потенциальные пользователи из всех игр, поддерживаемых q3map2, так что проблема с форматами наверняка всплывёт, например:
новичёк: посмотрите карту плз, что я не так делаю?
неновичёк: ой нет, для этого джек надо ставить, фу, фу
Также есть порядочное количество форков q3map2 с разным функционалом и сетами багов. Добавлять поддержку формата hl в каждый - таки много работы, даже при наличии инструкции
Garux писал: новичёк: посмотрите карту плз, что я не так делаю?
неновичёк: ой нет, для этого джек надо ставить, фу, фу
новичёк: ставь, ставь, там есть бесшовный текстуринг, wysiwyg-редактирование шейдеров и много всяких славных плюх, радиант отныне не нужен.
Не, ну как говорится, редактор - дело вкуса. Радианты меня бесят, притом что редактор под мой движок был таки радиант (на тот момент джека не было). Ну бесят, и всё. Там всё как-то не так, по сравнению с хаммером.
Цитата:
Garux писал: Попробовал импорт кубика с brush primitives
Я толком и не тестировал эти примитивы. Ну никто из моих знакомых ими не пользуется даже под ку3, что поделаешь. Кинь, плиз, мап с этим кубиком, я гляну.
- модели в циклер спрайтах не прорисовываются, с монстр генерик всё ок
- мелочь: при открытом окне Объект пропортиес, нажимаешь закрыть карту и табличка с вопросом сохранения находится за Объект проп.
- тот же глюк, что и в хаммере: большие модели, типа 3д-скайбоксов начинают прорисовываться только под определённым углом и расстоянием от центра модели
- в энтити репорт было бы хорошо добавить путь к моделям и спрайтам от энтить типа циклер спрайта, чтобы можно было легко найти нужное
- кнопка Сейв на панели предлагает сохранить в жмф, хотя открыта карта в мап, это плохо
- нужно убрать управление движением брашей на крестик в 2д виде, всё-таки он в хаммере для навигации использован, а тут неудобно получается, если что-то где-то вдалеке выделено, то оно двигается, а ты этого и не видешь. Использовать ползунки либо постоянно убирать выделение - это ужасно
- как насчёт рендера неба как в игре?
Добавлено 15-05-2015 в 22:25:
Джек зачем-то испоганил текстурные координаты. До:
Yo Den писал: модели в циклер спрайтах не прорисовываются, с монстр генерик всё ок
Правильно. В циклер-спрайтах прорисовываются спрайты.
Цитата:
Yo Den писал: в энтити репорт было бы хорошо добавить путь к моделям и спрайтам от энтить типа циклер спрайта, чтобы можно было легко найти нужное
Оно и так предельно легко - вбиваешь key = "model" и value фрагмент нужного названия, и список обновляется.
Цитата:
Yo Den писал: кнопка Сейв на панели предлагает сохранить в жмф, хотя открыта карта в мап, это плохо
Это прекрасно. Формат МАР предназначен для экспорта карты компилятору, а хранить исходник следует в JMF. Об этом подробно написано в FAQ.
Цитата:
Yo Den писал: нужно убрать управление движением брашей на крестик в 2д виде
Ничего не понял. Какой крестик? Какое управление дорожным движением?
Цитата:
Yo Den писал: как насчёт рендера неба как в игре?
Это не нужно.
Добавлено 16-05-2015 в 11:47:
Цитата:
Yo Den писал: Джек зачем-то испоганил текстурные координаты.
Ну раз испоганил - значит, так нужно было. Так работает алгоритм. Более подробно откомментировать не могу, т.к. ты не сообщил никакой информации, а скриншут мне ни о чём не говорит.
Странность в том, что UV-lock участвует в поворотах брашей, а должен работать только для морфинга
26-04-2015 10:51
Вложение: 
