Новые компиляторы уровней для Xash3D

[Дядя Миша]

2 Ku2zoff: может в китайских что-то сломали.

Post automatically merged: Oct 29, 2017

Переделал экстрасамплинг на кудвашный метод - сразу же ушли практически все артефакты освещения. Ну собсно, как я и предполагал. Конечно это имеет значение только для прямого освещения, но учитывая этот бесконечный радиус эмиттера в халфе, вклад прямого освещения даёт куда более ощутимый вклад, нежели радиосити. Если конечно речь не идёт о полигонах за светящимися сурфейсами, ну например потолок за лампами. Время рассчёта прямого света упало с девяти секунд до четырёх (у китайца, напомню почти 30 секунд).
За непрямое освещение пока ничего не скажу, а вот основные проблемы прямого вызваны исключительно низким разрешением лайтмапы и ошибками округления. Ну как бы неудивительно. У китайца там идёт какая-то дикая охота за валидными точками, откуда можно осветить полигоны, но я пока не въехал в этот сакральный смысл. В раде даже малейшие изменения приводят к изменению освещения (тоже незначительному), которые можно заметить лишь сравнивая старый-новый скриншот. Причём нельзя сказать какой из них более правильный.

 

[Raid]

Вообще по идее они чо-то говорили про прекращение вещания в аналоге, тк переходят полностью на цифру.

 

[ZAZA]

Переделал экстрасамплинг на кудвашный метод - сразу же ушли практически все артефакты освещения.

Если не трудно, можно скриншотики с c1a0d для наглядности?

 

[Дядя Миша]

Можно. Тестируем компиляторы с Тхамбсом, пока что до рада. В целом надежды есть.

Post automatically merged: Oct 29, 2017

Кстати. Зависимость качества освещения от метода построения дерева хотя и снизилась, но всё равно еще осталась.

 

[GNU/Hurt]

2 Дядя Миша:
3й

 

[Qwertyus]

Этот свет на потолке, идущий из закрытой двери, несколько сбивает. Тем не менее, как раз на 2-м скрине это пятно наиболее реалистичное - просто пятно света. На первом скрине там явно проходит сквозь него тёмная полоса, чего не должно быть, на 3-м тоже есть этот эффект, только в менее выраженной форме. И опять же, на втором скрине более интересен рисунок теней на дверках боксов на заднем плане.

 

[Ku2zoff]

3й

А я никак не могу определиться, 2й или 3й. На 3м у правой стены под потолком какие-то переходы между гранями. Математически, это конечно правильно, но ИРЛ, ИМХО, из-за отражения света не бывает таких резких переходов. А там светотекстуры на лампах, или лайты? Нужно ведь ещё крутить настройки отдельно взятой текстуры или лайта, чтобы было красивее в таких местах со сложной геометрией.
Кстати, какой скрин после каких компиляторов (или параметров)?

 

[GNU/Hurt]

2 Ku2zoff:
А вот да, пожалуй, и 2й. Только сейчас заметил, что на 3м припотолочный трим несглажен.

 

[Дядя Миша]

Сглаживание еще в процессе. Плюс там любая мелочь влияет на результат. Отличия между вторым и третьим скрином это я HUNT_OFFSET уменьшил с еденички до 0.5.

Post automatically merged: Oct 30, 2017

Там теперь другая гадость вылезла, потом покажу

 

[Дядя Миша]

Слева мои компиляторы, справа VHLT. Как видите VHLT-шные компиляторы, начиная, кажется с 31-го билда научились сглаживать несглаживаемое (см. подставку у стола). Разрешение лайтмапы на скринах - 4 текселя на люксель, чтобы заведомо исключить ошибки округления в сравнении.
У меня два соображения - во первых такое сглаженное освещение лайтмапы будет сильно отличаться от динамических источников, например, а во вторых, мой компилятор управился за 39 секунд, а китайцу понадобилось 3 минуты 13 секунд. Это чисто прямой свет, радиосити тут нет.

Post automatically merged: Oct 31, 2017

