Raid
Фишка может быть в том, что хаммер игнорирует дефолтовые значения флагов, а джек - учитывает и ставит галочки согласно тому, что прописано в фгд. И вот такой побочный эффект.
Попробовал проделать ровно такое в radiant1.4/1.6/1.5/netradiant - не сбивается
В 1.4/1.6 только уезжает позиция после четырёх последовательных поворотов по 90 градусов, но с сеткой порядок
Левый вопрос: отличается ли mapformat 220 по возможностям текстуринга от brush primitives (проекция по нормали к фейсу, shift, scale, rotation)?
Я пытаюсь понять, доступны ли в мап220 алигны, принципиально невозможные в других форматах, или преимущество заключается в простоте расчётов
Пока не смог придумать алигн, невозможный даже в убогом axial projection
Garux писал: доступны ли в мап220 алигны, принципиально невозможные в других форматах
Разумеется.
Цитата:
Garux писал: Пока не смог придумать алигн, невозможный даже в убогом axial projection
Это же просто. Любой align, где текстурный базис неортогональный.
Например:
Беда всех этих глупых браш-примитивов в том, что они не родные компилятору. Компилятор работает с текстурными векторами. В формате 220 они хранятся в чистом виде, в остальных форматах их нужно сначала посчитать. Вопрос - зачем, если можно хранить? Вопрос риторический, на самом деле.
Путём экспериментов выяснил, что brush primitives из радиантов тоже имеет текстурные оси!
Только записан компактнее, типа ( scaleS*sx scaleS*sy offsetS ) ( scaleT*tx scaleT*ty offsetT )
Повторил алигн из напримера:
...задав оси вручную в мапнике
В surface inspector этот формат на редкость криво привинчен, он попросту ломает такой текстуринг
Зато texture lock чётенько работает, ничего не дёргается
Garux писал: В surface inspector этот формат на редкость криво привинчен, он попросту ломает такой текстуринг
Ну вот. А в хаммере, хоть такой фичи и нет, ничего не ломается. Более того, с помощью определённых извратов можно так затекстурить и в самом хаммере (используя строго высчитанное положение камеры + Align to view, мне попадалась статья на эту тему).
Цитата:
Garux писал: Зато texture lock чётенько работает, ничего не дёргается
А какая связь чёткой работы texture lock и способа хранения текстурных осей?
Добавлено 26-04-2015 в 00:39:
Цитата:
Garux писал: Повторил алигн из напримера:
Любопытно. Как ты смог задать раздельные неортогональные текстурные оси, применяя матричную трансформацию к ортогональным?
Или в новых радиантах какой-то другой браш-примитив, не тот, что в Q3Radiant (и поддержка которого есть в джеке, разумеется, только импорта)?
XaeroX писал: А какая связь чёткой работы texture lock и способа хранения текстурных осей?
Это к тому, что хоть что-то работает
Хотя там две оси относительно нормали к фейсу, а не три относительно мира - может и есть связь, т.к. меньше пересчётов при поворотах
Цитата:
XaeroX писал: Любопытно. Как ты смог задать раздельные неортогональные текстурные оси, применяя матричную трансформацию к ортогональным?
Или в новых радиантах какой-то другой браш-примитив, не тот, что в Q3Radiant (и поддержка которого есть в джеке, разумеется, только импорта)?
Похоже неортогональные там оси
Проверил, в Q3Radiant202 такой же brush primitives
Достаточно задать разные скейлы по s и t и поменять rotaion, чтобы это заметить
Выходит, что можно экспортировать из джека в понятный радиантам формат без потери текстуринга; полезно, когда с одной картой работают несколько человек
Вертел браш тудой-сюдой, поймал баг:
Потолок от стандартной коробки, texture fit 1:1, поворот в положение с диагональю слегка не на оси
Ещё пропущена сущность _decal, compiler-side деколь
Это не совсем баг. Дело в том, что UV-lock надо отключать при первой же возможности, когда он не нужен. С ним оси пересчитываются при каждой трансформации и, конечно же, рано или поздно заглючат.
Цитата:
Garux писал: Выходит, что можно экспортировать из джека в понятный радиантам формат без потери текстуринга; полезно, когда с одной картой работают несколько человек
Наверное, можно, если кто-то пояснит мне:
Цитата:
XaeroX писал: как ... задать раздельные неортогональные текстурные оси, применяя матричную трансформацию к ортогональным
Либо объяснит, почему я неправильно понимаю суть браш-примитивов (а это не исключено ).
Насколько я разобрался, там сначала строятся таки ортогональные оси путём проецирования на плоскость фейса. А потом матрицей из браш-примитива доводятся до нужного положения. Или нет? Тогда хотелось бы, чтобы кто-нибудь прокомментировал код расчёта осей из браш-примитивов.
Цитата:
Garux писал: с одной картой работают несколько человек
Дело хозяйское, но кейс вполне конкретный и ловится без прелюдий, так сказать из коробки: new box map, texture fit 1:1, поворот:левая вершина чуть выше правой, поворот:левая вершина чуть ниже правой
Слетают shift и scale по Y
И вот ещё что показалось странным: rotation обнуляется после любых поворотов с UV-lock
Ну, собственно, и баг без него не ловится
Цитата:
XaeroX писал: Насколько я разобрался, там сначала строятся таки ортогональные оси путём проецирования на плоскость фейса.
Надеюсь, мы хотя бы об одном говорим, потому что так происходит с дефолтным в радиантах форматом (axial projection)
А brush primitives включается опцией и явно имеет текстурные оси
Garux писал: И вот ещё что показалось странным: rotation обнуляется после любых поворотов с UV-lock
Ничего странного тут нет. Rotation - это число, которое показывается в редакторе, и более ничего. Компилятор его не использует.
Цитата:
Garux писал: А brush primitives включается опцией и явно имеет текстурные оси
Ну вот а я их там не вижу.
Цитата:
Garux писал: Шутка хорошая, смешной ответ не найден
Это не шутка. Кому нужны фичи джека - перешли на джек. Кому нужны фичи радиантов - давно от меня отстали и забыли про существование джека как страшный сон.
17-04-2015 15:51
