Введение


В этом посте будут рассмотрены трудности и аспекты производства, которые нужно учитывать при создании новых методик и алгоритмов рендеринга/графики, особенно в контексте прикладных исследований рендеринга реального времени. Я буду рассказывать о своём личном опыте работы над Witcher 2, Assassin’s Creed 4: Black Flag, Far Cry 4 и God of War.

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

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

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

Я вспоминаю об этой теме ещё и каждый раз, когда слышу дискуссии о том, что «фотограмметрия, трассировка лучей, нейронный рендеринг, [вставить любую другую новую тему] станет универсальным решением для рендеринга и заменит всё остальное!». Спойлер: этого не случится (по крайней мере, в ближайшее время).

Целевая аудитория


Целевая аудитория моего поста:

  • Студенты, изучающие компьютерную графику, и прикладные исследователи,
  • Инженеры рендеринга, особенно начинающие свою карьеру, которые ещё не выработали интуитивного понимания,
  • Технические художники и руководители/продюсеры арт-отделов,
  • Технические директоры и ответственные лица, не имеющие опыта в графике,
  • Инженеры и архитекторы оборудования, работающие над тем, что связано с GPU или с графикой (которым любопытно, почему сложно использовать новые аппаратные функции),
  • Люди, которые любят игровую графику и интересуются ею (или графикой реального времени в целом), желающие чуть больше разобраться в том, «как делается колбаса». Некоторые концепции могут показаться слишком техническими или в них может быть слишком много жаргона, но их спокойно можно пропустить.

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

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

Как интерпретировать это руководство


Очень важное замечание — ни одно из описанных в статье «препятствий» на самом деле не является причиной не использовать методику.

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

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

Способы применения


Категории «способов применения» заслуживают отдельного объяснения и описания «серьёзности» их ограничений.

Технологическое демо


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

Вы можете совершенствовать всё: концепцию демо, саму графику, траекторию камеры, демонстрирующую технологию и скрывающую все проблемы.

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

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

Специальный уровень/однократное использование


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

Примером может служить освещение на уровнях с джунглями в Assassin’s Creed 4: Black Flag, над которым я работал.


Источник: рекламные материалы Assassin’s Creed 4: Black Flag. Обратите внимание на столбы света с подобием каустики, которые были важным элементом рендеринга на уровнях с джунглями и позволили нам много сэкономить на рендеринге теней!

Джунгли были «отрезаны» от остальной части открытого мира специальными потоковыми коридорами, и в них мы полностью заменяли всю модель освещения! Вместо древоподобных карт теней и глобального освещения мы создали фальшивую «каустику», которая выглядела намного мягче и хорошо сочеталась с нашей системой объёмного освещения/атмосферных явлений. Она не только выглядела лучше, но и была гораздо быстрее. Очевидно, что она работала только благодаря особым условиям.

Кинематографические вставки


Чуть более требовательный тип функций — кинематографический. Кинематографические вставки слегка отличаются тем, что их очень сильно могут контролировать художники и большинство их аспектов (освещение, расположение персонажей и анимации) фальшивы — прямо как в настоящем кино! Кинематографические вставки часто содержат быстрые смены кадра (полезно для сокрытия переходов/рывков) и имеют больший бюджет вычислительных ресурсов благодаря своей предсказуемости (и даже в консольных играх с 60 fps рендерятся в 30 fps).


В кинематографических вставках Witcher 2 увеличена детализация персонажей, добавлено красивое реалистичное радиальное боке и уникальное освещение. Однако заметьте, что в них рендерится очень мало объектов!

Обычные функции рендеринга


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

В моём посте в основном будет рассматриваться эта категория.

Ключевые/уникальные функции


Как ни парадоксально, если что-то является ключевой или уникальной функцией, это может облегчить многие трудности. Возьмём для примера VR — стереозвук, производительность (низкие задержки) и идеальное сглаживание AA без размазывания (так что забудьте о TAA) являются главными функциями, абсолютно необходимыми для ядра игрового процесса. Это означает, что вы можете, например, игнорировать рендеринг растительности или какие-то анимации, которые бы выглядели нереалистично: самое важное — это погружение и ощущения от VR!

Совместимость функций


Давайте рассмотрим совместимость новосозданной функции с другими популярными функциями (различие между функциями и конвейером весьма расплывчато).

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

Плотная геометрия


Плотная геометрия, например, растительность (которая и вдохновила меня на создание поста) — враг большинства алгоритмов рендеринга.

Главная проблема в том, что при очень плотной геометрии (множестве перекрывающих друг друга мелких треугольников) многие «оптимизации» и допущения становятся невозможными.

Ранее отсечение по глубине и перекрытию? Реализовать очень сложно.

Отделение поверхностей от объёмов? Очень сложно.

Хранение информации для каждой уникальной параметризации поверхностей? Почти невозможно.

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


Растительность в Witcher 2 — какая плотность! На мой взгляд, это по-прежнему один из лучших примеров леса в играх.

Плотная геометрия, через которую можно смотреть (например, стебли травы), несовместима со многими методиками, например, картами освещения (хранение предварительно вычисленного освещения для каждого тексела стебля травы было бы очень затратно).

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

Альфа-тестирование


Альфа-тестирование — продолжение описанный выше темы, потому что оно не позволяет использовать ещё больше аппаратных функций/оптимизаций.

Альфа-тестирование — это методика, при которой пиксель вычисляет значение «альфы» из текстуры или вычислений пиксельного шейдера, а потом сравнивает его с пороговым значением, принимая решение, нужно ли его рендерить/записывать.

Это гораздо быстрее, чем альфа-смешение, но, например, не позволяет использовать ранние записи в буфер глубин (ранние z-тесты выполнять можно), и требует hit-шейдеров трассировки лучей, а также считывания из текстуры, чтобы решить, непрозрачен ли тексел.

Также это сильно усложняет сглаживание (забудьте об обычном MSAA, необходимо будет эмулировать alpha to coverage).

