Войти
ПрограммированиеФорумГрафика

Произвольный 3D объект в качестве источника света (3 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3
#30
16:26, 13 дек. 2011

Outlaw
> самое простое что приходит в голову это точечный источник света и кубемапа
> которая хранит расстояние от источника до стенки объекта.
Это называется Ambient Occlusion Fields.

JohnSmith
А то, что ты предлагаешь, называется (или очень похоже на) Volume Ambient Occlusion.


#31
5:35, 14 дек. 2011

JohnSmith
>Если взять длинный забор в качестве источника света и какой-нибудь объект, находящийся далеко на краю этого забора, тогда мы пускаем луч от этого объекта до центра забора, >этот луч долго идёт вдоль забора постепенно приближаясь к нему - мы получим большое расстояние до объекта, когда некоторая его часть на самом деле находится очень близко.
спасибо кэп. очевидно что для больших объектов нужно делать разбиение, как и очевидно что погрешность зависит от "сложности" формы объекта.
VirT
>Это называется Ambient Occlusion Fields.
почитай хоть что постиш, там не про это.

#32
16:31, 14 дек. 2011

Outlaw
> почитай хоть что постиш, там не про это.
Прочитал еще раз. Автор, судя по треду, ищет решение для АО, ты для этого предлагаешь хранить растояние для края объекта в кубмапе. В AOF в кубмапе хранится функция затухания АО, что эффективнее обычного расстояния.

#33
19:18, 14 дек. 2011

вот у меня такой вопрос,  а какой именно предмет источник света?
если это там огненный демон, светящийся колобок, или радиоктивное желе, т.е достаточно локальный объект освещает сцену, то вполне можно описать набором источников света. Если же мы хотим от глобальных объектов, на локальные, то из центра локальных объектов строим кубемапы, записываем цвет + расстояние, блюрим кубемапу по 3ем направлениям и используем как амбиент цвет

#34
11:19, 15 дек. 2011

Давно была такая мысль для Deferred Lighting.
Рендерить вместо лайт вольюма, вольюм нужной формы, у которого в качестве аттрибутов для каждого вертекса лежит центр омни лампочки и их радиус. Сам вольюм повторяет нужную форму, только увеличенную. Поэтому может и радиусы не надо, если задать расстояние фиксированным. Жаль дальше идеи не пошло. Времени не было реализовать. В голове вроде нормально выглядит, на практике - хез.

ЗЫ. Согласен на 50% прибыли...

#35
11:23, 15 дек. 2011

Мда. Перечитал и понял, что лучше пояснить, а то деньги потеряю.

Берем чайник и рисуем как есть. Ведь сам светящийся объект тоже надо видеть. Потом рисуем его в лайт проходе увеличенным. Задаем скейл какой-нить (это радиус освещения) и рисуем с этим скейлом. Далее для каждого вертекса считаем его предыдущий вариант (по идее надо свдинуть вдоль нормали назад на расстояние скейла), который становится центром лампочки. Расстояние уже есть. Можно в принципе и не считать центр, а задать аттрибутами. Далее во фрагментном делаем как обычно, т.е. восстанавливаем пиксель под вольюмом и освещаем его как обычно. Разница в том, что центр у нас не один, а каждый раз новый. По идее не придется рендерить кучу лампочек. Каждый раз расчет один. Просто для разных центров.

#36
11:58, 15 дек. 2011

DeadMeat
если ты хочешь передавать массив лапочек в шейдер, то это почти форвард. да и что мешает набрать нужное кол-во источников света на процессоре?

#37
12:03, 15 дек. 2011

VirT
>Прочитал еще раз. Автор, судя по треду, ищет решение для АО, ты для этого предлагаешь хранить растояние для края объекта в кубмапе. В AOF в кубмапе хранится функция >затухания АО, что эффективнее обычного расстояния.
так функция затухания любая какую хош и она зависит от дистанции.
просто d = дистанция между источником света и точкой объекта которую он освещает считается как:

float3 L = pos - light_pos;
float d = max(length(L) - texCUBE(s, L), 0);
а не просто как:
float d = length(pos - light_pos);
а в AOF автор ищет функцию объекта, т.е. когда свет освещает объект, т.е. кубемапа для объекта считается, насколько я понял.
тут же кубмапа для источника света.

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

#38
12:19, 15 дек. 2011

MAMOHT-92
> если ты хочешь передавать массив лапочек в шейдер, то это почти форвард. да и
> что мешает набрать нужное кол-во источников света на процессоре?
Я не хочу передавать массив лампочек. В том то и прикол. Вершины и есть лампочки уже.

#39
13:12, 15 дек. 2011

DeadMeat
> Я не хочу передавать массив лампочек. В том то и прикол. Вершины и есть
> лампочки уже.
так освещение не повершинное же, как в пиксель шейдере это использовать?

#40
13:25, 15 дек. 2011

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

#41
13:49, 15 дек. 2011

DeadMeat
так не взлетит.

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

хотя вот ты пишешь что вольюм большего размера, чем объект, т.е утраты освещения может и не быть. но проблема в том, что освещенность точки - это интеграл от всех точек меша. Т.е тут придется использовать скринспейс трассировку. И да, как ты будешь учитывать то, что объект не плоский, и сзади например синий, а с переди красный? у тебя сцена будет освещена только красный светом, но не синим. Ну хорошо, можено разрезать его. В одну тексуру нарисовать наш вольюм передними гранями, а в другую - задними. Но как же бока? Если объект будет направлен перпендикулярно экрану?

#42
14:00, 15 дек. 2011

Т.е. денег я не получу?

ЗЫ. Я же говорил, что это только мысли, которые я никак не проверял. Вот про повороты/отвороты не подумал.

#43
16:29, 15 дек. 2011

Outlaw
> а в AOF автор ищет функцию объекта, т.е. когда свет освещает объект, т.е.
> кубемапа для объекта считается, насколько я понял.
> тут же кубмапа для источника света.
Так источник света и есть объект. И в АОF не "когда свет освещает объект", а просто функция затенения от объекта. Затенение или освещение - одна фигня.
Хотя, техника тот еще гимор, писал я ее как-то раз.

Страницы: 1 2 3
ПрограммированиеФорумГрафика

Тема в архиве.