ONCE per JOB

Привет знатокам

Поразительная вещь - тени OncePerJob считаются для летящего многодетального объекта, источники света прилинкованы к этому объекту, и ,естественно, я хочу тени для них одинаковые в каждом кадре, а они , просчитавшись в первом кадре
(с поставленным на него referance frame) в следующих - накладываются "в том же месте пространства", то есть не проецируются из привязанных летящих источников. ;(
Эффект таков: объект "вылетает из своих теней", и прекрасно летит дальше без них.
Как же привязать просчитаные в 1-м кадре тени к движущимся источникам?
Может ObjectSpace-ы какие-ввести?

Алексей Гусев

 

Я об этом говорил на Виагре. Скоро вроде в сети кой чо про виагру появится

По сути: Хитрость в том что шадоу мапа в себе имеет матрицу трансформации в координатную систему источника из которого мапа считалась, упрощенно говоря там записано где источник находился когда мапа считалась. Обойти эту проблему можно модифицируя стандартный темплейт шедоу мапы. Вводится дополнительная МТОРовская координатная система coordsys, после чего она кладется внутрь анимируемого трансформа (туда же где твои источники света лежат). В том кадре, в котором считается тень, эта референсная система должна иметь нулевые значения ориентации в пространстве, соответственно в любом другом кадре значения трансформа этой системы равны смещению тени относительно исходного кадра. Дальше трансформируем точку относительно этой координатной системы и используем базовую тень:
...
tQ = transform ("current", "world", tQ);
tQ = transform ( "world", coordsys, tQ);
tQ = transform ("world","current", tQ);
...

ЗЫ.Можно написать простой майский скрипт, который будет обнулять все такие трансформы (они, например могут определенным образом называться) в начальном кадре, а потом вызов этого скрипта вставить перед вызовом рендера.

 

Привет, JinnDOS

Озадачил ты меня....
Правильно ли я понял: в textures.slim в pxslSoftShadowMap нужно ввести
твои три строчки после
uniform point p0, p1, p2, p3;
uniform float r = softsize * .5;
И далее, может воспользоваться констрейнтами для помещения этого coordsys-а чтобы его координаты всегда были мировыми?
И уйдет ли эта проблема если источники не линковать а констрейнтить?


Алексей

 

Ты не до конца понял - в шадоу мапе _записано_ то место с которого она считалась (это упрощенно). КОгда ты вызываешь функцию shadow она считывает эту координату и считает затен ли обьект именно из этой точки. Обойти это можно, если подсунуть функции shadow точку не настоящую а сдвинутую обратно, на то же место где она была, когда считалась шадоу мапа. Сделать это можно только внутри шейдера (можно конечно обратить трансформ в майке и наложить эти трансформы на все обьекты в сцене - тогда двигаться будут все остальные обьекты относительно исходно санимированного - типа теория относительности)
Так вот надо написать свой шейдер (он же темплейт) Переписывать существующий нехорошо, так как старые сцены могут перестать работать.
Лучше написать свой темплейт и добавить его например после существующего.
На самом деле я эту фигню писал только для обычного шэдоу, но по идее аналогично будет и для софт:
скопируй шедоу темплейт,
измени: "templateV float SoftShadowMap 1" на "templateV float JSoftShadowMap 1"

перед collection manifold manifold {......

добавь parameter string coordsys {
default ""
}

вместо RSLFunction {
void
pxslSoftShadowMap(....){.....}

вставь

RSLFunction {
void
pxslJSoftShadowMap(
uniform string filename;
uniform float softsize;
uniform float samples;
uniform float blur;
uniform float bias;
uniform float gapbias;
string coordsys;
point Q;
vector dQu;
vector dQv;
output float result
{
uniform point p0, p1, p2, p3;
uniform float r = softsize * .5;
point tQ = Q;
p0 = point "shader" (-r, r, 0);
p1 = point "shader" (r, r, 0);
p2 = point "shader" (r, -r, 0);
p3 = point "shader" (-r, -r, 0);
if(filename == "")
{
result = 0;
}
else{
if (coordsys != "")
{
tQ = transform ("current", "world", tQ);
tQ = transform ( "world", coordsys, tQ);
tQ = transform ("world","current", tQ);

}


if(bias != 0)
if(bias != 0)
{
result = shadow(filename, Q,
"samples", samples,
"blur", blur,
"bias", bias,
"source", p0, p1, p2, p3,
"gapbias", gapbias);
}
else
{
result = shadow(filename, Q,
"samples", samples,
"blur", blur,
"source", p0, p1, p2, p3,
"gapbias", gapbias);
}
}
}
}

(Не забудь проверить все открывающиеся - закрывающиеся скобки ;-)
сделай релоад обычной шадоу мапе (или перегрузи майку) и у тебя появится новый темплейт с дополнительным полем coordsys. Твори с этим шейдером что душе угодно

 

а не велосипед ли это очередной? Я к тому, что shadowmaps считаются очень эффективно, особенно если все лишнее поисключать, и не факт, что все эти многочисленные трансформы дадут тебе выигрыш по времени. тем более, что если ты будешь трансформировать обратно только точки движущегося объекта, то на себя то он тень отбросит, а вот на все остальное?

 

Я прошу прощения за, видмо плохое знание русского фольклора, но помоему выражение про изобретение велосипеда применяется обычно в других случаях (или кто-то уже предлагал такой вариант просчета тени в этой конфе?;-))
С другой стороны я не славлюсь совершением необдуманных поступков (иначе я уже давно сидел бы без работы...

В сторону шутки:

"Сдвинуть точки обратно" - это фигурное выражение, для более легкого понимания. Считаем так: шадоу мапа остается на одном месте, когда просчитывается затененные точки обьекты сдвигают в начальное положение (это тоже самое что сдвинуть мапу на величину трансформа). Конечно же такая шадоу мапа будет отбрасывать тень на все обьекты, но с другой стороны не анимированные данным трансформом обьекты, попавшие в шадоу мапу в момент генерации, не будут правильно отбрасывать тень. Проще говоря - если летят два самолета и источник свет находится только на одном, то от этого самолета тень на землю (и на другой самолет) будет правильной, но от второго нет. С другой стороны можно повесить источники на оба самолета, причем при генерации исключать другой самолет из просчета, тогда все будет зашибись

К вопросу о скорости. Три дополнительных трансформа на один пиксел - это смешно их там в процессе просчета значительно больше. Чтоб не быть голословным сделал тестовую сцену: 800 шариков с самым простым шейдером (чтоб меньше давал эффекта). Разрешение 640х480. Тень 2048 (нормальная тень для такого кол-ва деталей - для киноразрешения может потребоваться значительно больше).Кол-во самплов 16, блюр 0.01. Один процессор 1 ггц. Время просчета тени: 2мин 55 сек. Время просчета картинки: с трансформированием точки 53 сек, без трансформирования 52 сек. Проигрыш = 1 сек ) Тот-же случай но с анимацией на 30 секунд: Выигрыш от нерендереных теней: 36 часов 25 мин. Проигрыш от увеличения времени рендера картинки: 0 часов 12 минут. Суммарный выигрыш 36 часов 13 минут. Комментарии? ;-))
На самом деле могу приветсти информацию по реальным кино-проектам в которых учавствовал. Очень часто время просчета тени вылазит за 20 минут на кадр (и это отнюдь не на одном процессоре), так что экономия даже на коротеньких проектах может быть гигантской.

С другой стороны применение данного подхода имеет большие ограничения, но тут уж ни чего не поделаешь...

Ну вот вроде и все что я хотел сказать

 

в свою очередь прошу прощения... не шпециалишт я в рендермэне, не шпециалишт, так, по верхам нахватался...

>На самом деле могу приветсти информацию по реальным кино-проектам в >которых учавствовал. Очень часто время просчета тени вылазит за 20 минут >на кадр (и это отнюдь не на одном процессоре), так что экономия даже на >коротеньких проектах может быть гигантской

приведи. было бы интересно!

 

Я говорил, что скоро выйдет материал по Виагре, где я приводил статистику по одному из проектов. В общих словах - 30 сек рекламный ролик под кино, рендерился 1 месяц на 15-20 процессорах. В начале есть порядка 3 секунд (около 5 сек грязного времени) пролета космического кора@!#$ который подходит под выше описанную технологию. Просчет тени 2х2к длился порядка 10-20 минут (точно не помню) на нескольких процах. Ну я и решил переписать темплейт. Выигрыш помоему получился приличный (Тем более что мне пришлось несколько раз перерендеривать сиквенс ;-))

 

сдается мне что я видел этот ролик... хороший ролик! уважаю!

 

Черт круто мне понравилось !!!
(это я про статистику)

Я просто пользовался (твоим я тоже начал но пока совсем чуть чуть... правда я его модифицировал ну чтобы можно было не ставить координатную систему, а использовать информацию о матрице хранящиесю в shadow map) другим триком который "просто" (приблизительно в 15 - 30 раз) увеличивыет скорость просчета тени (ну и тени я часто кидаю восновном от персонажей, а они как бы имеют злобную особеность совершать всякие деформации в пространве на протежении времени)...

 

Хм, а что это за другой трик? Колись Костик!

Слушай я помоему туплю, но как поиметь точку, в которой находится лайт в данный момент?

 

Все ниже следуюшее работает восновном только с PRMan:

##########################################################3
1. Делаем Rib box сo следуюим содержанием

---------------
[if {$ELEMENTTYPE == "shadow"} {
return "ShadingRate 32"
}]
---------------

2. Можно использовать и более большой шадингРайт.
Только при шадингРайте более 50 становится замента
разбиение при теневом просчете - каcательно PrMan'а,
используете небольшой блюр для завуалирования этого.

3. И называем его world_FastShadow

4. Типа все рендрим.


Пример Rib файла для теней:
----------------------
XXXXXXXXXX
WorldBegin
XXXXXXXXXXXX

#### Плохая строчка (by Def. Mtor) #####
ShadingRate 1

#### Нужные строчки (by Def. Mtor) #####
ShadingInterpolation "constant"
Surface "null"

XXXXXXXXXXXX

#### Очень нужная строчка переопределяющая плохую (by RibBox Mtor) #####
#slim ribbox world_FastShadow
ShadingRate 32

# obj 1
AttributeBegin
xxxxxxxxxxxxx
AttributeEnd
# obj 2
AttributeBegin
ShadingRate 4
XXXX
Displacement "XXXXXX" XXXX
XXXXXXXX
AttributeEnd
# obj 3
AttributeBegin
XXX
ShadingRate 2
XXX
Surface "XXXXXXXX" XXXXXXXX
XXX
Displacement "XXXXXX" XXXX
XXX
XXXXXXXX
AttributeEnd
XXXXXXXXXXXX
# Section N
AttributeBegin
xxxxxxxxxxxxx
AttributeEnd
WorldEnd
FrameEnd
----------------------

Oписание для оъбектов:

1. (Непрозрачные объекты без дисплейсмента заметного в тенях) Essemble и Cast Shadow = Opaque

2. (Непрозрачные объекты с дисплейсментом заметным в тенях) Essemble Adaptor -> element Type = shadow -> Essemble только с displasmentom для просчета теней и с Shading Rate = 4 (можно и больше)

3. (Прозрачные объекты с дисплейсментом заметным в тенях) Essemble и Cast Shadow = Shade и Shading Rate = 2 (можно и больше)

Статистика для обычной сцены:

* Количесво обектов N1 > 90 процентов
* Количесво обектов N2 < 10 процентов
* Количесво обектов N3 < 1 процента (если вобше нужны скажам так прозрачные тени)

Вывод:
* Прирост производительности от 15 до 40 раз по сравнеию со стандартным вариантом

 

Круто! Молодец
Я вообще то что-то подобное пробовал, но не с такой технологической проработкой (просто назначал на некоторые обьекты ШР порядка 8).
Твоя статистика меня радует, но тут есть одно но - я большой любитель дисплейса . В моих сценах сильно задисплейсеных обьектов может быть 10%, но зато они покрывают 90% площади картинки Если ты помнишь - пол и стенки, сиденья, груз.... почти все имело сильный дисплейс. Одно время я даже простенькую травку делал дисплейсом. Ну не могу я без него %)).

