Семен ([info]sim0nsays) wrote,
@ 2008-03-12 01:10:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:graphics, tech

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

На удивление сложно найти людей, которые кодают на DX10, один Крайтек только и нашел. С мужиками из Крайтека хорошо и весело, привет Тимуру. Такое ощущение, что из Крайтека приехало больше народу, чем из MS...
Рассейского геймдева видел совсем уж мало, видимо отрываюсь от. Или это 1С не приехал. Надо в любом случае что-то делать.

Интересно на конференциях, как всегда, слушать девелоперов. IHV и платформодержатели расскажут тебе все и так, у них работа такая, а вот девелоперов слушаешь всего несколько раз в год. Мужики вполне отвечают на вопросы и не палятся (и даже реагируют на письма). Я тоже буду излагать достаточно примерно, надеюсь в случае чего смогу уточнить в комментах.

Не успел пробиться на тек в Uncharted, не выдержал километровой очереди на Final Fantasy.
Давайте буду рассказывать про то, что понравилось и запомнилось.


Lighting and Material of HALO 3, выложено тут.
Это было весело. Мужик сразу сказал: ну, в принципе освещение - это достаточно просто, это вот такой интеграл по всей сфере приходящего света, зависящий от позиции точки и направления взгляда, давайте его раскладывать.
Если серьезно, то у них большая часть освещения статическая, и для диффузного освещения они по-большому счету делают directional lightmaps на SH. То есть, в лайтмапе хранится разложение spherical harmonics для всех направлений, из которого сэмплится по normal map. Разумеется, лайтмап сильно менее детальный, чем normal map - получается мягкое GI-like освещение с детальностью normal map.
Накурившись травы товарища Питера и Пайка, хранят вместо 9 коэффициентов квадратного SH какой-то dominant light и только линейные коэффициенты, получается всего 4. Их ферма на 180 серверов считает это все добро, оптимизяет и пакует в DXT (детали - в отдельном докладе, я туда не ходил).
Dynamic lights, как я понимаю, рисуют обычными способами.

На персонаже для диффуза у них PRT, для спекулара сложное разложение освещения на разные частоты.
Нижние плавные частоты спекулара - разложение на много Spherical Harmonics в зависимости от направления взгляда, три страницы слайдов с формулами, убейте меня. Получаются такие красивые большие пятна.
Средние частоты - env cubemap c рефлекшеном.
Высокие частоты - аналитический спекулар с направлением источника.
Все они смешиваются на персонаже, получается типа естественная картинка. Хрен его знает, если хороший шейдинг - это который не бросается в глаза, то не бросаться в глаза у них точно получилось.

Для HDR на xbox пользуют две 8-bit текстуры, основной HDR эффект - блум с исправлением нелинейности. Подробностей не запомнил.

Art and Technology behind BIOSHOCK's Special Effects, вроде еще не выложили
Мужики сначала рассказывали как это здорово и правильно - жить программисту по эффектам и дизайнеру по эффектам рядом и друг с другом болтать о всяком и пиво пить. Кто бы сомневался, блин.
Из эффектов они сначала рассказывали про lit particles, я прокнулся не особо, ну там per pixel light от комбинированного из нескольких источников, чуть твикнутый шейдинг.
Единственная правильная задумка - дополнительный источник на камере для спекулара, это очень правильно и здорово, он гарантирует, что некий заметный вклад будет всегда. Видимо можно и нужно делать так далеко не только для патиклов.

Интересное же рассказывали про эффекты с водичкой. У них есть водопады с потолка, это тупо прямоугольник со скроллящейся текстурой детальностью воды и маской конкретных разводов. Для красивых эффектов персонажа, стоящего под водопадом, они рендеряют 1D-shadowmap для каждого водопада, и потом модулируют этим воду, офигеть можно :)
Эффект между тем красивый.

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

Самое красивое - ripples под ногами персонажей и предметов. Сначала пробовали тесселировать водную поверхность разными методами, получалось плохо. В результате сделали "deferred shading" для волн - специальный screen space буфер, куда каждый кадр рендеряют normal map от всех кругов под ногами в сцене, и потом воду освещают с нормалями из этого буфера. Важный момент - для освещения воды источники ставятся на другие позиции, чтобы лучше были видны цветные спекулярные блики от них.
Выглядит очень здорово.

