вторник, 9 октября 2007 г.

Sler AOV

Вот, для тех кто в курсе, что такое Sler. Если это не про вас, смотрите это.

Релизовал я таки в Sler AOV, хотя и не до конца. Получилось хоть и Output Variables, но точно уж не Arbitrary.

Посмотреть чего я натворил и как это использовать можно тут.

Суть такова, что все входы всех блоков не будут использоваться для аргументов генерируемых шейдеров (как это было раньше), если это явно не указать. Что вроде бы логично, т.е. обычно нужно изменять только некоторые атрибуты шейдера. В будущем нужно будет реализовать высокоуровневые команды, типа "Установить все инпуты всех блоков ниже по иерархии для использования в качестве аргументов шейдера". Ну и так далее.

Более того, аргументы можно объявить как output, что даст возможность записывать в файлы всё, что присваивается им внутри кода шейдера, т.е. то с чем это аргумент соеденён в редакторе графа.

И ещё, для инпутов теперь можно задать storage class (см. инфу по RenderMan, например, спеку) и вот как это работает.

Если инпут используется как аргумент, и ни с чем не соеденён, то storage class просто указывается в аргументах шейдера. По умолчанию storage class для всех будет uniform.

Если инпут используется как аргумент и соеденён с чем либо (имеет смысл только если он также объявлен как output), то storage class игнорируется, и в шейдере записывается storage class источника.

Если инпут не используется в качестве аргумента, то и storage class не используется никак, т.к. при генерации подставляется значение инпута, а не имя его переменной. Мало того, переменная не создаётся вообще.

Ну вот и всё вроде.

P.S. Ну а для того, чтобы сделать полноценный AOV нужно всего лишь реализовать возможность создания пользовательских инпутов, а остальное прибудет автоматически. Это должно быть понятно из вышесказаного.

понедельник, 1 октября 2007 г.

Запечённое освещение

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

Для моего текущего проекта необходимо очень маленькое время рендеринга отдельного кадра, в идеале конечно рилтайм, но это врядли достижимо. К тому же предполагается использование размытия движением и DoF эффекта, что значительно снижает скорость. А если использовать эти эффекты совместно с трассировкой лучей, то врядли удастся дождаться завершения рендеринга всей анимации.

Сколько времени требуется на рендеринг? Если длительность ролика 3 мин, и кадров в секунду 24, то получается 1440 кадров в минуте или всего 4320 кадра. Допустим время рендеринга одного кадра 3 минуты, тогда на рендеринг всей анимации понадобится 12960 минут, 216 часов или 9 суток.

В принципе это не так уж и много, но этих 3-х минут на кадр нужно ещё достич. Особенно если речь идёт о фотореалистичности.

Эффекты Motion Blur и DoF очень полезны в достижении реализма, кроме того, можно было бы использовать глобальное освещение, но на его расчёт требуется не приемлемое в моём случае количество времени.

К счастью Motion Blur и DoF имеют очень эффективные реализации. Например, RenderMan-совместимый рендерер 3Delight расчитывает эти эффекты очень быстро. Свободные RenderMan-совместимые рендереры Pixie и Aqsis тоже вполне для этого пригоды. Но это только в случае scanline рендеринга, для трассировки лучей эти эффекты довольно медленны.

Поэтому я буду обходить это ограничение. Например, можно в одном кадре запечь освещение в 2D или 3D текстуры и использовать их во всей анимации. Это конечно имеет смысл только для неподвижных объектов, которых однако очень часто большинство в сцене. В моём случае это действительно так.

Подвижные объекты будут освещаться отдельно, локальными источниками света, что не будет резать глаза при правильном подходе и их подвижности. Также можно использовать гибридный подход и расчитывать для них GI используя упрощённую геометрию и/или группы освещения для GI.

В Blender есть хорошая возможность для запекания результата рендеринга в текстуры. Вот тут:


Как видно можно запечь следующее: все вычисления рендеринга (Full Render), только Ambient Occlusion, нормали или текстуры. При нажатой кнопки Clear запечённые текстуры будут отчищаться перед очередным тестовым рендерингом. Margin влияет на кол-во пикселей, на которые будет расширен результат запекания, это делается для избежания чёрных полос на краях полигонов из-за интерполяции при получении значения из текстуры.

Однако перед запеканием объект должен быть развёрнут. Blender даже имеет специальный режим развёртки для LightMap (U в FaceSelect режиме -> LightMap UVPack), который делает развёртку полностью автоматически, однако далеко не всегда подходящую.

Мне нужно только AO, его я буду использовать вместо вызова occlusion в шейдерах. Стоит заметить, что это предварительный вариант, позже я возможно воспользуюсь одним из RenderMan-совместмых ренедереров для рассчёта карты освещения, если в этом будет необходимость.

Итак, вот тестовая сцена.

Включаю AO (F8->Amb Occ), устанавливаю кол-во сэмплов в 16, т.к. тут больше нужно заботися о разрешении тектсуры для запекания. Для UV кубика делаю картинку с разрешением 256x256, этого пока хватит. Устанавливаю Ambient Occlusion во вкладке Bake и жму соотвествующую кнопку. Повторяю для плоскости.

Перевожу Blender в режим отображения текстур. И вот что имею.


А вот и мой бульдозер с AO в реальном времени (правда ещё не все карты доделаны). Это то, что нужно, т.к. сам бульдозер не будет трансформироваться или деформироваться в процессе анимации. С такого расстояния как показано на картинке, для качественного результата вполне достаточно текстур с разрешением не большим 1024x1024. Максимально 1024 используется для корпуса и кабины. На некоторых мелких деталях можно использовать128 и даже 64.


Теперь я могу без пробем использовать Motion Blur и DoF, не боясь тормозов с трассировкой лучей. Motion Blur имеет смысл разве что для камеры, т.к. объект неподвижный.

Теперь вот нужно придумать чем ещё заполнить сцену, чтобы рендеринг занимал 3 минуты как задумано, а не доли секунды =). Думаю за этим дело не станет.