Отчет о КРИ2008 – 2

x-posted from zeux.livejournal.com

Вторая порция отчетов про доклады.

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

5. О некоторых особенностях приготовления брюквы
6. Промышленные убершейдеры
7. Анимационная система CryEngine2

5. О некоторых особенностях приготовления брюквы (день второй, 16:00, Нептун)

Один из лучших докладов, на которых я был. Речь шла о commodity. Commodity – это такой товар, который, не обладая качественными отличия от остальных товаров в схожей области, обязан удовлетворять определенным рамкам качества, и на который есть спрос (точно наврал, ну да и фиг с ним). Вот есть брюква гнилая – и спелая. Гнилую брюкву продавать неэтично. Поэтому надо учиться из гнилой брюквы делать спелую.

Например, игры типично неэффективно используют диапазон значений яркости. Можно снять скриншот, и посмотреть гистограмму в Photoshop. Дальше добавить один mad в шейдер, сделав им remap в полный диапазон. Картинка магическим образом преображается. Еще можно делать HDR. Еще можно делать разный HDR в разных частях экрана. Еще можно забыть про HDR, и сделать кривую цветокоррекции. Кусочно-линейную. И отдать ее артистам. И сделать ее per-zone.

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

Игры с однокнопочным геймплеем могут цеплять, а могут и не цеплять. Самый впечатляющий пример игры, которая цепляет – пупырчатые пакеты, на которых можно лопать пупырышки. Можно попытаться взять игру с таким геймплеем, и попробовать сделать до состояния “цепляет”. Игра в стиле “мышь бегает перед кошкой, кошка сшибает мышь лапой”. 2D арт рисовать уже никто не умеет, поэтому нужно сделать модели, заанимировать, затекстурировать. Сделать звук. Написать некоторое количества кода, про такую игру. Сделать несколько итераций, пока не начнет цеплять.

Пусть у нас есть две игры, игра с 30 спартанцами и игра с 300 спартанцами. Разница между ними – в количестве. Оказывается, что для того, чтобы брюква была спелой, при подобном изменении масштабов количественные улучшения в техпроцессе не спасают, обязательны качественные. Там была всякая конкретика, я ничего уже не помню – не бейте пианиста, он играет как умеет…

Я тут написал какие-то запомнившиеся мне тезисы – но этот доклад надо слушать вживую. Боря потрясающе интересно рассказывает, мне даже немного стыдно, что дерзнул записать святое на бумаге.

6. Промышленные убершейдеры (день второй, 17:00, Нептун)

Рассказ был о подходе к организации шейдинга в TimeShift. Там используются убершейдеры, для 90% шейдинга используется один шейдер. Я сразу расскажу о финальном варианте, к которому они пришли, там было еще несколько промежуточных).

Те, кто знают про систему материалов в Магии Крови (shodan читал лекцию на KRI2005), знают, что такое пин, для остальных – пин это константа времени компиляции (типично bool, иногда int), обычно пины реализуются через директивы препроцессора в шейдере, каждая уникальная комбинация значений пинов – это чаще всего уникальная пара vertex shader + pixel shader.

В игре TimeShift 77 пинов (2^77 комбинаций). Из них 51 это пины, которые художники расставляют на материалах (различные текстурные маски, бамп, параллакс, модель освещения, etc.), порядка 16 – различные комбинации количества и типов источников света (3 источника света рисуются за один проход, больше – в несколько проходов), остальное – это пины на платформы (в случае Xbox360/PS3) или на опции (в случае PC), и еще чуть-чуть разных пинов.

Сначала весь уровень (сцена в Maya) анализируется, из него вынимается список уникальных комбинаций материальных пинов (которых 51). Результирующее число комбинаций на среднестатистический уровень – порядка 180.

Пинов все еще слишком много, их количество урезается. Ценой дополнительных инструкций все источники света становятся источниками одного типа (spot), остальные эмулируются через них. В итоге получается относительно удобоваримое число – порядка 10-20 тысяч шейдеров на уровень, порядка 45 тысяч всего на одну платформу. Платформ в TimeShift около 40 – две консоли, и несколько конфигураций железа, на каждую конфигурацию несколько возможных комбинаций опций.

Для консолей (не помню, как для PC) экономится память – шейдеры хранятся в памяти в сжатом виде, и есть буфер с LRU политикой вытеснения, в который они распаковываются on demand.

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

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

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

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

Тот шейдер, который шейдит 90% сцены, занимает 300 Kb – это один шейдер, раскиданный по нескольким файлам (#include).

Код шейдера с точностью до некоторых локальных #ifdef-ов кроссплатформенный, т.е. является одновременно HLSL (PC, XBox360) и Cg (PS3).

7. Анимационная система CryEngine2 (день третий, 15:00, Галактика 1+2)

Доклад похож в чем-то на прошлогодний доклад про архитектуру современного 3D движка – достаточно много воды и что ли рекламы… Было немного рассказано о том, как устроен пайплайн – типа, анимация экспортируется из пакета в промежуточный формат, который потом компилируется resource compiler в финальный формат – движок умеет грузить и то и то, в релизе только финальный формат. Ну там еще всякое было, я опять же не помню уже, потому что было не интересно.
Из фич анимационной системы – есть блендинг, есть отдельное оперирование разными частями скелета, есть граф анимаций (конечный автомат), есть всякие IK контроллеры – look, aim, foot IK.

Всего анимаций в несжатом виде порядка гигабайта, после сжатия – 30 Mb.
Основной источник анимационных данных – mocap, у них есть внутренняя студия. Типично сначала анимация снимается с обычных работников (скажем, с аниматоров), специально обученные актеры использовались редко – только если качество неудовлетворительное.

Анимация семплится и оптимизируется выкидыванием кейфреймов. Реализованы два метода – выкидывание на основе локального threshold (упрощение кривой локального translation без использование информации об остальной модели), и анализ мировой ошибки движения вертексов (выкинули кейфрейм, перескинили нужные части модели, посчитали ошибку). Преимущественно используется первый, проблем серьезных с ним не было.

Для экспорта изначально был комплект скриптов на MaxScript, сейчас как я понимаю для экспорта они полностью перешли на COLLADA – либо для 3dsmax все еще скрипты, а COLLADA как доп. средство для остальных пакетов, было не очень ясно.