Добрый день!
Я занимаюсь разработкой движка для отображения геоинформационных данных, если проще - визуализатор карт.
Сейчас идёт разработка ночного освещения - сделан свет в окошках.
Необходимо разработать ещё и освещение уличными фонарями. Их может быть в кадре несколько десятков тысяч.
Подскажите оптимальное решение.
Варианты, которые вижу я:
1. Простые лайтмэпы, накладываются на тайл ландшафта и находяшиеся на этом тайле объекты. Накладываются тупо проекцией сверху. Строятся при загрузке данных путём отрисовки источников света в текстуру. В данном случае это получатся просто плавно затухающие к краям круги. Недостаток - источники получатся не сферические, а цилиндрические.
2. Учёт источников света в шейдере - цикл по всем источникам света, находящимся на данном тайле террэйна. Минусы - ограничение по количеству источников света на тайл террэйна. Думаю будут проблемы с передачей такого количества параметров в шейдер.
Плюсы - динамичность. Из оптимизаций - рисовать ближайшие к наблюдателю N источников света. Вдали рисовать только гало - частицу с соответствующей текстурой.
3. Слышал ещё про некие стенсильные источники света. Рисуются световые объёмы (по аналогии с shadow volumes) - сферы. В стенсиле получаем освещяется ли точка - находится ли она в световом объёме. Минусы - много вызовов, связанных с отрисовкой сфер. Границы источников света - жёсткие, не плавные.
Что посоветуете?
AST
Делай лайтмапы. Такое огромное кол-во света быстро тебе ничто не просчитает. Лайтмап - если правильно построен то и выглядеть будет красиво.
Вариант 1 можно усовершенствовать в шейдере, так что бы это были не цилиндры света, а некое приближение к сфере.
Посмотри Ассасин Крид для PSP. Там лайтмап, планарно на ландшафт + въсота света в каждой клетке. Возможно 2 въсотъ, если свет повъше над ландшафтом.
а как же deferred shading?.. это более продвинутый 3-й вариант
arabesc, DS будет медленнее, чем предложенные варианты. Причем, учитывая статичность фонарей, DS - очевидный оверкилл.
arabesc
Можно вблизи отрубать лайтмап и включать DS.
AST
Оффтоп: Можно к ночи прикрутить blue shift - только настроить правильно - немного пореалистичнее будет.
Синий Дракон
> DS будет медленнее, чем предложенные варианты.
лайтмапы надо считать и хранить
для геоинформационной системы, оперирующей большими объёмами данных, это может быть существенный минус
> Причем, учитывая статичность фонарей, DS - очевидный оверкилл.
а тут зависит от ТЗ, системных требований
мало ли что там, может надо свет по кварталам уметь включать, визуализировать отказы всякие...
я бы так сразу не отвергал вариант
arabesc
> лайтмапы надо считать и хранить
Подлетаем к городу - считаем лайтмеп.
FROL
Сложновато думаю для таких целей
ksacvet777
Синий Дракон
Z
Да, надо попробовать лайтмэпы. Может для фонарей они будут и ничего.
Только памяти они будут немало отнимать. Все объекты генерируются в реальном времни в отдельном потоке. Поэтому считать лайтмэп в отдельном потоке для меня не составит труда.
Надо попробовать.
fzr125
Это какой-то пост эффект?
arabesc
Да, deferred тоже можно поробовать.
По крайней мере deferred пасс сделать для уличного освещения.
После отрисовки сцены - взять depth buffer, из него получать положения и рисовать источники света. Единственная проблема будет - много draw call-ов.
А что насчёт гало частицами?
AST
> Да, deferred тоже можно поробовать.
посмотри демку ds от intel - там правда dx11
AST
> Единственная проблема будет - много draw call-ов.
группируй источники света и рисуй хоть за один dip
AST
Как таковые лайтмэпы не нужны, просто для каждого объекта учитываешь только те источки света, которые на него влияют.
Уличный же фонарь светит в радиусе 20-50 метров, а не 10км.
Тема в архиве.