Недавно мы рассказывали про рейды. Быстро освежим: это групповая практика, система, где люди собираются, чтобы совместно создать большой продукт. По сути, это симуляция настоящей работы.

Изначально рейды были достаточно маленькие, на очень упрощённом пайплайне. С каждым следующим рейдом усложняется пайплайн, усложняются технологии и усложняется организация. Да, мы любим усложнять.

И вот наша первая маленькая победа — Японский рейд. Это первый рейд, который был полностью организован учениками. Студенты не участвовали в препродакшене, просто приходили на уже готовый список пропсов, разбирали роли и моделили. В этот раз всё было иначе.

Даём слово нашим студентам, а сами уходим в тень…

Как мы начинали создавать этот рейд, как появилась идея, как происходила первичная организация

Как только появилась идея, мы начали собирать команду. Сразу прикидывали, какой вклад каждый из нас сможет внести в реализацию задуманного. Мы собрали первичные референсы, чтобы материализовать всё сказанное, сделать идею наглядной и развёрнутой.

Пока мысли лишь высказаны — это идея, но стоит сделать пару набросков и собрать немного материалов — это уже план.

Пока есть запал двигаться вперёд, делаем блокинг. Простенький, без лишних деталей, только главные элементы. Это базовый набросок идеи, мы нащупывали, что именно мы хотим делать. Дворец, беседка, вода. Чем больше объектов можно повертеть и потрогать, тем лучше.

Да, вопросов пока больше, чем ответов. Но кто спрашивает, тот не заблудится, так что уверенно двигаемся дальше.

Продолжаем развивать идею, пока не появится кусочек локации.

Команда собралась разнообразная, что сыграло нам на руку во многих моментах. Например, одна из участниц — архитектор по образованию, увлекающаяся ландшафтным дизайном, — в процессе блокинга подметила, что тропинки расположены неестественно: людям неудобно было бы ходить по ним. Тропинки должны начинаться у дверей поместья. Сейчас это звучит невероятно просто и логично, но тогда для нас было приятным открытием. Мы раньше с подобными задачами не сталкивались, поэтому просто не обратили внимания на подобные мелочи. А ведь детали — очень важная часть работы, позволяющая зрителям подсознательно верить (или не верить) в происходящее.

Это большая ценность групповой работы, потому что группа людей умнее каждого из них по отдельности. Общая степень компетентности растёт с ростом команды и разнообразием её опыта.

Рабочие моменты

Мы с самого начала знали, что будем использовать Unreal Engine 5 для рендера. У нас уже был один экстерьерный рейд, после которого появился опыт работы в этом движке. Не уверен, что мы были супер компетентны, но на знакомой территории всегда спокойнее. Понимание того, что есть софт, который знает часть команды, стало приоритетом.

Одна из наших задач в Unreal Engine 5 — разобраться с левелами. Когда работает большая команда, нужно так организовать действия, чтобы можно было выполнять их параллельно и при этом избежать конфликтов. Нам подсказали решение — левелы. По сути, они работают как слои в фотошопе: каждый левел условно с прозрачным фоном, на нём есть какие-то объекты. Когда вы их включаете, они отображаются, выключаете — исчезают.

Несмотря на то, что блокинг довольно условный, здесь уже много интересных сюжетов. На самых первых этапах рождались персонажи и их история, появлялся дизайн. Сцена наполнялась смыслами. Она технически была ещё очень просто сделана и просто реализована, но уже несла в себе историю, готовилась к тому, что мы перейдём к полноценному продакшену и разработке.

Начало работы — самая творческая часть проекта: всё придумывается, всё создаётся. Дальше уже идёт процесс реализации всех идей и задумок, а их здесь много. Уже на этом моменте мы видим очень близкий к финалу результат. Не по визуалу, а по содержанию.

В ходе работы рождалось много маленьких идей и сюжетов. К сожалению, не все из них дожили до релиза. Но это такой ценный момент сбора смыслов, которые потом и превратились в финальную сцену.

На этапе концепта постоянно держишь в голове, что графика — это итеративный процесс, где нужно неустанно делать разные версии, отслеживать прогресс, что-то убирать, что-то добавлять, искать новые инструменты. В итоге получается непрерывно меняющаяся сцена. Из этой черновой геометрии ничто не осталось неизменным, ничто не дошло до финала в таком варианте.

После блокинга наступает неизбежное — документация. Душная и немного менеджерская работа, но без неё никуда. Мы расписали роли, сделали роад мапу.