Описание и отличное визуальное объяснение некоторых из проблем см. в этом посте Бена Голуса.

Анимация — скелетная


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

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

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


Требюше из Witcher 2 — это не люди, но у них всё равно есть «скелеты» и «кости», и в них также используется скелетная анимация!

Анимация — процедурная и нежёсткая


Следующая категория анимаций — процедурные и нежёсткие. Процедурные анимации полезны для любой анимации, которая «бесконечна», относительно проста и не должна особо заметно зацикливаться. Самый распространённый пример — качание листьев и движение ветвей.

См. это видео про движение в промежуточном ПО Speedtree — всё движение здесь описывается математическими формулами, а не анимировано вручную, и выглядит фантастически и реалистично.

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

Нежёсткие анимации, изменение позиций вершин или даже потоковая передача буферов вершин целиком вызывает проблемы в трассировке лучей, потому что требует модификации в каждом кадре пространственных ускоряющих структур (чрезвычайно важных для RT), что на практике неприменимо.

Анимация — текстуры


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


Дождь в Assassin’s Creed 4 основан на смещении нормалей с процедурно генерируемой картой высот и текстурой дождя. См. мой доклад на Digital Dragons о рендеринге дождя в игре.

Динамическая точка обзора


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

Некоторые методики ускорения рендеринга оптимизируются под обзор с частичными ограничениями (например, Project Seurat, над которым работали мои коллеги). При адаптировании этой техники следует учитывать степени свободы камеры. Дерево-билборд может выглядеть нормально на дальнем расстоянии, но при приближении или при просмотре сцены с более высокой точки терять весь свой внешний вид.

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

Динамическое освещение


Насколько динамично освещение? Есть ли в игре динамическая смена дня и ночи? Система погоды? Может ли пользователь включать/выключать освещение? Испускают ли спецэффекты свет? Есть ли объекты, испускающие динамические тени?

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

Это необязательно исключает возможность использования решений с заранее вычисленным/запечённым освещением (например, нашего решения с заранее вычисленным GI для AC4, поддерживавшего динамическую смену времени суток!), но требует повышенного внимания.

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

Тени


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

Каждый раз, когда вам нужно вставить новый объект для рендеринга, вы должны задуматься: будет ли он иметь возможность получать тени от других объектов? Будет ли он бросать тени на другие объекты?

Для частиц и объёмов ответ может быть непростым (так как частичная пропускаемость не поддерживается картами теней), но и «простые» методики наподобие тесселяции мешей или параллаксных карт перекрытия тоже будут создавать несоответствие между испускающим и получающим тень объектами, что потенциально может вызывать артефакты теней!


Слайд из моего доклада на GDC 2014, демонстрирующий параллаксную карту перекрытия в AC4 — обратите внимание на полное отсутствие теней.

Динамическое окружение


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

В God of War участок карты Caldera Lake и мост, движущиеся уровни воды и повороты моста были одними из самых серьёзных проблем на протяжении всего продакшена с точки зрения систем освещения/глобального освещения, которые используют предварительные вычисления. Не существовало какого-то «общего» решения, всё зависело от ручной работы и потоковой передач загруженных данных/управления ими.


Мост на Caldera Lake из God of War. Было довольно сложно управлять им на основании изменения освещения по ходу сюжета!

Прозрачные объекты и частицы


Наконец, есть прозрачные объекты и частицы, сильно отличающиеся от остальных категорий.

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

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

Совместимость с конвейером


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

Тестирование и запись глубин


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

«Вкусный» эффект глубины резкости и многие другие эффекты камеры требуют буфера глубин. Старый добрый туман глубины? Ему тоже нужен буфер глубин!


Мне нравится боке на этом скриншоте и работа, которую я проделал с художниками над Witcher 2, но обратите внимание на ошибки: пламя перед драконом выглядит резко, а плоскость перед фоном размыта. Это баг, потому что они должны иметь одинаковую глубину резкости (DoF), однако глубина, считываемая для эффекта боке — это глубина твёрдых объектов, а не частиц!

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

Векторы движения


Близкий к глубинам компонент конвейера — запись векторов движения. Глубина необходима для многих вышеупомянутых эффектов, правильного перекрытия, отражений в экранном пространстве, тумана, и т.д., а векторы движения используются «только» для двух аспектов: размытия в движении и временного сглаживания (см. ниже).

Кажется, что размытие в движении (Motion blur) — это «просто эффект», однако незначительное его количество необходимо для снижения эффекта «стробинга» и ощущения дешевизны (см. motion blur полузакрытого затвора в фильмах с 24 fps).

(Немного хвастовства и ностальгии: размышления о motion blur заставляют меня ностальгировать — motion blur стал первой функцией, о которой я давал интервью прессе. Я до сих пор ощущаю гордость 23-летнего себя, живущего в Восточной Европе и ещё не закончившего колледж!)

Создание точных векторов движения — нетривиальная задача; для каждого пикселя нужно подсчитать, где эта часть объекта находилась в предыдущем кадре. Для этого может потребоваться пересчитать часть данных анимации, сохранить их для предыдущего кадра (ещё больше лишней памяти), или это вообще может оказаться сложно/невозможно (работа с перекрытиями, тенями или анимациями текстур).

В AC4 мы реализовали почти всё, за исключением океана и игнорировали в нём проблемы с TAA и motion blur.

Временное сглаживание


Временное сглаживание (Temporal antialiasing) — одно из величайших достижений движков рендеринга за последние несколько лет, но в то же время один из крупнейших источников проблем и артефактов. Я не буду обсуждать здесь его альтернативы и говорить, хорошая ли это идея, но оно останется с нами надолго — не только для сглаживания, но и для временного распределения сэмплов в методиках Монте-Карло, суперсэмплинге и стохастическом рендеринге, позволяя реализовывать в реальном времени более медленные вещи или картинку с повышенным качеством.

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


Мерцающий снег стал одним из самых востребованных функций художников God of War, но мне не удалось создать достаточно устойчивый эффект, потому что временное AA устраняло его полностью, считая временным мерцанием/алиасингом...

