Вы таки будете удивлены, но даже обычный линейный свет во всех трёх кваках немного различался, ниже скриншоты.
Quake 1:
C++ Source Code:
angle = (1.0 - 0.5) + 0.5 * angle;
add = (light->photons - dist) * angle;
add = max( add, 0.0 );
В первом квейке был не Фонг, а Халф-Ламберт, из-за чего там освещение персов так идеально гармонировало с лайтмапой. Просто они были освещены единой моделью освещения.
Quake 2:
C++ Source Code:
add = (light->photons - dist) * angle;
add = max( add, 0.0 );
классический линейный свет по Фонгу
Quake 3:
C++ Source Code:
add = light->photons * 0.9375 - dist * angle;
add = max( add, 0.0 );
Тут непонятно. С одной стороны, это свет, который идеально вписывается в заданный радиус, т.е. фактор освещённости превращается в мировые юниты. С другой стороны - корректно ли это? Обратите внимание на убранные скобки, множитель практически не влияет, я его вставил, потому что он есть в самом ку3.
У Психопата имхо самое красивое освещение получилось, остальное какое то кривое гамно, которое ещё не те цвета что выставил маппер рисует.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Дядя Миша писал: Обратите внимание на убранные скобки
скобки Кармак убрал, не ты?
Цитата:
FiEctro писал: У Психопата имхо самое красивое освещение получилось, остальное какое то кривое гамно, которое ещё не те цвета что выставил маппер рисует.
Пишешь три строчки гамма-коррекции и будет те цвета рисовать.
ИМХО ку3шный вариант самый паршивый, видите вот это уродливое белое пятно по центру с чёткими гранями? Оно занимает практически всё освещаемое пространство, когда на первых двух вариантах хоть это пятно по прежнему и присутствует, но переход уже не такой жёсткий, и мапперам нет необходимости увеличивать радиус этого уродства.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Я полностью согласен с FiEctro в обратную сторону. Вариант в ку3 самый корректный и красиво выглядящий, разумеется, при правильных радиусах и при наличии радиосити (которой в ку3мапе нет, но могла бы быть).
Проблема в том, что он напрямую не совместим с халфовской моделью. Но и это поправимо, в принципе. В vmap я сделал поддержку обеих моделей, ну вы помните, я показывал халфовские карты под волатилой.
Дядя Миша писал: причём сразу для реалтайма и лайтмапы, чтобы они совпадали.
Для матчинга статики и динамики можно просто считать статик-лайты так же, как динамики - по радиусу с квадратичной аттенуацией, а не по фотонам. А статики оставить с полноценным затуханием. Я в волатиле так и сделал, и вы можете посравнивать картинки на статике и динамике.
Для квадратичного радиуса затухания обычные значения света подходят мало. Ну вообщем-то, как это имеет место быть для area light, вы же обращали внимание, что там значения идут от нескольких тысяч.
В Quake3 любое значение точечного лайта умножается на 7500. Не знаю почему именно 7500.
В халфе, как мы помним квадрат самого себя делится на 10 и опять умножается на себя. Таким образом.
Для халфы:
Интенсивность 100.
l1 = 100 * 100 / 10;
intensity *= l1; // 100 * 1000
Результат 100 000 едениц умножить на DLIGHT_SCALE 2.0 (по умолчанию директ в халфе умножается на 2). Т.е. 200 000
Для Quake 3
Интенсивность 100.
intensity = 100 * 7500;
Результат 750 000 едениц.
В 3.75 раз выше.
Добавлено 27-07-2020 в 12:38:
Слева халфа, Справа ку3
Добавлено 27-07-2020 в 12:55:
В халфе экспоненциальная функция получается. Потому что при яркости 200, халфа уже даст 1 600 000, а ку3 1 500 000 соответственно.
При значении 300, 5 400 000 и 2 250 000.
Дядя Миша писал: С одной стороны, это свет, который идеально вписывается в заданный радиус, т.е. фактор освещённости превращается в мировые юниты. С другой стороны - корректно ли это?
О, я так делал в старой версии After Engine, когда приделывал 2D нормал-мэппинг. А то в 2D очень уж неудобно когда радиус лайта нечеткий
Наконец-то удалось как следует протестировать альтернативный упаковщик "уголком", за который так топил наш друг.
В обычных условиях оценить эффективность затруднительно, это надо считать неиспользованные пиксели, причём на одном и том же наборе данных, а тут никогда не угадаешь. Но вчера у меня появилось одно очень простое соображение. Вот у нас есть глобальный список лайтмап-кусочков, которые должны быть упакованы в атласы. Как мы обычно делаем в таком случае? Мы их пакуем-пакуем-пакуем, а если AllocBlock вернул false, то атлас считается заполненным, но ведь это в корне неверно! Это всего лишь означает, что в атласе уже нет места для этого конкретного куска. Он слишком большой. Но вероятно есть места для меньших кусков? Алгоритм реализуется очень просто - мы каждый раз пытаемся добавить в очередную страницу атласа все имеющиеся у нас кусочки лайтмап (разумеется помечая уже добавленные). Если AllocBlock нас послал - мы просто пропускаем этот кусочек и пытаемся добавить еще какой-нибудь. И так, пока не пробежим весь список. Разумеется он отсортирован от большого к малому.
И вот на таких вводных, я наконец-то получил чистые условия. Уголок действительно пакует эффективнее, т.к. он вообще не оставляет дыр при таком подходе. На той же q3dm1 я получил 5 идеально заполненных лайтмап без единого свободного пикселя. И шестую - заполненную процентов на 30. С Кармаковским алгоритмом я получил шесть неидеально заполненных лайтмап и седьмую, слегка начатую.
Но тут еще конечно вопрос, почему сам алгоритм оставляет довольно большие дыры в некоторых местах. Скорее всего особенность работы by design. Потому что, как я понял, для упаковщиков 70% успеха - это грамотная сортировка и подача. То есть всё свелось к тому, может ли алгоритм теоретически обеспечить 100% заполнение или нет. Да не случайным образом, а выдавая стабильные результаты. Ну вот пять полностью заполненных страниц вполне меня убедили в этом.
Полагаю это и есть самый валидный тест упаковщиков.
ЗЫ. картинки прикладываю, правда на данный момент их поровну, но дырки в заполненных атласах на кармаковском алгоритме видны невооруженным глазом, причём уже нельзя сказать "ну он их так расположил".
Вложение: q3dm1sample.zip (151.0 кб)
Этот файл был скачан 115 раз.
25-07-2020 13:45
Вложение: 
