Радиус освещения в Half-Life

[Дядя Миша]

Радиус освещения в Half-Life

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

 

[FiEctro]

Теперь вопрос - кто знает формулу, по которой идет затухание света в халфе?

А в hlrad её нет? Как же он тогда свет считает?
Вроде кто то писал что в хл у света нет радиуса, он якобы мнимый в том месте где цвет лайтмапы переходит в RGB 0 0 0. Наверное корень кроется в значении яркости лампочки. Может быть там какой нибудь квадрат гасстояния.

 

[Дядя Миша]

2 FiEctro: ты попробуй продерись сквозь весь этот китайский код, тем более что там оно вполне безобидно выглядит - обычная формула линейного затухания.

Post automatically merged: Sep 10, 2017

Наверное корень кроется в значении яркости лампочки.

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

Post automatically merged: Sep 10, 2017

Вот вальвовская документация по второй халфе:
https://developer.valvesoftware.com/wiki/Constant-Linear-Quadratic_Falloff
константная аттенюация, которая в принципе похожа на то, что происходит в первой халфе, но не совсем, т.к. там затухание происходит, пусть и на достаточно большом радиусе.
Линейная и квадратичная дают пятно света. Справедливости ради в первохалфе тоже есть это пятно света, но его легче увидеть в режиме показа лайтмап, чем на итоговой картинке.
Там еще что-то сказано про "Constant-Linear-Quadratic vs. 50%-0% falloff",
из чего можно предположить, что второй метод как раз из первохалфы. На границе радиуса он теряет ровно 50 процентов интенсивности и дальше идёт какой-то адский радиус, возможно квадрат радиуса. 150*150 = 22500 юнитов, это заведомо больше размера любой халфовской карты. Впрочем я еще поэкспериментирую.

Post automatically merged: Sep 10, 2017

Вот вам немного скриншотов, для наглядности.
карта покрыта текстурой white, источник 255 0 0, радиус 150.
Первый скрин - от стены до центра источника 300 юнитов, второй - 600, третий 900.
Как видите, даже на удалении в 900 юнитов, стенка всё еще освещается, хотя и хреновенько. Чётвертый скрин с выкрученной гаммой и яркостью 3\3, и становится понятно, что даже на удалении в 900 юнитов, освещается стенка очень даже неплохо.

Post automatically merged: Sep 10, 2017

Больше скажу - даже на расстоянии в 1800 юнитов, она продолжает освещаться. В полной темноте это выглядит дико.

Post automatically merged: Sep 10, 2017

Хорошо, я уменьшил радиус источника до 50 юнитов.
Теперь мне хватило радиуса в 900 юнитов, чтобы нагляднее посмотреть аттенюацию.
Первый скрин - дистанция 300 юнитов (яркость стены в RGB 28 0 0)
второй скрин - дистанция 600 юнитов (яркость стены в RGB 17 0 0)
третий скрин - дистанция 900 юнитов (яркость стены в RGB 9 0 0)
Для квадрата дистанции полное затухание было бы осуществлено лишь на удалении 2500 юнитов, поэтому я отбрасываю эту версию. Тут какая-то другая формула.

 

[ncuxonaT]

Радиус вообще влияет на что-то?
Учитываешь ли ты гамма-коррекцию, когда смотришь на РГБ стены? Или лайтмапа не гамма-корректная?
В лайтбейкере я использовал формулу att = 1.0 + 0.1 * dist + 0.01 * dist * dist;
И вроде более-менее похоже.

 

[FiEctro]

2 Дядя Миша:
Может нормаль стены даёт такой эффект? Я иногда встречаю очень странное поведение света на некоторых полигонах.

 

[Дядя Миша]

2 ncuxonaT: радиус влияет и еще как. Вообщем я понял, там квадрат радиуса делится на 10, причём 10 это магическое число. На него еще китаец ругался в комментариях.

Post automatically merged: Sep 10, 2017

Ладно, я почти разобрался, потом расскажу подробно.

Post automatically merged: Sep 10, 2017

