Чёт не пойму в чём вопрос. Выделяются кусочки-островки, на которые можно наложить лайтмапу в 2Д без особенных искажений, если островок больше размера страницы, то он делится пополам примерно.
А потом обычный рассчёт лайтмапы, считаем свет, пускаем луч для тени.
Добавлено 26-01-2021 в 12:21:
А ну и самое любопытное, если речь идёт именно про MU. В конце все люксели лайтмапы через систему линейных уравнений превращаются в один люксель. Он-то и освещает модель.
В Сталкере калечная трасса, раз в 20 медленней той, что использую я.
Отсюда и растёт половина проблем. Я как-то народ призывал к диалогу, но никто не откликнулся, и я снёс ту тему. Ну не надо, так не надо.
Да и лайтмапы считают на GPU давным-давно, вон наш Психопат написал такой осветитель, можешь у него поинтерисоваться за подводные камни и так далее.
И кстати насчёт динамики. Индирект считается для 80-150 солнц, равномерно расположенных по полусфере, а динамика считает только прямой свет. Если бы не этот индирект, даже на калечной сталкеровской трассе, скорость бы возросла кратно. Причём динамика ведь этот индирект тоже юзает, иначе была бы чернота как в дуум3.
Дальше там вообще жесть начинается
Цитата:
Подозреваю однопоточность и отсутствие BVH.
Там мультипоток и естественно BVH. Но цымес в том, что BVH дико медленный, там надо юзать k-DOP. Там даже по коду видно какой он медленный, там полная рекурсия.
Цитата:
В шадоумаппинге самый обыкновенный рейтрейсинг
Шадовмаппинг - это не рейтрейсинг в прямом понимании. Хотя смысл тот же.
А кто такой Абрам Куммер я не знаю. Дело не в точности, говорю же.
Дело в том, что индирект от солнца в реалтайме всё равно не рассчитать так, как это делалось всегда. Ну не вытянет ни одна видеокарта 150 солнц одновременно, даже GTX3080. Про рейтрейсинг щас не говорим, там и не нужно их столько рендерить.
Цитата:
Я давно здесь на форуме читал, что создаётся сфера для hemi. Прям геометрия.
Да какая нахрен геометрия? В нулевую точку спавнится 150 точечных лайтов и всё. У каждой нормаль равномерно распределена по полусфере.
Дядя Миша писал: Вот еще какую чертовщину я заметил. Но понять в чём тут дело не могу.
Начнём с того, что в сталкере целых три типа кодирования текстурных координат. Первый тип - обычные флоаты, безо всяких хитростей.
Второй тип - шорты, умноженные на (32768/32) и третий тип - шорты, умноженные на (32768/16).
Первый вид координат используется для ландшафта, второй для статик-моделей с лайтмапой, третий - для MU-моделей.
То что это именно так можно узнать из исходников компилятора. Но вот какая петрушка. Во первых, сам сталкер эти координаты не декодирует.
Он их сразу в видеопамять грузит. А там в шейдере, получается они сразу валидные. Ни на что не предумножаются. Получается их драйвер как-то сам раскручивает обратно. Я сам умножаю на обратные множители и в 99% это работает хорошо. Но есть исключения. В рыжем лесу поехала развертка у двух бтров в тоннели. Причём поехала так, как будто бы её вообще не было.
И на testers_mp_factory у всех электромоторов точно так же съехала развертка. Я попытался покрутить саму текстуру на 90 градусов, несколько раз, но это ни к чему не привело. Чертовщина какая-то.
Эта чертовщина разрешилась ВНЕЗАПНО и я долго смеялся. В процессе тестирования я слишком увлёкся и накопировал в одну папку карт из обычного сталкера, чистого неба, зова припяти и лост альфы. В итоге там какие-то текстуры из другой игры перезаписались первыми с тем же именем. А в тех текстурах развертка по другому нарисована, да и картинка отличается. Ну вот оно всё и съехало нахрен!
Добавлено 08-07-2021 в 15:42:
Цитата:
ncuxonaT писал: Я тут посмотрел презентации фростбайта, как запекают лайтмапы. Они делают лоуполи прокси меши и считают освещение для них, а потом переносят развертку под лайтмапу с лоуполи на хайполи.
Вот сейчас как следует вдумался в смысл этой фразы и остался в недоумении.
Какая разница для какой геометрии запекать лайтмапы, если её качество целиком и полностью зависит только от разрешения самой лайтмапы.
Будь у меня хоть ландшафт на 10 миллионов поликов, но если лайтмапа на нём 16х16 люкселей, то её рассчёт всегда будет менее секунды.
Другой вопрос что на лоу-поли вероятно быстрее пускать лучи, но и гораздо менее точно. Не полезли бы лайт-лики от такой оптимизации.
Добавлено 08-07-2021 в 15:45:
Цитата:
Дядя Миша писал: В Сталкере калечная трасса, раз в 20 медленней той, что использую я.
Отсюда и растёт половина проблем. Я как-то народ призывал к диалогу, но никто не откликнулся, и я снёс ту тему. Ну не надо, так не надо.
Небольшие поправки внесу. Не в 20 раз медленнее. Без SSE медленнее всего-навсего в 3 раза, с SSE медленнее процентов на 30. Зато BVH очень быстро строится, а построение KD-Tree может занимать до 10 минут, так что сталкеровская трасса оказывается медленее всего процентов на 20 по итогу.
Но медленее, да. Но лайтмапы считаются неделями совсем по другой причине. Всё дело в идиотском двухмерном хэше, который с какого-то момента чудовищно замедляет процесс поиска люкселя на сетке. Я вместо этого использую локальное AABB-Tree и это очень быстро. Хэш там вообще ни к месту.
Дядя Миша писал: Вот сейчас как следует вдумался в смысл этой фразы и остался в недоумении.
Какая разница для какой геометрии запекать лайтмапы, если её качество целиком и полностью зависит только от разрешения самой лайтмапы.
Будь у меня хоть ландшафт на 10 миллионов поликов, но если лайтмапа на нём 16х16 люкселей, то её рассчёт всегда будет менее секунды.
Другой вопрос что на лоу-поли вероятно быстрее пускать лучи, но и гораздо менее точно. Не полезли бы лайт-лики от такой оптимизации.
"Having low-poly version of geometry is quite desirable when it comes to
lightmap UV efficiency, as low-poly meshes typically have much fewer UV
charts/islands and therefore fewer lightmap texels are wasted."