Кстати о тенях и ансам@!#$х. То что ты сказал: хорошо, но у меня дисплейс наложеный через ансамбль не рендерится в шадоу пасс. Точнее рендерится просто ансамбль если либо изменить Casts Shadow на что-либо кроме Opaque, либо поставить Displacement Bound какой-нибудь не нулевой. А через Адаптор Ансам@!#$ вообще ни когда не рендерится. Это глюк, мне кажется, либо мой, либо МТОРовский.

 

04:16 !!!!!! Круто !!!!
Jinn ты вообще спиш когданибудь

 

Конечно сплю Заметь: некоторые умудряются писать в 12:04 утра - это же такая рань ;-)))))

 

Ну так назначай на них SH = 8 - 10 и оставляй диплесмент, поиграйся со созначениями, тебе же нужен восновном хорошой абрис для падуших теней, а на остольные 32 и без материалов ... Ну и производительность возрастет от 8 до 30 раз... Типа все равноже гуд..

Ну и не зыбывай в просчете теней при испрользованиии RibBox c процедурными приметивами тоже не делать лишних вызовов шейдеров..
(используй констукции типа IF.... )

А про окружение я тебе так скажу, оно же восновном твердое (конечно у некотрых яшики умеют прыгать при полете на супер современных кара@!#$х вражеской постройки и согласись что все остальное же стоит на месте ) так что линкуй источники света к окружению и вперед... Честные тени (изменяюшиеся от кадра к кадру) нужно кидать толькоо ОТ 1. CG персонажей 2. Летающих CG блюдечек....Теперь и они будут драматикали считаться фастер зен евер

А со с асамбли и с адаптор асамбли у меня вроде все работает я вроде многочисленное кол.раз проверял...

Да еще про то как дорабатать твой шейдер - дня через два .. Я шаз просто в инет кафе и шейдера под рукой почемуто не оказалось...

Типа все... Изредка нужно спать ... Чесное слово помагает...

 

Гуд, в общем правильно А про детали поговорим в понедельник лицом к лицу - сечешь фишку? ;-))))

 

Я то секу... Что понедель будет веселым...
Один хочет что бы я сек фишку утром, помотом наверное днем другой , ну и вечером третия ... Ладно я тебе вообшем позвоню в понедельник этак в 12 ...
Все давай ....

 

Крут! Бью в ладоши от щастья ) К соему стыду, я даже не знал, что в риббоксе можно на TCLе писать

 

Привет, JinnDOS

Сдалал все как ты сказал, темплейт появился, создал coordsys, поместил и сорентировал его по источнику света в первом кадре, прилинковал его к тому же ,к чему и свет, сбросил трансформ атрибуты, ввел имя mtorCoordSysShape в поле coordsys. Поставил пока EveryFrame. Считаю первый(исходный) кадр. Стичаться- тени считаются - но на выходе их нет....
что не так?

Алексей