Metro 2033. Интервью с Олесем Шишковцовым от Digital Foundry (перевод)
Metro 2033. Интервью с Олесем Шишковцовым от Digital Foundry (перевод)
Раньше вы работали над S.T.A.L.K.E.R., известным своими технологиями. Какая связь между 4A engine и вашей предыдущей работой в S.T.A.L.K.E.R.? Никакой. Когда я работал ведущим программистом и создателем архитектуры движка S.T.A.L.K.E.R., было ясно, что много архитектурных решений были отличными для того времени, но они просто не масштабируются для сегодняшнего дня. Главные преграды для развития X-Ray - это неспособность к распараллеливанию, слабый и глючный сетевой код, ужасное управление ресурсами и памятью, что не позволяло сделать стримминг или малый набор рабочих данных, вмещающийся в память консолей. Другая проблема - текстовое скриптование на LUA, которое дает много рычагов управления, но заставляет дизайнеров быть почти программистами. Это было одной из причин задержки S.T.A.L.K.E.R. Я начал личный проект для формирования будущей архитектуры и изучения возможностей дизайна движка. Он был неплохо развит, и хотя проект не был функционален как игра (не было даже демки, так как я тогда не имел движка рендеринга), он дал мне ясное виденье последующих действий. Когда 4А организовала независимую студию, эта работа стала основой нового движка. Из-за временных ограничений мы использовали много сторонних решений. PhysX для физики, PathEngine для навигации ИИ, LUA для основного формата файлов при разработке, не для скриптования, а для легкого SVN merging, RakNet для поддержки сети, FaceFX для лицевой анимации, OGG Vorbis для звуков, и много других вещей вроде библиотек сжатия. Рендеринг был сделан за три недели – это легко делается с отложенным затенением. Хотя это был лишь первый сырой вариант.
То есть у движков 4A и X-Ray нет общего кода? Невозможно иметь общий код у движков с разной философией. Например мы не используем стандартную библиотеку шаблонов С++, а в S.T.A.L.K.E.R. каждая вторая строка кода вызывает STL метод. Геймплейный код S.T.A.L.K.E.R. в основном использует модель update/poll, а наша модель основана на сигналах. Ответ «Нет», движков 4A и X-Ray нет общего кода, так как это невозможно.
Но если бы вы сделали прямой порт X-Ray, как бы он работал на PS3 и 360? Это было бы очень сложно. Прямой порт не поместился бы в памяти даже без всех текстур, звуков и геометрии. А работал бы он на скорости 1-3 кадров в секунду. Но это ничего не значит, потому что без текстур и геометрии вы не увидите эти кадры! Я лично считаю, что GSC надо подождать следующее поколение консолей.
Какие основные особенности дизайна ядра 4А? Основные особенности - это многопоточная модель, управление памятью и ресурсами, а также сетевая часть. У нас нет выделенных потоков для выполнения специальных внутриигровых задач, кроме потока PhysX. Все потоки являются обычными работниками. Мы используем модель ориентированную на задачи (task-model), но без предварительных условий (pre-conditioning) или предварительной/пост синхронизации. Все потоки могут выполнятся паралельно без любых блокировок из точки их запуска. Нет взаимных зависимостей между задачами. Это выглядит как дерево задач, которое начинается с самых тяжелых узлов в начале кадра (для самобалансирования системы). Конечно, между некоторыми подсистемами есть синхронизация. Например, между PhysX и игрой или между игрой и рендером. Но они пересекаются другими задачами, и ни один поток не остается незанятым. Последний раз, когда я измерял статистику, мы выполняли около 3000 задач в 30-миллисекундном кадре на Xbox 360 в нагружающих процессор сценах со 100-процентной загрузкой всех аппаратных потоков. Кстати, PS3 не такая уж и другая. Мы используем 'нити' для 'эмуляции' шестипоточного процессора и каждая задача может начать работу на SPU и переключится на другую 'нить'. Это разгрузка PPU, которая незаметна системе. Финальный результат этой прекрасной (помимо некоторых ограничений) модели - идеальное линейное приспособление к возможностям железа. Для управления памятью и ресурсами мы практически не используем указатели С++. Мы используем сильные и слабые указатели с подсчетом ссылок. С использованием атомарных операций и барьеров памяти они стают стойким инструментом для многопоточного программирования. Это звучит неэффективно, но это не так. Мы измерили при разнице в 2.5 раза в заданных вручную сценариях на PPU/Xenon. Если эта « неэффективность» даст хотя бы 0.1 процента потери производительности за всю игру, я поставлю вам пиво. Дальше идет управление памятью. Обычно это делается с учетом особенностей игры – много разных пулов (для ограничения подсистем или уменьшения вреда от блокирования), много разных стратегий выделения памяти для разных видов данных, но это скучно. Больше внимания обращено на главных потребителей памяти. Память под геометрические данные выделяется со сбором мусора, но самые важные данные статичны. При сдаче консольной версии у нас было 1Гб сжатого OGG звука и почти 2Гб сжатых без потерь DXT текстур. Ясно, что они не влезут в память консоли. По пути стримминга данных с DVD мы дошли до того, что мы не загружали предварительно ничего, даже базовых звуков ходьбы или оружия. Мы проделали много работы для компенсации времени поиска на диске, чтобы игрок не замечал этого. Это было тяжело. Так как Метро 2033 - одиночная игра, рассказывать про сетевую часть нечего.
Ваши первые технодемки показали, что вы также работали с PS3, но Метро 2033 выходит только на Xbox 360. Почему? С самого начала мы выбрали самую 'сложную' платформу. Много решений было принято со знанием ограничений и заковырок, которые мы встретим в будущем. Для меня видеочип PS3 (они почему-то любят называть его RSX) был оптимальным выбором, потому что я был занят в ранних стадиях разработки NV40 и все казалось родным: RSX является прямым наследником этой архитектуры. Читая документы Sony это было как 'Ха! Они не понимают где потерялись эти циклы. Они кодировали sub-optimal code-path в GCM для этой штуки.' Все в таком роде... THQ не хотела рисковать с новым движком от новой студии, учитывая сложность программирования на этой платформе, особенно когда не было бизнесовой потребности в этом. Решение разрабатывать для ПК и консоли было умным. Это позволило сфокусироваться на качестве для обеих платформ. Кстати, мы никогда не запускали Метро 2033 на PS3, только разрабатывали архитектуру для него. В студии много консольных игроков, но немного консольных разработчиков и Microsoft сделала многое, чтобы снизить барьер при помощи своих отличных инструментов, компиляторов и анализаторов. Наше решение разрабатывать для 'более сложной' платформы окупилось сразу. Целая игра была портирована на Xbox 360 в течение 19 рабочих дней. Хотя они не были восьмичасовыми...
Игра Halo 3 известна использованием избыточного подхода к реализации HDR освещения, создавая два суб-HD кадровых буфера и объединяя их с уменьшением разрешения и сглаживанием. Какой подход у вас? Отложенное затенение очень гибкое. Сначала вы имеете несколько LDR буферов в разных цветовых пространствах, которые еще не затенены. Но только в конце конвейера (само затенение) вы имеете HDR результат. В этой точке мы разбиваем HDR данные на два буфера по 10 бит на канал и тогда делаем постообработку, получая одно изображение имеющее 10 бит на канал. Оно отправляется на экран. На PS3 мы используем то же самое только с буферами 8 бит на канал. Они кстати имеют полные 720p. В версии для ПК все по другому: мы не разбиваем данные перед постообработкой, храня все в одном FP16 буфере.
Движок поддерживает MSAA, analytical anti-aliasing и даже deferred super-sampling. Все технологии поддерживаються консолями? Как вы определяете грани? На ПК доступны все эти техники (но мы не уверены, что оставить в финальной версии). Последние два года на Xbox 360 мы использовали deferred rotated grid super-sampling, но позже переключились на аналитическое сглаживание (ААА). Это дало нам около 10Мб памяти и уменьшили загрузку GPU сглаживанием с переменных 2.5-3.0 миллисекунды до постоянных 1.4мс. Качество довольно неплохое. ААА работает немного не так, как вы предполагаете. Оно не имеет полного определения граней. Проще объяснить технику, как удвоение шейдером разрешения изображения используя определение участков/граней (подобно морфологическому АА) и обратное уменьшение к оригинальному размеру, получая сглаженную версию. Так как окно определения паттернов фиксировано и мало для реализации на GPU, качество значительно хуже для близких к горизонтальным и вертикальным линиям, чем например в MLAA.
То есть вы можете заставить MSAA работать вместе с аналитическим сглаживанием? Да. Они могут работать вместе так как потеря производительности на современном оборудовании не будет большой.
Можете объяснить на пальцах преимущества вашего решения с отложенным затенением? Игрок проводит более половины игры под землей. Это темные туннели и слабо освещенные комнаты. Нет других источников электричества кроме генераторов. Визуально это интересно, убедительно и захватывающе. Нам нужно много малых источников света. Отложенное затенение – это лучший выбор.
Чем ваше решение отличается от Killzone 2? Они использовали отложенное затенение и традиционный forward рендер, аппаратное сглаживание… Их исполнение кажется плохо оптимизированным. Иначе зачем они делали предварительно вычисленные карты освещения? Зачем они освещают динамические объекты иначе чем мир, при помощи подобных Light Probe вещей? Основываясь на моем опыте, вам нужно как минимум 150 полноценных источников света, чтобы закрытые пространства выглядели хорошо и натурально и намного больше, чтобы подсветить такие вещи как глаза, прочее. Похоже они упустили это из виду.
Deferred lighting используется во многих играх начиная с Crackdown до Killzone 2 и GTA IV. Но вы также используете отложенные отражения. Как они работают и какие преимущества дают? При отложенном затенении вы начала сохраняете атрибуты в нескольких буферах, затем освещаете сцену и потом затеняете. Для зеркала вам надо сначала сохранить отраженные аттрибуты в первом проходе, а дальше все, как обычно. Мы используем это для воды, зеркал и других отражений. На ПК мы используем подповерхностное затенение для человеческой кожи. Но это уже другая история…
Консоли имеют сложности с убедительными тенями. Что вы с этим делаете? В этом нет ничего необычного. На Xbox 360 мы сначала рендерим традиционную глубину с точки зрения света, затем конвертируем в ESM (экспоненциальную карту теней) представление одновременно делая размытие по Гауссу. Далее во время освещения мы делаем одно билинейное обращение к таблице для получения процента затенения. В конечном итоге мы избавляемся от шумов и ошибок затенения или многих обращений к таблице при фильтровании тени, чтобы получить что-то издалека похожее на тень. Конечно, 10Мб eDRAM на Xbox 360 ограничивает разрешение карт теней, что заметно при движении источника света… Мы используем эту память для shadow mapping только два раза в кадр. PS3 имеет другие ограничения. Поэтому мы используем классический depth-based multi-sampled shadow-mapping. В будущем мы думаем использовать SPU для экспоненциальной фильтрации для унификации решения и визуального качества.
Как обстоят дела с ИИ? Каждый ИИ персонаж имеет чувства: зрение, слух и реакцию на столкновения. Модель зрения близка к реальности: угол обзора 120 градусов, переднее зрение более развито, также берутся во внимание освещенность и скорость цели. Например, подвижный объект видим лучше статичного. Также есть возможность ‘вглядываться’. Есть несколько уровней настороженности: легкое беспокойство, легкая тревога, тревога, сильная тревога, опасность. Каждый звук имеет 'метку для ИИ'... Звуки стрельбы отмечены как 'combat.shot'. Для этой метки расстояние слышимости, например, 50 метров, что достаточно много. Но используя порталы/секторы рендера, обработчик слуха определяет ‘виртуальное расстояние’ с учетом стен и коридоров. Так что персонаж никогда не услышит что-либо за стеной, потому что если ‘прямое’ расстояние всего пять метров, ‘виртуальное растояние’ при прохождении звука через стену составит 60 метров. Реакция на столкновения – это информация про удары воспринятые персонажем. Друзья не бьют друг друга, значит все хиты от врагов. Подсистема чувств предоставляет базовую информацию – объект, позицию, уровень. Объектами могут быть дружественные или враждебные персонажи, гранаты или оружие. Другая подсистема обрабатывает базовую информацию и решает, что сейчас важно для персонажа. Разные уровни чувств объединены с разными типами поведения. Например, типичным поведением для ‘легкое беспокойство’ будет что-то типа ‘Кто здесь?’ и пристальный осмотр, что может вызвать состояние ‘сильная тревога’ и начало поиска. Конечно, дизайнеры имеют полный контроль над всем и они могут заставить персонажей ровно стоять или показывать смешные анимации даже, если возле них упадет ядерная бомба и это подходит к текущей сцене.
Эта система ИИ означает что стелс геймплей стандартен? Для стелса очень важна система чувств, чтобы каждый персонаж не знал точно, где находится враг. Нашим заданием была сенсорная система Thief, которая описана во многих статьях. То же «виртуальное расстояние» похоже на их систему. Также есть поведения для поиска и патрулирования. При помощи звуковой системы персонажи показывают свое состояние. Наши NPC полностью готовы к стелсу. Также в этой системе важен дизайн уровней.
Какой ПК нужен для достижения производительности Xbox 360? Нам не нужно столько же памяти, как играм только для ПК. Любого ПК с 512Мб ОЗУ и поддержкой DX10/DX11 в Windows 7 будет достаточно. DirectX 9 дублирует в системной памяти почти все ресурсы GPU, поэтому вам придется добавить около 256Мб для избежания свопинга. Со стороны процессора есть проблемы. Поскольку система заточена под многопоточность, для ‘гладкой’ игры нужно как минимум два апаратных потока. Производительность процессора сильно не играет роли, кроме как в нескольких сценах за всю игру, если это конечно современная архитектура (не Intel Atom!) с более чем одним ядром. Что до видеокарты, то требования тут другие. Шейдеры, конвейер и другие детали движка очень разные. Обе версии лишь выглядят похоже из-за одинаковых ресурсов.
Сравните комбинацию Xenos и Xenon с аналогичной связкой для ПК. Приблизительно одно ядро Xbox 360 – это четверть ядра Nehalem (i7) с той же частотой. Добавьте 1.5 разовое ускорение от второго потока инструкций на 360 и 1.3 для Nehalem, умножьте на 3 ядра и вы получите 70-85 процентов мощи одного ядра современного процессора при нераспараллеленном выполнении. Но при правильной векторизации кода приведенный расчет не работает. В таком случае 360 обскачет ПК в производительности на поток/такт. GPU Xbox 360 – это иной зверь. Он в 5-10 раз слабее современного железа на ПК. Но аппаратная мощность это лишь одна сторона уравнения. Так как программисты могут оптимизировать задачу под специфический GPU, мы можем получить почти стопроцентное использование всех блоков. Это невозможно на ПК. В дополнение к грязным трюкам с MSAA, таким как использование некоторых поверхностей как multi-sampled (например hi-stencil masking the light-influencе делает это) или рендеринг multi-sampled shadowmaps и подальший семплинг корректных значений суб-пикселей, так как мы знаем какие паттерны и позиции имеют суб-пиксели, прочее.
Какие бонусы дает ПК версия кроме повышенных разрешений и фреймрейта? Частота обработки PhysX увеличена в два раза, что дает большую точность при определении столкновений и поведении соединений. Почти в два раза увеличится число обрабатываемых звуков (все с отслеживанием распостранения волн). - Большинство текстур имеют разрешение 2048х2048 (против 1024х1024 на консоли). - Разрешение карт теней до 9.43 Мегапикселей. - Улучшенное фильтрование карт теней. - Parallax Mapping для всех поверхностей, некоторые с occlusion mapping. - Объемный дым, туман, пыль. - Локальное размытие в DX10. - Взаимодействие света с материалом близко к «физически корректному» на высоких настройках. - Подповерхностное рассеивание для шейдеров кожи. - Улучшенная детализация геометрии с менее аггресивным LOD. В DirectX 11 поддерживается тесселяция. - Включение глобального освещения дает некоторое падение производительности за счет десятков тысяч дополнительных источников света.
Какие преимущества дает DirectX 11? В общем и в частности для Метро 2033. Хотя API немного неуклюжее функциональность неплоха. Я люблю три вещи в DirectX 11: вычислительные шейдеры, шейдеры тесселяции и разделение контекста draw/create. Главная вещь, увеличивающая производительность, – это вычислительные шейдеры. Сегодня в большинстве игр большая часть создания кадра тратится на постобработку. Легкий путь для добавления скорости – переписать эту постообработку через вычислительные шейдеры. Даже простое размытие может ускориться в два раза. Например, мы переписали код глубины резкости, что заметно улучшило качество при сохранении оптимального количества кадров в секунду.
Вы использовали аппаратную тесселяцию на Xbox 360? Нет, мы используем ее на DirectX 11. В Метро 2033 все ‘органические’ вещи типа людей тесселированы, а монстры используют реальный displacement mapping.
Какие ключевые преимущества аппаратного ускорения? Ключевое преимущество – это производительность. Процессоры не позволяют крупномасшатабные физические эффекты (хотя они хороши для традиционных твердых тел). Но разгружая процессор, вы имеете меньше времени GPU для рендеринга. Неплохо отдать вторую менее мощную видеокарту целиком для физики.
Как физика влияет на геймплей? Мы добавляем эффекты PhysX только в важных для геймплея местах. Мы не делаем эффекты ради эффектов. Человеческий мозг натренирован видеть несоответствия. Мы убираем их, чтобы не навредить геймплею и погружению в игру.
Как PhysX работает на нескольких ядрах без аппаратного ускорения? Как это делается на Xbox 360? Легко. PhysX SDK имеет понятие «задач». SDK создает их для каждой операции, которая может быть распараллелена, например для твердых тел, определения столкновений контуров, обновления для тканей или жидкостей, даже обработчик разделен на подзадачи. Мы используем эти задачи в нашем менеджере задач и они обрабатыватся как и другие потоки. Только у нас используется модель «запустил и забыл», а у PhysX – «запустил и ждешь».
4A это полноценное решение для разработки на PC, PS3 и Xbox 360. Вы будете лицензировать движок другим разработчикам? Да, мы изучаем возможности. Подробности будут позже.
Вы создали во многом лучшую технологию на консолях. Microsoft и Sony не собираются менять начинку. Можно ли улучшить достижения 4A engine? Большая часть Метро 2033 идет на частоте 40-50 кадров в секунду, если мы выключим vsync на 360. Большинство уровней имеют более 100Мб сэкономленного места. Мы немного перестарались в оптимизации.
Олесь Шишковцов - ведущий программист 4А Games Оригинал
773 Прочтений • [Metro 2033. Интервью с Олесем Шишковцовым от Digital Foundry (перевод)] [05.10.2012] [Комментариев: 0]