Ну я уже выше писал, что да, там довольно небыстрый рейтрейсер.
Раз в 40-50 медленней моего. Там где мой за 30 секунд управляется, оригинальный может считать минут 8.
Добавлено 23-11-2020 в 18:40:
И еще оригинальный код построения лайтгруп дико медленный, он рекурсивный. Надо его на стек переписать. Там блин он эти группы будет дольше искать, чем считать саму лайтмапу.
Дядя Миша писал: При таком подходе плотность люкселей должна быть заранее посчитана на этапе компиляции BSP. То есть чтобы изменить разрешение лайтмапы придётся заново пересчитывать всю карту. Одним только светом не отделаешься.
А в Сорсе так же? Я ему выставляю другое разрешение но эффекта нет.
Ну как-то так. Это testers_mp_factory. Проблема остаётся - здесь 76 тысяч сурфейсов - по кол-ву лайтмапгруп. Когда лайтмапа посчитана - они уже не нужны и можно эти группы объеденить обратно. Но компилятор света такими полномочиями не обладает. А даже если бы обладал - свет можно было бы посчитать только один раз, после чего требовалась бы полная перекомпиляция уровня. Не думаю что это кого-то обрадует.
Проблема конечно решаемая, но я пока думаю как лучше сделать.
Можно эти группы сохранить прямо в вертексы. Размер карты конечно вырастет. Можно попробовать сразу выделить место в атласе, но это проблемно - как потом считать плотность в юнитах, как реконструировать группы из атласа. Не факт что это вообще возможно. Буду думать.
Вообщем без затиралки швов не обойтись.
Даже в идеальном случае, когда развертка полностью разматывается вокруг колонны, мы получаем минимум 1 шов.
Там по идее на границе шва надо просто сделать билинейку и всё.
Добавлено 26-11-2020 в 19:06:
Набросал простенькую удалялку швов, но не всё так просто.
На картинке видно, в первую очередь, ну там кое-где пропущенные пиксели, ошибка округления. Это мелочь.
А вот колонна, на которой эти швы и лезут в первую очередь, как видите здесь сами координаты плохо расположены. Надо отцентровать люксели.
Сколько жы времени на бакэнд уходит, это очуметь можно.
Щас вот надо нормальный менеджер моделей написать, там до сих пор какие-то разроненные функции по типу кутришных. Оно мне досталось в наследство и я до последнего момента тянул, не хотел это говно трогать.
Но всё равно придется написать нормальную имплементацию.
Побочным эффектом можно будет создать всякие конветоры моделей из одного формата в другой. Т.е. такая же либа будет, как для изображений.
Дядя Миша ждать SMD 2.0? Кстати, почему такое низкое разрешение у лайтмапы? Может быть сделать возможность его регулировать внутри порталов? Например в индоре - более мелкое, а для ландшафтов, соответственно мягкое крупное
Я сделаю бинарный промежуточный формат для хранения моделей.
И может быть я ему даже дам расширение .csm
Cached Static Mesh.
Добавлено 28-11-2020 в 14:00:
Цитата:
KiQ писал: Например в индоре - более мелкое, а для ландшафтов, соответственно мягкое крупное
на ландшафтах тени от деревьев, нельзя там более крупное. Не слишком хорошая идея.
Добавлено 28-11-2020 в 14:06:
В загрузчике моделей я планирую сделать построитель развертки лайтмапы из исходных текстурных координат, с проверками на самопересечения и прочее. И вот еще какой важный момент - со встроенным анализатором плотности. Чтобы не получилось так, что моделька с лайтмапой будет иметь более низкочастотное освещение, нежели повертексное.
То есть, если люкселей меньше чем вертексов - оставляем повертексное.
Накрутили плотность лайтмапы - переключились на люксели.
Единственный недотстаток данного механизма - невозможно адекватно определить плотность, не посчитав лайтгруппы по настоящему.
Т.е. нередка ситуация, когда считали-считали и дропнули, т.к. вертексное ляжет лучше. Но на этот случай как раз и пригодится бинарный формат кэша. Туда меш сразу будет записываться уже с лайтмапными координатами и лайтгруппами. Чтобы потом не пришлось второй раз пересчитывать.
А вот кстати вопрос. В сталкере на статике тени меняются в зависимости от положения солнца? В лост альфе 1.4007 утром смешно видеть тени от деревьев в противоположную от солнца сторону.
Дык можно же распаковать ресурсы и посмотреть на лайтмапы.
Лайтмапа там запечена только для одного направления солнца.
Кто-то говорил, что можно запечь для произвольного кол-ва направлений, но я насчёт этого пока не интерисовался.
В сталкере, если вы изучали его лайтмапы, должны были отметить одну забавную особенность. Очень много кусков лайтмап повернуты под произвольным углом, отличным от 90 градусов. Это не касается механизма упаковки в атлас, это результат работы Orbitrary Ortho-Projection (оригинальный камент из кода XRay). Там в чём суть - полигоны группируются по нормали, следя, чтобы сумма этих нормалей не превысила некоторый угол, обычно 89 градусов. Результирующая нормаль частенько получается под произвольным углом, а вместе с нею и лайтмапа. Я отказался от этой схемы довольно быстро, использую своё изобретение, которое я назвал hashed lightmap axis. Идея в том, что для любого полигона можно найти максимально близкую аксиальную нормаль. Всего таких нормалей может быть шесть шутк - по сторонам куба. Это же автоматически повышает и плотность упаковки и исключает ситуации, с цилиндрической проекцией, например для колонны или цилиндра будет создано четыре лайтгруппы.
Правда между ними останутся швы, но при сталкеровском подходе они ведь тоже никуда не денутся. Еще и лайтмапу перекосит на какой-то угол.
Добавлено 30-11-2020 в 12:24:
ncuxonaT ты своим упаковщиком "уголком" когда-нибудь пробывал упаковать достаточно большие атласы? Ну скажем 1024х1024?
И не один, а штук 10. И сколько времени это у тебя заняло.
Потому что моя реализация какая-то адски медленная получилась.
Начиная с размера 512х512 она может маслать несколько минут.
До смешного доходит - освещение считается быстрее, чем упаковка в лайтмапу. Но если страница менее 512, то всё быстро.
173028152 total traces casted, 8122516 luxels illuminated
4
total lightmap pages 20
5
CreateLightmapPages: 817.050387 secs
6
writing maps\testers_mp_railroad.bsp
Упаковщик работал сопоставимо с рассчётом освещения. Кармаковский алгоритм таким не страдает, но и пакует ощутимо хуже.
Добавлено 30-11-2020 в 12:39:
Свежие скриншоты:
Фпс низкий, потому что в сурфейсы разбиты по лайтгруппам на 140 тысяч.
Такое кол-во даже просто отправить на рендеринг очень затратно.
Надо мержить обратно, по страницам лайтмапы, но тогда будут проблемы с множественным рассчётом освещения уже готовой карты. Иными словами, осветить карту можно будет только один раз, а потом заново пересобирать с нуля. Впрочем я этой проблемой пока еще не занимался вплотную.
Потом вместе решим как лучше сделать. В идеале тут должно быть 5-7 тысяч сурфейсов.
Добавлено 30-11-2020 в 12:41:
Кстати я реализовал эту схему, когда ландшафт использует лайтмапу более высокого разрешения, нежели остальные. Правда сама лайтмапа ландшафта идёт под таким же номером как и остальные и ничем не выделяется. Только размерами.
Добавлено 30-11-2020 в 12:42:
Деревья не освещены, т.к. подготовлены для повертексного, а его еще нет.
Впрочем это будет опционально, мне сперва надо сделать концепцию MU-моделей. Вот собсно, это и есть две самые главные задачи по компиляторам.
Дядя Миша скорость наверное зависит от количества элементов, а не от разрешения. Проверил, мой изначальный алгоритм уголком уложил 25к элементов в атлас 4096х4096 за 6 секунд. Оптимизированная более уродская версия алгоритма справилась за 1 секунду.
У тебя точно упаковка медленная? В CreateLightmapPages помимо неё ничего не входит? Может, не атлас долго составляется, а освещение в него долго записывается?