Впрочем, мы отвлеклись.
Таким образом, для того, чтобы заставить внешний движок просчитать картинку, вы должны произвести некоторые действия. Приведем некий усредненный алгоритм потребной работы:
1. Во-первых, ваш экспортер, то есть тот плагин, который производит экспорт сцены из MAYA во внешние файлы, итеративно обходит всю сцену и экспортирует ее геометрию и материалы
- обычно в некий новый файл собственного формата. Как известно, MAYA внутри представляет все свои данные в виде набора нод; некоторые из них связанны 8 DAG (прямой незамкнутый граф). Наш плагин должен обойти все ноды в этом графе, передвигаясь от предков к потомкам; для каждой ноды мы должны определить, с кем она связана и какой тип информации она представляет, и в зависимости от того, поддерживает ли наш внешний рендерер данную информацию - использовать ее или пропустить. Задача обхода сцены упрощается тем, что программист может заранее накладывать фильтр на граф перед тем, как проводить экспорт - например, если ваш рендерер поддерживает только полигональную геометрию, то и обходить вам нужно только соответствующие ноды. С другой стороны, в MAYA ОЧЕНЬ много различных типов нод и, скорее всего, вы не захотите терять информацию только потому, что ваш рендерер не поддерживает тот или иной вид геометрии или материалов. Это значит, что вашему плагину также придется заниматься преобразованием информации и приведением ее в тот вид, который подходит для вашего рендерера. Очень многие рендереры используют свои собственные системы описания материалов, гораздо более простые или сложные по сравнению с теми, которые используются в MAYA - но все они, как минимум, от нее отличаются, поэтому «правильный» плагин также должен понимать природу этих различий и уметь их обходить.
2. Итак, ваш плагин продирается сквозь глубины DAG, сквозь все эти текстуры, материалы, полигоны, NURBS, SDS, кривые, локаторы, источники света, камеры, объемные примитивы, трансформы, анимационные кривые и ключи, деформеры, динамику и системы частиц, слои и глобальные переменные. Некоторые рендереры воспринимают в виде входных данных файл, в котором описывается как сама геометрия, так и те материалы, которые присоединены к ней. Другие, напротив, разделяют эти понятия. Некоторые рендереры умеют хранить несколько кадров в одном файле, другие не умеют - или умеют, но не рекомендуют: просто исходя из того, что геометрия и материалы в сцене могут быть настолько сложны, что размеры полученных нами файлов будут очень велики.
3. Все эти сакральные знания спрятаны внутри экспортера, который, пока вы читали этот абзац, уже закончил экспорт и оставил на диске один или несколько файлов, которые передаются в рендерер для просчета. Не суть важно, что произойдет в этом случае. Мы можем просто запустить локальную копию рендерера, передав ей файлы и какие-то другие параметры. Абсолютно естественно, что в процессе рендеринга может происходить как препроцесинг, так и постпроцессинг данных, то есть будут выполняться какие-то скрипты, программы или их комбинации, которые будут преобразовывать ваши данные перед рендерингом или по окончании оного. Если вы работаете над каким-то большим проектом, то скорее всего вы используете программно-аппаратное решение (в просторечии - "ферму”, официально - “renderfarm”), которое позволяет распараллеливать ваш рендеринг на несколько машин, находящихся в локальной сети, будь то рабочие машины сотрудников или специальные компьютеры, выделенные для подобных расчетов. В таком случае вы не будете вызывать ваш рендерер напрямую, а запустите другую программу, которая уже и начнет раздачу подпроцессов в вашей ферме.