1. Пользоваться форумом на планшетах и телефонах стало удобнее благодаря Tapatalk

"VolumSurf возвращаються"

Тема в разделе "RenderMan", создана пользователем -, 4 ноя 2000.

Модераторы: Moderator.
  1. Guest

    (Для Alex и не только....)
    Для начала:
    http://www.geocities.com/andrewvk107/SurfVolum/Pict1.jpg
    http://www.geocities.com/andrewvk107/SurfVolum/Pict2.jpg
    http://www.geocities.com/andrewvk107/SurfVolum/Pict3.jpg
    http://www.geocities.com/andrewvk107/SurfVolum/Pict4.jpg
    http://www.geocities.com/andrewvk107/SurfVolum/Pict5.jpg
    http://www.geocities.com/andrewvk107/SurfVolum/Shader.zip

    SdadowMap генериться для объекта в его обычном состоянии
    (объект двусторонний, нормали наружу)
    В процессе просчета луч I натыкаеться на P1 (Pict1.jpg)
    и не пройдя проверку ( N.I > 0 ) идет дальше.
    (вектор I и нормаль N имеют противоположные направления
    (всмысле угол меж ними < 90 гр.))
    Прверка срабатывает когда I натыкаеться на P2.
    (вектор I и нормаль N имеют одинаковые направления
    (всмысле угол меж ними > 90 гр.))
    Вот тогда и начинеться процесс рэймарша.
    В цикле while от точки P2 мы начинаем двигаться вдоль
    луча I назад к камере с приращением stepsize
    Psamp = Psamp + stepsize * normalize (-I); /* (-I) значит в обратную сторону /*
    stepsize * normalize(-I) - float stepsize превращаеться в вектор теперь уже
    имеющии направление (в противоположную сторону от I)
    В текущей точке Psamp вызываються функции определяющие прозрачность
    и цвет в данной точке пространства, которые накапливаються с вычесленными на
    предидущем шаге по пока неведомому мне принципу :(
    В конце концов текущая точка Psamp отправляеться на проверку в функцию
    shadow:
    test = shadow (ShdName,Psamp);
    Переменная test (являющаяся условием продолжения цикла while) будет
    установлена в 1 - если Psamp внутри объекта или 0 - если Psamp
    на поверхности (точка P1 на картинке) или немного вылезла за пределы.
    Грубо говоря shadow map несет в себе информацию о координатах
    всех возможных точек P1. Еще грубее:
    отвечает на вопрос "Какие точки вдоль I начиная от P2 лежат "в тени" P1"
    При test = 0 рэймарш прекращаеться и рэндэру возвращаеться накопленный
    цвет и прозрачность.
    Вот примитивная реализация:

    >surface
    >VolumSurf ( string ShdTex = "";
    > float stepsize = 0.3;
    > )
    > {
    > Ci = Oi = 0.0;
    > varying float test = 1;
    >
    > if (I.N > 0)
    > {
    > point Psamp = P;
    > vector Imarch = normalize (-I);
    >
    > if (ShdTex != "")
    > {
    > while ( test == 1)
    > {
    > Ci += 0.001;
    > Oi += 0.001;
    > Psamp += stepsize * Imarch;
    > test = shadow (ShdTex, Psamp);
    > }
    > }
    > }
    > }

    В ARmane (насколько я знаю) предлагают другой способ:
    Использовать функцию Raysphere для определения
    сегмента через который пройдет рэймарш.
    Но если посмотреть на (Pict2.jpg)
    то станет ясно что если объект далек от сферы то в большенстве
    случаев имеет место быть ПЕРЕрэймарш причем в данном случае
    кое где даже очень ПЕРЕ.
    Отсюда увеличени времени просчета которое к тому же дает
    неверный результат.
    Существуют ситуации когда оба способа гонят
    (Pict3)
    Пустота будет воспринята как волум причем дважды.

    У моего способа есть недостаток:
    Когда камера или объект движуться то shadow map нужно
    генерить для каждого кадра. Но как показал эксперимент
    это всеравно быстрее и правильнее чем raysphere
    (в случае шибко несферического объекта)
    Это проверенный факт.
    Я тут слил перезаточенный shadowedclouds.sl Ларика Грыця

    В слиме к камере приатачь shadow генератор,
    установи резолюшн шэдов мапы больше чем максимальная у камеры.
    Выясни какое имя он будет генерить и подставь его в
    шейдер. Например для анимации:
    e:/projectsm/volumtest/rmantex/shd/test.camerashape1.shd.$F4.tex
    Для статики:
    e:/projectsm/volumtest/rmantex/shd/test.camerashape1.shd.tex

    Я не стал извращаться с функцией прозрачности и тем более цвета
    а оставил как есть. Потому что...... (САМОЕ СМЕШНОЕ)
    Качество сильно зависит от расстояния до объекта и
    его размеров на картинке. Но это уже неважно поскольку.....
    Что будет когда камера войдет внутрь объекта?
    НИХРЕНА!!!!
    Внутренняя стенка станет границей тени а маршировать мы будем
    от нее. Тоесть пройдет лиш 1 шаг так как test изначально
    установлен 1. На втором шаге он обратиться в 0.
    Хотя если заходы внутрь не предусмотрены то подобрав
    нормальную фрактальную функцию для прозрачности
    можно добиться весьма приличных результатов.
    Я тут отрэндерил облет вокруг облака.
    Ощущение волума потрясное.
    Запостить авишку пока несмог - связь дерьмо.

    А теперь о главном.
    Кажеться мне пришла в голову убойная идея решающая
    многие проблемы.
    Пиксаровский tx формат несет в себе матрицу трансформа
    точки P в пространство той камеры с которой это текстура делалась.

    Посмотри на Pict4.jpg, Pict5.jpg и почитай риспек 3.2
    про функцию textureinfo.
    Вокруг объекта делаем "виртуальный" куб из 6 ортогональных
    камер прилинкованых (в смысле он их Parent (если объект движеться))
    к объекту. Нужно ли в случае движущегося объекта заново генерить
    мапы я пока не въехал. Возможно можно обойтись одним единственным разом!!!
    Если объект деформиться то естественно надо.
    Генерим с них шэдов мапы (как для поинт лайта только не наружу а внутрь)
    Делаем точно такой же рэймарш только проверка на тень сожнее:
    Для каждой шэдов мапы
    с помощью матрицы полученой из функции textureinfo
    поочередно трансформируем Psamp
    в пространство той камеры с которой эта мапа генерилась
    и если если все 6 вызовов shadow вернут 1 значит 100% точка лежит
    внутри объекта. Если хотябы одна вернет 0 значит либо вышли либо
    в "дырке от бублика".
    На Pict4.jpg нижняя
    камера зафиксировала бы отсутствие тени.
    Вопрос с камерой внутри автоматически отпадает потому как тени теперь
    не привязаны к рэндэркамере.
    Но все это еще надо проверить.
    Короче неделька обещает быть веселой...когдаж работать то?
     
  2. Guest

    Блин как сюда постить чтобы серия пробелов
    не превращалась в один?
     
  3. Guest

    <code>
    If (test) { /* Many spaces */
    i = 2;
    }
    </code>
     
  4. Guest

    Блин, не работает...
     
  5. Guest

    Ну ты наворочал! У меня есть интуитивное ощущение, что все-таки можно сделать это как-то проще. Как - пока не знаю, да и опыта написания серьезных шейдеров у меня не так много. Но, по-моему, лезть в tx и выдирать оттуда матрицу - как-то... некрасиво, что-ли... Далее, в случае с 6 камерами - "полностью" внутренние дырки (как в куске сыра) все равно не получаются.. Да и не только: представь куб, у которого один из углов срезан сферой, ценр которой чуть-чуть "внутри" куба. То есть отверстие выходит на поверхность куба, но появляются полости, которые не отобразятся ни на одном из 6 шедовмапов.
     
  6. Guest

    Внутренние дырки - как геометрия объекта естественно исключаються.
    Если они нужны - так это задача решающаяся самой функцией прозрачности,
    причем довольно простая.
    А ситуация с гранями - так просто делай камерный куб заведомо больше
    (с учетом возможных деформаций объекта которые приведут к такой ситуации)
    и проблем никаких.
    Что до "некрасиво лезть в tx" так на эту мысль меня навел Sigg2000
    Там ребята лезли в tx за матрицей когда работали над крысой - Стюартом.
    Помоему получилось очень даже красиво :)
     
  7. Guest

    Хватит мучать, результаты покажи ;-)
     
  8. Guest

    Как получиться слить авишку
    я сообчу. Связь с геосайтом паршивая и тормознутая :(
    Может в понедельник...
    Смотреть на статику неинтересно.
     
  9. Guest

    Уф...не прошло и пол года...
    http://www.geocities.com/andrewvk107/SurfVolum/Vtest.zip
    Вовремя мне попался VirtualDub...
    Задавлена DivX - ом до 1.2 метра...думаю у тебя он есть.
    Чегото особенного не жди.
    Это всего лиш тест самой идеи для сравнения ее с raysphere
    поэтому функцию "облачности" я оставил как у Лари.
    Согласись что волум имеет место быть...
    Кое какаая статистика (PIII 450, 128 mb)
    Shadow Map = 10 сек.
    Кадр = 4 Мин.
    При тесте того же (shadowedclouds.sl с удаленным selfshadow) но с raysphere
    кадр = 9 Мин.
    Причем эфект перерэймарша сильно заметен (верхушка объекта при
    определенных положениях камеры становиться необычайно плотной)
    Постить авишку небуду - долго да и незачем.
    Я так же перепостил
    http://www.geocities.com/andrewvk107/SurfVolum/Shader.zip
    Что то я сначала перемудрил с EdgeFalloff.
     
  10. Guest

    Здорово. Объемность читается - даже очень. Но с функцией прозрачности, по-моему, еще надо поковыряться, а то на облако не очень похоже :) И местами есть четкий "край", несмотря на EdgeFalloff...
     
  11. Guest

    Край - это эфект дырки от бублика (там есть впадина)
    При Raysphere он тоже есть - даже хуже.
    А с прозрачностью буду работать на варианте с матрицами.
    Правда пока тут тупик.
    Переведеш вопросик на CGRR?
     
  12. Guest

    Конечно. А какой?
     
  13. Guest

    Сенкс за помосчь.
    Вот вопрос:

    Если я правильно понял то
    с помощью raysphere.h невозможно определить
    истинный сегмент через который должен пройти
    рэймаршер если объект "далек от сферы":
    http://www.geocities.com/andrewvk107/SurfVolum/Pict2.jpg
    Как следствие:
    Увеличение времени просчета + Неверный результат.
    Я попробовал немного другой способ (на основе shadowedclouds.sl):
    http://www.geocities.com/andrewvk107/SurfVolum/Pict1.jpg
    Из рэндэр-камеры для volum объекта генериться shadow map.
    Шейдэр делает рэймарш от внутренней стороны объекта
    до тех пор пока не выйдет из "тени" от внешней стороны.
    DivX AVI: http://www.geocities.com/andrewvk107/SurfVolum/Vtest.zip
    Shader: http://www.geocities.com/andrewvk107/SurfVolum/Shader.zip
    Статистика (PIII 450, 128Mb):

    Shsdow Map: 10 sec. + Frame: 4 Min.

    Shadowedclouds.sl (shadowdensity = 0) Frame: 9 Min.

    Но у этого способа одно большое ограничение:
    Нельзя пройти сквозь объект, поскольку внутренняя
    сторона при этом становиться границей тени.

    Сейчас я пробую другой способ, который
    устранил бы это ограничение и кроме того
    правильно реагировал на ситуации подобные:
    http://www.geocities.com/andrewvk107/SurfVolum/Pict3.jpg
    http://www.geocities.com/andrewvk107/SurfVolum/Pict4.jpg
    Суть в следующем:
    Вокруг объекта размещаються 6 ортогональных камер
    которые генерят 6 shadow map:
    http://www.geocities.com/andrewvk107/SurfVolum/Pict5.jpg
    Рэймаршер продолжаеться в случае если все 6
    вызовов shadow функции вернут 1.
    Проблема в том что я незнаю как перевести
    PSamp из "current" в систему координат
    камеры из которой shadow map генерилась.
    Я пытался сделать это с помощью "viewingmatrix"
    полученной из textureinfo но безрезультатно.
    Вот нерабочий тэстовый шейдер:
    http://www.geocities.com/andrewvk107/SurfVolum/Volumbox.zip
    Наверное я неправильно понимаю смысл
    этой матрицы. Кто нибудь может прояснить
    ситуацию. Если такое всетаки возможно
    то можно ли как нибудь обойтись 1 набором
    shadow map если объект (и shadow камеры естественно)
    движеться и не пересчитывать их для каждого кадра.
    Заранее благодарен.
     
  14. Guest

    случайно слил нетот volumbox.zip
    Уже перепостил...
     
  15. Guest

    Пардон за задержку, я тут шибко занят был. Вот перевел, посмотри и - если все ok - я запощу.

    A friend of mine (7x7@skif.net) is developing complex raymarching shaders and asked me to translate to English and post his message here.
    The stuff is rather large but probably someone will be so kind to dive in the subject and answer his questions:
    __________________________________________

    To my knowledge raysphere.h cannot calculate accurate segment required for raymarching given that the object is far from being a sphere.
    Look at http://www.geocities.com/andrewvk107/SurfVolum/Pict2.jpg to see what I mean
    As a result we have bad rendering time and probably bad calculations. I tried the modified approach (based on shadowedclouds.sl): http://www.geocities.com/andrewvk107/SurfVolum/Pict1.jpg
    First I render a shadow map from camera position for "volume" object only. At the second pass my raymarching shader starts his loop from the "far" side of the object, and marches to the camera while the ray is "in shadow". (*** Не совсем понятно, какая "внутренняя", я перевел - far, пойдет? ***)
    DivX AVI: http://www.geocities.com/andrewvk107/SurfVolum/Vtest.zip
    Shader: http://www.geocities.com/andrewvk107/SurfVolum/Shader.zip

    Rendering statistics: (PIII 450, 128Mb)
    Shadow Map: 10 sec. + Frame: 4 Min.
    Shadowedclouds.sl (shadowdensity = 0) Frame: 9 Min.

    But this method has a significant limitation: the camera cannot fly through the object, because "far" side becomes the shadow border.
    (**** Слушай, а почему бы все-таки не маршировать "от камеры (или передней поверхности объекта - у кого Z больше в camera space и до границы тени от "вывернутого" объекта, а?****)

    Now I am trying another method which seems to overcome this and some other limitations, like these:
    http://www.geocities.com/andrewvk107/SurfVolum/Pict3.jpg
    http://www.geocities.com/andrewvk107/SurfVolum/Pict4.jpg

    So to the matter: I place 6 orthographic cameras to form a box around the object and generate 6 shadow maps like in:
    http://www.geocities.com/andrewvk107/SurfVolum/Pict5.jpg
    Then the raymarcher borders are defined by 6 shadow() calls. The problem is: I cannot transform Psamp from "current" to these "orthographic" camera spaces in which these maps were rendered. I tried to do it via textureinfo "viewingmatrix" data but had no success.
    Here is the example of the non-working shader:
    http://www.geocities.com/andrewvk107/SurfVolum/Volumbox.zip
    Probably my understanding of these matrices is wrong. Can somebody clarify it? And is it possible to use a single shadow maps pass if the object is moving and these 6 cameras are moving with it?
     
  16. Guest

    Сенкс.
    Все Ok.
    Пости.
    А на счет обратной Z надо подумать, сейчас уже не помню но почемуто я от этого отказался.
    Всеравно вопрос с матрицами надо добить.
     
  17. Guest

    Не пишут ведь проклятые буржуины в c.g.r.r ничего...
    А я тут думал, думал и вот что придумал про твои 6 shadow maps. Не надо из них никакие матрицы выдирать. Они там для этого и сидят, чтобы по ним рендерер корректно трансформировал P при вызове shadow(). Вот.
    То есть вызываешь просто shadow() по каждому z-файлу и получаешь 1 - если P в тени, 0 - если не в тени. Вот и все. Убейте меня, если я неправ ;-<
     
  18. Guest

    Наверное это страшная буржуинская тайна.....
    Кстати как предпочитаеш....расстрел или через повешение....:)
    Собсно я с этого и начинал...это потом до матриц докатился....
    Но вот сейчас еще раз проверил (жизнь всетаки на кону)
    Неработает.
    В варианте с матрицами при определенных положениях камеры
    он таки начинает коегде маршировать но только местами.
    Сдаеться мне что трансформа P мало. Надо трансформить
    целую систему E........P. Короче я окончательно запутался....
     
  19. Guest

    Жить очень хочется. Ну представь себе, что это просто 6 shadowdistant lights. Как в light шейдере определять - где тень, а где нет? Просто shadow(...Ps...) и все. Он работает в "current" space, который - что в light, что в surface шейдере - один. Или я совсем тупой? Блин, щас приду домой, сяду BMRT мучить!
     
  20. Guest

    Пришел домой, открыл ArMan, а там - куча Volume шейдеров с scattering, self-shadowing и так далее! Я до них в плановом порядке еще не добрался :) Но если тебе срочно - на www.renderman.org должны быть исходники всех этих шейдеров из книжки. Если что не поймешь - пиши, в конце концов я могу пару страниц отсканить и распознать.
     
Модераторы: Moderator.

Поделиться этой страницей