© 2008-2019 Тимур Гафаров и соавторы.
Содержимое доступно по CC-BY-NC-SA.
Первое знакомство с ArmorPaint
Мы уже анонсировали этот проект на сайте CGWorld, и теперь пришло время для более детального обзора. Напомним, ArmorPaint – это программа для раскрашивания моделей, аналог Substance Painter, разрабатываемый автором движка Armory.
ArmorPaint распространяется на коммерческой основе через Gumroad, стоимость лицензии €16, в цену входят пожизненные обновления. Покупая ArmorPaint, вы также финансируете разработку Armory, который в настоящее время доступен бесплатно, поэтому рекомендуем поддержать эти замечательные проекты.
Для теста мы решили взять самую свежую версию пакета – 0.6 rc. Несмотря на предупреждение в дисклеймере, программа работает вполне стабильно – за все время пользования не было ни одного сбоя или порчи данных, что само по себе уже радует.
ArmorPaint имеет интуитивный и минималистичный интерфейс, обеспечивающий удобный доступ ко всем функциям программы. Как и в Substance Painter, здесь есть слои и материалы – у каждого слоя имеется полный набор PBR-текстур, и кисть с выбранным материалом модифицирует эти текстуры. При этом изменение параметров материала не влияет на уже нарисованные штрихи.
Программа поддерживает импорт моделей в форматах OBJ, FBX, glTF, blend и собственный формат проектов *.arm. Вы также можете импортировать готовые PBR-текстуры и применить их к модели при помощи графа материала.
Граф материала – самая интересная часть ArmorPaint. Он был явно вдохновлен Node Editor из Blender: очень похожие названия сокетов, даже есть полностью аналогичные векторные преобразователи и процедурные текстуры типа Voronoi и Musgrave. Для тех, кто незнаком с этим инструментом, поясним: граф используется для создания процедурных материалов – по сути, это визуальный язык описания шейдеров. Материал строится на основе цепочки узлов (нод), соединенных между собой через входные и выходные сокеты – узлы предназначены для ввода, вывода и промежуточной обработки данных. Как и в Blender, в ArmorPaint поддерживаются скалярные и векторные данные, а также значения цветов. Скаляры обозначены серыми сокетами, векторы – фиолетовыми, цвета – желтыми. В качестве узлов ввода вы можете использовать числовые константы, значения RGB, текстуры, геометрические данные модели и камеры. Вывод осуществляется в узел Material Output, который представляет интерфейс стандартного PBR-материала с параметрами Base Color (альбедо), Roughness (шероховатость), Metallic (металличность) и др.
Программа предоставляет достаточно богатый выбор инструментов рисования: кисть, ластик, заливка, декаль, текст, штамп, размытие, аэрограф. Поддерживаются графические планшеты с нажимом пера, который может влиять на радиус, прозрачность и четкость кисти. По умолчанию стоит 4 шага отмены операций рисования, в настройках можно выставить больше.
Вьюпорт ArmorPaint работает на удивление быстро и надежно. PBR-рендер на основе Armory, на наш взгляд, не хуже эталонов в лице Substance и Marmoset Toolbag. Есть возможность выбрать собственную карту окружения, в настройках можно включить SSAO, воксельный AO, bloom и отражения.
Программа находится в активной разработке, и стабильного релиза у нее еще нет, но уже сейчас ее вполне можно использовать в качестве недорогой легковесной альтернативы Substance, учитывая, что большого выбора в этой нише пока нет. ArmorPaint – отличное дополнение к Blender 2.80, Armory и любому другому PBR-пайплайну.
Свой движок?
Все «за» и «против»
«Не пишите свой игровой движок, используйте готовый», – такую фразу можно услышать сегодня повсеместно. Совет не лишен смысла, если ваша цель – создание типовой игры для заколачивания денег. Стоит вам сделать шаг в сторону от ширпотреба, попытавшись реализовать мало-мальски нетривиальную механику, изобрести новый алгоритм или графическую технику, как возможностей существующих движков резко перестанет хватать. Да и в том, чтобы иметь технологию собственного производства, есть особый шик, приятное ощущение независимости – вы можете делать с ней все, что хотите, не ограничиваясь условиями лицензий.
Конечно, создание своего движка – дело не из легких. Берутся за это очень многие, некоторые доводят движок до уровня техно-демки, но лишь единицы – до полной пригодности для разработки реальных игр. Большинство бросают на полдороги, осознав, что не имеют нужных знаний и теоретической подготовки.
Есть и категория людей, которые разрабатывают свой движок годами, постоянно переписывая и даже начиная с чистого листа. Я отношусь именно к этой категории – я задался целью создать свой движок в 2009 году, на тот момент имея весьма слабое представление о том, как он должен быть устроен. Страшно представить, через что я прошел за это время: чего стоит только эпическая смена языка (с C++ на D) или весьма болезненный переход с классического фиксированного конвейера OpenGL на современный шейдерный (что поделать – технологии не стоят на месте!). Техно-демка игры под кодовым названием Atrium, которая у меня получилась в итоге, стала довольно известной в кругах D-шников (и даже за их пределами) – а сейчас я работаю над новым графическим движком для Atrium, использующим OpenGL 4. Попутно я также написал собственный программный растеризатор, чем-то похожий на ранние движки id Software. Думаю, что 10-летний опыт работы с графическими API и низкоуровневым программированием графики позволяет мне дать несколько скромных советов начинающим. Я учился на собственных ошибках и ошибках многочисленных коллег по хобби – и теперь хочу рассказать о том, как не допустить их.
Для начала – типичные ошибки нуба:
1. Постановка заведомо недостижимой цели. В свое время это называли созданием «второго Doom 3» или «убийцы Crysis» – многие, вдохновившись любимой AAA-игрой, загораются желанием создать что-то похожее. Естественно, что в одиночку это физически невозможно – поэтому ставьте реалистичные цели и постепенно повышайте планку по мере накопления опыта. На первых порах можно набросать краткий разумный список того, что должен уметь ваш движок, и постараться реализовать все это, после чего сделать какую-нибудь мини-игру или просто насыщенную графикой демку. Ваш движок не обязан быть мощным и сложным – но он должен быть продуманным и работающим, пусть и на уровне простых шариков-кубиков. Нет ничего хуже, чем попытаться прыгнуть выше головы и не суметь осуществить задуманное – именно на этом большинство и заваливаются.
2. Разработка без определенной цели. Другая, противоположная крайность. Если вы не ставите перед собой конкретных задач, то ничего дельного в итоге и не получится. Если вы только начинаете изучать геймдев, то вам больше подойдут готовые движки – в них тоже можно неплохо баловаться. А разработка движка – все-таки не баловство, даже если вы и занимаетесь этим в свободное время для собственного удовольствия. Без четкого понимания, что вы делаете и зачем, у вас ничего не выйдет. Нужно сразу определиться – либо вы создаете конкретную игру/прототип/демку и движок для нее, либо универсальный движок для любых игр. Это две разные задачи, два пути, которые быстро расходятся и мало пересекаются. Создавать «движок ради движка» нет смысла – без конкретного применения от него не будет пользы ни вам самим, ни кому-либо еще. Такая разработка вам вскоре надоест, и вы просто потеряете на ней время и силы.
3. Закрытая разработка. Вы, разумеется, вправе выкладывать в Интернет только скомпилированные версии своего движка – но не удивляйтесь, если ими никто не заинтересуется. Засекречивать исходники и беречь их от посторонних – удел коммерческих компаний. Для энтузиаста же хорошим тоном считается делиться своей работой с другими. Я, конечно, не призываю выкладывать сырой недописанный код, но, все же, чем раньше вы откроете свое детище общественности, тем лучше для вас самих – если вы создаете что-то действительно интересное, то вам обязательно помогут. Не факт, конечно, что люди будут писать за вас новые фичи, однако найдутся те, кто захочет протестировать ваши демки, скомпилировать ваши исходники под разные платформы. При этом будут всплывать баги, о которых вы даже не подозревали – а исправить их общими усилиями намного проще, чем в одиночку. Кто-то даст ценный совет или объяснит сложную вещь, кто-то сам поделится исходниками или другими полезными материалами. Люди будут появляться и исчезать, но их вклад останется – все лучшие OpenSource-проекты именно так и создаются. Не открывая код, вы заведомо лишаетесь ценной вещи – сотрудничества: очень многие любительские проекты с большим потенциалом сгинули именно из-за того, что были закрытыми. Не стоит пополнять их число – дайте сообществу возможность помочь вам!
4. Желание поддерживать все технологии сразу. С таким императивом вы впадете в то, что называется over-engineering – то есть, сделаете движок более сложным, чем в действительности нужно. Не стоит добавлять в движок дополнительные технологии и возможности, если:
- вы не уверены, что они будут использоваться;
- вы не знаете точно, как они должны быть реализованы;
- они плохо вписываются в архитектуру вашего движка.
«Костыльная» поддержка всех мыслимых графических технологий, реализованная по принципу «хоть плохонько, но чтобы было», не сделает ваш движок привлекательнее, а скорее наоборот.
5. Желание поддерживать все графические API. Это заблуждение проистекает из предыдущего, но оно настолько распространено, что я решил упомянуть его отдельным пунктом. Если вы не компания уровня Epic Games, то вам поддержка нескольких API просто не нужна. Принцип простой – если нужна кроссплатформенность, то используйте OpenGL, а если разрабатываете исключительно под Windows, берите Direct3D. Попытка поддерживать и то, и другое приведет к тому, что вместо игрового движка вы будете лепить монструозные абстракции и glue-код, писать транслятор шейдеров и решать прочие многочисленные проблемы, порожденные разницей в функциональности Direct3D и OpenGL. То же касается и поддержки разных версий внутри одного API – не стоит гнаться за всеми версиями сразу, выберите одну и делайте все на ней.
6. Зацикленность на C++. Не спорю, многие современные игры написаны на нем. Если вы уже неплохо знаете C++, то, наверное, нет никаких причин не выбрать именно его. Но учить C++ с нуля только ради того, чтобы написать на нем игровой движок – увольте. На дворе уже не 90-е, сейчас есть масса более удобных и современных языков, которые сильно облегчат вам жизнь, не вынуждая жертвовать производительностью. Да, существуют узкие места и особые моменты, требующие ручной оптимизации, которую в высокоуровневых языках порой делать трудно. Но с повышением производительности компьютеров все эти хаки перестают быть необходимостью – основную нагрузку берет на себя GPU, а на каком языке написана CPU-сторона, уже не столь важно. Выберите язык, который вам понятен, которым вы можете овладеть в совершенстве, и пишите на нем. Лучше писать хороший код на Python, чем убогий код на C++.
Итак, вы поставили себе цель, составили список желаемых возможностей, выбрали язык и API. Как правильно начинать?
1. Не пишите все с нуля, используйте готовые библиотеки. Например, при использовании OpenGL для создания окна и чтения ввода можно взять SDL. Для загрузки шрифтов есть Freetype, для 3D-моделей – Assimp, для игровой линейной алгербы – glm. Библиотеки есть практичеси для всех типовых задач в мультимедийном приложении. Мне лично пришлось написать большинство таких библиотек самостоятельно, поскольку я выбрал язык D, а библиотеки для C++ в нем использовать крайне затруднительно – тем не менее, я использую C-библиотеки, такие как SDL, Freetype и OpenAL.
В целях обучения вы, конечно, можете попытаться самостоятельно написать свои аналоги этим библиотекам – в этом случае вы либо разочаруетесь и сдадитесь, либо потратите много времени и станете очень крутым специалистом, коих единицы. В любом случае, опыт может получиться интересный, но движок написать он вам не поможет.
2. Не используйте как основу для движка код из уроков и примеров. Примеры создавались с особой целью – наглядно показать работу той или иной технологии. Авторы примеров вполне ожидаемо не реализуют «настоящий» игровой фреймворк, поскольку это затруднило бы чтение кода – вместо того, чтобы сразу вникнуть в технологию, читателю пришлось бы сначала изучать фреймворк. Лучше вообще свести бездумный копипаст к минимуму – возьмите за правило не копировать чужой код объемом больше 5-10 строк, а просто читать его и затем писать свой. Нет ничего хуже, когда программист не разбирается в собственном же коде – а копипаст обычно приводит именно к таким ситуациям.
С заимствованием готовых компонентов дело обстоит немного иначе. Вы можете включить в свой проект модули, функции или классы из чужих разработок, если позволяет лицензия – это распространенная практика, и в ней нет ничего плохого, особенно если заимствуемые компоненты эффективны и проверены временем. Но в этом случае нужно быть готовым исправлять в них возможные баги. Если вы неспособны быстро вникать в чужой код, то лучше с ним и не связываться.
3. Очень часто движок на ранних стадиях пишется так, чтобы как можно быстрее получить картинку на экране. Это неправильно. Нужно с самого начала написать фреймворк, основу, которая в дальнейшем не будет меняться. Иначе вы будете раз за разом переписывать все «сверху вниз» (то есть, при добавлении высокоуровневых компонентов переписываются низкоуровневые), что является следствием плохого проектирования. О картинке можете не думать, пока у вас не будет пользовательского ввода, менеджера событий, управления памятью и ресурсами. Нужно постепенно наращивать функциональность – от общей и обязательной к частной и опциональной.
4. В современном геймдеве есть несколько распространенных техник рендеринга, и вы должны изначально определиться с техникой. Будет ли ваш движок использовать PBR-материалы или классические Diffuse-Specular? HDR или LDR? Прямой рендеринг или отложенный? Можно, конечно, попытаться поддерживать все техники сразу, но спросите себя – нужно ли вам это? Излишне самоуверенных отсылаю к ошибке нуба №4.
5. Продумайте, как вы будете управлять ресурсами – в какие моменты должна происходить загрузка, как будет выводиться экран загрузки, какие ресурсы движок должен перодически высвобождать, а какие – нет. Большинство не уделяет достаточно внимания этим вопросам, в то время как загрузочный экран с анимацией – важный атрибут любой уважающей себя игры. Поскольку рендеринг происходит только в главном потоке, загрузка ресурсов должна происходить во втором – придется научиться работать с многопоточностью. Если не реализовать грамотное управление ресурсами с самого начала, добавить его потом будет очень трудно.
6. Не менее важно разделение игровой логики на отдельные ситуации. Движок должен позволять создать меню, экран настроек, экран паузы – все эти моменты также нужно продумывать с самого начала. Ваш движок не обязан из коробки поддерживать сложный GUI, но хотя бы должен включать необходимый минимум инструментов для того, чтобы пользователь мог этот GUI реализовать.
7. Помните, что графический движок – лишь один из компонентов, которые придется реализовать. В любой игре нужны средства вывода звука, большинству action-игр нужен физический движок. Часто физика в игровых движках – это «бедный родственник», которому уделяется куда меньше внимания, чем графике. А ведь какой бы красивой и навороченной ни была графика, без качественной физики и проверки столкновений она бесполезна – никто не захочет играть в игру, где персонажи застревают в стенах или проваливаются сквозь пол.
Вы можете попробовать написать свой физический движок, либо взять готовый. Обычно советуют второе, но я, судя по собственному опыту, не буду столь категоричен. Да, во многих случаях функциональности существующих физических движков более чем достаточно, но бывают ситуации, когда они ведут себя не так, как нужно, а то и вовсе чего-то не умеют – типичным примером является контроллер персонажа. Часто в движках кинематика не пересекается с динамикой, что оборачивается невозможностью для контроллера персонажа нормально взаимодействовать с динамическими телами – эти две системы связываются с помощью «нефизичных» хаков, которых в готовых решениях обычно нет. При этом контроллер персонажа – еще довольно распространенная штука. А сколько может возникнуть проблем с готовыми движками в различных нетривиальных игровых механиках – и представить сложно! Взять хотя бы игры с открытым миром и динамической подгрузкой окружения. Реализация реалистичной физики в таких играх – архисложная задача, решения которой единичны. Именно поэтому вопрос выбора физического движка сугубо индивидуален, и давать общие советы здесь не представляется возможным.
8. Совершенно необязательно включать в движок поддержку всех мыслимых форматов 3D-моделей – большинство из них малопопулярны, и их загрузчики все равно не будут использоваться. Достаточно поддерживать два-три распространенных (например, OBJ, COLLADA, FBX), либо придумать свой собственный формат с четко заданной спецификацией и сделать движок расширяемым, чтобы пользователь мог самостоятельно добавить поддержку произвольного формата. Хорошим тоном является создание отдельной утилиты, которая конвертирует модели в понятный движку формат, либо предоставление готовых экспортеров в этот формат для популярных 3D-пакетов. Также неплохим решением является реализация загрузки моделей через библиотеку Assimp. Инструменты для создания контента вообще очень важны: чем проще пользователю загрузить свою модель в ваш движок, тем скорее он в нем освоится и захочет создавать на нем игры.
9. Не гонитесь за производительностью, особенно на ранних этапах. Во-первых, любая технология создается для будущего, а не для настоящего – то, что тормозит сегодня, скорее всего, не будет тормозить завтра. Во-вторых, производительность следует измерять только на реальных приложениях, когда движок написан и отлажен, когда уже можно сделать на нем что-то играбельное. Попытайтесь сначала написать на своем движке один полноценный игровой уровень, а уже потом судите – достаточна ли производительность, или необходима оптимизация.
Это, конечно, не означает, что нужно пренебрегать азами оптимизации и писать никчемный код, для рефакторинга которого придется переделать его полностью. Избегайте выделения динамической памяти в игровом цикле, сведите к минимуму использование системных вызовов, заменяйте деления на 2 умножениями на 0.5. Старайтесь писать просто грамотный, логичный код, и с высокой долей вероятности он не будет нуждаться в особой оптимизации.
10. В обязательном порядке протестируйте работу движка на разных компьютерах с разными операционными системами. Если вы сами не можете, то найдите тестировщика, который может. Как вариант – выпустите публичную альфа-версию движка, чтобы ее могли протестировать все желающие. Чем раньше вы убедитесь в работоспособности вашей разработки на всех основных платформах (Windows разных версий, Linux, macOS), тем лучше. Конечно, вы можете и отказаться от поддержки платформ, отличных от вашей, но в таком случае вы сильно сужаете свою потенциальную аудиторию, что для любительского проекта не очень-то хорошо. К примеру, линуксоиды обычно очень дружественны к персональным проектам и могут здорово помочь, но они не будут специально ставить Windows, чтобы запустить ваши демки. Если вы откроете исходники, вам может повезти – кто-нибудь поможет вам портировать ваше творение на Linux.
Напоследок хочу рассказать о психосоциальных аспектах разработки движка. Вопреки распространенному мнению, эта задача вполне по плечу одному человеку. Джон Кармак написал движки Doom и Quake в одиночку – и это притом, что ему приходилось быть первопроходцем и многое изобретать с нуля. Кто-то скажет, что Кармак – гений, но что есть гений? Один процент таланта и девяносто девять процентов пота. Если вы взялись за создание игрового движка, это должно стать вашей страстью. Нужно быть влюбленным в это дело, иначе нет смысла браться.
К тому же, во времена Кармака не был так развит Интернет, не было такого количества образовательных материалов. Сейчас к вашим услугам Википедия, научные статьи, материалы с SIGGRAPH, готовые исходники, примеры и демки. Знания доступны каждому, нужно лишь быть способным к самообразованию. Поэтому не слушайте тех, кто демотивирует вас, пытаясь убедить, что вы ничего не сможете.
Вот вам еще несколько вдохновляющих примеров:
- Николаус Гебхардт (Nikolaus Gebhardt) написал Irrlicht, один из самых популярных свободных движков.
- OGRE начался как персональный проект Стива Стритинга (Steve Streeting).
- Майк Лишке (Mike Lischke) в одиночку разрабатывал GLScene до версии 0.5.
Конечно, если у вас нет опыта работы с готовыми движками, то вряд ли с первого раза получится что-то стоящее. На самом деле, с первого раза мало что получается и у гениев. Если вы способны к самокритике, то вам самим не понравится ваше первое творение. Однако вы получите ценный опыт, который поможет в дальнейшем. Главное – не разочаровываться и не бояться начинать заново.
Для персонального хобби-проекта переписывать все с нуля – совершенно нормальное явление. Смело боритесь с психологическими барьерами, мешающими вам уничтожать и переделывать собственный труд – помните, что вы не пишете за деньги, у вас над душой не стоит начальник. Вы абсолютно свободны и можете делать с кодом все, что захотите – перед вами бесконечный путь совершенствования!
Тимур Гафаров
Blender и пластилиновая анимация
Как создавался мультфильм «Мишка»
«Мишка» – короткометражный анимационный фильм в пластилиновой технике с элементами CGI, созданный начинающим казанским продюсером Фархадом Гафаровым в качестве дипломной работы в КазГИК (Казанском государственном институте культуры). Это классическая детская комедия-буффонада в духе «Тома и Джерри»: смешные и неуклюжие злодеи – мишка-воришка и его приятель Свин – пытаются обокрасть медведя-пчеловода, но раз за разом терпят неудачи и попадают в различные забавные ситуации. Узнать подробнее об этом проекте и посмотреть его онлайн вы можете на сайте https://mishka-film.blogspot.com.
В статье ниже создатели фильма – братья Тимур и Фархад Гафаровы – поделились опытом пост-продакшена и создания спецэффектов к пластилиновому мультфильму. Для нашего журнала это интересно, в первую очередь, тем, что весь пайплайн проекта был основан на свободном ПО.
Для создания «Мишки» мы использовали свободное графическое программное обеспечение – в частности, предварительная обработка кадров осуществлялась в GIMP, также мы использовали ImageMagick для автоматизации рутинных процессов и даже разработали свой инструмент для вырезания фона, который теперь доступен для всех желающих на GitHub. Но самое сложное и интересное – сведение кадров в единую анимационную последовательность – было проделано в Blender.
Blender известен, в первую очередь, как пакет для работы с 3D-графикой – он включает полный набор инструментов для всех этапов производства 3D-анимации, от моделирования до видеомонтажа. Покадровую stop-motion анимацию в нем еще никто, насколько мы знаем, не делал. И, хотя в нашем проекте пригодились далеко не все возможности Blender, поначалу были опасения, потянет ли программа весь предстоящий объем работ: нам предстояло свести воедино более 5000 отснятых кадров, смоделировать и отрендерить 25 статичных фонов и двух полноценных CGI-персонажей. При этом весь исходный материал был рассчитан на Full HD, чтобы на выходе мы могли получить качественное видео не только для онлайн-трансляции, но и для показа в кинотеатрах и на экранах высокого разрешения. Теперь понятно, что опасения были напрасными: Blender не только прекрасно справился с нашими специфическими задачами, но и позволил применить на практике множество интересных приемов и техник, о которых и пойдет речь в этой статье.
Как читатель, вероятно, знает, создание классического кукольного мультфильма предполагает покадровую съемку персонажей с небольшими изменениями поз от кадра к кадру. И, если в кино снимается 24 кадра в секунду, то в кукольных мультфильмах, для сокращения объема работ – 12. Программа монтажа должна учитывать эту особенность, ведь итоговый видеофайл все равно должен содержать 24 кадра в секунду. Большинство видеоредакторов, конечно, позволяют вручную задавать длительность клипа, но выполнить эту операцию для всех 5000 кадров мультфильма было бы, конечно, нереально – поэтому от обычных программ видеомонтажа мы сразу отказались.
На наше счастье, в видеоредакторе Blender (Video Sequence Editor, VSE) можно импортировать кадровую последовательность из отдельных файлов PNG как единый клип, а затем задать для него необходимую длительность при помощи эффекта Speed Control – именно вокруг этого замечательного инструмента и был построен весь процесс монтажа «Мишки». Мы могли контролировать длительность клипов вне зависимости от количества содержащихся в них кадров – одни движения были специально ускорены, другие замедлены, и большинство чередовались со статичными кадрами. Все эти операции выполнялись легко и быстро.
Однако склейка кадров была лишь первым этапом работы. Мы изначально задумывали «Мишку» как фильм с элементами компьютерной графики, поэтому большинство кадров нужно было наложить на отрендеренный фон. Здесь очень пригодилась другая особенность VSE – чрезвычайно удобный монтажный стол с неограниченным количеством дорожек и гибким масштабированием, в котором можно создавать многослойные композиции с несколькими фонами и передними планами. Причем к каждому слою можно по отдельности применять инструменты цветокоррекции и трансформации, а также различные эффекты и фильтры – все это также нашло применение в «Мишке», и вот лишь несколько примеров:
- В сцене с Воришкой, скачущим на пчелином домике, приемы традиционной покадровой анимации оказались бессильны – этот эффект был полностью реализован средствами VSE. Поверх отснятого фона были размещены сам Воришка и тень от него. Затем слой с Воришкой был анимирован при помощи ключевых кадров, постепенно сдвигающих его и меняющих масштаб – все промежуточные кадры были рассчитаны программой. Этот же прием мы затем использовали для анимации Свина, запрыгивающего в дымоход. Благодаря тому, что в Blender любой числовой параметр может быть анимирован, VSE превращается в отличный редактор motion-графики.
- В сцене с закадровой дракой Воришки с дворовым псом необходимо было добиться классического эффекта «трясущейся камеры». Это удалось легко сделать при помощи модификатора F-кривой Noise – то есть, позиция изображения на экране смещалась под действием функции шума. Подобные сложные эффекты возможны благодаря тому, что в Blender любая анимация представлена в виде функциональной кривой, и есть специальный редактор, в котором можно менять параметры этой кривой.
- Одна из сложных в плане постпродакшна сцен – медленно идущий Свин с гротескно ускоренной сменой дня и ночи. Естественно, добиться такого эффекта физическим освещением было невозможно, поэтому было решено снять кадры при «дневном» свете и имитировать переход в ночь постобработкой. Это удалось сделать благодаря коррекционным слоям (Adjustment Layers) в VSE – для отснятого материала был создан коррекционный слой с необходимыми цветовыми фильтрами, и его прозрачность анимировалась для постепенного ухода в ночь. Солнце и Луна на небе были отрендерены отдельно и наложены поверх коррекционного слоя.
- Отдельного упоминания заслуживает сцена падения бочки в воду. Сначала мы попытались снять ее традиционным методом, покадрово, но результат нас не удовлетворил, и в итоге сцена была сделана в Blender с использованием изображений, вырезанных из отснятого материала. В этой сцене была применен физический движок Blender – движение бочки представляет собой симуляцию динамики твердого тела. Падение бочки в воду – симуляция плавающего тела – было имитировано при помощи контейнера с пружиной.
Это, конечно, далеко не все примеры использования CGI в проекте – сюда относятся и сцены с пчелами, и сон Свина, и путешествие героев на вагонетке в подземелье. Особенно интересна сцена с камерами слежения в магазине: сначала мы отсняли кадры, которые должны отображаться на экранах в комнате Охранника, затем смоделировали эту комнату в 3D-графике и наложили анимацию на экраны в качестве видеотекстур.
Наконец, фильм был сведен, и его оставалось озвучить. Это также было сделано в Blender – VSE поддерживает все необходимые инструменты для работы с аудио. Благодаря анимируемым свойствам клипов, нам удалось реализовать стереоэффект для звуков от движущихся объектов – например, звук моторной лодки плавно переходит от левого аудиоканала к правому или наоборот, в зависимости от анимации. Кстати, не лишним будет также упомянуть, что предварительную обработку звуковых эффектов и запись озвучки мы также выполнили свободной программе, а именно Audacity.
Игра в будущее
В знаменитой видеоигре «Urban Strike» в одном из эпизодов игры террористы разрезают лазером одну из башен Всемирного торгового центра, в которую также закладывают бомбу. Не правда ли, напоминает всемирно известный теракт в США 11 сентября 2001 года? При том, что события игры по сюжету происходят в 2001 году. А теперь самое главное: игра была издана... в 1994 году!
Пока эзотерики по всему миру пытаются разгадать новые «прогнозы» на будущее в изречениях Ванги и Нострадамуса, самые настоящие предсказания оказываются куда ближе, чем нам кажется. Все мы привыкли к мысли, что писатели-фантасты, создавая мир будущего в книгах, в каком-то смысле формируют взгляд ученых и изобретателей на будущее, тем самым, подталкивая к определенным открытиям. Так случилось с роботами, господство которых предрекали еще в 18-19 веке, киборгами, полетами в космос, клонированием, Интернетом, виртуальной реальностью. Однако, никто не задумывался над тем, что будущее предсказывают видеоигры!
Так в культовой для киберпанк-культуры игре «Deus Ex», где действия разворачиваются в антиутопическом мире, в котором экономический кризис практически уничтожил государства, а миром управляют террористические организации и иллюминаты, предсказали... птичий грипп! По сюжету игры, в мире разворачивается катастрофическая пандемия вируса «серая смерть», которая началась в Гонконге, а затем захватила весь мир. По ходу игры главный герой узнает, что вирус был специально создан в лабораториях. В 2006 году мир действительно захватила волна схожего вируса – «птичьего гриппа» H5N1, который распространился именно из Гонконга! Страх охватил весь мир, но через какое-то время все будто бы забыли, что такой вирус вообще существует – с некоторых пор о нем вообще ничего не слышно, словно «птичий грипп» действительно кем-то контролируется..
Интересно, что в аналогичной знаменитой игре – «шутере» «Crysis 2» (2011) почти что предсказали... вирус «эбола» – в игре присутствует чудовищная неизлечимая болезнь, очень поминающая лихорадку этого вируса.
В другой игре – «Perfect Dark», которая вышла практически в то же время (в 2000 году) предсказали... Барака Обаму в качестве президента США! Действия игры происходят в недалеком будущем. Одним из персонажей игры является американский президент, являющийся афроамериканцем и как две капли воды похожим на Барака Обаму (который был избран на пост президента лишь через девять лет). В игре, кстати, предсказали и общую моду на толерантность – главным помощником президента является женщина!
Смерть другого известного лидера Ким Чен Ира спрогнозировали в «Homefront»: причем дата смерти по сюжету отличается от реальной всего на несколько недель. В сверхпопулярной японской ролевой игре «Final Fantasy III» фигурирует вымышленная виртуальная независимая валюта «GIL». Ее иконка весьма напоминает... «биткоин», который по сути стал подобием «GIL» – тоже частный, независимый от государства и универсальный по всему миру! В восьмой же части «Последней фантазии» была предсказана смерть радио-телевидения и переход на цифровое ТВ высокой четкости.
А в менее известной стратегической игре «Sid Meier's Alpha Centauri», которая вышла в 1999 году, предсказали расшифровку ДНК. Действие игры происходит в далеком будущем, в котором расшифровка ДНК стала ключом к излечению от всех болезней. В 1999 году подобное казалось не более чем фантастикой, но уже в 2003 году ученые смогли сделать сенсационные открытия в области изучения ДНК. В 2018 появились первые практические результаты этих исследований – конечно, человечество еще далеко от того, чтобы лечить все болезни, но кто знает, что нас ждет впереди?
Видеоигра-бестселлер «Metal Gear Solid: Integral», вышедшая в 1999 году, представила игроку несколько сотен миссий-тренировок, в которых главному герою, шпиону Солиду Снейку, необходимо оттачивать скрытное проникновение, убийства, стрельбу и уничтожение роботов. Вся эта тренировка происходит в виртуальной реальности, подобные сюжеты были во многих фильмах и играх: «Матрица», «Люди Икс» и других. Удивительно, но уже сейчас подобное стало частью нашего мира: в 2012 году США внедрила военный тренажер «Dismounted Soldier Training System». Для тренировки солдат надевает специальный костюм с датчиками движения, рюкзак с портативным компьютером и шлем с внутренним дисплеем, после чего заходит в специальную комнату и начинает сражаться в виртуальном мире, двигаясь в реальности по пустому пространству.
Кстати, во второй части «Metal Gear» (1990) создатели спрогнозировали появление топлива из водорослей, которое по сюжету игры было создано чешским ученым в конце 90-ых. В реальности, конечно, оно появилось позже – в 2012 ученые из Калифорнии создали экологичное дизельное топливо на основе водорослей и бензина.
А в современной части «Metal Gear Rising: Revengeance» (2013 года выпуска) предсказали приход к власти... президента США Дональда Трампа! В игре фигурирует некий сенатор Стивен Армстронг, по сюжету участвующий в президентской гонке 2020 года. Персонаж внешностью и темпераментом подозрительно точно напоминает американского президента. Мало того, в одном из эпизодов игры Армстронг буквально кричит: «They will make America great again!» («Make America Great Again», «Вернем Америке былое величие» – предвыборный лозунг Трампа).
В другой военной игре «Call of Duty: Modern Warfare» создатели фактически предсказали современную военно-политическую ситуацию в мире. В игре затрагиваются такие темы, как национализм, империя, военный переворот. В 2007 году, когда вышла эта «стрелялка», никто и подумать не мог, что ситуация в мире может накалиться до такой степени. Но уже в 2014-ом Россия, по сути, вступает в информационную войну с Украиной и новую холодную войну с Америкой. Ситуация в Сирии, Украине очень сильно напоминает все то, что предрекали в «Call of Duty». Кстати, конфликт России с Грузией тоже был предсказан в игре – в «Ghost Recon». По ее сюжету, в 2008 году в Грузию внедряется миротворческий отряд, предлагающий свою помощь для того, чтобы разобраться с русскими. Удивительно, но ведь именно в 2008 году начались военные действия в Южной Осетии!
В другой известной игре, над сценарием которой, так же как и над «Ghost Recon», работал военный писатель Том Клэнси – «Splinter Cell» (2002) по сюжету в Грузии террорист-смертник убивает президента, в результате чего после досрочных выборов к власти приходит миллиардер Комбаян Николадзе. Эта история во многом схожа со случившимся в 2003-2004 году государственным переворотом в Грузии, когда после досрочных выборов пост президента занимает Михаил Саакашвили.
Трудно поверить, но даже теракт в Париже 13 ноября 2015 года тоже был предсказан! Создатели «Battlefield 3» (2011) в своей игре назвали точную дату этого теракта – 13 ноября! Ошиблись только годом – по сюжету он происходит в 2014, а не в 2015 году. В другой части «Battlefield» 2006 года в игре была возможность «засветить» врага, чтобы не потерять его из виду. В 2013 в США реализовали оружие с такой возможностью! Компания «TrackingPoint» разработала винтовку с компьютеризированной системой прицела на базе ОС Linux. Специальной функцией можно пометить врага, и помеченная точка будет сама отслеживать его перемещение. После того этого можно просто навести «мушку», и винтовка выстрелит сама!
Видеоигра «Madden NFL», симулятор американского футбола, вообще, по отзывам игроков, обладает практически магическим свойством предсказывать результат американского Суперкубка. Опытные игроки утверждают: если запустить игру в режиме симуляции искусственным интеллектом, выбрав команды, попавшие в финал чемпионата, то в 8 из 10 случаев игра даст правильный прогноз!.. Кроме того, с игрой связана другая мистика – практически все игроки, которых изображали на обложках игр серии «Madden NFL», либо вскоре серьезно травмировались, либо вообще попадали... в тюрьму.
Другой спортивный симулятор – «Football Manager 2007», в котором можно попробовать себя в роли футбольного менеджера, предсказал, что Лука Модрич, Серхио Агуэро, Жерар Пике, Серхио Рамос станут суперзвездами. Дело в том, что эта игра с помощью искусственного интеллекта могла анализировать потенциал молодых игроков и выдавать прогнозы об уровне их перспективности. Сейчас многие настоящие футбольные менеджеры и тренеры вновь обращаются к старой игре более чем десятилетней давности для того, чтобы получить ценную информацию об игроках. Не удивительно ли это?
А в аркадной игре «Smash TV», которая появилась в 1990 году были предсказаны реалити-шоу – такие, например, как «Последний герой» (в западной версии «Survivor»). Суть игры заключается в том, что герой попадает в некое жестокое телевизионное шоу, где нужно убивать других участников, а в конце сразиться с главным «боссом» – телеведущим. Конечно, во многом игра вдохновлена фильмом «Бегущий человек» с Арнольдом Шварценеггером в главной роли и со схожей концепцией.
Между тем, симулятор космических путешествий «Elite: Dangerous» предсказал открытие целой звездной системы! Игра использует специальный алгоритм для генерации космических объектов. Каково же было удивление разработчиков, когда в 2016 году «NASA» открыли звездную систему «TRAPPIST-1», которая... в точности совпала с существующей звездной системой в игре
Но самое пугающе точное предсказание было сделано в игре 2008 года «FallOut 3» – в ней придумана радиостанция, которая передает сообщения в шифрованном виде. Если расшифровать одно из сообщений, то выясняется, что 20 апреля 2010 года произошел «инцидент в заливе, несколько погибших. Разлив нефти, по всей видимости, предотвращен». Но ведь именно 20 апреля 2010 года в Мексиканском заливе произошла катастрофа на нефтедобывающей платформе «Deepwater Horizon». Конечно, в игре были и другие предсказания, например, о том, что Бритни Спирс в 2029 году получит премию «Оскар». Что ж, поживем – увидим!
Фархад Гафаров