Технический художник о создании инструментов, конвейеров и интеграции искусства с инженерией

Вы много лет работали над проектами AAA, AA, мобильными и симуляционными. Как ваш подход к техническому искусству развивался на таких разных платформах и в условиях производства?

В начале карьеры я уже искал способы сэкономить время и сделать рабочие процессы более предсказуемыми и устойчивыми к сбоям. Даже когда я был сосредоточен на создании окружения, я постоянно разрабатывал небольшие инструменты или процессы, чтобы устранить трудности.

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

Теперь мой подход сосредоточен на создании рабочих процессов, которые предотвращают проблемы, а не реагируют на них. Если что-то постоянно ломается, это обычно проблема конвейера, а не художника.

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

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

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

Если знания существуют только в уме, это становится проблемой. Когда кто-то уходит, эти знания уходят с ним. Правильная структура на раннем этапе приносит огромную пользу. Она поддерживает согласованность команд, быстрее выявляет проблемы и делает сложные задачи повторяемыми, а не хрупкими.

Вы много работали в Unreal Engine, включая помощь студиям в переходе с проприетарных движков. С какими самыми большими проблемами сталкиваются команды при таком переходе, и как технические художники могут облегчить этот процесс?

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

Хотя я провёл последние несколько лет, активно работая в Unreal Engine, ранее в своей карьере я также много работал в Unity. В обоих движках основные концепции очень похожи. Они просто представлены по-разному. Я обнаружил, что это помогает дать командам чёткую ментальную и визуальную карту того, что чему соответствует, чтобы они могли быстрее установить эти связи.

Технические художники могут облегчить процесс:

• Переводя рабочие процессы в нативные для движка подходы
• Устанавливая стандарты на раннем этапе
• Создавая мостовые инструменты там, где это необходимо

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

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

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

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

Вы работали с такими инструментами, как Unreal Insights и PIX для профилирования. Как вы переводите данные из этих инструментов в практические изменения для художников и дизайнеров?

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

Вместо того чтобы говорить «этот кадр дорогой», мы получаем:

• Что именно вызывает затраты
• Где это существует в контенте
• Что можно сделать, чтобы это исправить

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

Насколько важна автоматизация в современном геймдеве и где, по вашему мнению, команды используют её недостаточно?

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

Именно здесь автоматизация оказывает наибольшее влияние:

• Повторяющиеся задачи по настройке
• Валидация и очистка
• Проверка производительности во время разработки

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

Как специалист, который объединяет искусство и инженерию, как вы обеспечиваете, чтобы инструменты оставались удобными для художников, при этом оставаясь технически надёжными и масштабируемыми?

Всё сводится к разделению интерфейса и сложности. Базовая система может быть настолько надёжной и масштабируемой, насколько это необходимо, но сторона, обращённая к пользователю, должна быть простой и интуитивно понятной. Я стараюсь создавать инструменты с внутренней документацией (чёткие имена, подсказки и предсказуемое поведение). Хорошая документация по-прежнему имеет значение, но в идеале инструмент не должен требовать много объяснений для использования.

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

Заглядывая вперёд, как вы видите эволюцию роли технических художников, особенно с учётом растущей сложности движков, пайплайнов и рендеринга в реальном времени?

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

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

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

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

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

Идея студии заключается в том, чтобы решить эту проблему напрямую:

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

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

Я начал делиться некоторыми из этих работ публично, включая примеры кода и подходы к использованию инструментов, чтобы дать людям представление о том, как я думаю о решении подобных проблем.

• Все заинтересованные могут найти больше информации здесь.
• И больше информации о студии здесь.

Райан Амос, старший/ведущий технический художник

Интервью провёл Дэвид Ягнео