"Big Bukc Bunny" изнутри. Модели и линкование
Часть 2. Модели и линкование
Проект мультфильма «Big Buck Bunny» состоит из 422-х рабочих файлов, среди которых 59 содержат в себе модели, начиная от яблок с цветами и заканчивая персонажами. Как мы выяснили в прошлый раз, все файлы структуризированы и разнесены по папками. В конце концов все они собираются в сцены с анимацией в папке scenes, но при этом остаются на своих местах. В итоге, не смотря на то, что типичный анимационный файл, скажем, \scenes\01_intro\01.blend, на диске занимает 132 КБ, в памяти он разворачивается на 272 МБ.
То есть сам файл 01.blend не содержит в себе ничего, кроме ссылок на другие файлы и ключи с анимацией. Точно так же ведут себя и другие сцены. А достигается это при помощи системы линкования, которая позволяет подключать файлы друг к другу, оставляя их при этом в нетронутом состоянии.
Однако, прежде чем двигаться дальше, проведём сначала небольшой ликбез на тему линкования с целью выяснения, как эта система реализована в Blender, и как она работает.
Вероятно, ни для кого не является секретом, что основной структурной единицей в Blender является датаблок. Это тот кирпичик, из которого складываются и с помощью которого взаимодействуют все объекты и данные. Среди них самым интересным и самым нужным является объектный датаблок, который задаёт свойства трансформаций, такие как перемещение, поворот и мастшабирование, и без которого ни один объект в 3D-пространстве нельзя было бы даже увидеть. К нему подключаются датаблоки, отвечающие за характеристики трёхмерных данных — мешей, кривых, камер, источников света и других. Способ их соединения называется линкованием (linking), которое может осуществляться как между датаблоками внутри одной сцены, так и между сценами, находящимися в разных файлах. Наиболее распространённой ситуацией является такая, когда объектный датаблок находится в одном файле, а датаблок с данными — в другом.
Откроем чистую сцену Blender с находящимся в ней по умолчанию кубом, камерой и источником света. Удалим куб и создадим объект UVSphere. Так интереснее и в дальнейшем будет меньше путаницы. Сохраним теперь сцену в файл test.blend, а после этого снова откроем чистую сцену и начнём процесс линкования.
Выполните команду File → Append or Link. В окне File Browser установите способ подключения данных с Append на Link, затем найдите файл test.blend, войдите в него, перейдите в папку Mesh, выделите имя Sphere и нажмите либо среднюю клавишу мыши, либо кнопку Load Library.
Что-то произошло, но с виду ничего не изменилось. Теперь при выделенном кубе перейдите в панель редактирования объектов, в раздел Link and Materials и нажмите на иконку броузера датаблока. В нём кроме меша Cube появился меш L O Sphere. Это и есть тот меш, который мы взяли из файл test.blend. Буква O означает, что данный датаблок в сцене не используется, а L, что он извлечён из внешнего файла. Выберите его, и куб в окне 3D View сменится на сферу. Посмотрите теперь, что показывает Outliner.
Мешевый объект с именем Cube содержит прилинкованный к себе меш с именем Sphere (на это указывает иконка с надписью Li). Если вы попытаетесь перевести такой объект в Edit Mode, нажав клавишу Tab, то увидите надпись «Can't edit external libdata», и режим редактирования не включится. Таким образом, датаблоки прилинкованных объектов нельзя редактировать, что может защищать их от нежелательных случайных изменений.
Теперь сохраните нашу сцену с прилинкованной сферой в файл с каким-нибудь именем linked_sphere.blend, откройте test.blend, деформируйте сферу любым ужасным способом, сохраните файл и снова откройте linked_sphere.blend. Все ужасные деформации появились и в нём тоже, хотя мы всего лишь закрыли и открыли этот файл.
А можно ли обойтись без его перезапуска? Например, путём перезагрузки одной только ссылки. Нет. Впрочем, есть надежда, что это будет возможно уже в версии Blender 2.5.
Продолжим наши эксперименты. Что, если попытаться прилинковать в сцену не только меш, а сразу весь объект? Давайте попробуем.
Создайте снова чистую сцену по умолчанию и переместите 3D-курсор чуть в сторону от куба. Все создаваемые объекты должны становиться в позиции 3D-курсора, не так ли? Как правило, да. Значит, прилинкованный объект должен появиться не внутри куба, а рядом с ним. Выполните теперь все те же действия по линкованию сферы из файла test.blend, только выберите не меш Sphere, а сам объект.
Снова на вид ничего не произошло. Включите сеточный режим отображения экрана Wireframe, и окажется, что сфера всё-таки прилинковалась вместе с мешем, как мы этого и хотели, только почему-то не в позиции 3D-курсора, а в начале координат, оказавшись при этом внутри куба. Отодвинем куб чуть в сторону, чтобы он не мешал, и попытаемся подвинуть прилинкованную сферу. Ничего не выходит. Любые другие трансформации, вроде масштабирования и поворота, тоже не действуют. Да и сам объект имеет какую-то подозрительную голубоватую окраску. Посмотрим в Outliner.
Прилинкованным у сферы является не только меш, но и сам объектный датаблок. А в панели объектов в разделе Link and Materials изменить датаблок сферы тоже не удаётся. Таким образом, после линкования объект тоже стал нередактируемым. Все трасформации, которые остались у него в файле с мешем, были перенесены и в эту сцену. Поэтому сфера поместилась не в позиции 3D-курсора, а в те координаты, которые были у неё в файле test.blend.
Как видно, линковать объекты не очень удобно, разве что в тех случаях, когда мы не хотим в сцене с анимацией трансформировать прилинкованный объект, но такое случается редко. Чаще всего, как минимум, возникает необходимость, такой объект передвигать. Выберите куб и в Link and Materials назначьте ему датаблок L Sphere. Теперь прилинкованную сферу снова можно двигать, а ту непокорную, голубого цвета, удалите.
Это был, конечно, не единственный способ линковать внешние объекты и датаблоки. Рассмотрим ещё один, тем более, что знание его понадобится нам в дальнейшем, когда мы начнём исследовать линкование на примерах файлов «Big Buck Bunny». А в них отнюдь не всё так просто, как хотелось бы.
Откроем наш многострадальный файл test.blend и добавим сферу в группу с каким-нибудь экзотическим названием SphereGroup (при этом она должна позеленеть). Сохраним файл и очистим сцену, нажатием Ctrl+X. Куб нам теперь не пригодится, и мы его спокойно удаляем. Начинаем линковать сферу уже привычным нам способом, только в папках файла test.blend заходим в Group и выбираем данные SphereGroup. Визуально при этом снова ничего не изменилось.
Перейдём в меню Add → Group → test → SphereGroup, и в сцене появится наша сфера. Правда, сама она какая-то странная. Во-первых, из неё торчат оси координат, а во-вторых, при попытке перевести её в режим редактирования по клавише Tab ничего не происходит. Но зато она легко трансформируется. Outliner при этом показывает присутствие у объекта датаблока какого-то неопределённого типа, помеченного кружочком, а на панели редактирования данные датаблока вообще отсутствуют.
Всё это наводит на мысль, что мы получили обычный объект Empty, только с привязанной к нему облочкой меша. Так оно на самом деле и есть. Переместите нашу сферу немного в сторону и создайте новый Empty. Перейдите в панель объектов, нажмите в разделе Anim Settings кнопку DupliGroup и в соседнем поле впишите имя SphereGroup. При этом Empty останется на месте, но оденется в меш прилинкованной сферы.
Судя по Outliner и панели объектов, оба наших шарика абсолютно похожи, отличаясь только именами. В одном случае он называется Empty, а в другом SphereGroup. Получается, что их природа одна и та же и реализуется благодаря опции DupliGroup, просто когда мы создали объект через меню Add → Group, Blender все действия по настройке DupliGroup проделал автоматически и дал итоговому объекту имя прилинкованной группы.
Собственно говоря, данный способ линковавания объектов из внешних файлов является наиболее часто используемым. С его помощью собраны все сцены в «Big Buck Bunny». И, кстати, группировать таким образом можно сколь угодно много объектов, однако все они потом после такого группового линкования появятся под одной общей оболочкой и не смогут быть доступны по отдельности. Ну, а буква O в Outliner рядом с иконкой Li как раз и указывает на то, что линкование производится групповое.
В завершение нашего затянувшегося ликбеза рассмотрим способ размножения прилинкованного датаблока по полигонам другого объекта. В дальнейшем он нам тоже пригодится.
Удалите в сцене с двумя шариками, оставшейся после предыдущего упражения, объект Empty, а вместо него создайте Cube. Теперь припарентите сферу к куб, перейдите в панель объектов последнего и там в разделе Anim Settings включите кнопку DupliFaces. Установите параметр Scale в 0,1, чтобы уменьшить шарики в десять раз, либо уменьшите в масштабе сферу-оригинал. В итоге должна получиться вот такая картина:
Приведённый выше способ является незаменимым при создании многочисленных дубликатов объектов, которые было бы затруднительно размножить вручную. Так с его помощью, например, в «Big Buck Bunny» создаются листья на ветвях деревьев.
И последнее. Переключив Outliner в режим отображения Libraries, можно увидеть, какие файлы были подключены к сцене, и от чего ещё они зависят. К сожалению, управление записями о библиотеках в Blender развито очень слабо и позволяет только редактировать путь к внешним файлам. Добавлять через Outliner библиотеки, удалять или хотя бы перезагружать их без перезапуска Blender пока возможности нет, но она по обещаниям разработчиков должна появиться в следующих версиях программы.
Главный плюс системы линкования внешних файлов заключается в том, что она позволяет заниматься анимацией, не беспокоясь о возможных дальнейших изменениях содержащихся в сцене моделей. Если в конце работы над проектом художник захочет, к примеру (или его попросит об этом режиссёр), улучшить текстуру листьев на деревьях, то, изменив всего лишь один файл с листком, он появится потом в обновлённом виде во всех сценах с анимацией, где был задействован.
Второй плюс заключается в том, что одну и ту же модель можно использовать в разных сценах многократно. Что это означает на практике?
Линкование в «Big Buck Bunny» чаще всего многоуровневое, то есть оно идёт ступенчато от самых простых моделей к наиболее сложным. Типичный пример — дерево. На самом нижнем уровне иерархии у него находятся листья, затем они подключаются ссылкой в файл с деревьями, которые собираются в местность (файлы из папки sets) и уже после этого местность попадает в пошотовые сцены с анимацией. Таким образом, мы имеем всего одну модель дубового листка, а в конечном файле с анимацией их будет уже несколько тысяч копий. И тогда, к примеру, изменив текстуру листа с зелёного на жёлтый, мы можем тут же получить из летнего леса осенний во всех файлах с анимацией.
А теперь, когда мы вооружены приобретёнными знаниями и опасны, рассмотрим все эти вопросы более детальнее, используя в качестве примеров файлы «Big Buck Bunny».
Откроем файл сцены \scenes\09_tree_trunk\02.blend, в котором три свирепых грызуна выбегают из поля в сторону камеры, и рассмотрим, из чего она состоит. Данный файл открывается с экраном Compositing, поэтому, прежде чем двигаться дальше, переключим его в состояние 4-Model, которое как раз отобразит для нас Outliner в левой части окна.
Выясним, какие из объектов данной сцены были созданы непосредственно в ней, а какие прилинкованы из внешних файлов. Поскольку мы уже прошли продвинутый ликбез на тему линкования, то знаем, что если рядом с названием объекта или его датаблока стоит иконка с надписью Li, то, значит, они загружены из внешних файлов. В исследуемой сцене такими оказываются сборка местности лесной окраины, все три персонажа и реквизит, который они с собой таскают. Источники света, камера, различные маски для рендеринга и силовые поля, оказывающие влияние на траву, созданы непосредственно в сцене.
Переключим теперь Outliner в режим отображения библиотек и посмотрим, куда они ведут.
Судя по всему, сцена состоит из нескольких конечных прилинкованных файлов и одной вложенной библиотеки \sets\forestedge.blend, которая является сборкой места действия и ведёт в следующие файлы. Откроем его, произведём те же самые манипуляции с окнами и увидим следующее:
В этом файле мы наблюдаем кусочек леса из двух деревьев (точнее — их нижней половины), двух груд камней и нескольких растений. Собственных элементов тут также содержится мало, но много прилинкованных. Впрочем, это характерно для любого сборочного файла местности. И наш священный долг — разобраться, из чего он в данном случае состоит.
Как видно из Outliner, в этой сцене снова есть как конечные элементы, вроде \envs\rock.blend или \envs\root.blend, так и файлы, которые ведут глубже, на более низкий уровень иерархии. Откроем самый первый из них — \envs\trees.blend.
Итак, наконец мы выбрались из сцен и попали в библиотеку. В этом файле хранятся уже только деревья. Они разных сортов — для переднего плана, для дальнего, с кронами и без, а просмотреть их можно, переключаясь с одного слоя на другой. Однако в Outliner в режиме отображения Library мы видим, что есть ещё один, более низкий уровень иерархии, представленный файлом leaves.blend. Откроем теперь и его.
Это снова библиотека, и теперь она содержит модели листьев с настроенными материалами и текстурами. Поскольку модели маленькие и простые, то, будучи отображёнными все сразу в одном окне, они не замедляют работу Blender и поэтому находятся в одном слое.
Таким образом, мы прошли всю иерархию вложенных друг в друга библиотек объектов от сцены с анимацией до самых простых и многократно дублируемых моделей. Интересует теперь вопрос, а как эти простые модели дублируются потом на более высоких уровнях? Для этого существует несколько способов и мы их предусмотрительно уже изучили в нашем продвинутом ликбезе.
Откроем опять файл trees.blend и посмотрим в Outliner (теперь в обычном режиме Visible Layers). Там мы увидим, что то дерево, которое по умолчанию отображается в 8-м слое, имеет не слишком сложную структуру. Это ствол chubbychestnut_tr.001, ветви tree_chubbychestn и листья leaf_chubbychestn.002. Причём, листья выглядят как-то странно. Если присмотреться к ним поближе, то окажется, что это один меш-объект, который состоит из множества отдельно разбросанных в пространстве полигонов. Однако это ещё не листья, а лишь основа для них. Вокруг каждого полигона располагается невыделяемый сеточный меш параллелепипедной формы. Логика подсказывает, что как раз этот меш и является листьями. Для проверки можно отрендерить сцену и увидеть, что так оно и есть.
Осталось только выяснить, как эти параллепипеды стали листьями, и как они прикрепляются к полигонам. При выделенном объекте leaf_chubbychestn.002 перейдём в панель объектов и в разделе Anim Settings увидим нажатой кнопку DupliFaces.
Это указывает на то, что каждый полигон меша leaf_chubbychestn.002 заменяется неким объектом, который к нему припарентен. А в Outliner мы видим, что припарентен к нему объект leaf_oak_lo.001, меш которого находится в файле leaves.blend. Найдём его в сцене. Оказывается, он спрятан внутри корня дерева. Это и есть та самая модель листа leaf_chesnut_meshed, которая прилинкована из файла leaves.blend и размножена потом по всему дереву.
Если теперь этот прилинкованный объект удалить и снова отрендерить дерево, то мы получим очень грустную картину:
Пойдём ещё дальше и посмотрим, как же теперь на более высоком уровне иерархии размножаются деревья. Делается это по уже известному нам из ликбеза принципу.
Деревья состоят из нескольких объектов. Как мы уже видели, туда входит ствол, ветви, листья и оригинальная модель листа, прилинкованная из библиотеки листьев. Чтобы перетащить всё это вместе в другой файл, нужно эти объекты объединить в группу. На примере нашего исследуемого дерева такая группа есть, и называется она chubbychestnut_branch.
Переместимся теперь в файл \scenes\06_killing\12.blend и переключим экран в состояние 4-Model. В окне 3D View мы при этом увидим уже знакомое нам дерево. Но если выделить его и поглядеть в панель Editing, то окажется, что оно не имеет датаблока с данными. А объект без такого датаблока — есть ни что иное, как Empty, пустышка.
Переключимся в режим Object и увидим там в разделе Anim Settings такие настройки:
Группа с деревом chubbychestnut_branch из файла tree.blend была подключена к Empty через опцию DupliGroup. Таким образом, прилинкованное с помощью группы дерево было размещено в сцене с анимацией путём привязки его к объекту Empty.
В отличие от способа размножения листьев через опцию DupliFace (или DupliVerts), опция DupliGroup не позволяет автоматически клонировать объекты. Чтобы разместить в сцене несколько копий одного и того же дерева, придётся создавать несколько Empty и в каждом из них указывать в поле DupliGroup одну и ту же прилинкованную группу. Поэтому данный способ годится для единичных или немногочисленных объектов. В том числе и для персонажей.
И раз уж мы подобрались к линкованию персонажей, то рассмотрим сперва, как создатели «Big Buck Bunny» избежали бардака с нагромождением десятков объектов в сценах с анимацией. Поскольку один из таких файлов, \scenes\06_killing\12.blend, у нас уже открыт, то его и будем разбирать.
Первые десять слоёв обычно отдаются свету и персонажам. В первом слое чаще всего содержатся источники света, хотя они также распределены и по другим слоям, освещая каждый свою часть сцены. Со второго по четвёртый слой находятся персонажи, а в нижнем ряду, строго под ними — риги этих персонажей. Например, в слое 2 помещена летяга Фрэнк, а в слое 7 — его риг. В слое 3 — косоглазая белка, а в слое 8 — её риг.
Вторые десять слоёв обычно заняты под окружение. В 11-м слое находится сборка места действия, загруженная ссылкой из set-файла, а в остальных — различные вспомогательные объекты. Самый последний слой, 20-й, как правило, отводится под всякий мусор, который необходим для корректной работы сцены и анимации, но не требует постоянного доступа. Если в сцене отсутствуют персонажи, тогда второй блок слоёв смещается на первый, а окружение располагается, начиная с первого слоя и далее по порядку.
Как было рассмотрено выше, персонажи занимают по два слоя — один для оболочки, а другой для рига, то есть скелета с элементами управления. В связи с этим линкование персонажей производится несколько иначе, чем для простых объектов, и состоит из двух этапов: на первом линкуется весь персонаж целиком, а на втором из него извлекается риг и переводится в прокси-режим. Это позволяет, не прикасаться к оболочке, которая в прилинкованном виде доступна только целиком и без возможности редактирования, управлять её деформациями путём анимирования костей скелета.