Так, последнее из хорошего мне запомнилось про анимации в Uncharted - Creating a Character in Uncharted: Drake's Fortune, выложено тут (как кстати и тот доклад про тек, который я пропустил).
Самый цимес - additive animations. Типа, правильно нарисовав анимацию "бега" и "усталого бега" получается вытащить добавки к костям, которые означают "усталось движения", которые потом можно применить к "ходьбе" и "медленному бегу". Одновременно можно таких применять много.
Ну вот например aiming - это такой additive animation из интерполяции шести нарисованных поз с разными углами.
Я подозреваю, там есть кучи тонкостей с тем, как блендить эти анимации, впрочем.

Похожие штуки показывали и в Assassin's Creed, и в Crysis, и в Far Cry 2.

Вторая круть, какую показывали - variations. Можно нарисовать всего одну новую позу в которой персонаж стоит и целится, и разница между ней и дефолтной может автоматически смешиваться со всеми нарисованными анимациями, и утверждается что смотрится сносно. То есть, нарисовал 20 поз (не анимаций, только поз) из которых NPC в тебя стреляет, и получил все анимации забесплатно. Опять же, рисовать позы и анимации надо с некоторыми ограничениями, чтобы срасталось.
Но такое удешевление рисования анимаций вполне возможно стоит того.
А, ну разумеется по всем этим поводам пацаны считают анимацию на SPU.

Остальное мне запомнилось меньше. Выходил дядя и фантазировал, как можно имплементировать мегатекстуро, показывал исполненные смыслом строчки из писем Кармака. Выглядит это все ugly, надо что-то делать не так. На наркоманскую лекцию про "style and structure" пришел неподготовленный - не накурившись, думал хватит того, что у докладчика. Не хватило.
Про толпы в Assassin's Creed было мало технических деталей, про процедурный стафф в Far Cry 2 я тоже не воткнул, хотя симпатично выглядит.
Лекции IHV как обычно скучные.
"Вот как-то так" (с)

Crossposted to blog.gamedeff.com




(Post a new comment)


[info]10chiken
2008-03-12 09:23 am UTC (link)
Эх, лекции по IK я бы послууушал...

(Reply to this) (Thread)


[info]10chiken
2008-03-12 09:24 am UTC (link)
В смысле - о костях :)

(Reply to this) (Parent)


[info]plakhov
2008-03-12 09:27 am UTC (link)
Нет ничего нового под солнцем.

Variations мы делали в Ночном Дозоре, а аддитивные анимации еще с Silent Storm.
Оно сцуко работает, и даже кучи тонкостей нет (впрочем, одна есть: рутовая кость должна находиться между ступней персонажа, а не где-то выше, иначе очень неудобно ставить на террейн персонажа, играющего сгенеренную анимацию). Но как же запариваешься объяснять художникам, как именно им надо нарисовать эту позу!

(Reply to this) (Thread)


[info]sim0nsays
2008-03-12 05:22 pm UTC (link)
Интересно. А какие additive animations у вас были? Сколько можно было лепить одновременно?

А какие-то скрины с этим и variations есть?

(Reply to this) (Parent)(Thread)


[info]plakhov
2008-03-12 05:31 pm UTC (link)
Где-то были и скрины, и длинная переписка с людьми, использовавшими движок (она ценна тем, что в подробностях все было рассказано с расчетом на внешних людей, так что наверное копипаста оттуда хватило бы; так писать лень, да и не помню я уже всего). Но не на этом компе, к сожалению. Если тебе правда интересно, напомни завтра. У тебя моя аська есть?

Еще у нас трупы из ragdoll'а умели вставать и снова ходить, кстати :)

(Reply to this) (Parent)(Thread)


[info]sim0nsays
2008-03-12 05:32 pm UTC (link)
Интересно, ага. Твоей аськи нету, моя написана в профайле.

(Reply to this) (Parent)


[info]troichina
2008-03-12 08:42 pm UTC (link)
да да, можно про трупы из рэгдолла по подробнее? ну и про выриации тоже было бы прикольно услышать.

Томат

(Reply to this) (Parent)


[info]sim0nsays
2008-03-13 05:44 pm UTC (link)
Завтра пришло. Ау? :)

(Reply to this) (Parent)(Thread)


