Volum Surf Part II

Сначала для Alex:
RiSpec 3.2
Пункт 12.3:
The shader computes the new color at the ray origin P-I
Меня всегда доставал вопрос какого собственно они считают
WOrigin = P-I (shadowedclouds.sl, hipertexture.sl) когда это по идее есть E
Вопрос исчез когда я увидел что в слимовском фоге эту фишку заменили на E.
Мы несколько уклонились от темы. Речь шла о Surface шейдере симулирующим волум (ну нужен мне дисплэйс) а не о volume шейдере.
Забудем бред про z deph. Кажеться я нашел способ куда проще.
К камере цепляем shadow генератор генерящий шэдов только для интересующего нас объекта. В шейдере как обычно начинаем маршировать
от внутренней P вдоль I назад к камере. Каждый раз передавая на проверку
текущую Pi в shadow функцию которая возвращает 1 если Pi в тени
(до внешней P мы еще не домаршировали) или 0 если мы вылезли наружу
(из типа тени) что прекращает процесс рэймарша.
На днях попробую.
Правда тут есть одно но. В случае сложного объекта (взять хотя бы торус с торца) мы будем маршировать и через дырку от бублика. Правда мне кажеться что эта проблема вообще нерешабельна. (Rayshere.h тоже неспасет)

 

Посмотрел 3.2 и понял, что ты, пожалуй, прав. Хотя в 3.1 все было настолько запутано, что я приходил к противоположному выводу... В любом случае напиши, что получится.

 

Кажеться нихрена не получиться...
Теоретически все правильно НО
я забыл что Shadow, ZDepth должны быть размером по степени 2
(128х512, 1024х1024) в то время как мне надо как у камеры.
Правда tx тащит за собой еще и 2 матрицы трансформов которые
можно исползовать в шейдере вызывая их функцией textureinfo
(Эта фишка описана в Sig2000 про мех крысы-Стюарта) Но я еще
доконца не понял. Если чо выйдет - сообчу.

 

Просто ты смотрел риспек3.1 в котором действительно
I в волумах идет от P а в мануале по PRMan есть сноска
что конкретно в Prman I идет к P.
В риспек3.2 все поставили на место.
В BMRT I в волумах попрежнему идет к P (как в риспек3.1)
Всетаки хочеться добить вопрос о волуме.
Не мог бы ты запостить это в C.G.R.R:
Вопрос:
Если я правильно понял то в Surface_A_La_Volum шейдерах
(shadowedclouds.sl, hipertexture.sl) обращение к
Rayaphere.h не дает действительную точку пересечения
I c внешней P а всего лиш точку пересечения с некой сферой.
Можно ли наити действительную P следующим способом:
1. Сгенерить Shapow Map из рэндэр-камеры только
для SurfVolum объекта.
2. Сделать рэймаршевый шеидер типа:
if ( P.N > 0 ) /* Do not shade the front of the sphere -- only the back! */
{
if ( ShdName != "" )
{
while ( P current In Shadow )
{
do RayMarcher
}
}
}
Если да то как быть с тем что shadow map генериться квадратной (512х512)
в то время как resolution камеры 720х576 например?
Можно ли как нибудь уладить этот "конфликт" или "конфликта" небудет?

P.S.
Если тебя беспокоит перспектива нарваться на гнилые помидоры и банные тазики
то можеш сразу переадресовать их на меня. Ну блин не дает мне покоя етот вопрос.
Буду весьма признателен.

 

Andrew, слушай, я тут первел твои мысли, а заодно и сам врубился в вопрос
_________________________

A friend of mine ( Kab-12@tgv.khstu.ru ) has a question he would like to ask here.
He is planning to make a surface shader mimicking a volume shader. Using volume shaders in his case is not suitable, because he needs to control many volume parameters, like displacement, light scattering, etc.

The techniques described in raymarching examples like shadowedclouds.sl, hypertexture.sl using raysphere.h won't give the location of I intersected to _outer_ P, but some abstract sphere intersection point instead. So can I find actual intersection point using the techiques as follows:

1. Generate Shadow Map at camera's view for Volume object.
2. Write a raymarching shader a la:

if ( P.N > 0 ) { /* Do not shade the front of the sphere -- only the back! */
if ( ShdName != "" ) {
while ( P current In Shadow ) {
do RayMarcher
}
}
}

If yes, then how should we handle square shadow maps (512x512 or like) while the final image should be 720x576 for example?
___________________

