Comments 16
Если нужен метод только для ограничения области видимости, то есть более простой вариант (если не ошибаюсь, он используется, например, в teleglitch): просто над препятствием рисуем чёрную вертикальную стену с сильной перспективой, которая просто загораживает лишнее.
Ранее не сталкивался с данной игрой, вы правы, отдаленно похоже, но эффект несколько иной.
В вашей прошлой статье ведь тот же принцип построения теней был?
Кстати, как там полигоны теней отрисовывались: что-то быстрое типа такого?
Точечные источники освещения отбрасывают очень уж жёсткие тени. Для теней многоугольников можно упростить рейкастинг, например, как тут ncase.me/sight-and-light.
Мягкие тени сделать сложнее, т.к. источник света не точка, а, например, отрезок. И вместо видно/не видно точку нужно считать под каким углом виден отрезок освещения из точки (получается как-бы обратный рейкастинг от точки к источнику/ам освещения). Хотя это и вычислительно сложно, можно заранее «запечь» карту освещения для статических источников.
Мягкие тени сделать сложнее, т.к. источник света не точка, а, например, отрезок. И вместо видно/не видно точку нужно считать под каким углом виден отрезок освещения из точки (получается как-бы обратный рейкастинг от точки к источнику/ам освещения). Хотя это и вычислительно сложно, можно заранее «запечь» карту освещения для статических источников.
Метод что указан по ссылке будет хорошо работать только когда объектов не много. Например: при разрешении Full HD — разрешение 1920×1080 и размере тайла 32х32, получим сетку 60х33 видимых тайла, итого верхняя граница 1980х4 ~ 8к лучей, без мягкой тени. Перспективно нужно пробовать.
Я не сторонник мягких теней, их делать не сложнее, а вычислительно дороже. Нужно лишь выпустить пару лучей со сдвигом в стороны от испускающего свет объекта, создав как бы объёмный источник освещения.
Я не сторонник мягких теней, их делать не сложнее, а вычислительно дороже. Нужно лишь выпустить пару лучей со сдвигом в стороны от испускающего свет объекта, создав как бы объёмный источник освещения.
Не соглашусь с рассчётом :). В сетке 60х33 будет (60+1)х(33+1) ~ 2к точек.
Один тайл мы отдадим на откуп обрамлению ).
Про то, что у каждого тайла 4 угла вы забыли, или я не правильно понял метод?
Хотя, карта должна состоять хотя бы наполовину из коридоров, а не только стен, так что 2-4к лучей вполне реально.
Про то, что у каждого тайла 4 угла вы забыли, или я не правильно понял метод?
Хотя, карта должна состоять хотя бы наполовину из коридоров, а не только стен, так что 2-4к лучей вполне реально.
Лучи идут к точкам.
Одна и та-же точка может быть использована для нескольких тайлов. Например для одного тайла она верхняя левая, для другого она же нижняя правая. Нет смысла трассировать одну и ту-же по факту точку дважды.
В плотном блоке 2х2 тайла действительно по 4 угла на тайл, но точек по факту 9, а не 16. Внутренняя точка общая для всех 4х тайлов, точки на серединах граней общие для 2х смежных блоков (сколько тайлов используют точку):
1 2 1
2 4 2
1 2 1
Одна и та-же точка может быть использована для нескольких тайлов. Например для одного тайла она верхняя левая, для другого она же нижняя правая. Нет смысла трассировать одну и ту-же по факту точку дважды.
В плотном блоке 2х2 тайла действительно по 4 угла на тайл, но точек по факту 9, а не 16. Внутренняя точка общая для всех 4х тайлов, точки на серединах граней общие для 2х смежных блоков (сколько тайлов используют точку):
1 2 1
2 4 2
1 2 1
Очень разумное решение, руки чешутся применить, по моим расчётам выигрыш на математике будет 2-3 раза, жаль, что на общем фоне расчётов это мизер.
Сейчас основная нагрузка идёт на тайловый движок и слияние слоёв.
Основная идея состоит в том, что хоть расчёты придется делать для всех тайлов экрана, но соединения стен можно просчитать заранее и кэшировать.
Сейчас основная нагрузка идёт на тайловый движок и слияние слоёв.
Основная идея состоит в том, что хоть расчёты придется делать для всех тайлов экрана, но соединения стен можно просчитать заранее и кэшировать.
В лабиринте стоит докрашивать освещение до полного блока, если освещено больше 1/3 блока
Реализовать не проблема, но в чём эффект такого подхода?
Полагаю чтобы игрок чётко понимал — согласно игры он видит содержимое тайла или нет. В DoomRL, например, от этого зависит можно ли выстрелить в противника. Если механика игры это предусматривает, то логично как-то однозначно трактовать видимость в спорных ситуациях. Субъективно для игрока по факту противник виден, а выстрелить по нему по непонятным причинам нельзя. Дополнительная подсветка в таком случае устранила бы неоднозначность видим/не видим можно/нельзя попасть.
Как сказал человек выше — чтобы было однозначнее. Ну и глазу приятнее, раз карта квадратная, значит и тени должны быть квадратными
Как-то писал систему 2D освещения на рейтресинге в шейдерах. Работало довольно быстро, но со своими минусами. Ещё из особенностей была поддержка любых форм источников света, задавались они через обычные спрайты. Сейчас, к сожалению, забросил проект и он не заработает на последних версиях Unity3D.
Sign up to leave a comment.
В поисках перспективных теней для roguelike