В новом ксаше нету 3д-скаев. Я пока не трогал этот вопрос. Но технически сложностей нету.
Добавлено 15-12-2020 в 10:35:
Вообщем я дропнул эти эксперименты с микрософтовским параметризатором. Ужасно мутный и тошнотворный код, никогда еще такого не видел. Обычно я в любом незнакомом коде спустя час изучения уже могу выделить ключевые моменты и понять принцип работы. Здесь это сделать невозможно, потому что на каждой стадии алгоритм проваливается дальше и дальше и даже когда он завершил работу нельзя сказать, что там на выходе уже какой-то корректный результат, потом еще идут пост-процессы, мержинг и замазывание, то есть понять, что даёт наибольший вклад решительно невозможно. Это видимо современный стиль программирования. Может быть оно там на всех этапах выглядит как дерьмо, но в конце эти кусочки объединяются, сглаживаются и конечный результат уже на что-то похож. Но там нет главного алгоритма. Там нельзя сказать, что 90% параметризации осуществляется через какую-то функцию, а некоторые специальные случаи - отдельно. Нихрена подобного. Там минимум пять или шесть вариантов и на каждом этапе оценивается качество построения. Плюс для геодезической изомапы надо рассчитать vertex importance и они не придумали ничего умнее, как сделать это через построение progessive mesh, что само по себе довольно тяжелая операция, но самое интересное - это учесть, что чаще всего в атлас попадают вообще какие-то незамкнутые конструкции с одной границей, для которой считать PM на мой взгляд вообще бессмысленно. Но предполагается что для таких кусочков параметризация будет выполнена типа раньше - на этапе планарной параметризации. Самое смешное, что изомапа тоже может сфейлить и следующий этап - барицентрическая параметризация, но перед этим будет проверка на цилиндр. Я опробовал барицентрическую отдельно - ну это просто несеръезно. Не зря её в Thekla Atlas дропнули.
Кстати LSCM они там сразу выключили по умолчанию. Видимо он не оправдал надежд даже по их меркам.
Я всё больше склоняюсь к тому, что надо просто создавать атлас из текстурных координат. Это самый простой и надёжный путь. Причём с тем подходом, который использую я, не имеет даже значения тот факт, что текстура может быть наложена с повторами. Потому что тексели конвертируются в мировые юниты, а потом ремапятся к реальному размеру атласа. Этот же механизм позволяет заранее кэшировать меши без реальной привязки к сэмпл-сайзу. То есть, когда в материале он меняется, меш не надо пересчитывать заново. Ну и самый важный момент - юзер контролирует качество лайтмапы при таком подходе. Очевидно, если шов на текстуре, то шов на лайтмапе заметить уже невозможно.
Добавлено 15-12-2020 в 10:38:
И кстати. Я в своё время был очень удивлён насколько пользователи готовы самостоятельно всё исправлять и улучшать, не полагаясь на движок. Они просили лишь вменяемые инструменты контроля, чтобы не пришлось это делать через хитрозакрученную задницу.
Добавлено 15-12-2020 в 13:16:
Ну да ладно. Пора возвращаться к основной задаче, из-за которой я не могу двигаться дальше - сделать поддержку MU-моделей. В Волатиле её кстати нет, из-за чего невозможно сделать ТЛез32. В Сталкере, как мы пару дней назад выяснили в соответствующей теме MU-модели могут освещаться только повертексно. Шареная геометрия + массивы цвета. Я понятия не имею как они при рендеринге объединяются, никогда с подобной задачей просто не сталкивался. И если честно, не хочу и пробывать. Я хочу сохранить цвета вертексов в лайтмапу, а брать их через VTF. Надеюсь, что он у всех потдерживается, начиная с GF6600. Потому что я точно помню, что смотрел его демки именно на этой карточке. Плюсов много - структура повертексного располагает теми же данными, что и попиксельное (т.к. на вертекс обычно приходится меньше данных, чтобы он сам не распух), здесь это неактуально. Не надо городить какие-то дополнительные массивы опять же. Из минусов боюсь только, что VTF будет недостаточно быстрым. Ну это я проверю. Так же предстоит понять, как именно модельки должны превращаться в MU. Не то по запросу юзера, не то автоматически.
Но тут вот какое соображение. В сталкере это автоматически провоцировало повертексное освещение, т.е. экономя на переиспользовании мы лишались лайтмапы. У меня этого не будет, поэтому я думаю, можно сделать автоматически, подсчётом референсов. Если референсов больше одного - это MU.
В лайтмаппере трассу придётся перестроить с учётом новых реалий. Это уже будет сложносоставная трасса из AABB и локальных Kd-tree. Но кстати она должна напорядок быстрее строиться и занимать гораздо меньшы места. А вот удержится ли её производительность на уровне чистого KD-tree тут уж хз. Будем надеяться, что да.
Ну и в шейдер придётся пропустить параметр смещения в лайтмапе от референса (для всей модели или для визгруппы). Опять жы интересный вопрос, как набивать цвета вертексов в лайтмапу. Если линией, то явно не хватит её длины. Значит где-то надо будет сделать перенос. Ну или скажем извлечь корень из числа вертексов и это будет стороной квадрата с люкселями для вертексов. Что-то такое. Впрочем повертексного у меня пока что нету.
Добавлено 15-12-2020 в 13:31:
Любая реализация начинается с концепции. Я бы мог принять за концепцию, что любая MU-модель доступна только для мира, а для саб-моделей они дублируются, но это не слишком прозрачно.
Эти модельки по идее должны глобально шариться между любыми энтитями.
Это будет более разумный подход. К тому же их можно отпроцессить заранее, еще до того, как будет построено дерево для мира.
Дядя Миша писал: Ужасно мутный и тошнотворный код, никогда еще такого не видел. Обычно я в любом незнакомом коде спустя час изучения уже могу выделить ключевые моменты и понять принцип работы. Здесь это сделать невозможно, потому что на каждой стадии алгоритм проваливается дальше и дальше и даже когда он завершил работу нельзя сказать, что там на выходе уже какой-то корректный результат, потом еще идут пост-процессы, мержинг и замазывание, то есть понять, что даёт наибольший вклад решительно невозможно. Это видимо современный стиль программирования. Может быть оно там на всех этапах выглядит как дерьмо, но в конце эти кусочки объединяются, сглаживаются и конечный результат уже на что-то похож. Но там нет главного алгоритма. Там нельзя сказать, что 90% параметризации осуществляется через какую-то функцию, а некоторые специальные случаи - отдельно. Нихрена подобного. Там минимум пять или шесть вариантов и на каждом этапе оценивается качество построения.
Современный стиль? Но ты же говоришь это в 2002-2003 году писалось? Какая же это современность?
А вот на что похоже-так это на то как работают нейросети.
Цитата:
Дядя Миша писал: Я в своё время был очень удивлён насколько пользователи готовы самостоятельно всё исправлять и улучшать, не полагаясь на движок. Они просили лишь вменяемые инструменты контроля, чтобы не пришлось это делать через хитрозакрученную задницу.
Ты только смотри, что это были за пользователи. Если это было то поколение которое потом первую Паранойю сделало, то данное наблюдение уже устарело.
Я тут озаботился важнейшим вопросом - решил узнать сколько же деревьев в настоящем лесу. И вот данные колеблются от 600 до 4000 на гектар.
А минимальный - полгектара, т.е. 50х50 метров, но это несеръезно конечно.
Возмьмем нормальный лес, ну скажем 100 квадратных километров, это десять тысяч гектар. Таким образом в подобном лесу может расти 40 миллионов деревьев. Вот это настоящий ТЛез32.
Внедрил поддержку MU-моделей на две трети. А почему на две - в компилятор, в движок, осталось в лайтмаппер сделать. Вес карт очень резко упал. Теперь он не превышает 90 мегабайт даже на картах из LostAlpha.
Причём судя по всему он даже меньше чем оригинальная геометрия (но правда у меня пока еще нет лодов). Скажем la23_oldroad с копированием геометрии весила 550 мегабайт , а с MU-моделями - всего 78 мегабайт.
Удивительно как маленькие модельки, вставленные на карту много раз так сильно раздувают конечный размер. Бонусом упало потребление памяти для компиляции. Раньше оно могло достигать почти двух гигабайт, т.е. впритык, теперь - непревышает 400-500 мегабайт, что даже меньше чем у p2st.
Правда FPS всё же сильно падает, если смотреть из одного края карты на другой. Так что нужны лоды. А потом - писать конвертор уровней из метро эксодус. И вот ежели новый ксаш прожует тамошние карты, можно сказать, что всё удалось.
Дядя Миша слушай, ты проверь сам, конечно, но похоже, что считать TBN в шейдере - это дохлый номер. Тангенты получаются граненые, и ничего с этим не сделать. Ортогонализация помогает не сильно.
Очень непростая это штука - лайтмапы для инстанс-моделей.
Во первых рассчитать динмически размер страницы - почти нерешаемая задача, поскольку размер блока для инстанса может превысить размер подсчитаной страницы для статичной геометрии. Обычно это вылезает на картах-коробках, но теоретически может везде вылезти.
Второй момент - лайтмапа не скейлится в зависимости от размеров объекта, она всегда единичного размера. Это можно поправить введя индивидуальный скейл для координат лайтмапы, но я чот слабо себе представляю, можно ли эти координаты прямо вот так вот скейлить, как бы они просто не уехали нахрен. К тому же как спроецировать трёхмерный скейл на двухмерный тоже непонятно. Ну можно взять какое-то среднее число конечно.
Добавлено 19-12-2020 в 14:39:
А и да, самое мерзопакостное. Разбиение KD-tree на локальные суб-деревья роняет производительность трассы как минимум вдвое.
То есть я эти дерева сую в AABB-три и уже по нему передвигаюсь.
на первый взгляд это могло бы наоборот ускорить дело, но не всё так просто.
Мы должны проверить каждое такое локальное субдерево на предмет того, что трасса в него упёрлась. Мы не можем попасть в первое и остановиться. Да и если честно, это не сильно влияет на производительность.
К тому же результаты освещения для единой модели и для инстансов у меня отличаются. Не сильно, но кое-где вылезают косячки. У меня есть одна идея, как обратно эти инстансы налету построить в единое дерево, получится компромисс между потреблением памяти и скоростью работы.
Ну чтож, сработал мой хитрый план, построил единое дерево для всех инстансов, потребление памяти всё равно меньше, чем при старом подходе, поскольку вертексы не дублируются. Правда в фейс пришлось сохранить их позиции, чтобы не трансформировать при каждом обращении, без этого построение дерева по времени вырастало вдвое. Размер фейса был 64 байта + 36 байт на позиции = 100. Но изначально, неоптимизированный размер фейса в предидущей итерации был вообще 114 байт, так что можно сказать - да, действительно удалось сэкономить. Ну а размер вертексного буффера так и остался маленьким за счёт инстансов. У некоторых карт к примеру из-за дубликатов вес достигал 550 мегабайт, в оптимизированной версии 70-90 мегабайт. Т.е. как минимум здесь потребление упало в несколько раз. Из плюсов - удалось сохранить время постройки дерева на прежнем уровне, а время рассчёта освещения, помоему даже сократилось процентов на 15, но я хз почему, подозреваю, что там что-то неправильно считается. Ну это потом уже разберусь. Главное что оптимальный подход найден. Второй любопытный момент относится к скейлу лайтмапы в зависимости от скейла конечного меша. Если координаты были построены текстурных, то они естественно сохранены в .CSM-модельку и для таких кэшированных мешей скейл геометрии на карте не влияет на разрешение лайтмапы. Ни для дублирования, ни для инстансов. Так что можно сказать, в этом плане отличий не будет.
Скачал сорцы UE4 на предмет изучения. Там lightmass тоже юзает KD-tree. Видимо это самый оптимальный вариант, другие деревья заведомо медленее.
Опробывал переупаковщик атласов из UE4. Полное разочарование.
В документации зато как красиво. Вообщем первое что становится понятно из кода - эта штука не дружит с отраженными развертками. Она их видит, но сделать не может ничего. Объединяет обратно тоже из рук вон плохо, поскольку разъединение как раз и происходит на зеркальной развертке.
Ну нет худа без добра, из уешной реализации я вынес для себя две очень важных вещи. Во первых - механизм трансляции мирового скейла в текстурный, что нужно для придания правильной пропорции. На самом деле, где бы я еще нашёл эту формулу, подобные вещи не валяются на каждом углу. Сама формула довольно несложная, но я лично хрен бы догадался.
edge1, edge2 - это рёбра в трёхмерном пространстве, а edgeUV - в текстурном. UVLength - это worldScale. Потом еще надо поделить сумму worldScale на UvScale, которая сумма текстурного пространства.
Ну а второй момент - как правильно задетектировать отраженную развертку, причём идея настолько тривиальная, что я очень удивился почему мне эта мысль в голову не пришла. Мы просто умножаем signed UV area на аналогичную у соседнего треугольника и смотрим знак. Если обе негативные - будет положительный, если обе позитивные тоже. А если встретилась позитивная и негативная площади, ну значит здесь шов от зеркалки. Элементарно.
Я почти управился с развертками, буду использовать комбинированный подход. В большинстве случаев это будет подготовленная развертка из текстурных координат как в UE. А для планарных поверхностей - трипланарная проекция. Надо только определиться какие треугольники лучше параметризовать через текстурные координаты, а какие через проекцию. Трипланарка сфейлить не может, но надо оценить оптимальность результатов, завязанную на множество параметров, на качество освещения, наличия швов и общий размер атласа.
К тому жы у меня на освещении лезут какие-то подозрительные белые точки в некоторых местах, главное раньше их не было вроде.
Когда с этим управлюсь, останется только прикрутить прогрессивные мешы и радиосити. Ну и полностью всё отладить и взапроверить.
Добавлено 22-12-2020 в 11:19:
Слева направо:
1. без рендеринга ребёр
2. ребра рендрятся, используя нормаль треугольника ( как в сталкере )
3. ребра пытаются получить сглаженную нормаль, а если нет, то используют нормаль треугольника
4. ребра используют только сглаженную нормаль, полученную через барицентрические координаты UV-лайтмапы
5. ребра используют только сглаженную нормаль, полученную через барицентрические координаты мировой позиции (в P2 аналогично)
Различия в освещении между полной геометрией (когда каждая моделька вставляется по месту) и инстансами (когда хранится один эталонный набор).
Как видите есть небольшая разница. Черт его знает почему так. Ну тени еще ладно, а вот то, что мелкие кусты немного по разному осветились, это я вообще хз. Я не могу это забороть. Наверное потеря точности при трансформации. Может быть этих различий не будет если увеличить разрешение лайтмапы.
| IP: 
15-12-2020 10:31
, а с MU-моделями - всего 78 мегабайт.
