HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Jackhammer (https://hlfx.ru/forum/forumdisplay.php?forumid=35)
-- Багрепорты (https://hlfx.ru/forum/showthread.php?threadid=4450)
Отправлено Garux 26-04-2015 в 10:51:
Цитата:
XaeroX писал:
Ничего странного тут нет. Rotation - это число, которое показывается в редакторе, и более ничего.
Занятная концепция
Странность в том, что UV-lock участвует в поворотах брашей, а должен работать только для морфинга
Очевидно, это и есть сбойное место
Цитата:
XaeroX писал:
Насколько я разобрался, там сначала строятся таки ортогональные оси путём проецирования на плоскость фейса. А потом матрицей из браш-примитива доводятся до нужного положения.
Тоже попробовал разобраться, похоже так и есть
Код из компилятора
C++ Source Code:
1 | /* brush primitive texturing */ |
4 | /* calculate texture s/t from brush primitive texture matrix */ |
5 | x = DotProduct( vTranslated, texX ); |
6 | y = DotProduct( vTranslated, texY ); |
7 | dv->st[ 0 ] = s->texMat[ 0 ][ 0 ] * x + s->texMat[ 0 ][ 1 ] * y + s->texMat[ 0 ][ 2 ]; |
8 | dv->st[ 1 ] = s->texMat[ 1 ][ 0 ] * x + s->texMat[ 1 ][ 1 ] * y + s->texMat[ 1 ][ 2 ]; |
На моём уровне понимания выглядит вполне раздельно
Отправлено XaeroX 26-04-2015 в 11:07:
Garux
Ну так откуда texX и texY берутся? Это ж и есть сами оси.
Добавлено 26-04-2015 в 17:06:
Цитата:
Garux писал:
Странность в том, что UV-lock участвует в поворотах брашей, а должен работать только для морфинга
Наоборот, предпочтительно пользоваться им только в режиме shear (третий режим выделения). Но в принципе он работает в любом режиме, однако т.к. "запирание" координат может привести к тому, что оси принципиально окажутся невосстановимыми (иными словами, текстурные координаты не будут корнями одной и той же системы линейных уравнений, как должно быть с осями), то лучше этот режим использовать как можно реже, когда точно известно, что и где нужно получить.
Добавлено 26-04-2015 в 17:07:
Цитата:
Garux писал:
Занятная концепция
С введением формата 220 оно и в хаммере так.
По сути вращение выполняется не на заданный угол, а на разницу между предыдущим и текущим углом. Т.е. число там может быть любое, обрабатывается только приращение.__________________
Отправлено Garux 26-04-2015 в 11:44:
Цитата:
XaeroX писал:
Ну так откуда texX и texY берутся? Это ж и есть сами оси.
Оси в компиляторе берутся из ComputeAxisBase( vec3_t normal, vec3_t texX, vec3_t texY ), что похоже на таки проекцию ортогональных осей на фейс
Не совсем понимаю техзадание. Надобно отклонить оси, исходя из матрицы? Пересчитать их относительно мира?
Просто, если б я был такой умный, то, пожалуй бы, уже сочинил свой black jack с автокалком и локами
Цитата:
XaeroX писал:
предпочтительно пользоваться им только в режиме shear (третий режим выделения). Но в принципе он работает в любом режиме
Так для поворотов брашей UV-lock ничего полезного не делает, только баг вызывает
Отключить в коде его для поворотов, делов-то
Отправлено XaeroX 26-04-2015 в 11:55:
Цитата:
Garux писал:
Не совсем понимаю техзадание.
ТЗ: объяснить мне, как получаются неортогональные оси в браш-примитивах.
ComputeAxisBase создаёт ортогональные, и я не понимаю, как матричная трансформация этих дотов позволяет добиться эффекта, как на гифке.
Я не очень силён в математиках, ибо по образованию биолог, а иначе уже сочинил бы свой унреал-5 с собственным удк.
Цитата:
Garux писал:
Отключить в коде его для поворотов, делов-то
Кабы всё было так просто.
Архитектура редактора такова, что фейс не знает, поворачивали его или что другое похабное сотворяли. Ему просто матрицу дают, и всё. А матрица совсем в другом месте считается (в коде селекшен-тула).__________________
Отправлено Garux 27-04-2015 в 08:08:
Хорошо, попытка - не пытка
Цитата:
x = DotProduct( vTranslated, texX );
Это дистанция плоскости с нормалью texX и содержащей точку vTranslated
Другими словами размер проекции вектора точки на вектор одной из ортогональных осей
Цитата:
y = DotProduct( vTranslated, texY );
другой
Значит раскидали точку по осям
Цитата:
dv->st[ 0 ] = s->texMat[ 0 ][ 0 ] * x + s->texMat[ 0 ][ 1 ] * y + s->texMat[ 0 ][ 2 ];
dv->st[ 1 ] = s->texMat[ 1 ][ 0 ] * x + s->texMat[ 1 ][ 1 ] * y + s->texMat[ 1 ][ 2 ];
Тут смотрим, будет ли 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 тоже так делает
Отправлено XaeroX 27-04-2015 в 09:55:
Ага, теперь понятно, спасибо.
Как-то я не сообразил, что матрица применяется не к осям, а к проекциям, а там понятия ортогональности уже нет. Значит, теоретически действительно можно экспортировать текстурирование джека в формат браш-примитивов.
Другой вопрос, зачем вообще их придумали? В чистом ку3 оси нужны, чтобы грамотно присовокупить к фейсу лайтмапу. Если использовать неискажённые оси - лайтмапа будет не прямоугольником, а параллелограммом, и жрать ненужное пространство. Далее, оси нужны для касательного пр-ва для бамп-маппинга, что умеет считать ку3мап2. То есть, по сути, нам всё равно придётся восстанавливать искажённые оси в компиляторе. Ну почему же их сразу не писать в мап-формат, слегка доработав именно компилятор? Это же намного проще и логичнее, чем докручивать новый экспорт-формат джеку, где придётся решать хитрые уравнения для вычисления этой текстурной матрицы?
__________________
Отправлено Garux 27-04-2015 в 13:18:
Ума не приложу, из каких корыстных соображений был выбран такой формат текстурирования
Посмотрел на формат карт Doom3 - там плоскости фейсов заданы, как нормаль + дистанция, а текстуринг через такую же матрицу
Что до уравнений - можно взять готовое решение отсюда:
https://gitlab.com/xonotic/netradia...2/convert_map.c
функция ConvertBrush
Отправлено XaeroX 27-04-2015 в 13:22:
Этот код заражён GPL-вирусом. 
Ну не важно, принцип понятен.
Вопрос - а кому именно-то нужен экспорт в формат браш-примитивов? Я не знаю ни одного пользователя джека, работающего с ку3, а компиляторы ку1/ку2/хл1 всё равно брашпримитивы не понимают.
__________________
Отправлено Garux 27-04-2015 в 14:25:
Цитата:
XaeroX писал:
Я не знаю ни одного пользователя джека, работающего с ку3
И я
Поддержка q3 в джеке это потенциальные пользователи из всех игр, поддерживаемых q3map2, так что проблема с форматами наверняка всплывёт, например:
новичёк: посмотрите карту плз, что я не так делаю?
неновичёк: ой нет, для этого джек надо ставить, фу, фу
Также есть порядочное количество форков q3map2 с разным функционалом и сетами багов. Добавлять поддержку формата hl в каждый - таки много работы, даже при наличии инструкции
Попробовал импорт кубика с brush primitives:
Отправлено XaeroX 27-04-2015 в 14:45:
Цитата:
Garux писал:
новичёк: посмотрите карту плз, что я не так делаю?
неновичёк: ой нет, для этого джек надо ставить, фу, фу
новичёк: ставь, ставь, там есть бесшовный текстуринг, wysiwyg-редактирование шейдеров и много всяких славных плюх, радиант отныне не нужен.
Не, ну как говорится, редактор - дело вкуса. Радианты меня бесят, притом что редактор под мой движок был таки радиант (на тот момент джека не было). Ну бесят, и всё. Там всё как-то не так, по сравнению с хаммером.
Цитата:
Garux писал:
Попробовал импорт кубика с brush primitives
Я толком и не тестировал эти примитивы. Ну никто из моих знакомых ими не пользуется даже под ку3, что поделаешь. Кинь, плиз, мап с этим кубиком, я гляну.__________________
Отправлено Garux 27-04-2015 в 17:12:
Положение кубика погоды не делает, с фейсом на осях и дефолтным алигном тот же результат
Отправлено thambs 08-05-2015 в 00:08:
*bug*bug*bug*
path-tool, крупная сетка, выделяем несколько вершин, используем перемещение. все вершины привязались к сетке, даже если были не её.
__________________
http://www.moddb.com/mods/monorail-quest
Отправлено JPEG 15-05-2015 в 19:25:
- модели в циклер спрайтах не прорисовываются, с монстр генерик всё ок
- мелочь: при открытом окне Объект пропортиес, нажимаешь закрыть карту и табличка с вопросом сохранения находится за Объект проп.
- тот же глюк, что и в хаммере: большие модели, типа 3д-скайбоксов начинают прорисовываться только под определённым углом и расстоянием от центра модели
- в энтити репорт было бы хорошо добавить путь к моделям и спрайтам от энтить типа циклер спрайта, чтобы можно было легко найти нужное
- кнопка Сейв на панели предлагает сохранить в жмф, хотя открыта карта в мап, это плохо
- нужно убрать управление движением брашей на крестик в 2д виде, всё-таки он в хаммере для навигации использован, а тут неудобно получается, если что-то где-то вдалеке выделено, то оно двигается, а ты этого и не видешь. Использовать ползунки либо постоянно убирать выделение - это ужасно
- как насчёт рендера неба как в игре?
Добавлено 15-05-2015 в 22:25:
Джек зачем-то испоганил текстурные координаты. До:
__________________
МОЙ НОВЫЙ ПАБЛИК ПО ХЛ))
Отправлено JPEG 15-05-2015 в 19:25:
после
__________________
МОЙ НОВЫЙ ПАБЛИК ПО ХЛ))
Отправлено XaeroX 16-05-2015 в 05:47:
Цитата:
Yo Den писал:
модели в циклер спрайтах не прорисовываются, с монстр генерик всё ок
Правильно. В циклер-спрайтах прорисовываются спрайты.
Цитата:
Yo Den писал:
в энтити репорт было бы хорошо добавить путь к моделям и спрайтам от энтить типа циклер спрайта, чтобы можно было легко найти нужное
Оно и так предельно легко - вбиваешь key = "model" и value фрагмент нужного названия, и список обновляется.
Цитата:
Yo Den писал:
кнопка Сейв на панели предлагает сохранить в жмф, хотя открыта карта в мап, это плохо
Это прекрасно. Формат МАР предназначен для экспорта карты компилятору, а хранить исходник следует в JMF. Об этом подробно написано в FAQ.
Цитата:
Yo Den писал:
нужно убрать управление движением брашей на крестик в 2д виде
Ничего не понял. Какой крестик? Какое управление дорожным движением?
Цитата:
Yo Den писал:
как насчёт рендера неба как в игре?
Это не нужно.
Добавлено 16-05-2015 в 11:47:
Цитата:
Yo Den писал:
Джек зачем-то испоганил текстурные координаты.
Ну раз испоганил - значит, так нужно было. Так работает алгоритм. Более подробно откомментировать не могу, т.к. ты не сообщил никакой информации, а скриншут мне ни о чём не говорит.__________________