Отложенное затенение/освещение


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


Пример описания GBuffer — текстуры представляют различные свойства материалов и объектов. Позже к ним применяется освещение. Источник: learnopengl

Однако наличие «узкого места» в виде GBuffer и освещения, а также отсутствие доступа ко всем другим данным может сильно ограничивать.

Новая модель затенения? Новая таблица поиска? Новые данные, предварительно вычисляемые/запекаемые и сохраняемые в вершины или текстуры? Нужно уместить всё это в GBuffer!

Современные GPU с лёгкостью управляются с ветвлением и расхождением (при наличии частичной связности), но это может усложнить конвейер и приводить к созданию «эксклюзивных» функций.

Например, в God of War нельзя использовать подповерхностное рассеивание (subsurface scattering) одновременно с моделью зеркальных отражений ткани/светоотражения, потому что они используют одинаковые слоты в GBuffer. Сам GBuffer занимает очень много памяти и в игре было гораздо больше взаимоисключающих функций — я записал в свой блокнот многие возможные комбинации (если не ошибаюсь, там было 6 битов только для кодирования типа материала + его особенностей) и «торговался» об этих компромиссах с разными художниками, у каждого из которых были свои потребности.

Из-за каждой новой функции приходилось вырезать что-то другое или идти на какие-то ещё компромиссы.

Наличие/отсутствие переключения камер


В большинстве кинематографических вставок постоянно присутствует активное переключение камер, показывающее разных персонажей, разные перспективы на сцену или параллельно происходящие действия. Этот инструмент активно применяется во всех видах кино (возможно, за исключением «Догмы 95» или «Бёрдмена»), и если художник по кинематографии хочет его использовать, нужно обеспечить его поддержку.

Но что произойдёт, когда камера переключается со всей этой попиксельной историей временного накопления, необходимого для TAA/временного суперсэмплинга? Как насчёт потоковой передачи текстур, которая внезапно видит совершенно новый вид? Что насчёт амортизированного рендеринга, зависящего от вида, например, кэширования карт теней? Всё это решаемо, но потребуется много работы или могут возникнуть нежелательные задержки/рывки/слишком большие затраты на новый кадр. Мой коллега сказал, что это проблема и для физики или анимаций — часто при переключении камеры аниматоры изменяют позиции и мы видим, как физические объекты «оседают», например, на персонаже движется ожерелье. Это тоже разрушает погружение в игру и требует собственного набора «хаков».

Нехватка переключений камер (например, как в God of War) тоже сложна, особенно для освещения кинематографических сцен, хороших анимаций, переходов и т.д. Как бы то ни было, обе проблемы необходимо решать/учитывать. Стоит даже добавить в рендере флаг «камера была переключена».

Пирамида усечения


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


GIF из Horizon: Zero Dawn демонстрирует усечение по пирамиде видимости. Многие разработчики игр были немного удивлены тем, что игровые медиа и игроки «обнаружили» в играх усечение по пирамиде видимости (оно использовалось всегда).

Теперь всё становится сложнее! Зачем анимировать невидимые объекты? Не будем этого делать, чтобы сэкономить много времени ЦП.

Однако предметы, видимые в основной камере — это только часть истории, есть ещё и отражения с тенями… Не могу сосчитать, сколько раз я видел, что в тенях персонажи вне экрана находятся в «T-позе» (стандартная поза, когда персонаж не анимирован). Ещё одна новая проблема заключается в том, что трассировка лучей может «касаться» поз объектов!


Персонаж в T-позе. Я уверен, что вы видели такой баг очень много раз! Стоит обратить внимание и на тени с отражениями.

Усечение по перекрытию


Усечение по перекрытию (Occlusion culling) — это следующий этап после усечения по пирамиде видимости. Нам ведь не нужно рендерить объекты за пределами камеры? Да. Но если перед камерой находится огромное здание, нам тоже не нужно рендерить весь город за ним!


Источник: “A Survey of Visibility for Walkthrough Applications”.

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

В каком-то смысле система occlusion culling — это новая функция рендеринга, которая должна проходить все перечисленные в этом посте этапы! Но учитывая сложность и общую хрупкость многих решений (ещё один аспект, который нужно учитывать), мы не хотим ещё больше усложнять её.

Уровень детализации


Любая методика, требующая некоего вычислительного бюджета на рендеринг и объёма памяти, должна правильно «масштабироваться» в зависимости от расстояния. Когда отрендеренный объект находится в 100 метрах от камеры и занимает всего несколько пикселей, он не должен занимать 100 МБ памяти, а его рендеринг/обновление не должно занимать и миллисекунды.

На сцене появляется уровень детализации (level of detail, LOD) — упрощённое представление объектов, мешей, текстур(последние реализуются автоматически в форме mip-текстурирования, но их всё равно нужно правильно и по отдельности потоково передавать), а также их вычисления.


Источник: Википедия.

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

Как должно масштабироваться глобальное освещение с расстоянием? А объёмные эффекты? Освещение? Частицы?

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

Загрузка, переключение и потоковая передача LOD


Уровень детализации нужно передавать потоково. Если объект вдалеке занимает на экране несколько пикселей, мы можем использовать десяток вершин и, может быть, вообще не применять текстуры — в целом это займёт несколько килобайт. Но потом камера начинает приближаться, и нам нужно загружать материал, текстуры, меши… Для всего этого нужно писать код систем и решений. Что произойдёт, когда камера просто телепортируется? Система потоковой передачи должна справляться с этим.

Более того, переключение между этими LOD должно быть как можно более незаметным. Большинство визуальных багов в играх с отсутствием/размытостью текстур, мерцанием, рывками и внезапным появлением объектов связано с системами потоковой передачи, загрузки и переключения LOD!

Открытый мир


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

