ShadowMaps
- Автор темы Narvi
- Дата создания
По моему опыту, eyeSplit равное 3 - лучший выбор рендеровода для камеры внутри закрытого пространства и в большом количестве других случаев
При этом в большинстве случаев ни каких глюков не наблюдается, хотя конечно ПРман ругается, но при этом тормозов не бывает (как при eyeSplit = 10). Причем если при 3 получаюстя глюки, то обычно даже 10 не помогает
При этом в большинстве случаев ни каких глюков не наблюдается, хотя конечно ПРман ругается, но при этом тормозов не бывает (как при eyeSplit = 10). Причем если при 3 получаюстя глюки, то обычно даже 10 не помогает Shadow maps генерятся для каждого объекта к которому они приаттачены, при этом, позиция и aim direction объекта(light) становятся тем же для камеры. Параметр near - это near of clipping plane, для этой камеры. Если стоит 0, то используется global default settings.
Может помочь оптимизация spot lights:
1. Сделать конусы как м/о меньше.
2. В поле "Objects in Map" указывать объекты которые участвуют в образовании тени, для каждого light in question. В противном случае участвуют все объекты.
По поводу вопроса вдогонку:
"By default, MTOR generates a shadow RIB file using the current light's information for position, cone angle, field-of-view etc."
1. Создать rib для каждого источника света, либо раздраконить большой rib.
2. Если рендеришь по сетке, то очевидно, что все доступные машины, master shedule, service keys, priorities etc. прописаны в huntgroups. И выглядят примерно так:
Name host UDI Selection Keys
[Gumby] [iris42] [5] [pixarRAT pixarRender SGI big fast FieldTrip]
[Pokey] [sun007] [1] [pixarRender pixarNRM Sun fast NightWalrus]
если нет, то надо создать.
3. Имея рибы сгенеренные MTORом, типа light1.rib запускаешь script
##AlfredToDo 3.0
Job -title {A Simple Job} -subtasks {
Task {Scene One} -subtasks {
Task {Shadow A} -cmds {
Cmd {netrender -f -Progress render light.1.rib} -service {iris42}
}
Task {Shadow B} -cmds {
Cmd {netrender -f -Progress render light.2.rib} -service {sun007}
}
} -cmds {
Cmd {render scene01.rib}
}
}
Названия job, scene etc. естественно свои. С названиями теней поосторожнее - ссылки на них в поле file должны быть корректными.
После того, как тени будут готовы, начнет рендерится scene01.rib.
Может помочь оптимизация spot lights:
1. Сделать конусы как м/о меньше.
2. В поле "Objects in Map" указывать объекты которые участвуют в образовании тени, для каждого light in question. В противном случае участвуют все объекты.
По поводу вопроса вдогонку:
"By default, MTOR generates a shadow RIB file using the current light's information for position, cone angle, field-of-view etc."
1. Создать rib для каждого источника света, либо раздраконить большой rib.
2. Если рендеришь по сетке, то очевидно, что все доступные машины, master shedule, service keys, priorities etc. прописаны в huntgroups. И выглядят примерно так:
Name host UDI Selection Keys
[Gumby] [iris42] [5] [pixarRAT pixarRender SGI big fast FieldTrip]
[Pokey] [sun007] [1] [pixarRender pixarNRM Sun fast NightWalrus]
если нет, то надо создать.
3. Имея рибы сгенеренные MTORом, типа light1.rib запускаешь script
##AlfredToDo 3.0
Job -title {A Simple Job} -subtasks {
Task {Scene One} -subtasks {
Task {Shadow A} -cmds {
Cmd {netrender -f -Progress render light.1.rib} -service {iris42}
}
Task {Shadow B} -cmds {
Cmd {netrender -f -Progress render light.2.rib} -service {sun007}
}
} -cmds {
Cmd {render scene01.rib}
}
}
Названия job, scene etc. естественно свои. С названиями теней поосторожнее - ссылки на них в поле file должны быть корректными.
После того, как тени будут готовы, начнет рендерится scene01.rib.
По поводу разбрасывания подзадач по машинам, можно поковырять настройки Alfred-a. Сейчас точно не скажу какие, т.к. сетки под рукой нет, но была ситуевина, когда на одну тень набрасывались все хосты одновременно, потом после простой правки, типа min/max processors 1/1 (или типа того -- не помню), за каждую подзадачу брался один комп.
Тогда, если интересно, можешь попробовать рендерить тени отдельным проходом, а потом композить.
Плюс в том, IMHO, что можно немного упростить задачу понизив качество просчета теней, а потом доработать их в композере (разблюрить, изменить цвет, прозрачность).
Методов решения можно придумать несколько.
Варианты уже обсуждались на этом форуме (можно поиском проверить).
Andrew V.K. предлагал использовать шейдеры, просчитывающие тени в отдельные файлы. Я пробовал -- работает, но в виду ленности, в основном пользую два прохода. На первом -- рендер без теней. На втором -- в Custom Renderer -е подставляется Perl скрипт заменяющий на всех поверхностях шейдер на ratBackplaneS (остаются черные тени на белом фоне).
Польза в том, что иногда приходится перерендерять только слой без теней (если конечно геометрия не меняется). Ну и можно просто загрузить отдельную группу машин рендерингом теневого прохода -- и пусть себе считают в свободное от отдыха время.
Плюс в том, IMHO, что можно немного упростить задачу понизив качество просчета теней, а потом доработать их в композере (разблюрить, изменить цвет, прозрачность).
Методов решения можно придумать несколько.
Варианты уже обсуждались на этом форуме (можно поиском проверить).
Andrew V.K. предлагал использовать шейдеры, просчитывающие тени в отдельные файлы. Я пробовал -- работает, но в виду ленности, в основном пользую два прохода. На первом -- рендер без теней. На втором -- в Custom Renderer -е подставляется Perl скрипт заменяющий на всех поверхностях шейдер на ratBackplaneS (остаются черные тени на белом фоне).
Польза в том, что иногда приходится перерендерять только слой без теней (если конечно геометрия не меняется). Ну и можно просто загрузить отдельную группу машин рендерингом теневого прохода -- и пусть себе считают в свободное от отдыха время.