Камера является таким же важным и неотъемлемым элементом сцены, как и геометрические объекты или источники света. И подобно им, камера также должна быть определена и инстансирована. Основные функции камеры в сцене состоят в определении точки зрения на сцену и способе расчета изображения, выводе результатов на экран и в файл. Операторы определения камеры позволяют задать многопроходный рендеринг, различные спецэффекты, связанные с трансформацией первичных лучей, contour рендеринг и вывод данных из фрейм-буферов.
Определение камеры в сцене выполняется при помощи конструкции
| camera | " имя_камеры " |
| ............. | |
| операторы свойств камеры | |
| ............. | |
| end camera |
Установка в сцене определенной таким образом камеры выполняется при помощи стандартной интсанс-конструкции:
| instance | "имя_инстанс-камеры" |
| "имя_камеры" | |
| transform () | |
| end instance |
В сцене не может быть определено несколько instance-камер в одном и том же кадре, поскольку в каждый момент времени расчет изображения может быть выполнен только из одной единственной точки зрения. Поэтому, имя instance-камеры, через которую выполняется рендеринг, указывается в команде render каждого кадра. Это обстоятельство не запрещает иметь в сцене несколько камер для разных кадров.
Всех операторов определения камеры можно разделить на три большие группы: операторы свойств камеры, операторы вывода output и операторы пассов многопроходного рендеринга pass. Операторы свойств камеры
По умолчанию, в расчетах изображения mental ray использует идеальную, или pinhole, камеру. Идеальная камера представляет собой черный куб с единственным точечным отверстием, куда проникает свет, и проецирует изображение на противоположную от входа стенку или расположенную вблизи нее так называемую viewing plane - плоскость проецирования изображения. Такая камера не вносит искажений в изображение и ее свойства могут быть определены единственным параметром - field of view (fow), или углом обзора. Именно такое описание камеры принято в 3ds max.
Однако, по принятому соглашению, в mental ray используется не fow, а два других параметра - aperture, или ширина изображения на плоскости проецирования (viewing plane), и focal distance, или расстояние от точки входа света в камеру до плоскости проецирования изображения. Aperture и focal distance однозначно определяют fow и наоборот, поэтому оба описания можно считать равнозначными.
Отверстие, через которое свет проникает в камеру, принято считать началом камеры и ему присваивают координату (0, 0, 0).
Три типа операторов свойств камеры - volume, environment, lens могут быть указаны в определении не один, а несколько раз (вообще - любое число раз) и могут содержать в качестве параметра не один шейдер, а несколько - целый список шейдеров.
Оператор
focal distance | infinity
устанавливает фокальное расстояние камеры (focal length) при помощи параметра distance. Если вместо distance используется infinity, камера становится ортографической - фокальное расстояние считается бесконечным, а лучи, попадающие в камеру, - параллельными. Для ортографической камеры не существует перспективы и невозможна тесселяция поверхности типа view.
Оператор
aperture width
определяет ширину плоскости проецирования (viewing plane) при помощи параметра width и тем самым - ширину изображения. Высота плоскости определяется автоматически делением aperture на aspect.
На практике при настройке камеры можно следовать простому правилу: фокусное расстояние устанавливается равным расстоянию до интересующей группы объектов в сцене, а апертура - равной горизонтальной протяженности этой группы в пространстве камеры.
Оператор
aspect ratio
определяет соотношение высоты (aperture) и ширины изображения при помощи параметра ratio.
Focal, aperture и aspect полностью определяют свойства линз идеальной камеры.
Оператор
resolution x y
определяет разрешение изображения в пикселях по высоте и ширине. Другими словами, плоскость проецирования (viewing plane) разбивается по ширине на количество пикселей, указываемых в параметре x. Если соотношение x/y оператора resolution не совпадает со значением aspect, изображение будет искаженным - сжатым или растянутым. Это обстоятельство следует учитывать при выводе изображений на разные устройства. Например, для компьютерных мониторов aspect ratio по умолчанию принято равным 1,33 и соотношение разрешений изображения по высоте и ширине следует этому значению. Для стандарта PAL приняты разрешения 1, 0667, поэтому, если не компенсировать значение aspect, изображение на компьютерном мониторе будет сжатым по высоте и нормальным на PAL-мониторах.
Оператор
offset x y
По умолчанию плоскость проецирования центрирована относительно фокальной оси. Оператор offset позволяет сместить плоскость и тем самым нарушить центровку в ту или иную сторону. Это приводит к искажению изображения, известному как keystone distortion.
Величина смещения измеряется в пикселях и определяется при помощи параметров x, y.
Оператор
window x_low y_low x_high y_high
позволяет задать для рендеринга часть изображения в виде прямоугольной области. Параметры x_low y_low определяют координаты нижнего левого угла прямоугольника, x_high y_high - верхнего правого угла. Координаты измеряются в пикселях, все пиксели вне прямоугольной области будут при рендере черного цвета. Отключить рендер в окне можно, задав значения параметров равными 0 0 99999 99999.
Оператор
clip near far
позволяет определять положение плоскостей отсечения для камеры. Объекты, оказывающиеся вне пределов области, ограниченной плоскостями, в рендеринге принимать участия не будут. Использование clipping-плоскостей имеет значение для проекционных трансформаций с использованием scanline алгоритма и не имеет никакого значения при рейтресинге, если не учитывать влияние на производительность и объем используемых ресурсов. Обрезающие плоскости имеют значение только для геометрии сцены и не принимаются в расчет для environments. Значения near и far по умолчанию равны 0,0001 и 1000000 соответственно.
Оператор
volume [список_шейдеров]
позволяет использовать в расчетах "атмосферные" объемные шейдеры. Такие шейдеры будут воздействовать на все лучи, пересекающие сцену вне пределов объемов объектов (для объектов объемные шейдера определяются отдельно в материалах). При определении камеры может быть указан не один, а несколько операторов volume, которые будут выполняться по порядку.
Если оператор не содержит явного указания хотя бы одного шейдера, список volume-шейдеров обнуляется, что можно использовать при incremental-изменениях камеры. Если шейдер указан и оператор volume первый в текущем определении камеры, список предыдущего определения камеры (если он был) обнуляется. Если оператор не первый в определении, шейдер добавляется к списку ранее заданных шейдеров в текущем определении камеры.
В списке стандартно доступных для 3ds max атмосферных шейдеров находятся:
- Beam (lume)
- Mist (lume)
- Parti Volume (physics)
- Shader List (Volume)
- Submerge (lume)
Оператор
environment [ список_шейдеров ]
позволяет задать шейдеры, которые управляют цветом первичных лучей (eye ray, или camera ray), если лучи после выхода из камеры покидают сцену без единого пересечения с какой-либо геометрией. В mental ray имеется еще один тип environment шейдеров, которые указываются в материалах объектов. Материальные environment- шейдера управляют цветом вторичных лучей типа reflection/refraction, если они покидают сцену без пересечения с геометрией.
В интерфейсе 3ds max назначить шейдера типа environment для камеры нельзя. Косвенно это можно сделать при помощи определения Environment в меню Rendering 3ds max, при этом environment-шейдер должен иметь в apply также значение material (apply environment, material), иначе он будет недоступен для выбора.
Стандартные environment- шейдера mental ray:
- mib_lookup_spherical
- mib_lookup_cube1
- mib_lookup_cube6
- mib_lookup_background
- mib_lookup_cylindrical
по умолчанию скрыты и в 3ds max не видны.
Оператор lens [ список_шейдеров ]
позволяет заменить идеальную модель камеры, используемую в mental ray по умолчанию. Шейдера линз используют направления и начало лучей идеальной камеры, модифицируют их, рассчитывают и испускают новые лучи из камеры. Таким образом, оператор lens позволяет моделировать в mental ray произвольные камеры посредством custom-шейдеров. При определении камеры допускается указывать несколько операторов lens и несколько шейдеров для каждого оператора lens. В этом случае шейдера выстраиваются в последовательную цепочку, когда каждый следующий шейдер использует лучи, рассчитанные предыдущим по списку шейдером.
Если оператор не содержит явного указания хотя бы одного шейдера, список lens-шейдеров обнуляется, что используется при incremental-изменениях камеры (например, при анимации). Если шейдер указан и оператор lens первый в текущем определении камеры, список линзовых шейдеров предыдущего определения камеры (если он был), обнуляется. Если оператор не первый в определении, шейдер добавляется к списку.
Одним из наиболее известных линзовых шейдеров является depth of filed - размывание четкости изображения вне фокуса. Среди других, представленных в списке доступных для 3ds max:
- Distortion (lume)
- Night (lume)
- WrapAround (lume)
- p_fisheye
собственный список mental ray (base и physics) включает следующие линзовые шейдера:
- mib_lens_clamp
- mib_lens_stencil
- physical_lens_dof
- oversampling_lens
Оператор
frame frame [ time ] [ field field ]
обязательный для определения камеры оператор, задающий номер текущего кадра, или номер кадра, просчитываемого данной инстанс-камерой. Параметр frame устанавливает номер кадра и необязательный параметр time - время кадра в секундах. Второй необязательный параметр field позволяет указать какое поле рендерится: 0 - рендер кадра целиком, без полей, 1 - нечетное (odd) поле, 2 - четное (even) поле. По умолчанию используется 0. В настоящее время mental ray не использует ни одно из значений оператора frame, но обеспечивает их передачу шейдерам.
Оператор
data data_name | null
позволяет присоединять к камере пользовательские данные, которые должны быть определены предварительно. Параметр null обнуляет список данных, присоединенных ранее к камере. Операторы вывода output
Операторы группы output предназначены для вывода в файл или для организации постобработки с последующим выводом результата как стандартных фрейм-буферов mental ray, так и пользовательских буферов.
Используется два вида синтаксиса операторов.
Первый: output [ " datatype "] " filetype " [ options ] " filename "
предназначен для вывода данных фрейм-буфера типа datatype в файл типа filetype с именем filename.
Параметр datatype идентифицирует тип буфера, данные которого выводятся. Стандартно mental ray выполняет расчет пяти типов буферов:
- буфер цвета, datatype = rgba. Содержимое этого буфера - обычное цветное изображение, получаемое при рендере: r=red, g=green, b=blue, a= альфа-канал. Более точно, datatype для буфера цвета может принимать следующие значения:
- rgb/rgba - три/четыре канала по 8 бит на канал, определяющие стандартные 256 оттенков цвета на канал. Значения могут быть только положительными целыми числами
- rgb_16/rgba_16 - три/четыре канала по 16 бит на канал, определяющие 65535 оттенков цвета на канал. Значения могут быть только положительными целыми числами
- rgb_fp/rgba_fp - три/четыре канала по 32 бита на канал. Численные значения оттенков цвета могут быть дробными (нецелыми в формате с плавающей запятой) и не обязательно положительными. Диапазон значений лежит в пределах [ -3.4 10^38, 3.4 10^38 ]. Тип rgba_fp также используется в mental ray во всех внутренних вычислениях, то есть все промежуточные числовые данные хранятся в этом числовом представлении
- буфер глубины Z, datatype = z. Буфер глубины содержит z-координату в пространстве камеры наиболее близко расположенного по глубине элемента геометрии. Координаты x, y не учитываются, и, следовательно, z-глубина не равна расстоянию от камеры до элемента геометрии. Буфер глубины содержит один канал в 32 битном числовом представлении. Значения глубины - нецелые отрицательные числа. Если сэмпл не пересекся с геометрией, его значение полагается равным 0
- буфер нормалей геометрии, datatype = n. Буфер содержит три канала в 32 битном представлении - по одному каналу на каждую нормаль. Нормали вычисляются только для объектов, наиболее близких по глубине к камере. Если сэмпл не пересекся с геометрией, вектор нормали полагается нулевым
- буфер векторов смещения, datatype = m, содержит три 32-битных канала. Как и для глубин и нормалей, вектор смещения рассчитывается только для самого близкого объекта и не вычисляется для всех остальных объектов за ним. Если сэмпл не пересекся с геометрией, вектор нормали полагается нулевым
- буфер тэгов (tag), datatype = tag, содержит один 32-битный канал. Тэг может быть назначен при определении геометрического объекта или при создании его инстанса. Для буфера вычисляется тэг только ближнего к камере объекта и полагается нулевым для пикселей, не содержащих геометрии
Данные datatype могут иметь знаковый префикс: "+" или "-". Эти знаки определяют интерполяцию значений данных для тех пикселей буфера, для которых такие данные не были вычислены явно в том случае, если пиксел в расчетах не был просэмплирован. Например, при undersampling (отрицательные уровни сэмплинга: -1, -2 и так далее), когда один сэмплирующий луч определяет цвет нескольких пикселей. Знак "+" означает, что значение отсутствующих данных пикселя будет интерполировано усреднением данных окружающих пикселей. Знак "-" означает, что усреднение не используется, а цвет пикселя определяется выбором подходящего значения одного из соседних пикселей, в соответствии со следующей таблицей:
| datatype | интерполяция |
| -rgba | интерполяция отсутствует, используется цвет последнего вычисленного сэмпла |
| +rgba | цвет интерполируется по цвету окружающих пикселей |
| -z | интерполяция отсутствует, используется наименьшее из вычисленных значений глубины |
| +z | усреднение по глубинам окружающих пикселей, за исключением бесконечных по величине |
| -n | интерполяция отсутствует, используется последняя вычисленная нормаль |
| +n | усреднение по окружающим нормалям, за исключением нулевых векторов |
| -m | интерполяция отсутствует, используется последний вычисленный вектор смещения |
| +m | усреднение по векторам смещения окружающих пикселей, исключая нулевые вектора |
| -tag | интерполяция отсутствует, используется последняя вычисленная метка |
| +tag | при вычислении тэгов их усреднение вообще не имеет смысла, вместо этого используется максимальное вычисленное значение метки |
Если знаковый префикс не указан явно, по умолчанию полагается "+" только для буфера цвета, и "-" для всех остальных буферов.
Хотя mental ray может выполнять расчет пяти вышеперечисленных типов буферов, обязательно рассчитывается только буфер цвета, вне зависимости от того, указан ли он в операторе output. Остальные четыре типа буферов рассчитываются по запросу - только в том случае, если они указаны явно в операторе output.
Кроме стандартных буферов, существует еще один специальный тип буфера - пользовательский. Пользовательские буфера предназначены для вывода данных, рассчитываемых какими-либо шейдерами.
Для работы с пользовательскими frame buffer должен быть выполнен ряд условий:
- пользовательский буфер должен быть определен в блоке Options сцены при помощи оператора frame buffer номер_буфера "datatype"
- должен быть хотя бы один шейдер, осуществляющий вывод данных в пользовательский буфер
- в определении камеры должен быть использован оператор output "fbномер_буфера" " filetype " " filename "
Например, для определения пользовательского буфера с номером 0 mi файла должен содержать следующие фрагменты:
| .......... | |
| options | "SceneOpt" |
| frame buffer 0 "rgba_fp" | |
| end options | |
| .......... | |
| camera | "Cam1" |
| .......... | |
| output "fb0" "tif" "my_buff_out.tif" | |
| .......... | |
| end camera |
Начиная с версии mental ray 3.4, количество пользовательских буферов неограниченно. В более ранних версиях разрешалось использовать не более восьми буферов.
Явное указание типа выводимых данных datatype в операторе output необязательно, поскольку может быть определено по типу файла filename, в который выполняется вывод. Другими словами, не все типы данных могут быть выведены в файл того или иного типа, а лишь в соответствии с таблицей:
| filetype | datatype | описание |
| pic | rgba | Softimage color |
| Zpic | z | |
| alias | rgb | Alias color |
| rgb | rgba | Silicon Graphics 8-bit RGBA color |
| rgb | rgba | Silicon Graphics 8-bit RGBA color |
| rgb | Silicon Graphics 8-bit RGB color | |
| rgba_16 | Silicon Graphics 16-bit RGBA color | |
| rgb_16 | Silicon Graphics 16-bit RGB color | |
| jpg | rgb | JPEG JFIF |
| png | rgb | Portable Network Graphics 8-bit RGB color (3.2) |
| rgba | Portable Network Graphics 8-bit RGBA color (3.2) | |
| exr | a | OpenEXR 8-bit scalar |
| rgb | OpenEXR 8-bit RGB color | |
| rgba | OpenEXR 8-bit RGBA color | |
| a_h | OpenEXR 16-bit scalar | |
| rgb_h | OpenEXR 16-bit RGB color | |
| rgba_h | OpenEXR 16-bit RGBA color | |
| a_fp | OpenEXR 32-bit scalar | |
| rgb_fp | OpenEXR 32-bit RGB color | |
| rgba_fp | OpenEXR 32-bit RGBA color | |
| z | OpenEXR depth map | |
| n | OpenEXR normal-vector map | |
| m | OpenEXR motion-vector map | |
| tif | rgba | 8-bit RGBA TIFF |
| rgba_16 | 16-bit RGBA TIFF | |
| rgba_fp | floating-point RGBA TIFF3.x | |
| rgb | 8-bit RGB TIFF | |
| rgb_16 | 16-bit RGB TIFF | |
| rgb_fp | floating-point RGB TIFF (3.x) | |
| tifu | rgba | 8-bit RGBA TIFF |
| rgba_16 | 16-bit RGBA TIFF | |
| rgba_fp | floating-point RGBA TIFF (3.x) | |
| rgb | 8-bit RGB TIFF | |
| rgb_16 | 16-bit RGB TIFF | |
| rgb_fp | floating-point RGB TIFF (3.x) | |
| iff | rgb | Alias Maya 8-bit RGB image (3.1) |
| rgba | Alias Maya 8-bit RGBA image (3.1) | |
| rgb_16 | Alias Maya 16-bit RGB image (3.1) | |
| rgba_16 | Alias Maya 16-bit RGBA image (3.1) | |
| rgba_fp | Alias Maya float RGBA image (3.2) | |
| a | Alias Maya 8-bit alpha | |
| a_16 | Alias Maya 16-bit alpha | |
| _fp | Alias Maya floating-point alpha (3.1) | |
| a_fp | Alias Maya floating-point alpha (3.1) | |
| z | Alias Maya depth map | |
| z | Alias Maya depth map | |
| z | Alias Maya depth map | |
| rla | rgba | 8-bit or 16-bit Utah/Wavefront color, type A |
| rlb | rgba | Utah/Wavefront color, type B |
| picture | rgb | Dassault Systemes CATIA PICTURE |
| hdr | rgbe | Radiance high dynamic range color, 8-bit RGB color (3.1) |
| ppm | rgb | Portable pixmap, 8-bit P6 binary |
| tga | rgba | Targa color |
| bmp | rgb | MS Windows and OS/2 color |
| qntpal | rgb | Abekas/Quantel, PAL (720 576) |
| qntntsc | rgb | Abekas/Quantel, NTSC (720 486) |
| ct | rgba | mental images 8-bit color |
| rgba_16 | mental images 16-bit color | |
| rgba_fp | mental images floating-point color | |
| st | a | mental images 8-bit alpha |
| a_16 | mental images 16-bit alpha | |
| a_fp | mental images floating-point alpha (3.1) | |
| vt | vta | mental images alpha basis vectors |
| wt | vts | mental images intensity basis vectors |
| zt | z | mental images depth map |
| nt | n | mental images normal-vector map |
| mt | m | mental images motion-vector map |
| tt | tag | mental images normal-vector map |
| bit | bit | mental images mask bitmap |
| cth | rgbe | mental images HDR color, 8-bit RGB color (3.1) |
В скобках указаны версии mr, в которых впервые введена поддержка указываемого формата. OpenEXR поддерживается в mental ray, начиная с версии 3.3.
Помимо общеупотребимых форматов вроде tif, tga, jpg, которые чаще всего используются для хранения данных буфера цвета (изображений), в mental ray существуют специальные форматы файлов, предназначенные для хранения информации только определенного типа данных. Например, для данных глубины имеется формат " zt ", для нормалей - " nt" и так далее. Эти форматы после вычислений могут быть преобразованы к общеупотребимым при помощи утилиты imf_disp или imf_copy, входящих в поставку mental ray.
Тип файла filetype является обязательным параметром оператора вывода и не может быть пропущен. Как видно из таблицы, довольно часто filetype совпадает с расширением в имени файла.
Необязательный параметр options позволяет задавать дополнительные свойства формата файла вывода. В настоящее время options используется только для jpg и позволяет задать степень сжатия (степень качества, например, 100 - сжатие без потери качества изображения) и для Softimage pic, позволяя задавать поля при выводе (odd и even).
Вторая форма синтаксиса оператора output
output " datatype " " шейдер " (параметры шейдера)
используется для обработки шейдерами рассчитанных ранее данных буферов. Указание типа данных datatype в этом формате является обязательным и может содержать несколько типов данных, разделяемых запятыми.
Output-шейдеры имеют доступ ко всем буферам, могут изменять их содержимое и запускаются после завершения рендеринга. Результат работы output-шейдера также сохраняется в буфер. Поэтому обычно при определении камеры сначала записываются операторы output с шейдерами и лишь затем - output-операторы вывода буферов в файл. В противном случае можно не увидеть результаты работы output-шейдеров.
Типичные сферы применения второго типа операторов output - фильтрация и постобработка. Так, фильтрацию сэмплов при антиалиасинге с помощью указанного в настройках фильтра можно считать output-шейдером, встроенным в ядро mental ray. Постобработка открывает самые широкие возможности и обеспечивает высокую востребованность output-шейдеров, поскольку позволяет реализовать множество спецэффектов и различные способы монтажа данных буферов в готовое изображение.
Например, такие эффекты как дисперсия, motion blur, depth of field и другие линзовые эффекты могут быть получены постобработкой, то есть посредством манипуляции с изображениями, а не "честным" расчетом цвета сэмплов, хотя результат будет отличаться.
В более старых версиях mental ray буфера передавались output-шейдерам при помощи переменной состояния, что приводило к необходимости держать буфера целиком в оперативной памяти. В mental ray 3.4 этот способ существенно изменен - теперь буфера не хранятся в памяти, а могут быть записаны при рендеринге во временные файлы на диске, а шейдера могут открывать эти файлы для чтения и записи. Такой подход позволяет снять ограничение на число пользовательских буферов, а также - существенно увеличить доступный рабочий размер самих буферов.
В 3ds max эти output-шейдера доступны через слот Output в Renderer > Camera Effects > Camera Shaders. Библиотека 3ds max и библиотека lume содержат набор output-шейдеров, например, glow или glare. Однако эти шейдера по умолчанию скрыты и не доступны для выбора. Впрочем, ситуацию довольно легко поправить. Операторы многопроходного рендеринга
Многопроходный рендеринг, или рендеринг по пассам, относительно новая возможность, появившаяся в mr 3.1.2, позволяет сохранять результаты рендеринга не в виде изображений, а в виде списка всех испущенных из камеры первичных сэмплов (eye ray) совместно с информацией, собранной во фрейм-буферах. Это обстоятельство является самым существенным отличием и преимуществом рендеринга по пассам, поскольку цвет пикселя формируется с использованием всех сэмплов и буферов всех пассов, и лишь затем фильтруется в окончательный цвет пикселей изображения.
Многопроходный рендеринг позволяет рендерить сцены с одними и теми же фрейм-буферами, одинаковым разрешением, идентичными настройками антиалиасинга, но разные по содержащейся в них геометрии. Поэтому многопроходный рендеринг используется в основном для расчета больших сцен, просчитать которые сразу целиком невозможно, либо для сцен, которые изменяются только частично. Рендер по пассам предполагает разделение всей геометрии сцены на группы или слои, рендеринг каждой группы в отдельный пасс и последующую сборку таких пассов на отдельном шаге, называем слиянием пассов (merging).
Таким образом, пассы содержат гораздо больше информации, чем обычные изображения. Сборка пассов выполнятся индивидуально по сэмплам с учетом информации фрейм-буферов, и поэтому дает намного более корректный результат, нежели сборка обычных изображений.
Содержимое отдельного пасса записывается при рендеринге в специальный буфер и может быть сохранено в файл. Формат файлов, содержащих пассы, является закрытым и не предназначен для переноса информации в другие приложения, например, программы монтажа. Файл-пассы используются исключительно mental ray во время рендеринга.
Таким образом, пассы могут быть записаны в файл для последующей сборки нескольких пассов в один новый пасс (слияние пассов) или финальное изображение, а также подвергнуты дополнительной обработке перед слиянием. Следует иметь ввиду, что пассы, сделанные с использованием rasterizer и без него, смешивать нельзя, поскольку пассы будут сильно отличаться наборами сэмплов. По этой же причине следует отказаться от использования jitter для сэмплов. А вот пассы с разными значениями суперсэмплинга можно собирать, хотя это и не рекомендуется.
Вся функциональность рендера по пассам реализуется пятью основными типами операторов:
Пасс-оператор
pass null
удаляет все пасс-операторы, определенные для камеры. Выполняется на этапе препроцессинга сцены перед рендерингом и полезен для реализации нарастающих (incremental) изменений определения камеры.
Пасс-оператор
pass [ " types " ] write " filename "
Это основной оператор рендера по пассам - он инструктирует mental ray рассчитать пасс и необходимые фрейм-буферы для него, сохраняет текущий сэмпл (первичный луч из камеры) в файл с именем filename и фрейм-буферами типа types (буферов, как правило, несколько, поэтому типы указываются через запятую). Указание типов фрейм-буферов types относится только к команде write, то есть определяет, какие буфера будут рассчитаны и записаны в пасс-файл. Если типы не указываются явно, рассчитываются и записываются фрейм-буферы, определенные операторами output. Буфера цвета и глубины рассчитываются всегда.
Пасс-оператор
pass merge [ " types " ] read [ " filename1 ", " filename2 ", ... ]
[ write " new_filename " ] [ function ( parameters ) ]
выполняет сборку нескольких пассов в один новый пасс. Собираемые пассы должны быть предварительно рассчитаны и записаны в файлы filename1, filename2, …, filenameN. Если текущий рассчитываемый пасс (рендер) используется при сборке, его не обязательно сохранять в файл, поскольку при рендеринге он хранится в промежуточном фрейм буфере. Его участие в сборке можно обеспечить, указав пустые кавычки "" в качестве аргумента команды read.
Сборка пассов происходит индивидуально по каждому сэмплу: расчет очередного сэмпла рендеринга, чтение соответствующих сэмплов из пассов на диске, сборка, запись нового сэмпла в буфер. Сэмпл-результат сборки может быть записан в файл с именем new_name, указываемым в качестве аргумента команды write. Рекомендуется всем файлам пассов давать уникальные имена.
Способ, или алгоритм, сборки определяется необязательным параметром function - это может быть управляющий сборкой шейдер с параметрами. Если function явно не указан, по умолчанию используется алгоритм сборки, основанный на данных буфера глубины (z) и альфа-канала буфера цвета (а).
Окончательная сборка пассов может выполняться сразу после расчета последнего пасса, или как совершенно отдельный самостоятельный шаг, без выполнения рендеринга. В последнем случае должен быть соблюден ряд следующих условий:
- определение камеры не должно содержать ни одного оператора вывода пасса типа pass write
- блок опций mi- файла сцены должен содержать указание настроек сэмплинга
- должно присутствовать определение камеры с операторами resolution и output
- в mi-файле должен быть инстанс камеры, root group и оператор render с именем instance-камеры
Пример mi-файла, выполняющего только сборку. Предварительно геометрия сцены была разбита на три группы, которые были сохранены как отдельные сцены и отрендерены с выводом пассов в файл. Определение камеры для каждой из таких сцен должно включать оператор pass write:
| camera | "cam_scene1" |
| pass write "pass.1" | |
| end camera |
Тогда mi-файл для сборки пассов может быть таким:
| options | "my_options" |
| samples 1 2 | |
| end options | |
| camera | "my_cam" |
| frame 1 | |
| pass merge "rgba_fp, z" read [ "pass1", "pass2", "pass3" ] | |
| output "tif" "out.tif" | |
| resolution 640 480 | |
| end camera | |
| instance | "my_cam_inst" "my_cam" |
| end istance | |
| instgroup | |
| "rootgrp" "my_cam_inst" | |
| end instgroup | |
| render | "rootgrp" "my_cam_inst" "opt" |
Такой mi-файл будет только собирать пассы pass1, pass2, pass3 с учетом альфа-каналов и буфера глубины и записывать результат в буфер, который выводится оператором output в файл с расширением tif, без выполнения рендеринга геометрии. При сборке пассов может потребоваться поднятие минимального уровня сэмплинга близко к максимальному, что особенно важно, если имеются пересекающиеся объекты, принадлежащие разным пассам. Также, предметом особого внимания должны стать тени, которые объекты из разных пассов отбрасывают друг на друга. Для решения этой задачи можно либо создать упрощенные дубли объектов, невидимые для камеры, но отбрасывающие тень, либо использовать matte - поверхности.
Пасс-оператор
pass prep [ " types " ] read " filename1 " write " filename2 " function ( parameters )
позволяет организовать предварительную обработку записанного ранее отдельного пасса из файла filename1 и записать результат в новый файл с именем filename2. Алгоритм обработки определяется обязательным параметром function. В данном случае обязательность означает отсутствие встроенного алгоритма препроцессинга, используемого по умолчанию.
Пасс-операторы выполняются последовательно в том порядке, как они записаны в определении камеры. Поэтому, порядок записи пасс-операторов важен: нельзя выполнить сборку пассов до того, как эти пассы были рассчитаны и сохранены в файл. Инструменты для работы из интерфейса 3D программ
Формирование пользовательских буферов, создание шейдеров для работы с ними, пассы и постобработка позволяют очень гибко управлять рендерингом.
Так, механизм пользовательских шейдеров допускает выполнение рендеринга по элементам освещения, материалов и окружения - можно выводить в отдельные изображения расчет прямого освещения, отражений и преломлений, диффузного цвета, теней, глобального освещения, объемных эффектов и многое другое. Такие изображения затем можно "собрать" в результирующий рендер в программе монтажа, используя их как слои. Гибкость заключена именно здесь - слои можно смешивать по-разному, а каждый из слоев можно дополнительно обрабатывать фильтрами. Наконец, если какой-либо элемент освещения требует изменения, можно снова выполнить рендер только этого элемента, что быстрее, чем рендер всего изображения по новой. Использование пассов многопроходного рендеринга открывает другой путь управления рендером и иной, более точный, способ монтажа, основанный на сэмплах.
Но mental ray предоставляет для этого только необходимые возможности и не содержит удобных автоматизирующих труд многофункциональных инструментов. Поэтому, а также ввиду их высокой востребованности, такие инструментальные средства являются предметом пристального внимания разработчиков custom-шейдеров и пользователей.
Прекрасным инструментом, удобным в работе является набор шейдеров p_MegaTK_pass, созданный Павлом Лединым для Maya и 3ds max 8.
Идеологически p_MegaTK_pass содержит шейдера трех типов, выполняющих различные функции: Геометрический шейдер p_MegaTK_pass, шейдер материала p_MegaTK и три шейдера источников освещения -p_SpotTK (источник типа spot), p_PointTK (точечный источник) и p_DirectTK (направленный источник).
Геометрический шейдер предназначен для объявления пользовательских фрейм-буферов в разделе Options и добавления операторов output для вывода содержимого этих буферов в определении камеры mi-описания сцены. Материальный шейдер предлагает обобщенную модель шейдинга, назначается объектам сцены и выполняет собственно запись рассчитанных компонент цвета в указанные пользовательские буфера. Шейдеры освещения позволяют учесть и вывести в буфер только определенные элементы освещения (прямое и непрямое, только тени), а также связывать освещение от определенных источников света только с определенными элементами материального шейдера (Light category) тех или иных объектов и записывать результат в отдельный буфер.
Все это позволяет при помощи p_MegaTK_pass рассчитывать и выводить по отдельности в виде изображений самый широкий класс элементов освещения и компонент цвета материалов. Изображения записываются в файлы распространенных графических форматов для выполнения монтажа в других программах.
Подробное описание установки и работы с шейдером в Maya можно почитать по адресам:
http://puppet.cgtalk.ru/download/megatk_e.shtml
и
http://puppet.cgtalk.ru/tutorials/howtomegatk_e.shtml
Использование p_MegaTK_pass в 3ds max принципиально ничем не отличается. Единственная особенность состоит в необходимости установки дополнительного плагина mrGeomShaderObject.dlo из SDK, который позволяет использовать геометрические шейдера mental ray в сценах 3ds max.
Уникальными преимуществами p_MegaTK_pass является расчет всех элементов рендеринга за один проход, без необходимости запускать рендер каждый раз по новой для расчета отдельного элемента, и специальная оптимизация выводимых изображений на основе собственной "ноу-хау" технологии, существенно повышающей качество финальной сборки изображений во внешних программах монтажа.
Еще один известный и популярный рабочий инструмент - набор шейдеров ctrl_buffers, созданный francescaluce для Maya.
Набор ctrl_buffers содержит геометрический шейдер buffer_api, объявляющий пользовательские буфера в Options, output-шейдер для камеры buffer_write, выполняющий вывод буферов в файлы, и специальный шейдер для объектов buffer_store, через который подключаются обычные материальные шейдера, и который записывает результаты их расчетов в буфера. Шейдер buffer_store содержит до 15 пользовательских буферов, через которые подключаются компоненты материального шейдера. Практически это означает, что для каждого выводимого буфера должна быть определена копия основного материального шейдера, у которой включен выводимый элемент и отключены все остальные. Например, если требуется вывести только диффузный цвет, нужно определить основной материальный шейдер одну его копию, у которой определен только диффузный цвет, а все остальные свойства обнулены.
Что же касается рендера больших сцен по пассам, то в настоящий момент доступны только предоставляемые mental ray средства для работы с пассами через редактирование mi-описаний сцен, инструментов для работы из интерфейса 3D-пакетов пока нет.
Завершая обзор определения камер, хочется отметить, что mental ray предоставляет все необходимые возможности для создания произвольных моделей расчета первичных лучей и спецэффектов при помощи custom-шейдеров, а также гибкие и мощные средства для хранения и вывода данных таких расчетов в буфера и файлы для последующей обработки.