Когда я присоединился к команде разработчиков AC4 в Ubisoft и увидел все технологии «открытого мира» для потоковой передачи, рендеринга на дальних расстояниях и тому подобное, или элементы теней на дальнем расстоянии в Far Cry, я был поражён, насколько специализированный (и продуманный) труд необходим для выпуска игр на консолях.

Бюджет


Наконец, о бюджете… Ниже я буду говорить о бюджете «продакшена», но, надеюсь, это понятно и так. Если новая методика требует памяти или тактов CPU/GPU, их необходимо выделить.

Часто встречается заблуждение о том, что если нечто укладывается в 30 мс — это «методика реального времени». Она может ею быть, но если рендерится только эта методика и только в игре на 30 fps.

В VR иногда приходится иметь дело с бюджетами меньше 10 мс на рендеринг камер для двух глаз для целого кадра! Это означает, что методика освещения, требующая 1 мс, уже слишком затратна!

Аналогично с ОЗУ — все затраты необходимо оценивать в целом и обычно игры уже и так используют всю свободную память. То есть ради любого нового компонента приходится жертвовать чем-то ещё. Стоит ли функция X снижения бюджета на потоковую передачу текстур и риска багов потоковой передачи текстур?

Ещё один «невидимый» бюджет — это пространство на диске. О нём говорят не очень часто, но при современных конвейерах видеоигр мы уже едва можем уместить игру на диски Blu Ray (в God of War это было большей проблемой, чем размер памяти или производительность!).

Можно вспомнить и о патчах, занимающих по 30 ГБ — это смехотворно и обычно является признаком того, что в системе упаковки ресурсов недостаточно хорошо учли патчинг. Как бы то ни было, новое решение с предварительно вычисляемым глобальным освещением, занимающее «всего» по 50 МБ на фрагмент уровня, для целой 30-часовой игры «внезапно» масштабируется до 15 ГБ на диске; скорее всего, это будет неприемлемо!

Процесс


Хотя я оставил процесс на конец статьи (потому что он может быть интересен части читателей), перечисленные здесь сложности важнее всего.

Многие «альтернативные» методики рендеринга уже во многих смыслах практичны (например, знаковые поля расстояний), однако нехватка инструментария, конвейеров и опыта в продакшене совершенно исключают их использование, за исключением особых случаев, в которых применяется создаваемый пользователем контент (см. великолепные Dreams или Claybook).

Художественный контроль


Легко впасть в восторг от потрясающих результатов процедурного рендеринга, фотограмметрии или в целом захвата и повторного рендеринга 3D-контента — результаты выглядят великолепно и, казалось бы, обещают устранить огромную долю затрат на продакшен.

Однако художники должны иметь полный контроль над процессом создания контента и участвовать в нём.

Захват модели стула при помощи neural implicit representation выполнить легко, но сможете ли вы изменить цвет сиденья, удлинить некоторые части стула или сделать краску потёртой? А когда арт-директор решит, что нужен стул в стиле «барокко», вы будете искать его?

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

В Assassin’s Creed 4 один из моих коллег работал над процедурным рендерингом неба (в сотрудничестве с другими командами, а также, если не ошибаюсь, с вычислениями какого-то промежуточного ПО). Результат выглядел потрясающе, но арт-директор (который также был профессиональным художником) не мог получить именно тот вид, который ему нужен, поэтому мы продолжили работу с олдскульными, статичными (но красивыми!) скайбоксами.


Разработка процедурной системы рендеринга, способной создавать точно такое же небо, как на этом художественном концепте Assassin’s Creed 4, будет сложной задачей!

Инструменты


Любой творческий/художественный инструмент или методика должны иметь инструментарий для управления им, размещения на уровнях и обеспечения интерактивности. «Инструментами» может быть что угодно — от редактирования файлов CSV до специальных полнофункциональных WYSIWYG-редакторов.

Даже простейшие новые методики требуют каких-нибудь инструментов/элементов управления (хотя бы простейшего «вкл./выкл.»), а их необходимо написать.

Следующий уровень сложности — это, например, новый BRDF или модель материала: они должны быть интегрированы в редактор материалов, текстуры должны обрабатываться в конвейере платформы и запекаться, сжиматься в правильный формат, для них должны генерироваться шейдеры и комбинироваться с другими функциями… При этом нельзя разрушать уже имеющуюся функциональность.

Кроме того, если вы предлагаете нечто для замены представления мешей, вам необходимо подумать о том, что это внезапно влияет на всю экосистему, к которой привыкли художники — от создания контента в Z Brush, 3D Studio Max и Maya, инструментов анимирования и экспортёров наподобие Motion Builder или специализированного ПО для захвата движения, до всех плагинов движка, импортёров и экспортёров. Это схоже с переделкой десятков лет работы всей отрасли. Выполнимо? Вполне. Разумно? А это уже зависит от вашего бюджета и от преимуществ, которые могут дать такие изменения.

У меня есть теория о популярности движков наподобие Unity и Unreal Engine — она появилась не благодаря новым функциям (хоть их и много!), а из-за их зрелости и стабильного, выразительного и хорошо известного инструментария (см. ниже).

Обучение и опыт


Некоторые художники видеоигр работают уже пару десятков лет и наработали много знаний, «ноу-хау» и опыта. Если вы предложите нечто, не связанное с их опытом, то он окажется ненужным. Чтобы был стимул отвыкать от старых привычек, выгода должна оказаться огромной или стать стандартом всей отрасли (для популяризации Physically Based Rendering потребовалось несколько лет).

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

Поддержка других людей


Мне потребовались время и несколько неприятных уроков, чтобы осознать, что «эмоциональная» сторона сотрудничества важнее, чем техническая.

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

Я научился этому сам и довольно болезненным образом: в начале своей карьеры я в основном оказывался в командах, где люди были такими же восторженными и молодыми; позже, в другой команде, когда я предложил что-то новое, что не заинтересовало моих коллег, я не понял «сопротивления», и всё равно продолжил работу, что привело к провалу функции (её просто не стали использовать).