[info]troichina
2008-03-13 06:54 pm UTC (link)
>>Завтра пришло. Ау? :)
самому тема интересна. Может письмом побеспокоить уважаемого?
Томат

(Reply to this) (Parent)(Thread)


[info]plakhov
2008-03-14 09:20 am UTC (link)
Я тут заболел слегка, и до работы не добрался. Ладно, попробую пока по памяти. Если где совру, не бейте. Соответственно, придется без скринов.

Процедурными анимациями в том движке баловались традиционно много. Это был РС проект с соответствующей культурой кодирования, поэтому в качестве анимаций допускался произвольный объект, реализующий интерфейс IAnimator. Т.е. снаружи системы обычные анимации и процедурные выглядели совершенно одинаково. При этом наследники IAnimator, естественно, могли в конструкторе принимать на вход один или несколько других IAnimator'ов, и свой выход строить на их основе. Например, существовал наследник IAnimator, в конструкторе получавший другую анимацию и фризящий ее на таком-то кадре; это и был правильный способ зафризить анимацию, другого не было. Был интерполятор между двумя анимациями, переводящий одну в другую за заданное время, ограничитель, играющий только кусок анимации, инвертер, играющий ее задом наперед и тп. Еще один получал на вход произвольный IAnimator и ставил в нем ноги на террейн. Все это чем-то похоже на DG из Maya и, собственно, оттуда и было слизано. Для отладки этой системы я в какой-то момент сделал отладочный вывод этого графа (характерно, что это произошло только на адд-оне, на этапе багфиксинга). Выяснилось, что в банальной ситуации "юнит идет" участвовало штук 10 IAnimator'ов, только 2-3 из которых были анимациями, нарисованными художником. Несмотря на все это, работало оно довольно шустро (из-за ленивости большей части вычислений в этом графе), но памяти жрало даже не знаю сколько, мы тогда об этом не думали, т.к. РС.

Теперь ближе к теме. Примеры того, что на всем этом делалось.
1) Интерполяция анимаций. Использовалась, чтобы ружье целящегося или стреляющего персонажа было направлено точно в цель. Интерполировались, кажется, 4 анимации, для каждой из которых художники указывали соответствующие углы.
2) Смешивание с разделением по указанной кости. Например, для стрельбы на ходу (на бегу). Совершенно банальная вещь (выше какой-то кости по иерархии играем одну анимацию, ниже - другую), при этом выглядит очень сносно. Больше того. Нам оно не понадобилось, но я ради развлечения включал в качестве одной из анимаций ragdoll, делил по плечу/бедру, и бесплатно получал персонажа с перебитой конечностью. Ну и немного помогло для роликов на движке (персонаж пятится назад, держа при этом кого-то под прицелом, или персонаж сидя говорит по телефону, хотя раньше умел только стоя). На самом деле стоит сказать, что большинство таких процедурных анимаций художники все равно в итоге переделали. Я, честно говоря, не заметил особенного улучшения качества, но им виднее. В любом случае production это здорово ускоряет - многие фичи в первом варианте делаются только программистом (а ролики - только скриптовиком), без привлечения художников.
В такие variations, как написано в посте, я не очень верю (почему - ниже станет понятно, в пункте про аддитивную позу). Может быть, они все-таки то, что я описал, имели в виду?

(Reply to this) (Parent)(Thread)

Смешивание с ragdoll
(Anonymous)
2008-04-05 12:35 pm UTC (link)
Спасибо, очень интересно! Есть такой вопрос - IAnimator принимал/передавал матрицы в пространстве модельки/пространстве парентовой кости/кватернионы? Если что-то отличное от первого, то при каждом рассчете ragdoll (который вроде как в мире) надо переводить в модель (одно умножение) а потом еще и в пространство парентовой кости (N вычислений обратных матриц, умножения и т.д.) Опять же есть проблема, что ragdoll делается не на все кости, т.е. где-то надо брать позиции промежуточных (bind-pose?)

(Reply to this) (Parent)