Все правильно?

И тут я понял, что чего-то не понимаю: во первых, так генерить shadow map от обратной стороны нельзя: все равно передняя часть будет заднюю заслонять, то бишь надо сначала на объекте нормали развернуть "внутрь", а уж потом генерить shadow, и потом, что даст (P.N) > 0? Может, I.N?
Во-вторых, если развернуть нормали, то
if ( I.N > 0 ) уже дает тебе нужную P с обратной стороны. Или я чего-то не пойму?

 

Ой, блин, адрес-то я там не твой поставил. Где же я его взял -то ?.. Хорошо что хоть в c.g.r.r не запостил!

 

Блин конечно же ( I.N > 0 ) Как это я не заметил....
По поводу смысла поясняю:
Шэдов мап какраз и нужна с внешней стороны. (как обычно)
Мы начинаем маршировать от внутренней стороны (после проверки I.N>0)
вдоль I назад к камере мелкими шажками собирая илюминансу итп.
P при этом естественно в тени.
На каждом шаге мы отсылаем текущую Pcurrent в shadow функцию на проверку которая возвращает 1 если Pcurrent в тени или 0 если мы уже
вышли из тени (т.е добрались до внешней стороны для которой шэдов мап и генерилась)
А адрэса моя 7x7@skif.net

 

Ага, сейчас идею понял. Но тогда нормали флиповать придется уже при окончательном проходе, а иначе - где взять эту "начальную" точку на I, откуда маршировать к камере? То есть - разницы никакой - либо начальную точку определить, как P на обратной (дальней) стороне, и маршировать до выхода из тени, построенной от нормального объекта, либо наоборот, маршировать от "выхода из тени", построенной от "вывернутого объекта" на дальней стороне до точки P на ближней...

А так, по-моему все должно работать, надо реализовывать, потом уже все ясно будет. С разницей в aspect ratio, по-моему, вообще проблем быть не должно. Там же непосредственных raster space значений нигде нет...

И, самое последнее - а стоит-то овчинка выделки? Может, проще это все в 2D сделать?

 

?!*&^лядская Мая.....
Все вопрос с CGRR (пока) снимается.
Все (пока) работает.
Сегодня или завтра допишу шейдер и напишу "обяъснительную с картинками" и кину тебе ссылку. Сразу все поймеш.
Проблема была в том что сначала если ты помниш я пытался экскрементировать с Z Depth для чего выключал 2Sided и включал
oposite. Вдоволь наигравшись я просто включил 2Sided. Oposite при этом
просто стал неактивным (но включеным). Для майки это прошло а вот
рэндэрмэну мтор подсовывал вывернутый объект и шейдер неработал.
Когда крышу начало сносить от непонимания происходящего я начал тупо нажимать на кнопочки и заменил (I.N>0) на (I.N<0). Как не странно все заработало что привело в еще большее замешательство ведь нормали у
объекта смотрели куда надо. Тогда то и появилась мысля проверить oposite.
По поводу размеров кажеться ты прав. Просто мапка должна больше
чем резолюшн картинки. Поскольку в нее поститься P то лишние участки
просто окажуться невостребованными.
А по поводу 2D.....
Я провел немалое кол-во времени наверху и знаю что такое полет сквозь облака. В случае с 2D будет иметь место иллюзия нарисованная на стенках объекта. Предположим density функция генерит что то типа плотных столбов
внути волума. В случае рэймарша зайдя внутрь волума я могу облететь вокруг одиного из столбов так как он РЕАЛЕН и занимает ОПРЕДЕЛЕННОЕ
место и объем в пространстве, а в случае 2D - нет так как он
НАРИСОВАН на стенке объекта (при повороте он просто уйдет в сторону)

 

Мда-а! У меня тоже бывают ощущения, что она может исподтишка пнуть в самое неподходящее место Про облака - согласен, тут при активном движении с 2D даже и соваться нечего. Кстати, в ArMan, по-моему есть несколько примеров с volumetric clouds, но я пока до них не добрался.

 

Это какраз примеры с использованием Raysphere.h
ARman я к сожалению в глаза не видел. Правда у меня есть
исходники этих шейдеров. На их основе я и делаю свой шейдер.
Самое печальное что процесс накопления плотности и цвета при
рэймарше без обяснеительного текста мне несовсем (или совсем не)понятен.
Так что тут я как "обезьянка"