Хороший хайп «внутреннего маркетинга» и создание значимых взаимосвязей с полным доверием к компетентности и намерениям друг друга очень важны, и поэтому очень сложно реализовать что-то, если ты «сторонний» консультант или сотрудник на удалёнке.

Тестирование


Я написал пост об автоматическом тестировании графических функций. Считается само собой разумеющимся, что вывод в продакшен чего бы то ни было требует много месяцев тестирования со стороны исследователей/программистов, художников и отдела контроля качества.

Всё, что не тестировалось на практике. должно считаться сломанным или неработающим.

Отладчики и профилировщики


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

Большинство известных мне программистов графики искренне наслаждается написанием всего этого (потому что это и выглядит круто, и очень быстро оправдывает вложенное время), но этот этап нужно планировать, он стоит времени и его необходимо поддерживать.

Разрабатывая новую методику, пытайтесь думать: «Если по какой-то причине что-то пойдёт не так, как я или кто-то менее технически опытный сможет понять это и устранить проблему? Какие инструменты для этого нужны?»

Пограничные случаи


Ох уж эти пограничные случаи. Вещи, которые должны быть «редкими» или даже ничтожными, но гарантированно происходящие при реальном крупномасштабном производстве. Меши с нарушенной герметичностью или сломанной топологией? Гарантированы. Треугольники с нулевой площадью? Гарантированы. Вывернутые нормали? Гарантированы. Материалы с нулевой шероховатостью? Безусловно. Чёрное или полностью белое albedo? Да. Единственный уровень, где стены должны быть такими тонкими, что просачивается глобальное освещение? Ага.

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

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

Практик всегда должен думать: «Как это можно сломать? Как можно устроить здесь деление на ноль? Что произойдёт, если x/y/z?», и в целом готовиться потратить большую часть времени на обработку и обеспечение надёжности этих пограничных случаев.

Бюджет продакшена


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

История о разработке Witcher 2: я реализовал спрайтовое боке в выходные примерно за две недели до выпуска gold master. Я был в полном восторге от него, и мой восторг разделяли художники по окружениям и кинематографическим вставкам. Мы были полны решимости внедрить его и потратили следующие две недели на упорную переработку параметров глубины резкости во всех созданных кинематографических вставках (очевидно, что модифицировать нужно было только некоторые). Я рад что тогда мы были очень неопытными и не знали, что так делать не нужно — эффект был очень крутым, я не могу представить, что такое могло бы случиться в моих последующих, более опытных компаниях.

Подведём итог


Подытожим: в случае графических алгоритмов путь от исследований к продукту может быть очень непростым!

Реализовать технологическое демо легко, а со следующими этапами не всё так очевидно:

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

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

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

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

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

P.S. Если вам любопытны старые «военные истории» о рендеринге растительности в Witcher 2, то прочитайте следующий раздел.

Дополнение: пример использования — растительность


Я начал статью с шутки о том, как рендеринг растительности ломает всё остальное, но давайте более серьёзно проанализируем, сколько труда и обсуждений понадобилось для рендеринга растительности в Witcher 2.

Примерно в то время, когда я пришёл в CD Projekt Red на этапе препродакшена The Witcher 2, в игре не было «системы растительности» или специального решения для рендеринга листвы. Художники размещали растительность как обычные меши — один стебель травы за другим. Каждый меш был компонентом и объектом внутри объекта-сущности. Обычно он был очень тяжёлым и использовал «обобщённые» структуры данных. Одинаковые структуры использовались для камней, растительности и персонажа игрока. В течение продакшена нужно было изменить очень многое!


Импортёр и ветер Speedtree

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

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

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

Но это выглядело отлично и я признал, что был прав, когда мечтал стать программистом графики — это занятие даёт такую самоотдачу!

Просвечивание и нормали

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

Исправление импортёров, редактора мешей и отладка проблем с художниками, их (и моё!) обучение потребовали довольно много времени.

Выполнять альфа-тест или отрисовывать мелкие треугольники?

Когда мы стали доходить до более критичных для производительности этапов, растительность всё больше становилась проблемой для производительности. Альфа-тестирование затратно и приводит к перерисовке, а отрисовка мелких треугольников вызывает так называемую перерисовку четырёхугольников (quad overdraw). Оптимизация перерисовки растительности была бесконечной историей — помню, что когда мы начали профилировать некоторые уровни, на них присутствовал один ресурс, рендеринг которого занимал 8 мс даже на мощных PC. Мы провели множество итераций и экспериментов, чтобы заставить его работать быстро. В конечном итоге решение оказалось гибридным — множество отдельных стеблей травы, но листья были упорядочены как «карты листьев» с альфа-тестированием.

Слои мешей уровней

Одной из первых важных оптимизаций части затрат ЦП, снизивших время загрузки было «вырезание» всех достаточно простых мешей (без анимаций, за исключением ветра, без геймплейного управления) в отдельную, гораздо меньшую структуру данных.

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

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

Автоматическая система билбордов

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

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

Редактор растительности

Следующая работа над растительностью тоже была связана с инструментарием!

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

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

Усечение и инстансинг растительности

Внося вручную множество оптимизаций, мы приближались к дате выпуска Witcher 2 на PC и начинали работать над версией для X360. Новый программист, который теперь стал моим хорошим другом, исследовал производительность, особенно усечение по перекрытию на 360 (олдскульный «хипстерский» алгоритм, о котором вы, наверно, никогда не слышали — beam tree). Оказалось, что построение в каждом кадре рекурсивного BSP из сотен перекрывающих объектов и обработка тысяч мешей вместе с ним — не самая хорошая идея, особенно на процессоре PowerPC консоли X360.

Мой коллега потратил довольно много времени для того, чтобы превратить систему растительности в настоящую «систему» (а не просто контейнер для мешей) с иерархическим представлением, улучшенным усечением и аппаратным инстансингом (у него, в отличие от остальных членов команды, был опыт работы с ними на X360). На это тоже потребовалось много недель, и это была критически важная работа для выпуска игры на Xbox.