[info]plakhov
2008-03-14 09:38 am UTC (link)
Дальше, про аддитивные позы.
Делалось очень просто: есть дефолтная поза А, есть аддитивная поза В, есть target анимация X. У нас был аниматор CAddPose: public Ianimator (название не помню), принимавший на вход A, B и X, и в момент времени t выдававший позу X + B - A (эта операция применялась к углам и смещениям костей; для scale'ов было X*B, кажется). Все.
Дальше была совершенно уникальная проблема: объяснить аниматорам, что B должно быть похоже на А. Т.е., например,есл А - это стандартная Т-образная поза, то поза В усталого человека все равно должна быть похожа на Т-образную. Это кажется простым, но с завидной регулярностью получали баги "у вас тут наши анимации портятся" и выясняли, что А - это Т-образная поза, а В - "естественная". Я не знаю, почему до них это не доходило, и как с этим бороться, но вот было такое.
В итоге аддитивные позы в игре использовались, но не так широко, как я ожидал. Я думал, например, что большинство "женских" анимаций можно получить из "мужских" добавлением "женской позы" (и afaik так оно и было, но их все равно нарисовали вручную). Я подозреваю, местами не хватило желания понять и квалификации у художников. Им было проще руками.
Был большой геморрой с тем, что pivot в нашем стандартном скелете был расположен где-то в груди, а значит, со scale'ами и с постановкой итога на terrain был большой геморрой. Если использовать аддитивные позы, то pivot обязательно надо располагать между ступней.
Если аддитивная поза А сильно отличается от референсной В ("стоит" vs "стоит и целится"), то все это не работало, т.к. как только в target-анимации Х начинают двигаться руки (а, например, при беге, они обязательно будут это делать), то с учетом сдвига А-В мы легко получаем крайне странные (залезающие в бока или неанатомические) положения конечностей. Поэтому в variations в том виде, как оно описано в посте (а не в разделяемые по костям) верится слабо. Возможно, имеет смысл совместить оба подхода (т.е делить по кости, но не жестко, а слегка добавлять влияние второй анимации), но тут будет много геморроя с настройкой этого дела (причем как минимум под каждый конкретный скелет, а то и под конкретный тип анимаций), а смысла я в этом не вижу - оно и с жестким смешиванием неплохо выглядело.

(Reply to this) (Parent)(Thread)


[info]sim0nsays
2008-03-17 06:26 pm UTC (link)
Очень интересно, спасибо. У них все выглядело как они действительно смешивают много анимаций на теле (то есть, может и ограничивают по костям, но однозначно не жестко).
Основной пойнт variations - в быстром создании контента. У них действительно были guidelines для аниматоров, вполне возможно на практике они сложные. Руки вовсю двигались, да.

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

(Reply to this) (Parent)


[info]plakhov
2008-03-14 09:54 am UTC (link)
Ну и про вставание трупов.
Идея абсолютно банальная.
К тому времени, как мы это делали, в движке уже было с десяток анимаций всякого разнообразного вставания (упал на спину - встал, лег-встал, сел на стул - встал и тп). Еще пяток нарисовали, чтобы они были поразнообразнее. Когда труп хотел встать, он искал среди этого набора кадр, наиболее похожий на свое текущее положение (не обязательно первый), интерполировался в него, а дальше играл анимацию до вставания. Естественно, поиск шел среди анимаций, повернутых, условно говоря, на тот же угол, что и труп.
Если в момент проигрывания анимации вставания зомби оказывался в неустойчивой позе (с определением слов "неустойчивый" были проблемы), вся процедура прекращалась, включался ragdoll после чего все повторялось (пример: повис на заборе, захотел встать, упал с забора, окончательно встал). Если встать дважды не удалось (кажется дважды), то на все забивали и молча телепортировали юнита в ближайшую проходимую точу. Происходило в 0,1% случаев, в основном в ситуациях, когда и человеку не очень понятно, как оттуда вообще можно выбраться.

Основные проблемы были в двух местах:
- детектор "неустойчивой позы" (основная мораль оказалась в том, что его ложное срабатывание гораздо хуже ложного несрабатывания, хотя изначально казалось, что должно быть наоборот)
- поскольку это был TBS, уже вставшего юнита надо было поставить на сетку. У нас он уже встав на ноги, туда приходил ножками. Нужно было определить, куда именно "туда", чтобы он не ходил по пропастям и вообще все это разумно выглядело. Изначально вставал-то он не в сетку, а стандартные механизмы ходьбы были неявно расчитаны на ходьбу по сетке - например, не умели ходить на слишком маленькие расстояния (порядка одного шага), не проверяли наличие пропастей/препятствий по пути (pathfinding по сетке всегда выдавал корректный в этом смысле путь, но к сожалению, тут он не мог поработать). Так что ходьбу для данного конкретного случая пришлось допиливать напильником. Как я понимаю, для не-TBS игр это все не имеет значения.

(Reply to this) (Parent)(Thread)


(Anonymous)
2008-03-14 11:43 am UTC (link)
а чтобы совсем выпытать:
>>Когда труп хотел встать, он искал среди этого набора кадр, наиболее похожий на свое текущее положение (не обязательно первый)

я правильно понял, что зарэгдоленный труп искал:
+среди всех подходящих анимаций
++среди всех кадров этих анимаций
такой кадр в котором между костями зарэгдоленного трупа и костями в этой анимации было меньшее расстояние \ ошибка? просто мне кажется приходится перебирать очень, ОЧЕНЬ много кадров?

или был другой \ секретный алго?
Томат

(Reply to this) (Parent)(Thread)


[info]plakhov
2008-03-14 02:16 pm UTC (link)
на самом деле перебирать совсем немного, потому что:
1) анимаций вставания не так уж много (порядка десятка)
2) конечно, не нужно проверять каждый кадр (более чем достаточно это делать с шагом, скажем, полсекунды). В каждой анимации - кадров 10 всего.
3) и на самом деле не нужно даже проверять положение и ориентации всех костей. Нам хватило, кажется, семи, и при этом только положений (где голова, где руки-ноги).
Итого порядка 100 вычислений кадров анимации (для РС - по-моему, смешно; но даже если занимает много времени, это можно закешировать), и порядка 700 сравнений 3d векторов (тоже, в общем-то, смешно). И это нужно проделать максимум два раза за всю процедуру.