Итак, приступим. Про халфу не зря ругаются, что там сломано освещение, в принципе там слишком много "нехороших" мест, где всё вытягивается либо нормализацией цвета, либо гаммой, либо еще какой-то странной хренью.
Итак, основной смысл в следующем: т.к. интенсивность света получается по следующей формуле:
rgbColor * radius (четвёртое значение в поле _light)
далее, путём сравнения, из трёх компонент находится самая значимая и принимается из интенсивность света. Она возводится в квадрат, а затем делится на 10. Почему на 10, откуда взялось это 10 я не знаю. Китаец не знает. Вальва знает. Но не скажет. Приведу пример: При настройках свет 255 0 0 150 (цвет + радиус), значение интенсивности получается:

intensity = color / 255; // приводим к диапазону 0-1
intensity = intensity * radius; // теперь наша интенсивность равна 150 0 0
l1 = max( intensity[0], max( intensity[1], intensity[2] )); // находим самое большое значение из трех, ну в данном случае очевидно 150
l1 = l1 * l1 / 10; // возводим радиус в квадрат и делим на ту загадочную десятку (получаем 2250)
intensity *= l1; // теперь у нас тут интенсивность возведённая в куб и поделённая на 10. То есть 337500 0 0. Если бы не делили на 10, то было бы вообще за три ляма.

Ну а дальше возводим в квадрат дистанцию между источником света и точкой, куда ударился луч и делим dot( N, L ) на получившееся число, где L - направление на источник света, а N нормаль стенки.

ratio = dot / (dist * dist);
light = intensity * ratio; // надеюсь тут всё понятно.

Пример для поинтлайта, но остальные не сильно отличаются и можно в компиляторе посмотреть (лучше брать старый рад из сдк, который не испорчен макросами).
Используя такой подход и заранее заготовив описания ворлдлайтов в формат БСП (помните новые компиляторы), мне удалось достаточно похоже воспроизвести полностью динамическое освещение на месте лайтмапы.
Собственно скриншоты с пояснениями (где фпс выше, там лайтмапа).
Тестовая карта. Обратите внимание, что на динамическом освещнии стенка не отбрасывает тень - шадовмап пока еще нет.
На test_dyn это особенно заметно.

Post automatically merged: Sep 10, 2017

Еще один момент хотелось бы осветить: невидимый лайтфейс даёт на потолке этот уродливый теневой крест в режиме динамического освещения. На самом деле этот крест есть и в лайтмап-варианте, просто он компилятор блурит и сглаживает лайтмапы, из-за чего не слишком заметно. Но если включить показ лайтмап, то его очертания угадываются вполне явственно:

Это пока что тесты с отключённым радиосити.

 

[Sozon]

Для всех источников света, имеющих реальную мировую позицию (точечный, прожеторный, площадный, сферический, произвольный меш) можно задавать параметры затухания света с расстоянием. Концепция затухания света для этих источников очень важна и имеет непосредственно отношение к физической корректности источника. И это не имеет никакого отношения к затуханию света в непрозрачной среде (такой как туман например). Для соблюдения физической корректности источников света (за исключением spot light, про который мы будем говорить отдельно), интенсивность света от источника должна убывать квадратично с расстоянием до источника. Этот закон вытекает из соображения, что количество энегрии падающее в точку от источника будет пропорционально его угловому размеру по отношению к этой точке, что в свою очередь обратно пропорционально квадрату расстояния от источника до этой же точки. Однако, при вычислени вторичного освещения (диффузно или зеркально переотраженный свет) такое затухание не учитывается, почему?
Все дело в том, что при вычислении отраженных лучей квадрат расстояния получится сам собой, за счет того, что в далеко стоящие объекты попадет меньше лучей, чем в близко стоящие - есть прямое моделирование. Однако поскольку некоторые источники вообще не имеют размера, или имеют маленький размер, но при этом они очень яркие, моделировать их таким образом невозможно. По этой причине источники света обычно сэмпляться детерминированно (то есть мы считаем затенение и трассируем теневые лучи при каждом новом шаге рекурсии), то для того чтобы все-таки получить правильный результат искуственно домножают на коэффициент затухания. Может просто использовали какую то формулу для света? Вот чего нашел. Эт вообще формула которую используют. Может это 10 магическая отсюда?

 

[Дядя Миша]

2 Sozon: ты мог просто дать ссылку вот на это, а не выдавать текст из статьи за свои слова?
И на кой это здесь?

 

[FiEctro]

2 Дядя Миша:
Супер! А как крест появился, если теней нету 0_о? Тот же блюр который осуществляет компилятор, нельзя реализовать на уровне шейдера?

 