Забыл про один любопытный момент упомянуть. Видите на скрине VHLT разрыв от тени столешницы несмотря на всё его модное сглаживание? Это вот как раз последствия вальвовского метода применения экстрасемплов. Я еще в начале темы говорил, что в ку2 совершенно по другому сделано. Ну, собсно при кудвашном подходе, который я применил, этого артефакта нет. Текстурстеп напоминаю равен аж четырём (т.е. лайтмапа в 16 раз чётче, чем халфовская).

 

[PoD-Stas]

2 Дядя Миша:
уже очень круто.

 

[crystallize]

Сглаживание от китайца, даже если физически некорректное, выглядит красиво, потому что двойная тень выглядит как будто это две тени от двух ламп, ну типа как в люстре.

 

[Дядя Миша]

2 crystallize: ты об чём?

 

[Raid]

2 Дядя Миша:
Выходит экономия по раду 60% где-то?

 

[crystallize]

Я про двойной контур тени от стола. Я так понял ты его назвал "разрыв от тени столешницы".

 

[Qwertyus]

К таким мелочам, мне кажется, стоило бы придираться, если бы тени в принципе выглядели настолько красиво, что только это бы и бросалось в глаза. А так меня, например, больше волнует эффект лесенки на тенях, ну и какие-нибудь совсем нелепо выглядящие моменты. Со сглаживанием, оно, конечно в целом красивее. Ну, когда Дядя Миша своё сглаживание добавит, будет ещё лучше, видимо.

 

[GNU/Hurt]

2 Qwertyus:
Стоит придираться, всё это вылезет как только начинёшь делать аутдоор или пещеры.

 

[Дядя Миша]

2 Raid: финальная версия будет медленее.

2 crystallize: двойной контур как раз-таки в VHLT.

больше волнует эффект лесенки на тенях

Лесенку заблурить можно.

Самое адское зло - это привязка качества лайтмапы к текселю, а не к мировому юниту. Половина китайских ухищрений направлена на то, чтобы нивелировать эти различия.
Помните флипнутную лайтмапу на выступающей колонне?

До меня только щас дошло почему такое происходит. Если отключить билинейку, то всё в порядке. Там текстурные матрицы разные, блин! Одна влево смотрит, другая вправо, фильтрация имеет разные направления, вот одна фильтрует слева направо, а другая справа налево. Но поскольку лайтмапа там в один пиксель, то получается вот такой артефакт. И никаким чудом, никакими китайскими примочками это не исправить. Единственный разумный выход - отвязать нахрен лайтмапу от текселя и привязать к юниту. Причём сами лайтмапные матрицы не писать в карту, а строить налиту из текстурной, т.е. неявное задание. Единственное что меня беспокоит - для текстуры и для лайтмапы у нас получится два разных тангент-спейса. Технически это не очень большая проблема, но например для рендеринга кубемап нормали переводятся в ворлд-спейс, т.е. придется иметь два комплекта тангент-спейсов на вертекс, а это ведёт к увеличению его размера.

 

[crystallize]

2 crystallize: двойной контур как раз-таки в VHLT.

Ирония в том что этот бажный двойной контур выглядит лучше твоего корректного, потому что он выглядит как наложение теней от двух разных источников в реальной жизни. Там может по факту и не быть этих двух источников, но это не важно, ведь раз мы смотрим на тень то источник по определению совсем в другой стороне и мы его не видим.

Post automatically merged: Nov 1, 2017

И никаким чудом, никакими китайскими примочками это не исправить.

Ну тогда нужно править генерацию текстурной матрицы, нет?
Пол и потолок повернуты друг к другу на 180 градусов,и поэтому перпендикулярные к ним части колонны тоже развернуты друг относительно друга, так?

 

[Дядя Миша]

Там может по факту и не быть этих двух источников, но это не важно

Там под столом зачем-то всунули поинтлайт. А на начальных картах второй кваки возле каждой светотекстуры продублирована лампочка. Компиляторы доделывали параллельно разработке карт.

Ну тогда нужно править генерацию текстурной матрицы, нет?

Я думаю надо просто взять идентити матрицу и поделить на масштабы люкселя.
Буду экспериментировать. Я вам еще попозже покажу как сильно гуляет качество лайтмапы на разных поверхностях. Вот как раз из-за этой привязки к скейлу текстур. Я и сам не понимаю, зачем было городить этот огород. Может для софт-рендера был смысл.