(Reply to this) (Parent)(Thread)


[info]troichina
2008-03-14 06:08 pm UTC (link)
ясно, спасибо за секреты, было очень интересно.

Теперь мучает риторически вопрос, посему у "них" - так круто и технологично, а у "нас" - "местами не хватило желания понять и квалификации у художников. Им было проще руками." :=(
И это не только в нивале так.

(Reply to this) (Parent)(Thread)


[info]plakhov
2008-03-17 10:34 am UTC (link)
Вопрос риторический, так что "в общем" его обсуждать смысла нет, конечно. Но вот в данном частном случае могу рассказать, если правда интересно.
Просто мне не кажется, что дело тут "вомгле", причины были более банальные.

(Reply to this) (Parent)(Thread)


(Anonymous)
2008-03-18 12:00 pm UTC (link)
Конечно интересно.
Томат

(Reply to this) (Parent)


[info]golergka
2008-03-12 09:47 am UTC (link)
По анимациям - механизмы additive animations и бленда разных поз и в HeroEngine, к примеру, есть - только протестировать не успел пока. Ограничений, судя по документации, нету, на практике придётся самим смотреть, как "срастётся" :)

(Reply to this)


[info]x0ras
2008-03-12 12:34 pm UTC (link)
Дык по-моему, север Калифорнии в это время довольно дождливый.

А Рос. геймдев уж совсем как-то притих...

(Reply to this) (Thread)


[info]watkin
2008-03-12 03:26 pm UTC (link)
К КРИ готовятся :)

(Reply to this) (Parent)


[info]sim0nsays
2008-03-12 05:22 pm UTC (link)
yeah right, в воскресенье перед уездом уже вовсю солнце

(Reply to this) (Parent)


[info]kzot
2008-03-12 09:49 pm UTC (link)
единственное, что я понял из вышенаписанного, - это строчку из Ultimate группы Gogol Bordello)

(Reply to this) (Thread)


[info]sim0nsays
2008-03-12 09:52 pm UTC (link)
Ага. Это они к нам вчера приезжали.

(Reply to this) (Parent)(Thread)


[info]kzot
2008-03-12 09:53 pm UTC (link)
ну согласитесь, они боги

(Reply to this) (Parent)(Thread)


[info]sim0nsays
2008-03-12 09:58 pm UTC (link)
О да. Бесконечный позитив.

(Reply to this) (Parent)


[info]doc_allegator
2008-03-12 10:20 pm UTC (link)
Как всегда приятно и полезно пишешь.

(Reply to this)


Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…