Конечно, планы были грандиозные, но не всё удалось осуществить. В каких-то моментах нам не хватило компетенции, где-то время сыграло против нас. Если быть до конца откровенным, подобные планы, наверно, почти никогда не соответствуют реальности и конечному результату. Наша задача — максимально подстраивать таблицу под реальность и реальность под таблицу, чтобы они друг другу соответствовали.

Мы расписали роли, пропсы — то, что нужно замоделить: предметы, анимация. Наладили систему, которая упростит нам работу. Ценность подобного подхода в том, что ты всегда видишь, на каком этапе твой сосед, какие пропсы свободны, какие референсы используются. Например, был такой прецедент, что референсы, по которым лепился дракон, позже пригодились для анимации его поз. Две эти задачи выполнялись разными людьми. Это удобнейшее рабочее пространство и невероятный симбиоз людей, увлечённых одной целью.

Перед тем, как закончился препродакшен, мы подготовили таблицы. Много таблиц. Здесь были написаны названия пропсов, которые нужно сделать, для каждого пропса отдельная строка и несколько столбцов: к какой команде принадлежит пропс, исполнители, референсы, скрины работ, комментарии для арт лида и тех лида. Таким образом мы смогли объединить работу команды максимально удобно и эффективно.

Честно об ошибках и неудачах

Мы собирали блокинг не в анриле: то в блендере, то в майе, а потом уже переносили всё в анрил. Это была большая ошибка, за которую мы поплатились. Нам пришлось много чего переделывать. Все объекты, находящиеся на блокинге, были заменены руками. Мы не с самого начала знали о чудесной функции в анриле — реимпорт. Возможно, это сэкономило бы нам время. Условно, беседка прошла блокинг, потом мы её доделали: подкрутили сетку, сделали UV; модель обновилась, её нужно поставить на то же самое место. Реимпорт ставит модель на те координаты, где находился блокинг. А мы сначала удаляли блокинг, а после выставляли заново на глаз эту модель. Да, не ищем лёгких путей.

У нас было несколько версий неба, мы искали способ, как кго сделать. У нас был вариант с HDR: просто текстуры на небе. Соответственно, одна дневная и одна ночная. Но нам не очень понравилось, как это выглядит. Потом мы попробовали вариант с анриловским небом и анриловскими облаками — тоже не то. В итоге мы пришли к варианту Ultra Dynamic Sky — достаточно известный плагин, который помогает делать классное небо, классную погоду и атмосферу. Хотя варианты со старым небом некоторым нравились, были симпатичные и довольно интересно смотрелись, Ultra Dynamic Sky дал гибкость и возможности настройки, при этом сохранив простоту.

Вначале мы не умели работать с системой файлов. Вообще вся анриловская система файлов, система синхронизации контроля версий, GIT — это сложности. Их надо изучать по ходу проекта. Конечно, можно прочитать гайд, который разложит основные принципы работы с этими системами, сразу разобраться во всём. Но мы больше сторонники подхода, в котором нужно сначала поковыряться в незнакомом, что-то сделать правильно, что-то неправильно, обязательно сломать GIT, потом вместе чинить его. Начало — это важный этап, на котором есть некоторый карт-бланш на дестрой.

GIT — система контроля версий. Например, у тебя есть один проект, и на многих компьютерах хранятся файлы этого проекта. GIT — система, в которой все эти файлы синхронизируются. Если ты залез в GIT и скопировал оттуда проект, — это называется «клонировать репозиторий» — то потом по нажатию одной кнопки ты заливаешь в общие файлы обновления проекта, а также по одной кнопке скачиваешь все обновления из этого репозитория. Это необходимо для того, чтобы все работали в актуальной версии проекта и при необходимости отматывали прогресс назад, если где-то совершились ошибки. Большие проекты и любая командная работа без GIT не делаются.

Одна из основных проблем, с которыми мы столкнулись, — работа с текстурами. До какого-то момента у нас не было понимания, что нужно отсматривать всю сцену в каком-то определённом режиме: Base Color, Roughness и других. Это позволяет увидеть, что нужно регулировать цвета сцены, сводить их к чему-то единому. При смене режимов можно увидеть, например, что какие-то объекты слишком контрастные или наоборот очень бледные, или обнаружить в сцене металлический бамбук.

Ещё один наш промах заключался в том, что мы обновили Master Material, основной для всех ассетов, под Virtual Texture. Но к этому материалу был привязан плейсхолдер, который лежал локально, то есть не синхронизировался с GIT, а мы не уследили за этим моментом. В итоге у половины людей сломался этот шейдер, потому что анрил очень чувствительный: либо у него шейдер виртуальных текстур, либо обычных. Соответственно, если плейсхолдер в шейдере лежит, и он не виртуальный, а шейдер под виртуальными текстурами, то шейдер ломается, он не работает. Мы не обратили внимание на этот момент, и он поломал нам часть материалов. Мы в итоге это починили, конечно, но нервишки нам это потрепало знатно.

