РасширениеВозможностейРендерера

Расширение возможностей prman.


Как и большинство других production-ready рендереров, prman допускает расширение своих возможностей путём реализации новой функциональности в виде плагинов в нескольких направлениях:

  1. Вы можете написать специальный драйвер дисплея (dspy в терминологии Pixar), который позволит записывать/показывать результат рендеринга в собственном формате/окне/передавать в собственную систему.
  2. Существует возможность написания генераторов RIB кода (Rib Gen), вызовы которых встраиваются в RIB файлы.
  3. И наконец, и это наиболее известный факт, можно расширять Shading Language своими собственными функциями.

На Siggraph 2003 Pixar показала новые возможности расширения prman, которые будут предоставлены пользователям prman 12. Поскольку для нас это актуально пока что только теоретически, отсылаем читателя к первоисточнику.


Как видно из приведенного выше списка, он не очень велик :( Так, отсутствует возможность встраивать собственную функциональность напрямую в rendering engine, скажем, на определённом этапе; отсутствует возможность скриптования движка рендеринга; этот список можно продолжить. Тем не менее, имеющиеся возможности представляются автору достаточно проработанными и удачно реализованными.


Итак, в prman определены 3 типа расширений – dspy, SL Shade OP и Rib Gen. В том или ином виде эти расширения поддерживаются большинством Renderman-совместимых рендереров; тем не менее, приведённые далее примеры проверялись только для prman.


Dspy и расширения SL реализуются при помощи DSO – эта аббревиатура (Dynamic Shared Object) пришла к нам из мира Unix и обозначает то же самое, что и привычная пользователям Windows DLL (Dynamic Linking Library) – некий бинарный объект, содержащий в себе выполнимый код и некоторый, заранее объявленный набор интерфейсов, по которым этот код можно вызвать из посторонней программы. Данные объекты в системах Unix имеют расширение файла *.so; Windows определяет эти файлы как *.dll; в некоторых системах рендеринга принята своя собственная система именования файлов (в 3dlight драйвер дисплея должен иметь расширение *.dpy).


С Rib Gen ситуация несколько посложнее, поэтому мы поговорим о них чуть ниже.

SL Shade OP.

  1. Основные положения. BMRT raytracer как классический пример.

Написание новых функций(shadeops) на С и разметка их как DSO имеет много преимуществ перед написанием функций на SL, включая:
    • Результирующий объектный код DSO используется во всех вызовах во время рендеринга. Для сравнения, в откомпилированном коде шейдера функции подставляются inline при каждом вызове и не предполагается общего использования функций отдельными шейдерами, вызывающими одну и ту же функцию. непонятно, нужно перефразировать.
    • DSO функции компилируются в машинный код, тогда как функции шейдера интерпретируются. Хотя у PRMan очень эффективный интерпетатор, он всё же медленнее выполнения машинного кода.
    • DSO функции могут вызывать функции из стандартных С библиотек или библиотек сторонних производителей.
    • Функции, реализованные на SL, ограничены операциями и типами данных, доступными в Shading Language. DSO-функции могут использовать все возможности, доступные для С программ, например, сложные структуры данных или работу с файлами.
DSO функции имеют некоторые ограничения, которые следует учитывать:
    • в общем случае DSO функции имеют доступ только к информации, передаваемой им в качестве параметров. Они не знают о глобальных переменных шейдера, таких как P, параметрах шейдера или режимах рендеринга. Если требуется доступ к глобальным переменным или параметрам шейдера локально, нужно передавать их как параметры. prman позволяет доступ к глобальным параметрам рендерера посредством библиотеки Rx, которая не является стандартной, но достаточно подробно описана в соответствующей документации.
    • DSO функции выполняются как одна точка процесса. Они не знают о топологии поверхности, производной и т.д. Это также при необходимости следует передавать как параметры.
    • DSO функции не могут вызывать встроенные функции из SL или другие внутренние точки входа самого рендера.

Вы можете компилировать свои DSO компиляторами ‘C’ или ‘C’, но следует использовать ‘C’ разметку – т.е. при применении C необходимо использовать extern “C” для гарантии C-style разметки.


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


Каждая новая SL функция имеет три С функции: init функция, method, и shutdown функции. Они имеют следующие прототипы:

void *init(int ctx, void *texturectx);
int method(void *initdata, int argc, void **argv);
void shutdown(void *initdata);

Опциональная функция init вызывается перед первым использованием method, и может быть использована для инициализации переменных, выделения памяти, построения типов данных, и т.д. Функция init имеет два аргумента: integer обозначающее уникальный ID процесса и void* которое является дескриптором текстурируемого контекста для данного потока. Если method использует где-либо эти данные, то их необходимо сохранить где-нибудь и выйти из инициализатора. Тем не менее, эти параметры не обязательно использовать.


Функция init возвращает void*, который может возвращать любую структуру данных, которую Вы зададите в процессе инициализации. Функция init может возвращать NULL, или отсутствовать вовсе, если не требуется явная инициализация. Функция init обычно вызывается однажды в начале рендеринга, но может однократно вызываться для каждого процесса при сетевом рендеринге.


method вызывается каждый раз при вызове SL функции. Возвращает 0 при успешном выполнении, 1 при ошибке. Метод имеет три аргумента: указатель на результат функции init (*initdata), количество аргументов SL функции, массив из указателей на аргументы SL функции (argc). argv[0] – указатель на результат работы SL функции, argv[1]... argv[argc-1] – указатели на аргументы SL функции.


Опциональная функция shutdown вызывается по окончанию всего рендеринга и обычно используется для освобождения выделенной памяти. Аргумент – указатель на результат работы init.


  1. Пример на C. Особенности работы со строками. Код от JFong:


Пример 2:

sqr.c:

testsqr.sl:


И еще пример:


Компиляция:


SGI: cc -n32 -mips3 -I/usr/local/prman/include -c sqr.c
ld -n32 -mips3 -shared sqr.o -o sqr.so
SUN: cc -I/usr/local/prman/include -c sqr.c
ld -G sqr.o -o sqr.so
Alpha: cc -I/usr/local/prman/include -c sqr.c
ld -shared sqr.o -o sqr.so
Linux: cc -I/usr/local/prman/include -c sqr.c
ld -shared sqr.o -o sqr.so

  1. Пример на Delphi. Особенности.
  2. Особенности реализации бакетов в prman?

“Rib Gen”.

  1. Основные положения.
  2. Пример на C.
  3. Пример на Perl.
  4. Пример на Delphi.

Тут не всё так однозначно. Под словом Rib Gen, вообще говоря, понимаются 3 сущности, выполняющие одинаковую, с точки зрения пользователя, задачу – генерацию RIB кода:


  1. DSO 
  2. RunProgram
  3. RIB Gen (MTOR) = Maya + Mtor Api + DSO.

Dspy.


  1. Основные положения.
  2. Пример на C.
  3. Пример на Python (работает, возможно, только под Aqsis, но хорош в качестве примера). http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/aqsis/renderer/pythondisplay/

Что почитать, благодарности.