Dark Engine Viewer

[nemyax]

У меня есть потроха, все видно

Ты и компилятор уровней накопал?

[Force]

nemyax
Да не, я просто говорю про листинг чанков. У них у всех имена говорящие - одноименные с полями в редакторе. Сложность только в расковыривании формата их хранения, и какая логика стоит за ними. Если со вторым помогут местные умельцы, или не только местные, то вот с первым - как повезет. Пока что всё нужное мне встречалось в OPDE, но я недавно забрел в DromEd'е в такие интересные места, что OPDE такое и не снилось!

[Chuzhoi]

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

Любопытно. То есть ты хочешь сказать, что в оригинальных алгоритмах учитывается переотражение света от объектов, поэтому светотень такая мягкая (т. е. используется radiosity lighting)? Действительно, в Dromed есть опции RayCast и ObjCast Lighting (никогда их не включал) - получается, это оно и есть?

Вторая картинка похожа на TDM. Кажется, я, наконец, начинаю понимать, почему там все выглядит таким угловатым (хотя в последние, гм, годы стало вроде бы получше). А третья в углах выглядит неестественной вообще (осветленный угол стены слишком бросается в глаза).

[Force]

Chuzhoi

Любопытно. То есть ты хочешь сказать, что в оригинальных алгоритмах учитывается переотражение света от объектов, поэтому светотень такая мягкая (т. е. используется radiosity lighting)?

Вот ты сказал и я сам задумался. А ведь нет, действительно! Оно МОГЛО БЫ БЫТЬ ТАМ, но его нет.



Думаю тогда проблема в другом. В обратном подходе. Лайтмэп накладывается на абсолютно освещенную поверхность, тогда как реалтаймовое освещение пытается рассеять абсолютную тьму. В итоге лайтмэп не учитывает нормаль к поверхности, отсюда и равномерность освещения на всех "гранях" стены.

А третья в углах выглядит неестественной вообще (осветленный угол стены слишком бросается в глаза).

Меня тоже как раз это коробит, поэтому я и сделал эту штуку выключаемой, кому совсем плохо от неё станет . Она ещё и исчезает у границ экрана при поворотах камеры как SSAO .

[Force]

ВНЕЗАПНО!!! На меня снизошло откровение! Убрал учет нормалей, поставил честную формулу затухания света и вот:



Идеально!

Ну, это работает так только с условием, что никаких других эффектов нет... Ну что, оставить пока так?

[Chuzhoi]

Думаю тогда проблема в другом. В обратном подходе. Лайтмэп накладывается на абсолютно освещенную поверхность, тогда как реалтаймовое освещение пытается рассеять абсолютную тьму. В итоге лайтмэп не учитывает нормаль к поверхности, отсюда и равномерность освещения на всех "гранях" стены.

А может, просто дело в элементарном разбавлении теней эмбиентом? На второй картинке эмбиента нет или он недостаточен, поэтому и углы такие резкие.

Любопытно, кстати, что тогда означают эти RayCast и ObjCast Lighting, если не radiosity. Кстати, в последнем нет ничего такого фантастического - уже в Quake 2 этот способ использовался.

Оффтопик: Кстати, вспомнил, что еще мне напоминает вторая картинка: освещение в классическом Unreal Engine (до второй версии включительно; в третьей, кажется, алгоритмы поменялись) с отключенной опцией Dark Corners (которая была включена по умолчанию). В этом движке использовался свой способ "оживления" освещенных примитивными компьютерными алгоритмами полигонов - затемнение углов. Видимо, по замыслу разработчиков, это должно было создать ощущение полумрака. Кстати, в редакторе на пустых комнатах это выглядело довольно неестественно, но в реальных игровых уровнях это вполне неплохо работало, придавая картинке своеобразный анриловский шарм.

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

[Force]

Вот еще два скрина.
New dark (тут видно, что учет нормалей уже сделан):



Без нормалей, эта же миссия, исправленная для New Dark:



Да, в общем, надо это дело тюнить и обкатывать. Искать/составлять алгоритмы, удовлетворяющие нашим потребностям.

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

