Войти
OpenGL communityФорум

Реализация ESM (exponential shadow maps) (комментарии) (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
16:13, 27 июня 2011

Вот меня давно мучает попрос.
Зачем раскладывать экспоненту на составляюшие?
т.е. почему бы просто не хранить обычную shadow map, ее блюрить, для нее использовать фильтр. А уже потом в шейдере брать экспоненту от разности?


#16
19:23, 27 июня 2011

VirT
Потому что получиться совсем другая функция, совсем другой результат, причем весьма далекий от того чего бы хотелось.

#17
20:20, 27 июня 2011

KpeHDeJIb
> Потому что получиться совсем другая функция, совсем другой результат, причем
> весьма далекий от того чего бы хотелось.
Это все общие слова не о чем.
Ну получится другая функция и что? Она будет такая же плавная и тоже будет зависит от блюра и фильтрации. Чем она будет не такой какой хотелось бы? А какую хотелось бы?

#18
22:21, 27 июня 2011

VirT
> Это все общие слова не о чем.
okay

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

#19
22:51, 27 июня 2011

KpeHDeJIb
При чем тут используй что хочешь? )))

Мне реально непонятно зачем это делается. Вот я и спрашиваю. Если и ты не знаешь зачем, то лучше ничего не писать, чем пустые сообшения "так не будет работать".
Мой вопрос не был адресован конкретно к тебе как автору статьи. Я его запостил сюда, т.к. ветка посвещенна именно этим теням и возможно кто-то знает ответ.

#20
2:14, 28 июня 2011

VirT
> VirT
чем больше это число тем ближе к максимальному числу использованному в сглаживание.
Untitled-3 | Реализация ESM (exponential shadow maps) (комментарии)

или можно по другому чем больше число тем больше его вес при фильтрации, а esm влияет на сколько больше вес.

можно попробовать хранить еще и просто расстояние и тогда можно будет оценить как сильно 'сглаживать'.

#21
4:44, 28 июня 2011

susageP
> чем больше это число тем ближе к максимальному числу использованному в
> сглаживание.
Что за "это число"? Ты, наверное, имеешь ввиду коэффициент с на который домножается (d-z)?
Его назначение понятно и очевидно. Вопрос был не в этом.
А если ты имел ввиду то, что я напишу ниже, то сори, что не понял )

Суть заключается в следующем:
Как мы уже обозначили раньше тень у нас представляется в виде функции f(d,z).
Так как мы хотим получить сглаженную тень, то градиент представляется в виде w * f(d,z)
Соответственно и получается w * exp(-c*d) * exp(c*z)
Как раз здесь мы и будем считать exp(-c*d) и писать в шадоумапу. После blur и фильтрации мы получим значение w * exp(-c*d)
И тогда нам останется просто домножить на exp(c*z)

У данного подхода есть недостаток, заключающийся в том, что из-за пременения функции экспоненты и домножения на коэффициент, у нас теряется точность float'a.
Чтобы избежать этого, мы можем хранить линейную глубину в shadow map и делать blur фильтр в логарифмическом пространстве.

float log_conv ( float w0, float X, float w1, float Y )
{
    return (X + log(w0 + (w1 * exp(Y - X))));
}

В таком случае и тени гладкие и точность не страдает.

Есть еще Exponential Variance Shadow Map. Но это уже отдельная история.

#22
10:04, 28 июня 2011

VirT
> Суть заключается в следующем:
Спасибо что цитируешь нам тут Shader X и Сальви, я это все уже читал и понять не могу что тебе надо-то в итоге?

> В таком случае и тени гладкие и точность не страдает.
Okay, только количество вычислений увеличивается. Я сразу сказал что ESM одна из самых капризных техник, поэтому нет смысла с ней мучиться дотачивая ее до приемлемого состояния, возьмите лучше PCSS с SAT, вот где все хорошо можно настроить, бросьте ESM, я его рассмотрел только ради интереса.

#23
11:25, 28 июня 2011

VirT
> Чтобы избежать этого, мы можем хранить линейную глубину в shadow map и делать
> blur фильтр в логарифмическом пространстве.
В любом случае почитай про подводные камни этого подхода в Shader X, там впринципе все описано.

#24
13:09, 28 июня 2011

KpeHDeJIb
> SAT

А это чего такое?

#25
14:39, 28 июня 2011

Executor
> А это чего такое?
SAT - Summed Area Table, в общем их в PCSS применяют для быстрой фильтрации, также можно заменить на MipMap-ы в случае теней.

Однако их надо считать, идеальных техник нету :)

#26
15:30, 28 июня 2011

KpeHDeJIb
> SAT - Summed Area Table, в общем их в PCSS применяют для быстрой фильтрации,
> также можно заменить на MipMap-ы в случае теней.
Так у тебя SAT должен комбинироваться с одним из методов фильтрации теней. Т.е. у тебя либо SAVSM, либо SACSM, либо SAESM.
Или что ты имел ввиду под связкой PCSS + SAT?

#27
16:31, 28 июня 2011

VirT
> Или что ты имел ввиду под связкой PCSS + SAT?
Это и имел ввиду, выбор ширины выборки от техники PCSS тени от любой подходящей техники и фильтрация на основе SAT или MipMap, вроде все ясно.

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

#28
16:49, 28 июня 2011

VirT
"В любом случае почитай про подводные камни этого подхода в Shader X, там впринципе все описано."

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

Изображение

Изображение

#29
23:19, 30 июня 2011

попробовал сделать
конечно же ниче не вышло

1)
с чем может быть связана такая засветка

http://dl.dropbox.com/u/5862637/R.f.d000.jpg

+ мягкости и в помине нет!

2)
color = exp(esm_factor * length(lightWorld.xyz - vertex.Worldposition.xyz));

length(lightWorld.xyz - vertex.Worldposition.xyz) - больше 1? или должно быть чтото типа

length(lightWorld.xyz - vertex.Worldposition.xyz)/radius

?

может дожно быть везде -

invRadius=1/radius
color = exp(esm_factor * length(lightWorld.xyz - vertex.Worldposition.xyz)*invRadius);

??

Страницы: 1 2 3 4 5 Следующая »
OpenGL communityФорум

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