[DrTressi]

2 Дядя Миша: лучше бы просто добавил переменные: дистанцию начала затухания и конечную дистанцию, где света уже нет совсем. Таким образом можно было бы в энтити light крутить параметры этих дистанций.

 

[FiEctro]

2 DrTressi:
Ерунду сказал, сам свет устроен так что там отсутствует понятие дистанции. Смотри формулы выше.

 

[ElbeR]

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

 

[Дядя Миша]

А как крест появился, если теней нету

Тень это отсутствие света, очевидно. Крест появился там, куда не достаёт свет. А не достаёт он потому что там 4 светящихся невидимых лайтсурфса. Светят в 4 стороны, а над ними света нет, вот и крест.

Тот же блюр который осуществляет компилятор, нельзя реализовать на уровне шейдера?

До этого дело может вообще не дойти, например. На данный момент задача стоит нарисовать хотя бы просто c1a0d, просто со всеми статик-лампочками, даже без теней. Я уже молчу про подобие радиосити. Не до блура пока что.

сам свет устроен так что там отсутствует понятие дистанции

Дистанция там очевидно есть, но не поддаётся контролю со стороны маппера, как в той же кваке. Самое смешное, что я все эти годы считал вот это заливание светом результатом работы радиосити
Ну как мне казалось, если я ставлю лампочке радиус 150, а она заливает всю комнату светом, что же еще это может быть? Правда компил с -bounce 0 картину практически не менял, но я себя успокаивал тем, что там какие-то встроенные лимиты на число баунсов. А в итоге вон какая лютая хрень оказалась. Из-за того, что лайты друг-дружку много кратно перекрывают, возникает чудовищный овердрав, это очень тяжело рисовать в реалтайме.
2 ElbeR:
А почему ты решил, что мне непонятна формула? Тут вопрос к вальве, которая начала туда совать свои магические числа.

Или это просто научный интерес?

Это всё мои исследования в рамках разработки нового рендерера. У меня есть форвард, он неплохо работает, но встал вопрос большого кол-ва динамических лайтов в кадре. Зачем? Первое что приходит в голову осветить мир полностью динамически. Но расставлять заново лайты под новую формулу неинтересно.
Интересно, используя параметры статических лайтов заставить их рисоваться динамически. Чем я и занят в данный момент. Результаты пока совсем не радуют, в плане производительности, но выводы еще рано делать. А основной вопрос который я решаю - надо ли всё это переводить на отложенное освещение или нет. Ну и новый опыт получаю.

 

[FiEctro]

Результаты пока совсем не радуют, в плане производительности, но выводы еще рано делать.

А в чем проблемы? Помнится даркплейс рисовал эти лампочки с тенями на картах халфы с полне вменяемым ФПС для видюх того времени. И многие из них перекрывали друг друга. Ты помнится говорил что еще была суперсекретная версия где фпс был еще выше чем в других билдах.

А почему ты решил, что мне непонятна формула? Тут вопрос к вальве, которая начала туда совать свои магические числа.

Скорее всего они её откуда то утащили и адаптировали под халфовские координаты, ну чтобы очень большими не были лампочки.

 

[Дядя Миша]

Помнится даркплейс рисовал эти лампочки с тенями на картах халфы с полне вменяемым ФПС для видюх того времени.

С двумя оговорками - во первых обычные лампочки он рисовал с линейным радиусом из кваки, а во вторых полностью игнорировал рад-текстуры. Т.е. на c1a0d он рисовал от силы 3-4 лампочки. Вместо 120. А так да, всё правильно, уже почти победа. Да чего спорить - запусти сам карту и увидишь, как это выглядит.

Post automatically merged: Sep 11, 2017

А вот пример артефактов после carve на лайтмапах. Не спасают даже хвалёные китайские компиляторы.

 

[crystallize]

rgbColor * radius (четвёртое значение в поле _light)

А если заданы только 3 числа?

Post automatically merged: Sep 11, 2017

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

Зачем? И как я понимаю, выбор одной компоненты из трёх-тоже неправильное решение?

Post automatically merged: Sep 11, 2017

Ну а дальше возводим в квадрат дистанцию между источником света и точкой, куда ударился луч и делим dot( N, L ) на получившееся число, где L - направление на источник света, а N нормаль стенки.