После Witcher 2 — рельеф и процедурная растительность

Но на этом история растительности в играх Witcher не заканчивается.

В Witcher 3 (учтите, что я мало работал над ней, меня перевели в команду Cyberpunk 2077) мои коллеги решили интегрировать системы рельефа и растительности с потоковой передачей (что необходимо для игры с открытым миром!), а наш потрясающий технический художник кодировал процедурную генерацию растительности на основе физических процессов (влияние высоты, количества солнца, близости воды) и игры «Жизнь», которые применялись для «засаживания» мира реалистично выглядящими растениями и лесами.

Я уверен, что происходило много всего другого. Но представьте, что вам приходится переделывать всю работу из-за какой-то новой технологии. Повторюсь, это реально, но стоит ли оно того?

Комментарии (40)


  1. keydon2
    26.08.2021 13:24
    +2

    А где ответ на вопрос "Почему графику в видеоиграх по-прежнему так сложно создавать?" ?

    Почти все в статье либо из прошлого десятилетия, либо характеризуется фразой "маркетологи".

    Что ж, раз автор не смог, попробую я.

    Рукотворная сложность. Графические библиотеки это в основном адъ. Хотя бы потому что оперируют графическими апи, которые тоже адъ. Графические апи адъ потому что у нас адские драйвера. Драйвера адские потому что из gpu сделали комбайн, поддерживающий 100500 функций, потому что разработчикам видеокарт плевать на драйвера, потому что в сами драйвера добавляют еще 100500 функций не нужных для конкретного устройства, в том числе легаси. Приправим все это легаси средствами разработки (C/С++ все же решил остаться легаси, альтернативы нет, rust это не альтернатива).

    Закрытость. Исторически игры противятся опенсурсу. Частично из-за винды, которая подмяла под себя рынок грязными способами, частично из-за самой стратегии единичного продукта (сделал, продал). В такой среде никто не стремится обмениваться знаниями (конкурентным преимуществом, ха), стандартизировать решения (графические апи это скорее средство давления чем реальная стандартизация) или делать бескомпромиссные решения. Таким образом бразды правления переходят к разработчикам ОС (как мы знаем это винда) и к разработчикам видеокарт (как мы знаем это 2 монополиста). А им сложность и закрытость только на руку - это не пустит на рынок конкурентов. Каковы начинающего игрока стандартизироваться в майкрософт (если он конечно не интел)? Скорее всего он даже и не подумает и уйдет делать видеокарты для мобилок.

    Рынок. Сделал, разрекламировал, продал. Чем быстрее, тем больше. Не нужно ничего оттачивать. Лучше вообще не думать, тебе не за это платят, а клепать ширпотреб. Фанаты скушают и сами пофиксят загрузку json'ов, отреверсив закрытый код на закрытой системе с закрытыми драйверами. А может быть и ничего не заметят. Ну и конечно нужно сделать быстрее и сильнее чем у конкурентов, даже если в итоге получится демка, а не игра.

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


    1. major-general_Kusanagi
      26.08.2021 14:20
      +11

      100500 функций не нужных для конкретного устройства, в том числе легаси

      Легаси нужно!
      Потому что когда в драйверах исчезает легаси, то старая любимая игра начинает жёстко глючить. :(
      Да и, не только старая, относительно новая игра тоже может использовать легаси-функцию.

      PS а ещё можно вспомнить как умер Delphi, когда в одной из версий убили всё легаси = перенос кода и форм из старой версии в новую. Что привело к тому, что одни предпочли остаться на старых версиях Delphi, а другие просто ушли на C# и Java, и так далее.


      1. goldrobot
        28.08.2021 17:45

        А может лучше завести аналог дуалбута, но для драйверов?


    1. SinsI
      26.08.2021 18:50
      +3

      Есть отличные открытые игровые движки вроде Unreal Engine и прочее middleware, что прекрасно стандартизируют решения, да и текучка персонала среди игровых компаний вполне себе приличная - так что секреты не остаются секретами после выпуска проектов.

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


      1. titsi
        27.08.2021 11:55

        да и текучка персонала среди игровых компаний вполне себе приличная

        C чем это связано?


        1. UberSchlag
          27.08.2021 15:29
          +1

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


        1. SinsI
          27.08.2021 16:19

          Загрузка распределена неравномерно - в препродакшене достаточно небольшого костяка в десяток-другой человек, а в полном продакшене и несколько тысяч мало, плюс львиная доля расходов - как раз на з/п.

          Соотстветственно, если вы не какой-нибудь Activision с десятками проектов одновременно, студии не могут содержать постоянный штат, а массово набирают и увольняют сотрудников на разных этапах разработки, или прибегают к услугам аутсорсеров.


  1. BattleAngelAlita
    26.08.2021 13:28
    +1

    >Почему графику в видеоиграх по-прежнему так сложно создавать?
    Тому что кое-кому денег на графику жалко. Выгоднее нанять 1000 бангладешских моделлеров, которые будут клепать скинчики.


    1. Darth_Biomech
      31.08.2021 15:19

      Судя по ощущениям в большинстве современных игр ведь и так 70% бюджета и сил уходит именно на графику.


  1. spag002
    26.08.2021 13:34
    +2

    Вот как раз за графику в "Witcher 2" хочется плюнуть в глаза.

    Посмотреть на торжество bloom'a

    P.S. А заголовке скрин вообще из третьей части.


    1. BattleAngelAlita
      26.08.2021 13:47
      +1

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


      1. UberSchlag
        27.08.2021 15:34

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


  1. Nomad1
    26.08.2021 14:32
    +13

    В основном проблема в том, что графика сейчас это набор хаков и хитрых решений. Критическая нехватка мощности видеокарт/памяти/ширины шины и прочего приводит к совершенно невероятным ухищрениям. Когда-то много лет назад, с появлением glMultiDrawElements, мы представляли себе будущее игр так - вся сцена загружается в видеопамять, отдельные Compute шейдеры выполняют отсечение и решают, какие LODы и инстансы рисовать, а трафик между CPU и GPU будет занят лишь подгрузкой параметров камеры, анимаций и прочего. Прошло 10 лет, от святого Грааля мы отодвинулись еще дальше, шина занята на 100%, отсечение перекидывается туда-обратно между CPU и GPU, а целиком на видеокарте считаются и рисуются в лучшем случае только системы частиц. И все это держится за счет хаков, ручных оптимизаций шейдеров и контента, изменения гейм и левел дизайна из-за технологических особенностей.

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


    1. 0o00oo00o0
      26.08.2021 15:31

      Прошло 10 лет, от святого Грааля мы отодвинулись еще дальше, шина занята на 100%, отсечение перекидывается туда-обратно между CPU и GPU, а целиком на видеокарте считаются и рисуются в лучшем случае только системы частиц.

      Это проблема ограничений вычислительных ресурсов? То есть можно ли реализовать игровой движок, который бы создавал подобие синглтона сцены, например, в памяти видеокарты (какой-нибудь 3060 с избыточным объемом), и все вычисления до растеризации выполнялись с загруженными данными? Может быть, есть какие-нибудь публикации на эту тему?


      1. Nomad1
        26.08.2021 15:45

        Это проблема разработчиков, пытающихся выжать еще больше, чем карта позволяет чтобы и на 980TI было красиво и работало, а если на новых, так с 8K и 120 FPS. Но такой подход уже только через хаки, ручное управление ресурсами и пр.

        Реализовать можно, конечно. Вот как это делалось на OpenGL: https://www.gamasutra.com/blogs/SergeVanKeulen/20180801/323415/Efficient_instancing_in_a_streaming_scenario.php

        Сейчас этот разработчик где-то в команде PUBG, а наработки свои и уникальный демо-проект Military Oprations совсем забросил. Я было хотел повторить его путь для своего проекта, но вовремя одумался, потому как времени скушает много, а сделать из этого полноценный движок с инструментарием для каждого - непосильная работа.


      1. BattleAngelAlita
        26.08.2021 16:09

        Пробовали так делать, но что-т оне очень быстрее получается, а тулзы под такой подход надо переписывать.


        1. Nomad1
          26.08.2021 17:32
          +2

          Интересно, а сами NVidia и компания разобрались, почему в их тестах и на бумаге получалось сверх быстро и очень красиво алгоритмически, а в реальных играх не вышло, прямо как описано в статье?


    1. Nikita_64
      26.08.2021 15:45
      +5

      Критическая нехватка мощности видеокарт/памяти/ширины шины и прочего приводит к совершенно невероятным ухищрениям.
      Это было и 35 лет назад. Если это так сейчас, то будет всегда. По аналогии с проблемой «броня — снаряд», «вес сайта — скорость интернета», «размер файла — скорость чтения с дискеты флешки». А причины описал keydon2 выше.


      1. Nomad1
        26.08.2021 15:51

        Но смотрите, ведь появились в итоге сайты уже не на 100% использующие все фичи и не загружающие процессор, не тянущие сотни мегабайт библиотек, чтобы затормозил и гигабитный канал. Таки была грань, после которой оно "стало работать" без колдовства и долгих загрузок? Может и с играми так произойдет - они будут выглядеть достойно и работать быстро и без жутких ухищрений? Например, 2д игры уже ж не оптимизируют так страшно, как приходилось когда-то, с ручным свопом страниц видеопамяти и собственными Blit методами на асме.


        1. Nikita_64
          26.08.2021 15:54
          +3

          Наверное, Вы правы, я слишком категоричен. Просто всегда будет соблазн использовать — пусть и не везде — возможности на 110%, чтобы обойти конрурентов.


          1. Jalt
            26.08.2021 17:06
            +2

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

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

            Например, тот же Hades имеет достаточно скромные требования - исходя из концепции игры "110%" не требовало вещей, которые утыкались бы в железо. Какой-нибудь Ведьмак или Cyberpunk с их концепцией с большим открытым миром и фотореалистичной графикой - другой вопрос.


        1. LaG1924
          26.08.2021 17:23
          +1

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

          Так что, для светлого графического будущего осталось всего ничего: выпустить действительно производительный аппаратный ускорятор рейтрейсинга и сделать его популярным (скажем, чтобы оно точно было хотя бы у 95% целевой аудитории). И чтобы единственная градация железа была лишь в том, сколько десятков километров дальности видимости, или сотен тысяч объектов частиц надо нарисовать.

          За лучами будущее, и так считают многие в индустрии.


          1. Insane11
            26.08.2021 20:27
            +1

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


            1. LaG1924
              27.08.2021 04:10
              +2

              Проблема текущей реализации RT - в том, что она очень и очень медленно считается. Когда вырастет производительность аппаратных ускорителей не в десятки раз, а в сотни-тысячи десятков раз и мы сможем полноценно считать кадр одними лишь лучами за вменяемое время (все современные инженерные и кинематографические визуализаторы из разных CAD'ов и 3dsmax'ов так считают, например), то вот тогда мы сможем полностью отказаться от растеризации.

              Все же, реальный мир "рендерится" исключительно лучами (ну, насколько я могу судить из той программы физики, что мне преподавали), так что для получения максимальной "реалистичности" картинки надо просто повторить то, что уже было создано далеко до первого изобретенного способа растеризации.

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


          1. EvilFox
            27.08.2021 00:23

            Насколько я помню RTX/DXR это просто ускоряющая аппаратная структура, она не сделает сама правильную картинку, там отдельная морока с шумодавом (для той же кваки2ртх там их аж два), каустикой, дисперсией и т. п. Просто там только базовое.


            1. LaG1924
              27.08.2021 04:11

              Я не говорю именно про текущую реализацию RTX/DXR. Я говорю про сам способ рендеринга трассировкой лучей. А шумодавы нужны для подавления шума, который появляется из-за недостаточного количества лучей.

              Основной же мой ответ можно увидеть в соседней ветке.


              1. Chaos_Optima
                27.08.2021 12:36
                +2

                Ну на самом деле рейтрейсинг это совсем не панацея, там также очень много проблем, даже больше чем в растеризации. Шум в рейтрейсинге будет всегда, семпленг лайтов, даёт очень много шума, особенно если например закрытое помещение с окнами, а свет только уличный, каустика, обычные лайты, подповерхностное рассеивание, indirect specular (не смог адекватно перевести), волсы\шерсть это вообще ад. Само собой это если мы говорим о рендеринге сродни тому что используется для фильмов\мультиков. Даже с двухчасовым рендерингом с АА64 и с большой глубиной рекурсии, шум есть. Сейчас используется куча техник, монтекарло рендер с мис, nee и двунаправленные трейсеры и куча остальные, и всё это чтобы снизить количество шума, но шум всё равно остаётся. Так что рейтрейсинг вообще не панацея, даже если кадр несколько часов рендерить.


    1. Endeavour
      26.08.2021 22:29
      +2

      Какая шина занята? PCIe 3.0 x16 даже не загружается играми полностью.


  1. Wizard_of_light
    26.08.2021 15:50

    По "туману глубины" есть ещё одна (неустранимая?) особенность: дистанция до тумана обычно берется одинаковая... но только по трём осям. В результате в углу поля зрения обзор дальше, чем в центре. Как я понимаю, шар просчитывать сложнее, чем куб, никто обычно не заморачивается.


    1. findoff
      27.08.2021 21:29

      Это обычно либо в старых играх, либо в некоторых инди. Чаще всего щас таки считают в 3д, ибо видеокарты уже не так дорого за это берут.


  1. maledog
    26.08.2021 17:01
    +1

    Так ли графика важна? Я вот запускаю старые игры и особых проблем с графикой не замечаю. Главная проблема - плохая адаптация под современные экраны(не поддерживает соотношение сторон или разрешение). Вот когда выпускают ремастер, тогда я замечаю очень много проблем в игре: меняется угол обзора(RE4), меняется динамика(Bioshock) и геймплэй(вот я знатно офигел, когда в Metro 2033 бэкпортировали смену дня и ночи, и вместо того чтобы воевать с отрядом фашистов ночью - пришлось это делать при солнечном свете). А сколько замечаний у фанатов было после ремастера Crysis при том, что оригинальная игра вполне себе нормально смотрится и на современном ПК.


    1. Insane11
      26.08.2021 20:39

      Вы имеете в виду, так-ли важна фотореалистичная графика? Это каждый художник решает сам. Одному нужен ультра-реализм, другой наоборот делает нарочито мультяшную картинку. Лично я за разнообразие. Мне заходит и реализм с трассировкой лучей в стерильных интерьерах космической станции в Deliver us the moon, и Disco elysium с её пост-импрессионизмом. )


    1. vtal007
      27.08.2021 12:46

      А я покупаю по скидке, а потом понимаю, что в «это» играть я не могу. Глаза жалко. Например первый Just Cause (можете глянуть скриншоты). И управление дурацкое (на PC) — 2006 год
      steamuserimages-a.akamaihd.net/ugc/98349535609814750/E89A3D6BE360384F418A92757D264D6076C37352/?imw=5000&imh=5000&ima=fit&impolicy=Letterbox&imcolor=%23000000&letterbox=false
      Или вот Act of War. 2005 А ведь был неплохой графоний в свое время. А теперь ужас
      steamuserimages-a.akamaihd.net/ugc/264976469343083646/47CF19605146E13703928C73FAE1D335DAE9F959/?imw=5000&imh=5000&ima=fit&impolicy=Letterbox&imcolor=%23000000&letterbox=false
      А Вы старыми называете игры после 2010-го?


      1. maledog
        27.08.2021 12:55

        В 2008 кажется году я купил первые две части max pain(2001 и 2003 год). И остался вполне доволен. Вторая часть Silent Hill мне понравилась больше чем последующие. Недавно играл в Bioshock (все части), Crysis, Dishonored, Half-Life 2 (без модов), S.T.A.L.K.E.R, Dead Space, Mass Effect, RE4/5 Obscure1/2... Все до 2010 года.

        Just Cause и прочие GTA ... не очень люблю открытый мир, от него сюжет портится.


        1. vtal007
          27.08.2021 13:03

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


          1. maledog
            27.08.2021 13:11

            Обе скорее большой коридор. И с определенного момента тебя ведут по сюжету, не давая отклоняться. Dishonored туда же. И первый Rage. Открытый мир это скорее Skyrim, Fallout 3, GTA, Far cry 2+, Assasins Creed... Horizon zero dawn. Не то чтобы я их не любил, но мне не нравится когда разработчики искусственно затягивают игру посылая тебя в разные концы карты за еще одним однотипным заданием. Если уж отправляют, то пусть это будет хотя бы протяженная цепочка заданий объединенных своей мини-историей.


      1. Aldrog
        27.08.2021 13:37

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


        1. vtal007
          27.08.2021 14:13

          «до», например?
          мне кажется «до» вообще никак не могла получится хорошая графика, просто потому, что компы не тянули
          собственно нормальная графика появилась относительно недавно. И уже некритично сколько там полигонов и насколько достоверно отображается закат.
          Для примера, Saints Row 3. Оригинал ( 2011) и сейчас нормально выглядит. Недавно римейк выпустили


  1. EvilFox
    26.08.2021 23:29
    +1

    "знаковые поля расстояний", но контент, продакшен...

    В первом случае надо хотя бы в скобках оставлять оригинальное (signed distance field), потому что перевод не устоялся.

    Хотя за перевод статьи конечно спасибо.


  1. shybovycha
    27.08.2021 03:53

    Последнее время как раз заинтересовался данной темой. И даже начал исследовать все эти ухищрения на шейдерах, которые симулируют красивые эффекты (все те же лучики света, aka volumetric light, красивые и быстрые динамические тени, отражения, свечение и тд).

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

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

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