ncuxonaT правда не понимаешь? От одного солнца ты лучи собираешь в строго определённые точки, от множества солнц и получается множество теней, которые потом заглаживаются фильтром и выглядят как говно.
Множество солнц можно использовать, как некоторые мапперы, для достижения эффекта солнечного света, приходящего со всех сторон.
Была парочка карт в таком сюрреалистичном стиле.
Дядя Миша правда, не понимаю. При большом количество солнц это множество теней размывается, и заглаживать их уже ни к чему. И если лучи пускать в разные стороны - будет то же самое. Если лучей мало, и их направления совпадают для всех люкселей, станут видны отдельные тени. Если направления лучей варьировать для каждого люкселя - будет шум. Чем больше лучей, тем меньше шума или отдельные тени сильнее размоются.
Решил проверить обновлённый STB_DXT (они там какие ошибки исправили).
Результат в аттаче, файлы названы, согласно режимам качества STB, squish референсный (макс качество).
Разница в скорости. squish без SS2 сжимает эту картинку 41 секунду. squish с SSE2 делает тоже самое за 2.2 секунды. STB при любом уровне качества тратит 0.05 секунд. Это вообще хороший пример того, что грамотная оптимизация работает лучше тупого использования новых инструкций.
Вложение: dxt_compare.zip (904.5 кб)
Этот файл был скачан 149 раз.
Бензиновые разводы возникают на этапе конвертирования Lightvalues из вещественного в unsigned char. Надо будет уделить этому вопросу внимание.
Построил группировку треугольников по смежным рёбрам и сглаживание нормалей. Пора делать рейтрейсер, а то фейковые тени уже надоели.
Добавлено 09-07-2020 в 01:24:
Кстати, надо будет добавить такую фишку, как множественное небо с разным светом от него. Меня это всегда бесило, что на карте может быть только одно небо.
Не факт, что ренормализация цвета вообще корректная операция. Может её и нельзя делать. Для единичного цвета - можно, а для целой лайтмапы не знаю. Может надо найти вообще со всех лайтмап пиковое значение и поделить все луксели на него. А когда это делается локально, вот и получаются бензиновые разводы.
Для чего вообще нужна эта ренормализация цвета? Я думал лайтмапы пишутся в сыром виде.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro ну допустим в ХЛ2 лайтмапы во флоатах, которые перед записью в карту конвертятся в четыре числа: rgb24 и степень. А в ХЛ1 они просто зачем-то обрезаются порогом 196 или 232 у ДМ, это вроде чтобы работало на Вуду, но хз если честно. И тут как повезёт, если какой-то компонент до обрезания был сильнее других то он обрежется сильно, а другие намного слабее или не обрежутся вообще. И у этого люкселя скакнёт насыщенность которая суть разница значений разных каналов.
FiEctro писал: Для чего вообще нужна эта ренормализация цвета? Я думал лайтмапы пишутся в сыром виде.
Лайтмапа считается в вещественных числах, а записывается в картинку 24 бита, очевидно, каждый канал может хранить максимум 0-255. А во флоате там могут быть любые значения, источники света-то суммируются.
Отсюда же все эти залысины и бензиновые разводы. Просто потому что каждый цвет нормализуется по СВОЕМУ максимальному значению, а не по общему для всех лайтмап. Вместо нормализации происходит разброд и шатания. Этож не векторы, так просто нельзя делать.
Добавлено 09-07-2020 в 14:38:
Цитата:
Crystallize писал: А в ХЛ1 они просто зачем-то обрезаются порогом 196 или 232 у ДМ, это вроде чтобы работало на Вуду
не знаю насчёт вуду, но там какие-то магические числа при скейле лайтмап, это всё тянется еще с софтрендера.
На самом деле здесь масса вариантов как исправить эту ситуацию.
1. Можно, как я уже сказал найти пиковое значение света для всех страниц атласа, сохранить его, ну например в ворлдспавн, предварительно умножив на него все значения света. Это в некотором смысле даст такой же эффект, как и BestFitNormals - сдвигаем значения диапазона, оставляя его границы нетронутыми. А потом просто умножить в шейдере каждый пиксель лайтмапы на это значение и получим почти HDR.
2. Сохранить лайтмапы в RGBe как в сорсе. Четвертый байт отводится под экспоненту. Минус в том, что скорее всего этот формат не имеет никакой аппаратной поддержки, его не сожмёшь в DXT и он занимает больше места, а я бы может четвертый байт хотел под тени заюзать.
3. сохранить лайтмапы в half-float. Они займут еще больше места, но зато это будет HDR.
4. вообще не хранить лайтмапы, хранить только тени, свет рассчитывать деномически в шейдере и умножать на запечённые тени (насколько я знаю, впервые такой подход был опробован еще в Сталкере, думаете как там смена дня и ночи на лайтмапах сделана? Вот именно так). В Юнити тоже есть такой механизм, насчёт UE не знаю. Но скорее всего да.
В принципе можно осуществить поддержку всех вариантов. ну или отобрать самые интересные на пленуме ЦК.
07-07-2020 22:27
Вложение: 
