Dark Engine Viewer

Автор Force, 30 ноября 2019 23:55:27

« назад - далее »

0 Пользователи и 2 гостей просматривают эту тему.

nemyax

Цитата: Force от 06 марта 2020 20:25:42У меня есть потроха, все видно
Ты и компилятор уровней накопал?
Желаю тебе из тысячи рулеток одну — самую русскую!
Желаю тебе из тысячи надежд одну — самую крупскую!

Force

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


Chuzhoi

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

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

Force

Chuzhoi
ЦитироватьЛюбопытно. То есть ты хочешь сказать, что в оригинальных алгоритмах учитывается переотражение света от объектов, поэтому светотень такая мягкая (т. е. используется radiosity lighting)?
Вот ты сказал и я сам задумался. А ведь нет, действительно! Оно МОГЛО БЫ БЫТЬ ТАМ, но его нет.



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

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

Force

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



Идеально! :yay:

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

Chuzhoi

#95
Цитата: Force от 06 марта 2020 22:29:48Думаю тогда проблема в другом. В обратном подходе. Лайтмэп накладывается на абсолютно освещенную поверхность, тогда как реалтаймовое освещение пытается рассеять абсолютную тьму. В итоге лайтмэп не учитывает нормаль к поверхности, отсюда и равномерность освещения на всех "гранях" стены.
А может, просто дело в элементарном разбавлении теней эмбиентом? На второй картинке эмбиента нет или он недостаточен, поэтому и углы такие резкие.

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

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

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

Force

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



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



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

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

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

Zontik

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

Force

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

Force

#99
На 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.

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