Mental ray не является рендер-плагином. Mental ray - это рендер-система. Гибкая, мощная, расширяемая и настраиваемая. Наибольшую выгоду можно извлечь только в том случае, если она используется как "равноправный партнер" в связке "программа моделирования + программа рендеринга". Встраивание неизбежно влечет ограничения. Предлагаемая ниже информация предназначена совсем не для программистов. А для тех, кто хочет получить в свое распоряжение все возможности этой замечательной рендер-системы, работать с ней в полную силу, без купюр, и вне зависимости от используемого пакета моделирования. Речь пойдет о рендеринге сцен и анимаций при помощи самостоятельной версии mental ray (standalone версии).
Mental ray обладает собственным языком описания трехмерных сцен. Прежде чем сцена или анимация смогут быть отрендерены, они должны быть представлены языковыми конструкциями, понятными для него. Такое описание необходимо всегда, выполняется ли рендер встроенным в пакет трехмерного моделирования mental ray или же его независимой версией.
В 3D пакетах описание - перевод возложено на специальную подпрограмму - транслятор и опирается на библиотеку дополнительных шейдеров, являющихся, по сути, описанием конструкций пакета моделирования на языке mental ray. Другими словами, каждый из элементов, которым оперирует пакет - геометрические объекты, камеры, источники света, материалы, окружение, типы освещения, динамика, анимация, спецэффекты, все имеют соответствующий шейдер, описывающий их возможности и свойства понятным для mental ray образом.
Подборка таких шейдеров индивидуальна и образует библиотеку, без которой совместная работа данной программы моделирования и mental ray просто невозможна. Дополнительные шейдеры хранятся в специальных файлах, имеющих в Windows расширение dll. Например, для 3ds max 7.x такой файл - 3dsmax7.dll, а для Maya - mayabase.dll.
Процесс перевода, или трансляции сцен для рендера происходит "на лету" и при обычных условиях совершенно незаметен. В рамках программы трехмерного моделирования мы всегда имеем дело с конечным результатом в виде готового просчитанного изображения или анимации.
Тем не менее, трансляция сцены может быть записана в файл с расширением .mi и такую возможность предоставляют все трехмерные пакеты со встроенным mental ray. Выполнив экспорт сцены, можно получить доступ к ее описанию и редактированию этого описания в каком-либо текстовом редакторе, если экспорт выполнен в ASCII формате. Зачем это нужно?
Основная причина - получить доступ ко всем возможностям mental ray. По вполне объективным причинам реализация встроенной версии всегда является неполной. Выполняя рендер только в рамках интерфейса того или иного 3D-пакета, мы всегда будем ограничены, лишены доступа к каким-либо важным и нужным функциям mental ray.
Для 3ds max это очень актуально. Бурно развиваясь сразу во многих направлениях, он нередко страдает "издержками роста" - некоторые относительно новые его возможности не всегда идеально реализованы. Ситуация со встроенным mental ray не является исключением. Предоставляя в наше распоряжение один из самых надежных в индустрии трансляторов, который работает практически безошибочно, он "не страдает" как раз полнотой реализации. В результате, наиболее оптимальным способом работы, по крайней мере, на сегодняшний день, является моделирование сцен в 3ds max, экспорт сцен в mi - файлы с последующим редактированием и их рендер из командной строки самостоятельной (standalone) версией mental ray.
Хотя дальнейшее изложение ведется на примере работы с 3ds max, бОльшая часть предлагаемой информации носит универсальный характер и будет справедлива и в случае использования других 3D- пакетов.
Язык mental ray прост и интуитивно понятен, потому что логичен и продуман. Поэтому его изучение дается легко, а сам процесс - увлекателен и доставляет моральное удовлетворение. "Скелет" трехмерной сцены
Начнем с изучения структуры трехмерной сцены, какой ее "видит" mental ray.
"Скелет", или основу, описания сцены составляет совокупность необходимых элементов, которые обязательно присутствуют в любой типичной трехмерной сцене - камера, источники освещения, геометрические объекты и назначенные им материалы. Эти базовые элементы очень удобно использовать в качестве опорных точек при анализе листингов mi-файлов.
Пример. Рассмотрим описание очень простой сцены, состоящей из одной камеры, единственного точечного изотропного источника света, геометрического объекта - трехмерной пирамиды и простого синего цвета, используемого в качестве материала пирамиды. Файл сцены набран в текстовом редакторе, сохранен с расширением mi (scene_1.mi) и отрендерен standalone mental ray с использованием команды:
"ray -v 4 -x on -imgpipe 1 scene_1.mi | imf_disp -notop -"
О командах рендера мы еще поговорим, а сейчас рендер этой сцены:
Рендер простой сцены
и листинг ее mi-файла:
| # mi 3.4 | |
| # ------------------------------------scene_1.mi |
| link "base.dll" | |
| $include |
| options "SceneOpt" | |
| samples 0 1 | |
| contrast 0.05 0.05 0.05 0.05 | |
| scanline on | |
| filter box 1.0 1.0 | |
| object space | |
| end options |
| camera "myCam" | |
| frame 1 | |
| output "rgb" "Scene_1" | |
| focal 4.345584 | |
| aperture 3.6 | |
| aspect 1 | |
| resolution 500 500 | |
| end camera |
| instance "myCam|Inst" "myCam" | |
| transform | |
| -0.46947578 0.28016394 -0.83731753 0 | |
| -0.88294536 -0.14896753 0.44521475 0 | |
| -6.8064194e-009 0.94832307 0.3173061 0 | |
| -3.8659956 -14.127339 -121.62366 1 | |
| end instance |
| light "light1" | ||
| "mib_light_point" | ||
| "color" 1 1 1 , | ||
| "factor" 0.75 | ||
| ) | ||
| origin 0 0 0 | ||
| end light |
| instance "light1|Inst" "light1" | |
| transform | |
| 1 0 0 0 | |
| 0 1 0 0 | |
| 0 0 1 0 | |
| 54.126644 4.8438337e-006 -300 1 | |
| end instance |
| material "mat" | ||
| opaque | ||
| "mib_illum_phong" ( | ||
| "ambient" 0.5 0.5 0.5, | ||
| "diffuse" 0.6 0.3 0.9, | ||
| "ambience" 0.3 0.3 0.3, | ||
| "specular" 1.0 1.0 1.0, | ||
| "exponent" 50, | ||
| "mode" 1, | ||
| "lights" ["light1|Inst"] | ||
| ) | ||
| end material |
| object "cube1" | ||
| visible trace shadow | ||
| tag 1 | ||
| group | ||
| -30.0 -27.5 0.0 | ||
| -30.0 27.5 0.0 | ||
| 30.0 27.5 0.0 | ||
| 30.0 -27.5 0.0 | ||
| 0.0 0.0 50.0 | ||
| v0 v1 v2 v3 v4 | ||
| c "mat" 0 1 2 | ||
| c "mat" 0 2 3 | ||
| c "mat" 0 1 4 | ||
| c "mat" 1 2 4 | ||
| c "mat" 2 4 3 | ||
| c "mat" 3 4 0 | ||
| end group | ||
| end object |
| instance "cube1|Inst" "cube1" | |
| transform | |
| 1 0 0 0 | |
| 0 1 0 0 | |
| 0 0 1 0 | |
| 0 0 0 1 | |
| end instance |
| instgroup "rootScene_1" | |
| "myCam|Inst" "light1|Inst" "cube1|Inst" | |
| end instgroup |
render "rootScene_1" "myCam|Inst" "SceneOpt"
# ---------------------------------------------- end scene_1.mi
Описание сцены на языке mental ray состоит из команд, устанавливающих различные опции рендера (выделены красным цветом) и шейдеров с параметрами, описывающих элементы сцен (выделены зеленым цветом).
Давайте поближе познакомимся с каждым из элементов сцены.
# Этот знак определяет начало комментария и будет проигнорирован mental ray.
# Действует только до конца строки.
| link "base.dll" | |
| $include |
Это первый в листинге блок команд и он определяет, какие файлы библиотек шейдеров и их деклараций подключаются к сцене.
Первая строка "линкует", или подключает, файл base.dll, содержащий программы шейдеров. Дословно эту команду можно перевести так: "исполняемый программный код шейдеров, которые используются в сцене, находится в файле base.dll, откуда их и нужно брать по мере необходимости".
Вторая строка указывает на файл, в котором содержатся декларации используемых в сцене шейдеров. Дело в том, что mental ray недостаточно просто знать, где лежит программа шейдера. Каждый шейдер перед первым его использованием в сцене должен быть еще и декларирован. Смысл "декларации" состоит в том, чтобы сообщить mr структуру параметров, используемых шейдером, и тип рассчитываемого (возвращаемого) шейдером результата. Во время рендера, при вызове очередного шейдера, mr получает только адрес-указатель на начало блока параметров шейдера. Если он не знает структуры, то есть количество, типы и имена параметров шейдера, он вообще не сможет извлечь необходимые данные.
По соглашению, декларации шейдеров записываются в отдельные файлы с расширением mi, которые подключаются во время рендера. Какие файлы нужны для конкретной сцены, определяется именно командой $include <имя_фала.mi> и их, также как и команд link, в фале может быть несколько, или - сколько угодно.
| options "SceneOpt" | |
| samples 0 1 | |
| contrast 0.05 0.05 0.05 0.05 | |
| scanline on | |
| filter box 1.0 1.0 | |
| object space | |
| end options |
Блок Options определяет настройки рендера, общие для всех элементов сцены. Например, настройки антиалиасинга, теней, глобального освещения и многое другое.
В 3ds max смысл и значение интерфейсных настроек встроенного mental ray определяют содержимое именно этого блока. Однако соответствие это не взаимно однозначное. Все, что есть в интерфейсе настроек рендера 3ds max, будет представлено и в блоке опций. Но далеко не все, что доступно в блоке опций, есть в настройках рендера 3ds max.
Поэтому, редактирование этого раздела mi-файла сразу дает ощутимую выгоду перед встроенным рендером.
Далее список всех опций будет рассмотрен подробно. Как видим, определение блока опций выполняется при помощи конструкции {options … end options}. Блоки настроек рендера обязательно должны иметь имя (SceneOpt в нашем случае), заключенное в двойные кавычки. Это необходимо для того, чтобы команда render в конце mi-файла смогла использовать блок настроек, сославшись на его имя.
| camera "myCam" | |
| frame 1 | |
| output "rgb" "Scene_1" | |
| focal 4.345584 | |
| aperture 3.6 | |
| aspect 1 | |
| resolution 500 500 | |
| end camera |
Конструкция, определяющая свойства камеры в сцене. Определение выполняется при помощи {camera "имя_камеры" … end camera}. Внутри конструкции перечисляются опции, настройки и шейдеры камеры (в нашей сцене шейдеры камеры не присутствуют).
Для того чтобы камера появилась в сцене и принимала участие в рендере нужно также определить ее так называемый "инстанс" (от английского "instance"). При помощи конструкции instance камера получает "адрес прописки" в сцене - трехмерные координаты, определяющие положение и ориентацию камеры. Дело в том, что определение любого трехмерного объекта, не только камеры, проще всего выполнять в пространстве, начало координат которого "привязано" к объекту - так называемом объектном пространстве. А его положение, размер и ориентацию задавать при помощи матрицы трансформации (16 чисел), определяющей преобразование объектного пространства в пространство мировых координат (world) сцены, а также масштабирование и ориентацию (углы поворота) элемента.
Это очень удобно еще и потому, что позволяет, один раз определив объект, получить, при необходимости, множество его копий в сцене, просто указав разные матрицы трансформации. Инстансы должны быть обязательно определены для камер, источников света и геометрических объектов. В нашей сцене определение инстанс-камеры выглядит следующим образом:
| instance "myCam|Inst" "myCam" | |
| transform | |
| -0.46947578 0.28016394 -0.83731753 0 | |
| -0.88294536 -0.14896753 0.44521475 0 | |
| -6.8064194e-009 0.94832307 0.3173061 0 | |
| -3.8659956 -14.127339 -121.62366 1 | |
| end instance |
Далее - конструкция, определяющая свойства источника света:
| light "light1" | ||
| "mib_light_point" | ||
| "color" 1 1 1 , | ||
| "factor" 0.75 | ||
| ) | ||
| origin 0 0 0 | ||
| end light |
определяет имя источника, шейдер освещения (light shader - в нашем случае "mib_light_point"), параметры и опции источника, такие как цвет, прозрачность тени и другие. Все настройки, опции и шейдер источников света будут рассмотрены подробно позднее.
И теперь мы это знаем, нам нужен еще инстанс источника:
| instance "light1|Inst" "light1" | |
| transform | |
| 1 0 0 0 | |
| 0 1 0 0 | |
| 0 0 1 0 | |
| 54.126644 4.8438337e-006 -300 1 | |
| end instance |
Определение материала выполняется конструкцией {material "имя_материала" … end material}:
| material "mat" | ||
| opaque | ||
| "mib_illum_phong" ( | ||
| "ambient" 0.5 0.5 0.5, | ||
| "diffuse" 0.6 0.3 0.9, | ||
| "ambience" 0.3 0.3 0.3, | ||
| "specular" 1.0 1.0 1.0, | ||
| "exponent" 50, | ||
| "mode" 1, | ||
| "lights" ["light1|Inst"] | ||
| ) | ||
| end material |
Конструкция может включать параметры, опции и шейдеры. В данном случае свойства материала полностью и единственно определяются одним шейдером - "mib_illum_phong" с заданными значениями его параметров и одной опцией - opaque, которая говорит о полной непрозрачности материала (что позволяет несколько ускорить расчет цвета материала). Обратите внимание на такой параметр конструкции, как "lights" - это параметр, который ссылается на инстансы источников освещения и обязательно должен присутствовать в любом материале, поскольку иначе расчет цвета становится просто невозможным. Отсюда следует простое правило. Источники освещения должны быть определены в mi-файле раньше, чем любой из материалов, их использующих.
Второе правило гласит, что материал должен быть определен раньше, чем объект, которому этот материал назначен. Опции, параметры, шейдеры и правила определения материалов будут позднее рассмотрены подробно.
Конструкция {object "имя_объекта" … end object} определяет описание геометрических объектов в сцене, в нашем случае - пирамиды:
| object "cube1" | ||
| visible trace shadow | ||
| tag 1 | ||
| group | ||
| -30.0 -27.5 0.0 | ||
| -30.0 27.5 0.0 | ||
| 30.0 27.5 0.0 | ||
| 30.0 -27.5 0.0 | ||
| 0.0 0.0 50.0 | ||
| v0 v1 v2 v3 v4 | ||
| c "mat" 0 1 2 | ||
| c "mat" 0 2 3 | ||
| c "mat" 0 1 4 | ||
| c "mat" 1 2 4 | ||
| c "mat" 2 4 3 | ||
| c "mat" 3 4 0 | ||
| end group | ||
| end object |
Это один из возможных видов описания полигональной геометрии, довольно простой. Все что идет до group - опции рендера геометрического объекта, все, что заключено между {group … end group} представляет описание собственно геометрии - перечисление трехмерных координат вершин объекта, назначенных им имен (v 0 - v 4) и описание полигонов объекта перечислением образующих его вершин с указанием материала. Материал к этому времени должен быть уже определен, в нашем случае это материал, на который объект ссылается по имени "mat" и который мы уже определили, непосредственно перед объектом.
Если нужно, чтобы нормаль полигона смотрела наружу объекта и была видима в камеру, перечисление вершин выполняется по часовой стрелке. В описание могут быть включены координаты нормалей и текстурные координаты (в нашем примере они не определялись).
Описание полигональной геометрии, принятое в трансляторе 3ds max несколько отличается от приведенного и более сложно, хотя общие принципы остаются неизменными.
Кроме полигональной, существует способ описания NURBS и patch поверхностей (free-form surfaces), а также - пространственных кривых.
В любом случае, следует запомнить, что определение геометрии выполняется при помощи object .. end object с указанием имени объекта, а собственно описание геометрии (вершин, нормалей текстурных координат и полигонов) выполняется конструкцией {group … end group} внутри object.
Доступные для объектов опции будут рассмотрены далее подробно.
Наконец, после того как все элементы сцены описаны соответствующими конструкциями и шейдерами, подается команда рендера сцены
Инстанс объекта, определяющий его масштаб, ориентацию и положение в сцене:
| instance "cube1|Inst" "cube1" | |
| transform | |
| 1 0 0 0 | |
| 0 1 0 0 | |
| 0 0 1 0 | |
| 0 0 0 1 | |
| end instance |
Наконец, после того как все элементы сцены описаны соответствующими конструкциями и шейдерами, подается команда рендера сцены.
render "rootScene_1" "myCam|Inst" "SceneOpt"
В рендере будут участвовать все элементы, которые указаны в качестве параметров сцены, в нашем случае - "rootScene_1" через инстанс камеры "myCam|Inst" и с учетом опций рендеринга, указанных в блоке "SceneOpt".
Инстанс - группа "rootScene_1" определена для удобства и является просто контейнером для всех инстанс-элементов, участвующих в рендере - сцена может быть сложной и количество ее элементов велико, поэтому удобно один раз определить группу таких элементов и затем просто ссылаться на имя этой группы:
| instgroup "rootScene_1" | |
| "myCam|Inst" "light1|Inst" "cube1|Inst" | |
| end instgroup |
В нашей сцене инстанс-группа содержит три инстанса: камеры, источника света и пирамиды.
Порядок появления конструкций в mi-файле, описывающих элементы сцены, не фиксирован жестко - элементы могут появляться в произвольном порядке. Однако существует несколько правил, ограничивающих этот "произвол" и вносящих некоторую упорядоченность и закономерность в расположение конструкций mi-файла. Вот они.
- Прежде чем какая-либо конструкция элемента сцены может быть использована для определения свойств другой конструкции, она должна быть определена. В примере нашей сцены определение источников света должно быть сделано в mi-файле раньше, чем дано определение использующих их материалов. А определение материалов - раньше, чем геометрических объектов, которым они назначены. Поэтому, наиболее часто будет встречаться именно такая последовательность описания элементов в сцене: сначала источники, затем материалы, затем объекты. Это правило следует учитывать как при анализе структуры сцены, так и при редактировании параметров конструкций элементов, и особенно имен, поскольку они могут упоминаться в других конструкциях
- Чтобы шейдер можно было использовать в сцене, он должен быть:
- декларирован перед первым его применением, либо явно - прямо в mi-файле с помощью конструкции {declare "имя_шейдера" (параметры_шейдера) end declare}, либо при помощи подключения соответствующего файла деклараций командой $include <имя_файла.mi> в самом начале описания сцены
- после декларации, шейдер должен быть определен указанием конкретных значений его параметров при помощи конструкции:
shader "имя_определяемого_шейдера" "имя_декларированного_шейдера" (значения параметров) - только после декларации и определения шейдера, он может использоваться для определения свойств элементов посредством ссылки на его имя
В нашем примере при определении материала используется шейдер "mib_illum_phong" из основной библиотеки шейдеров base.dll.
Если следовать указанным правилам, то в mi-файле это должно выглядеть так:
| декларация шейдера: | |
| declare color "mib_illum_phong" ( | |
| "ambient" | |
| "diffuse" | |
| "ambience" | |
| "specular" | |
| "exponent" | |
| "mode" | |
| "lights" | |
| ) | |
| end declare |
декларация описывает структуру параметров шейдера без указания их значений и тип возвращаемого результата.
| определение шейдера: | |
| shader "my_mat_shader" "mib_illum_phong" ( | |
| "ambient" 0.5 0.5 0.5, | |
| "diffuse" 0.6 0.3 0.9, | |
| "ambience" 0.3 0.3 0.3, | |
| "specular" 1.0 1.0 1.0, | |
| "exponent" 50, | |
| "mode" 1, | |
| "lights" ["light1|Inst"] | |
| ) |
мы определяем шейдер с именем "my_mat_shader" типа "mib_illum_phong", и присваиваем его параметрам конкретные значения. Указывать можно не все значения параметров, опущенным параметрам будут присвоены значения по умолчанию.
И ссылаемся на этот шейдер при описании материала, возможно, с другими значениями параметров:
| material "mat" | ||
| opaque | ||
| " my_mat_shader " ( | ||
| "ambient" 0.1 0.3 0.3, | ||
| "diffuse" 0.7 0.3 0.9, | ||
| "ambience" 0.3 0.3 0.3, | ||
| "specular" 1.0 0.9 1.0, | ||
| "exponent" 40, | ||
| "mode" 1, | ||
| "lights" ["light1|Inst"] | ||
| ) | ||
| end material |
В приведенном примере сцены декларации шейдера опущены, поскольку используется подключение декларации из файла при помощи команды $include , в котором есть декларация шейдера "mib_illum_phong".
Кроме того, в сцене используется сокращенное, так называемое анонимное определение шейдера, когда то же имя шейдера, которое используется при декларации, используется и в определении материала с указанными значениями параметров. Такое возможно, хотя и не рекомендуется.
Рассмотренные конструкции описания основных элементов options, camera, light, material, object, instance, instgroup относятся к конструкциям так называемого верхнего уровня. Эти конструкции определяются с использованием имен. Назначенные имена конструкций могут быть использованы для определения других конструкций и так далее.
В результате мы получаем иерархию элементов, определяющую структуру сцены. Эта иерархия может быть простой, как в приведенном примере, или очень сложной, что будет иметь место для большинства сцен, создаваемых на практике. Тем не менее, все основные строительные элементы этой иерархии и правила их соединения теперь нам известны, и потому мы можем понять эту иерархию и использовать ее в практических целях.
Если воспроизвести рассмотренную сцену в 3ds max, а затем выполнить ее экспорт в mi-файл, мы получим гораздо более сложное и длинное описание сцены. Это обусловлено тем, что транслятор 3ds max, кроме основных элементов сцены, вставит и различную служебную информацию, необходимую в силу специфики пакета моделирования.
Так, транслятор добавит описание сцены, включит в явном виде декларации всех используемых шейдеров, представит описание материалов как список шейдеров, добавит шейдер Environment и шейдер источника света, используемого в 3ds max по умолчанию, а также много другой информации.
Тем не менее, все основные элементы сцены также будут присутствовать - камера, источник, пирамида, материал, и в описании будут близко следовать тому, что мы видели в примере. Поэтому, не составит никакого труда идентифицировать эти элементы и отредактировать их при необходимости. Та же ситуация будет иметь место для любой сцены, экспортированной из 3ds max.
Поэтому, теперь мы знаем, что и где нужно искать. Как это правильно редактировать - узнаем далее, изучив свойства конструкций элементов. Команды
После запуска команды рендеринга mental ray из командной строки при помощи "ray.exe filename.mi", расчет изображения начинается далеко не сразу. Ему предшествует этап анализа (parsing) mi-файла. На этом этапе строки mi-файла читаются и анализируются mental ray последовательно, в том порядке, как они записаны в файле.
Целью этого этапа является выполнение различных необходимых предварительных операций - чтение регистров, подключение библиотек шейдеров и их деклараций, инициализация сетевого рендеринга, выделение памяти и создание структур данных, различные проверки и так далее. Только после успешного завершения анализа, начинается собственно рендеринг.
Мы имеем определенную возможность влиять на этап анализа посредством специальных команд. Эти команды могут быть записаны прямо в листинге mi-файла, в любом его месте и mental ray будет выполнять их сразу, как только встретит. Либо команды можно подавать указанием соответствующих ключей для ray.exe и в этом случае они имеют преимущество перед аналогичными командами в mi-файле.
Рассмотрим перечень, синтаксис и назначение этих команд.
Команды общего назначения:
- $include
- link
- namespace
- version
- verbose
- echo
- call
- touch
- system
- delete
- debug
- render
Команда
$include "имя_файла", или
$include <имя файла>
инструктирует mr о необходимости чтения содержимого файла, указанного в качестве аргумента. Результат действия этой команды аналогичен открытию указанного файла, копированию в буфер и вклеиванию его содержимого в то место, где встречается команда include.
$include "имя_файла"
Первая разновидность команды, когда имя файла указано в кавычках, определяет путь поиска файла в точности, как он указан в кавычках. Ее можно использовать для загрузки файлов с указанием полного пути для них.
$include <имя файла>
Вторая разновидность команды, с именем файла в угловых скобках. Указывается только имя файла, путь к нему определяется (неявно дописывается перед именем файла) по значению регистра _MI_REG_INCLUDE. Так что полный путь к файлу будет определяться как {значение_регистра__MI_REG_INCLUDEимя_файла}.
Команда не может быть вложенной (то есть include не может содержать include), должна начинаться с начала строки ($ обязательно должен быть самым первым символом строки), не может быть использована внутри команды $code … $end code.
Изначальное ее предназначение - вклеивание деклараций шейдеров в mi-файл. Однако, поскольку include читает любой внешний mi-файл, ее можно также использовать для загрузки определений элементов сцены, например - источников света с предопределенными свойствами или камер, текстур и другого.
При сетевом рендеринге файл, определенный при помощи include читается только на машине-сервере.
Команда
link " filename "
подключает файлы, содержащие скомпилированный исполняемый программный код шейдеров. Благодаря этой команде mental ray "знает", что должен делать каждый шейдер. Альтернатива link - команда code, предназначенная для отладки шейдеров, она позволяет подключать исходный текст программ шейдеров на C с последующей компиляцией "на лету".
Команда
namespace " name "
...
end namespace
может содержать внутри любое количество определений элементов сцены. Ее основное назначение - отделить группу элементов (субсцену) от остальных элементов сцены или групп, определенных другими командами namespace. Элемент, определенный внутри этой команды для внешних элементов будет виден как "name::имя_элемента". Mental ray всегда неявно использует эту команду при определении геометрических элементов. Благодаря этому, геометрические элементы даже с одинаковыми именами никогда не перепутываются при ссылках на их имена.
Команда
[ min] version " string "
max version " string "
информирует mental ray, что данный файл требует для расчетов определенной версии ray.exe. Версия записывается как четырехзначное число, цифры отделяются точками. Если указано меньше четырех цифр, отсутствующие полагаются равными "0". Например, "3.3" означает "3.3.0.0". Когда mental ray при анализе встречает эту команду, он сравнивает версию запущенного ray.exe, и если она меньше min или больше max, выдается сообщение об ошибке, а рендер прекращается. Проверка версии полезна при расчете относительно новых эффектов, таких как подповерхностное рассеяние, например.
Команда
verbose on|off| level
определяет подробность отчета mental ray о процессе обработки и рендера файла, выводимого на стандартное устройство вывода (на экран). Всего доступны 7 уровней:
- level 1: сообщения только о фатальных ошибках
- level 2: сообщения о любых ошибках (синоним "off")
- level 3: предупреждения
- level 4: сообщения о ходе выполнения расчетов (progress)
- level 5: информационные сообщения (синоним "on")
- level 6: отладочные сообщения
- level 7: verbose debugging messages
Сообщения более высокого уровня включают сообщения всех предыдущих уровней. Уровни 1, 2, 3 и 4 удобно использовать при отладке сцен, 5 - при рендере. Седьмой уровень может быть полезен только mental images.
Аналогом команды verbose является ключ командной строки -verbose n. Например: "ray.exe -verbose 4". Использование verbose в качестве параметра командной строки более предпочтительно и полезно в сочетании с параметром " -x on", который делает сообщения цветными, например, все сообщения об ошибках будут выдаваться на экране красным цветом.
Команда
echo " message "
отображает на экране сообщение, заданное в "message". Требует verbose level не менее 4.
Команда
call shader_list [ , " camera_inst " " options "]
выполняется сразу же, как встречается в mi-файле, а анализ сцены приостанавливается до тех пор, пока выполнение команды не будет полностью завершено. Предназначена для вызова шейдеров, указанных в качестве параметров команды с целью их ранней инициализация или для вызова интерфейса внешней программы. Используется редко.
Команда
touch " element_name "
помечает элемент как "изменяемый в процессе рендеринга" для повторных вычислений. Например, для повторной тесселяции геометрического объекта с назначенным шейдером дисплейсмента при изменении положения камеры в анимации или для повторного чтения текстуры из файла при ее изменении. Без использования touch, mr такие ситуации отслеживать не будет.
Команда
system " shell_command "
позволяет запускать команды операционной системы из mi-файла. Для Windows запускает отдельное окно и выполняет указанные стандартные dos-команды в нем. Полезна для запуска пакетных bat-файлов, содержащих последовательность dos-команд, например, для мониторинга времени рендера файла или для записи просчитанного кадра анимации на внешний видеомагнитофон.
Команда
delete " element_name "
предназначена для удаления элементов сцены с указанным именем, таких как объекты, текстуры, материалы, источники света. Все связи между элементом и его инстансами, а также ссылки на него в других элементах, разрушаются. Таким образом, команду можно использовать для отключения объекта, не заботясь о "вычищении" всех его "следов" и без фактического удаления описания самого элемента. Удобно использовать при отладке mi-файла для временного исключения элемента из рендеринга. Предназначена для удаления элементов сцены с указанным именем, таких как объекты, текстуры, материалы, источники света. Все связи между элементом и его инстансами, а также ссылки на него в других элементах, разрушаются. Таким образом, команду можно использовать для отключения объекта, не заботясь о "вычищении" всех его "следов" и без фактического удаления описания самого элемента. Удобно использовать при отладке mi-файла для временного исключения элемента из рендеринга.
Команда
debug " mode " [ " arg "]
более интересна разработчикам шейдеров, выводит отладочную информацию на системное устройство, заданное в качестве stderr, verbose level должен быть не ниже 4. Позволяет, например, получить информацию об используемых аппаратных шейдерах, значениях регистров, распределении памяти...
Команда
render " root_instgroup_name " " camera_inst_name " " options_name "
запускает рендер файла сцены и потому всегда находится в его конце. В качестве аргументов должны быть указаны имена инстанс-групп элементов сцены, участвующих в рендере, инстанс камеры и имя блока опций рендеринга.
Команда render может повторяться, например, при расчете анимации, тогда каждая команда рассчитывает очередной кадр анимации. Переменные, регистры и команды для работы с ними
Переменные не обрабатываются mental ray вообще. Механизм переменных обеспечивает передачу значений для каких-либо дополнительных целей. Например, транслятор какой-либо интерактивной программы, который использует mi-файлы, может получать и передавать через mi-файл номер версии, имя файла источника, и другую информацию.
Команда
set " name " [ " value "]
определяет значение "value" для переменной с именем "name". Если команда используется в виде set "name", без явного указания значения, содержимое переменной сбрасывается, и она считается неопределенной.
Регистры в чем-то схожи с переменными, однако, в отличие от них, активно используются mental ray. Так, все пути для используемых файлов библиотек шейдеров назначаются при помощи регистров.
Конструкция
| registry " name " [ " value "] | |
| [ value " value "] | |
| [ link " library.so/dll "] | |
| [ code " sourcefile.c "] | |
| [ mi " scenefile.mi "] | |
| [ spdl " scenefile.spdl "] | |
| [ echo " string "] | |
| [ system " shell command "] | |
| end registry |
создает регистр с именем "name". Любой из параметров конструкции может быть опущен (оставлен неопределенным). Имя регистра может быть произвольным, но существует несколько предопределенных имен регистров, которые имеют для Mental ray особое значение.
Регистр
_MI_REG_INCLUDE
определяет пути файлов, которые дописываются к имени файла-аргумента команды $inclide < имя_файла >. Фактически, этот регистр определяет пути (подстановку пути), которые mental ray будет использовать везде, где встречается команда $include <> или mi (в регистрах).
Регистр
_MI_REG_LIBRARY
определяет пути, по которым будет выполнен поиск фалов библиотек шейдеров с расширением dso/dll, подключаемых командой link. Используется везде, где встречается команда link.
Регистр
_MI_REG_TEXTURE
содержит пути файлов текстур, которые подключаются в mi-файле при помощи оператора texture.
Регистр
_MI_REG_LIGHTPROFILE
определяет пути поиска файлов, содержащих профили описания распространения света для IES источников (в 3ds max - для фотометрических источников) и упоминаемых в mi-файле как аргумент оператора lightprofile.
Регистр
_MI_REG_SWAPDIR
определяет директорию на диске, назначаемую для свопа (виртуальная дисковая память). Mental ray будет использовать эту директорию, а не общий для всех приложений page file операционной системы. Сказывается на производительности и стабильности расчетов самым положительным образом и настоятельно рекомендуется к использованию.
Регистр
_MI_REG_SWAPLIMIT
определяет максимальный размер файла виртуальной памяти mental ray, в мегабайтах.
Регистр
_MI_REG_FBDIR (начиная с версии mr 3.4)
определяет директорию, в которой будут храниться временные копии фрейм- буферов (frame buffers), например, при необходимости освободить оперативную память для других целей. Для ray.exe может быть указан параметр командной строки fb_dir имя_директории, который аналогичен по назначению, но имеет более высокий приоритет.
Значение регистра считается определенным, если его поле "value" определено.
Все вышеперечисленные регистры могут, а некоторые просто должны быть определены в rayrc.
Все остальные поля регистров используются командой $lookup.
Команда
$lookup " name "
просматривает значение регистра и выполняет его операторы:
- link: загружает файлы, указанные в качестве аргумента
- code: загружает, компилирует и линкует код шейдера написанный на языке С
- mi: вставляет содержимое указанного mi-файла
- spdl: читает файл сцены в синтаксисе Softimage SPDL
- echo: выводит текстовое сообщение
- system: выполняет команды операционной системы
Операторы в регистре могут повторяться.
Несколько слов о code. Этот оператор будет более интересен разработчикам шейдеров. Оператор позволяет использовать программу шейдера, написанную на C или C++ в расчетах, может присутствовать не только в регистрах, но в любом месте mi- файла сцены.
Эта команда бывает двух видов:
code " filename "
подключает программу из внешнего файла с именем filename.c, и
$code
исходный текст на C
$end code
позволяет вставлять текст программы непосредственно в регистр или mi-файл. Mental ray обеспечивает компиляцию и линкование кода, а после декларации шейдера, он становится доступен для использования, как и любой другой шейдер. Этот оператор введен с целью отладки программного кода шейдеров.
Пример. Напишем файл rayrc, который просматривается mental ray при запуске ray.exe. Без определения этого файла работа ray.exe просто невозможна, поскольку не определены пути библиотек шейдеров и их деклараций. Путь, по которому будет искаться сам rayrc задается в Windows системной переменной (Environment variable) MI_ROOT, которую необходимо определить. Обычно устанавливают MI_ROOT = дискдиректория mental_ray. Так, если mr установлен на диск С, в директорию mentalray3.4, то MI_ROOT = "c:mentalray3.4".
Далее в примере предполагается, что mental ray установлен на диске с в директорию mr34
Первое, что необходимо определить в rayrc - это регистры _MI_REG_INCLUDE и _MI_REG_LIBRARY.
Для _MI_REG_INCLUDE устанавливаем значение, определяющее путь к файлам деклараций основных шейдеров, если считать, что они лежат в папке c:mr34include, тогда:
registry "_MI_REG_INCLUDE" value "c:mr34include" end registry
Если считать, что файлы с кодом шейдеров лежат в папке c:mr34lib, тогда значение регистра _MI_REG_LIBRARY должно быть определено так:
registry "_MI_REG_LIBRARY" value "c:mr34lib" end registry
Таким образом, мы определили пути поиска файлов библиотек и деклараций основных (базовых) шейдеров mental ray.
Теперь введем новый регистр и выполним явное подключение файлов. В примере предполагается, что 3ds max7 установлен в папке c:3dsmax, а файлы встроенного mental ray находятся: в папке c:3dsmaxmentalrinclude - файлы деклараций, c:3dsmaxmentalrshaders - файлы библиотек шейдеров. Тогда:
| registry "MAXBASE" | |
| link "base.dll" | |
| link "physics.dll" | |
| link "contour.dll" | |
| link "subsurface.dll" | |
| link "c:3dsmaxmentalrshaders3dsmax7.dll" | |
| link "c:3dsmaxmentalrshaderslume.dll" | |
| mi "base.mi" | |
| mi "physics.mi" | |
| mi "contour.mi" | |
| mi "subsurface.mi" | |
| mi "c:3dsmaxmentalrinclude3dsmax7.mi" | |
| mi "c:3dsmaxmentalrincludelume.mi" | |
| end registry |
$lookup "MAXBASE"
Предполагается также, что при рендере будут использованы шейдеры и декларации, идущие в поставке с standalone mental ray, а не в комплекте 3ds max. Хотя, определением регистров это можно изменить.
Особенность экспорта трехмерной сцены из 3ds max в mi-файл заключается в том, что транслятор вначале mi-файла добавляет линки на все основные библиотеки шейдеров и вставляет декларации нужных шейдеров прямо в листинг описания сцены. Поэтому, на самом деле, вышеприведенный регистр можно сократить - не линковать файлы, пути к которым определены регистром "_MI_REG_LIBRARY, а декларации можно вообще опустить, останется:
| registry "MAXBASE" | |
| link "c:3dsmaxmentalrshaders3dsmax7.dl" | |
| link "c:3dsmaxmentalrshaderslume.dll" | |
| end registry |
$lookup "MAXBASE"
Поскольку для основных шейдеров путь совпадает со значениями, определенными регистрами _MI_REG_INCLUDE и _MI_REG_LIBRARY, в операторах просто указывается их имя, и они будут подключены правильно. Файлы шейдеров 3dsmax7.dll, 3dsmax7.mi, lume.dll и lume.mi находятся в совсем другом месте, поэтому в операторах link и mi указаны полные пути к ним. Аналогично, если потребуется подключить другие дополнительные шейдеры, можно добавить новые операторы с указанием полных путей к ним.
Определим еще директорию для свопа и хранения frame buffers, а также максимальный размер файла виртуальной памяти в 500 мегабайт:
registry "_MI_REG_SWAPDIR" value "c:mi_swap" end registry
registry "_MI_REG_SWAPLIMIT" value 500 end registry
registry "_MI_REG_FBDIR" value "c:mi_frbuff" end registry
Директории c:mi_swap и c:mi_frbuff должны быть созданы средствами операционной системы.
Также, еще определяются следующие регистры:
registry "{SYSTEM}" value "windows" end registry
registry "{DSO}" value "dll" end registry
Первый из них используется для идентификации операционной системы, второй - для подстановки (замены) расширений .DSO на .dll файлов библиотек шейдеров.
Таким образом, файл rayrc может выглядеть так:
#----------------------------
# rayrc for 3dsmax
#-------------------------------
registry "_MI_REG_INCLUDE" value "c:mr34include" end registry
registry "_MI_REG_LIBRARY" value "c:mr34lib" end registry
registry "{SYSTEM}" value "windows" end registry
registry "{DSO}" value "dll" end registry
| registry "MAXBASE" | |
| link "base.dll" | |
| link "physics.dll" | |
| link "contour.dll" | |
| link "subsurface.dll" | |
| link "c:3dsmaxmentalrshaders3dsmax7.dll" | |
| link "c:3dsmaxmentalrshaderslume.dll" | |
| mi "base.mi" | |
| mi "physics.mi" | |
| mi "contour.mi" | |
| mi "subsurface.mi" | |
| mi "c:3dsmaxmentalrinclude3dsmax7.mi" | |
| mi "c:3dsmaxmentalrincludelume.mi" | |
| end registry |
$lookup "MAXBASE"
registry "_MI_REG_SWAPDIR" value "c:mi_swap" end registry
registry "_MI_REG_SWAPLIMIT" value 500 end registry
registry "_MI_REG_FBDIR" value "c:mi_frbuff" end registry
#---------------------------------------------------------------------------------
Или в более коротком варианте:
#---------------------------------------------------------------------------------
registry "_MI_REG_INCLUDE" value "c:mr34include" end registry
registry "_MI_REG_LIBRARY" value "c:mr34lib" end registry
registry "{SYSTEM}" value "windows" end registry
registry "{DSO}" value "dll" end registry
| registry "MAXBASE" | |
| link "c:3dsmaxmentalrshaders3dsmax7.dll" | |
| link "c:3dsmaxmentalrshaderslume.dll" | |
| end registry |
$lookup "MAXBASE"
registry "_MI_REG_SWAPDIR" value "c:mi_swap" end registry
registry "_MI_REG_SWAPLIMIT" value 500 end registry
registry "_MI_REG_FBDIR" value "c:mi_frbuff" end registry
-----------------------------------------------------------------------------------
Для сетевого рендеринга, помимо rayrc, нужно определить содержание файла .rayhosts.
В этом файле должны быть перечислены сетевые компьютеры, на которых установлен standalone mental ray и которые планируется использовать в сетевом рендеринге:
сетевое_имя_компьютера или его IP:port,
номер порта может быть опущен. Например, .rayhosts может выглядеть:
comp1:7003
comp2:7050
comp3
......
compN:port
Файл .rayhosts должен находиться в строго определенном месте. А именно, mental ray будет его искать либо по пути, определенном переменными окружения HOMEPATHHOMEDRIVE, либо в директории, где была запущена команда ray.exe.
Узнать значение переменных HOMEPATH и HOMEDRIVE можно, набрав команду SET в dos-окне операционной системы (кнопка Start>Run ввести cmd и нажать ввод, затем вести SET). Команда SET также отображает множество другой полезной информации о компьютере - его сетевое имя, значение PATH, значение переменных окружения и другое. Если все было сделано правильно, при рендеринге mental ray найдет файл .rayhosts и попытается подключить доступные компьютеры. Если подключение состоялось, в окне лога будет отображено соответствующее сообщение.
В следующей части будут рассмотрены опции рендеринга и источники света mental ray.