Там этот dot правильно считается? В СДК он сломан был.

 

[qpAHToMAS]

Post automatically merged: Sep 11, 2017

А вот пример артефактов после carve на лайтмапах. Не спасают даже хвалёные китайские компиляторы.

Это оно самое?
http://cs-mapping.com.ua/forum/showthread.php?t=12784
Или там у тебя тупо щели после убогого Carve?

Post automatically merged: Sep 11, 2017

А хотя нет, там явно щелей нет, ведь от лампы тоже видны линии. Так как ты убрал их? Или на втором скриншоте полностью динамика?

 

[FiEctro]

2 Дядя Миша:
Такой вопрос, а если использовать повертексное освещение? Чехи в 2000 году предлагали использовать тесселяцию поверхностей в реальном времени и записывать результаты рей трейсинга в повертексное освещение (как я понял).
http://dee.cz/rr/rr.pdf (машинный перевод тут http://rgho.st/6ytC8JyYS )
Даже где то сорцы были. Конечно оно работало не очень быстро ибо 2000 все на CPU, причем на процессорах 200МГц!!! Вот если перенести на GPU, картина сильно изменится?

 

[Дядя Миша]

А если заданы только 3 числа?

Ну не будет домножения на четвёртое.

выбор одной компоненты из трёх-тоже неправильное решение?

Спорное.

Там этот dot правильно считается? В СДК он сломан был.

Все магические числа перекочевали и в ZHLT и в VHLT.

Или на втором скриншоте полностью динамика?

Ну да.

Такой вопрос, а если использовать повертексное освещение?

Сам скрин показывает - сам спрашивает.

Post automatically merged: Sep 11, 2017

причем на процессорах 200МГц!!!

на комнатке с двумя кубиками

Post automatically merged: Sep 11, 2017

Я вообще склоняюсь к тому, что надо писать свои компиляторы карт. Без прекомпиляции даже такую динамику обеспечить будет сложно, но дело даже не в этом. Во первых можно будет уже нормально поиграться с различными вспомогательными методами, да хотя бы встроить трёхвекторный бамп, на манер второй халфы, в компилятор. В китайский код, что либо совать всё тяжелее и тяжелее - наугад как ночью по тайге. А второе соображение заключается в том, что китайский компилятор - китайский в прямом смысле этого слова.
И хорошим он кажется только потому что перед ним был глючный ZHLT. То есть оцените последовательность: кармак пишет компиляторы, вальва их расширяет и слегка ломает, затем приходят больные ублюдки - авторы ZHLT и ломают капитально, затем приходит китаец и начинает накручивать поверх багов какие-то сложнейшие системы, дабы эти баги компенсировать. Но при этом не удосуживается даже сделать хэширование планесов в CSG. Там было много разговоров в своё время, какую грязь разводил ZHLT на лайтмапах и как китаец всё это победил своими хитрыми механизмами. Ну вон скриншот выше, как он всё победил. Аж два раза победил. И другие косячки тоже вылазили. Просто, те же кудвашные компиляторы имея в запасе простейшую триангуляцию грязь на лайтмапах не разводили и швов тоже почти не делали. Компиляторы - он больше на эпсилонах держатся чем на хитрых механизмах.
Вообщем надо брать чистые вальвовские компиляторы из SDK и писать на их базе уже нормальные.

 

[FiEctro]

Сам скрин показывает - сам спрашивает.

Это без интерполяции, я специально выложил чтобы был понятен принцип. К тому же сам рейтрейсинг дает шум, о чем авторы признаются в публикации. Открой публикацию, там есть скриншоты с уже сглаженным освещением.

Вот даже исходники нашел (там есть и демки, правда только под старый линукс и дос):

http://rgho.st/6z4CcHS94

на комнатке с двумя кубиками

Ну, а стандартные длайты даже на комнате с двумя кубиками не запустятся.

Ты сам прикинь, проц 2000 года считает радиосити в реальном времени, делает тесселяцию в реальном времени, все это интерполирует и отрисовывает, с фпс от 1 до 14. Если всё перенести на ГПУ, и вместо рейтресинга использовать более упрощенные модели освещения, мне кажется оно будет летать и не на только картах коробках. Ты же сам говорил что современным видимокартам ничего не стоит отрисовать пару лямов полигонов.