Были ещё трудности со светом. Местами свет баговал. Люмен нестабильный, это было ещё на старой версии анриала. Люмен — это метод непрямого освещения ретрейсинга. Мы находили его баги и исправляли их. Один из них заключался в том, что фонарики, которые парят в воздухе, не освещали окружение. Они изначально были близко к зданиям, и это сильно бросалось в глаза. В итоге мы убрали их подальше. Мы починили этот баг разными хитростями.

Наши победы

Юля

Изначально я не планировала брать какие-то серьезные и ответственные задачи на этом рейде. Я хотела попробовать сделать что-то новое, но небольшое, чтобы не тратить много сил и времени, потому что их на момент рейда было мало. Но пришлось всё-таки погрузиться в проект основательнее. Хотя был страх — вдруг я не справлюсь и подведу ребят, вообще вряд ли что получится, у меня ведь на это нет времени. Но в процессе я сама не заметила, как всё больше и больше брала на себя задачи. Сначала я хотела сделать деревце, позже нужен был левел артист — и вот я уже расставляю что-то в анриле, потом я как-то стала арт диром. Ответственности становилось всё больше и больше. Но всё получилось, и получилось классно. Это моя маленькая победа. Я рада, что на этом рейде у меня получилось попробовать много разных новых для себя ролей, что вряд ли случилось бы вне рейда.

Канат

Самая большая победа — мы завершили этот проект. Не моя личная, но заслуга всей команды. Несмотря на все трудности мы это сделали! Моя личная победа — я нырнул в RIG, хотя очень долго этого боялся. Но когда есть задача, которую ты взял, и тебе нужно сделать её в определённые сроки, приходится делать её хоть как-то. И это «хоть как-то» — хорошая база, чтобы начать и чтобы дальше учиться.

Гера

Соглашусь, что самая главная наша победа — окончание рейда. Проект был масштабный, длился 140 дней, сильно больших перерывов не было, поэтому под конец у всех силы уже были на исходе, очень хотелось закончить, и сделать это хорошо. Моя главная победа — я прошла весь путь от начала до конца, приобрела много знаний. Как сказал Канат: «Заходишь на рейд одним человеком, выходишь другим». Так как я была новичком, я почерпнула колоссальное количество знаний. Я тоже боялась лезть в Unreal, в GIT, в Speed 3. Я видела, как ребята работают с ними, но начинать всё равно было страшно. На рейде была возможность с этим разобраться, чему я очень рада.

Коротко о важном

Весь наш проект — это R&D. Research and Development — это процесс исследования, разработки и создания новых продуктов. Если говорить простым языком, то это весьма понятный цикл:

1. Гипотеза, которая у нас возникла.
2. Смотрим, кто её уже реализовывал и каким образом. Если примеры не находятся, то самостоятельно ищем способ её реализации: статьи, туториалы по нашей теме.
3. Проводим тесты, выявляя все ошибки, баги и неточности.
4. Собираем фидбэк: что сработало, что нет.

Колесо R&D дало оборот. Анализируем и проделываем этот алгоритм ещё несколько раз, пока результат нас полностью не удовлетворит.

На рейде было очень много ресёрча, много поиска технологий. Нам было важно сделать так, чтобы для студентов это была самостоятельная история, то есть настоящее исследование, как в продакшене. Мы с радостью подсказывали ответы на вопросы, когда к нам приходили ребята, но сами не навязывали свои советы. В этом смысле студенты взяли на себя очень много ответственности.

Мы восхищены нашим нетоксичным и дружелюбным сообществом, все друг с другом общаются, помогают. Это для нас большая ценность. Уровни компетенции, навыков и понимания (или непонимания) принципов работы, которые сложились воедино, создали большую сильную команду, которая как локомотив движется вперёд к своей цели. Единственная сложность у этого локомотива — нужно по пути строить рельсы. Но в проектах такое, к сожалению, происходит довольно часто.

Рейд — достаточно хардкорная история, потому что мы, по сути, бросаем ребят в воду и ждём, что они поплывут. Но наши жестокие (или нет?) методы с лихвой окупаются, когда мы видим их победы.

Приходи к нам делать крутые проекты! А если просто хочешь больше 3D-контента, то залетай в тг.

2025-11-10

Что значит рейд?

2025-11-13

Красота) Спасибо за статью!