P. S. Кстати, с этим затуханием искривленные нормали выглядят не так вырвиглазно. Гармонируют...

[Zontik]

Действительно, в Dromed есть опции RayCast и ObjCast Lighting

Фактически это одно и то же, только в последнем прочитываются тени еще и от объектов, а в первом - только от брашей. Но они в корне отличаются от первого режима Quick Lighting, где все делается как-то неаккуратно (но резких теней там все равно нет, если не считать артефакты).
Как говорится, чем могу... Листинг чанков лучше обсуждать не со мной.

[Force]

А какое свойство отвечает за то, чтобы фонарный столб начал отбрасывать тень хотя бы от других светильников? А то сейчас все фонари не отбрасывают теней вообще. Или это где-то в движке захардкожено?

[Force]

На ttlg нашел:

the object itself casting a shadow (Object System > Immobile: TRUE)

Это оно! Кажется, даже Zontik уже про это говорил когда-то...

[Force]

...вот только... Это совершенно унылый критерий для отбрасывания теней в современном проекте, потому что любой потенциально подвижный объект, типа ящика, бочки и т.п. тень отбрасывать не будет, потому что свойства Immobile у него быть не может. Пожалуй, приберегу это свойство до момента прикручивания физики, там оно даже семантически больше подходит, а для теней всё-таки использую Self Illumintation.

Насколько это будет объективная замена логики?

[Zontik]

Не получится ли в результате этой логики так, что светильник при выключении перестанет отбрасывать тень? Просто не знаю, что происходит со свойством в результате включения/выключения. Это уже задача движка - интерпретировать действия игрока, в редакторе этого не посмотришь.

[Force]

Zontik
А сейчас именно так и есть. Абсолютно все объекты, у которых нет свойства immobile, тень не отбрасывают никогда. Среди них все светильники, независимо от того, включены они или нет. Я же предлагаю наличие тени навесить на наличие свойства self illumination, причем даже с нулевым значением. Таким образом тени не будет только у светильников, которые могут или горят. "Мертвые" светильники, без свойства self illumination тень отбрасывать будут.

[Zontik]

Это какая-то инопланетная логика.

Я же предлагаю наличие тени навесить на наличие свойства self illumination

"Мертвые" светильники, без свойства self illumination тень отбрасывать будут.

Так наличие приравнять к наличию или все-таки к отсутствию?
В общем, сначала действительно хотелось бы понять логику, чтобы потом уже ее обоснованно разгромить. Потому что решение такое представляется более чем спорным: какая вообще связь между способностью светиться и способностью отбрасывать тень? Это имело бы смысл только в случае, если бы в помещении допускалось не более одного источника света - тогда понятно, что самому от себя тень отбрасывать затруднительно. (И то спорно.)

[Force]

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

Ты очень категоричен.

"Мертвые" светильники, без свойства self illumination тень отбрасывать будут.

Тут всё верно.

Я же предлагаю наличие тени навесить на наличие свойства self illumination

self illumination = 1.0 - тени нет.
self illumination = 0.5 - тени нет.
self illumination = 0.01 - тени нет.
self illumination = 0.0 - тени нет.
свойства self illumination нет вообще - тень есть.
Вот что имелось в виду.

Почему так? Предположим, если рядом стоят два фонаря, столбы, на которых они стоят не будут отбрасывать тень. Если один фонарь погасить рубильником, его self illumination станет 0.0 и он просто погаснет. Если же привязать тень к значению 0.0, то как только мы выключим один фонарь, у его столба внезапно появится тень, которой не было видно даже частично, хотя он горел очень тускло и её было бы видно, а это некрасиво и неправильно. Поэтому мы все потенциально работающие фонари теней лишаем, как и было в оригинале. Но даем тени никогда не работающим, чего в оригинале не было. Так же даем тени всем остальным объектам просто потому что можем, а Dark Engine не мог. Вот и вся логика.

Да, это тоже, в общем-то костыль, связанный с тем, что в оригинале светильники теней не отбрасывают вообще. Но это более логично, чем вешать тени только тем объектам, которые immobile.

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