| КРИ 2009 - slides |
[May. 18th, 2009|10:05 am] |
Впрочем, зачем ждать до вечера? Вот слайды моего доклада про SPU Render, в этой ветке я могу ответить на все вопросы, возникшие при прослушивании доклада, прочтении слайдов, или на те которые возникнут после того как выложат аудио/видео :) |
|
|
| КРИ 2009 - after |
[May. 18th, 2009|09:25 am] |
КРИ про кризис, и этим все сказано. Началось с родной компании, купившей билеты на плацкарт (а обратные к тому же еще и боковые) и забронировавшие мягко говоря странную гостиницу. Затем были стенды, которых раза в 2-3 меньше чем раньше. Наконец, были доклады, которых тоже меньше чем раньше, ну и качество многих страдает.
По докладам. Был на:
день 1
- "Игровая механика MMORPG как архитектурная задача. Компонентная модель.". Скрипт из маленьких компонент, компоненты пишут программисты, в визуальном редакторе дизайнеры составляют компоненты в одно целое и настраивают. Были какие-то детали, я особо интересного для себя не запомнил - это от меня слегка далеко.
- "SPU Render". Доклад, считаю, получился отлично :) Вечером выложу pdf-ку. Кстати, на всех докладах писали и аудио, и видео, так что видимо через некоторое время будет можно посмотреть и послушать почти как на конференции.
день 2
- "Индустрия видео-игр принимает человеческую форму". От меня это бесконечно далеко; neteraser в своем блоге выложил ссылку на PPT, может вам понравится.
- "Коктейль Молотова и санки: партизанские методы выживания маленького финско-русского доклада в суровых условиях нулевого бюджета". Я ожидал от Микко большего в смысле темпа и энергетики доклада. Иначе - было рассказано про раскрутку проекта, про борьбу с пиратством через его использование (don't fight it, embrace it), про то что реально пиратство по крайней мере на indie тайтлах бьет по продажам не очень сильно (1000 скачиваний с торрентов ~= 1 упущенная продажа), ну и еще что-то. Плюс на доклад были вынесены разборки с господами из Аструма (как хорошо, что я бесконечно далек еще и от этого!)
день 3
- "Быстро, Правильно и... Параллельно". Доклад от Интела про их набор утилит для профилирования и прочего. Цирк какой-то - была взята демка Bullet и соптимизирована. Во-первых, почему-то доклад делал дизайнер GUI, во-вторых он почти ни слова не сказал про то, в чем заключались оптимизации, в-третьих до оптимизации почему-то не проинлайнилась ни одна функция (всякие там конструкторы векторов, аксессор vector3::x(), operator[], etc.) [неудивительно, что получилось в итоге быстрее!], в-четвертых "рейтинг" параллелизации не изменился никак, в-пятых человек вообще не понимает видимо специфики кода (типа, было сказано про то что человек из буллета зачем-то написал свой код для тредов, а можно было бы взять TBB...). В общем какой-то кошмар. У нас вот каждый доклад пруфридится - два раза до КРИ человек читает доклад, а мы слушаем, притворяемся реальной аудиторией и одновременно пытаемся вместе с докладчиком его доклад улучшить. Мой доклад до пруфрида был на 20% больше и в 1.5 раза непонятнее. В Интеле видимо такого нет, это прискорбно.
- "Intel GPA. Современные средства отладки производительности графических приложений". Я про тул уже знал, т.к. был на стенде Интела и общался с разработчиками немного. Иначе доклад внятный, тул очень внятный. Задавал какие-то вопросы, руководитель проекта записывал себе пожелания, за вопросы дали мощный артефакт, который потом может сфотографирую и выложу.
- "Ruby: наш опыт применения". Кошмар. Ужас. Еще хуже чем Интеловский доклад. Во-первых я как-то думал, что речь пойдет про Ruby в игре; во-вторых докладчик абсолютно не умеет говорить (очень медленно, скучно и т.п.); в-третьих про языки было сказано много очень странных слов и выдвинуты странные гипотезы; через слово был зачем-то веб девелопмент и ruby on rails. Апофеозом лично для меня стал ответ на вопрос - "использовали ли вы интерфейс парсинга xml на больших файлах" - "да, работало прилично, 3mb xml парсился за 10 секунд" (да, это больная тема :)).
- "Внедрение многопоточного рендеринга в игровой движок". Для меня откровений никаких не было в принципе, но доклад внятный. Сначала были отвлеченные рассуждения про то, как хорошо делать параллельные программы и как плохо (с рассуждениями я к слову не согласен, но это тема для отдельного поста и не в этот блог), потом был реальный опыт параллелизации - в отдельную очередь вынесен рендер батчей, получаемых из lockless очереди (в нее объекты добавляются из main thread), который уже делает d3d вызовы и прочее. Полторы недели на первоначальную реализацию (и 3 месяца на допиливание, баги и пр.), прирост fps в полтора раза; на PC получилось неплохо, потому что скрылся оверхед от рантайма и драйвера, на XBox360 получилось неплохо, потому что скрылся оверхед от рантайма и от своего кода рендера, который медленнее чем на PC).
По стендам - из стоящего упоминания Ил2 на xbox360/psp, Дальнобойщики 3 (капелек не обнаружено, тени и облачка вроде как есть, меню открывается 5 секунд, закрывается 3), Интеловский стенд с Intel GPA (очень внятная тулза, респект Интелу - это лучшее что было на самой КРИ пожалуй).
Еще было пати. Пати в лучших традициях - слишком много народу, слишком громкая музыка. Имею мнение что формат должен быть совсем иной - по 5 человек за столиком, в более маленьком заведении. Если 25 человек - ну, 5 столиков, тоже мне фокус... Зато днем того же дня отлично с kas-ом и IronPeter-ом посидели и поговорили за всякое, как и в прошлом году собственно.
Резюме. КРИ плохое, GPA хороший, много народу плохо, личное общение рулит. О поездке не жалею. |
|
|
| КРИ 2009 - before |
[May. 14th, 2009|09:51 pm] |
| [ | Tags | | | kri2009 | ] |
| [ | music |
| | Within Temptation - Another Day | ] |
Через 3 часа поезд. Завтра в 4 мой доклад - не пропустите! В этот раз доклад ощутимо больше и сложнее, чем в прошлом году - однако и интереснее (по крайней мере для меня :)). Я сразу после КРИ выложу презентацию, любые вопросы можно будет задать здесь или по e-mail. Ну плюс разумеется когда-нибудь наверное на kriconf.ru появятся аудиозаписи, но до этого еще дожить надо.
Еще в субботу секретное пати, там я тоже буду.
Доклады по большей части какие-то странные - впрочем может хоть время по городу походить будет, а то в прошлом году фактически безвылазно в Космосе сидел. Поглядим.
Ну и недавно открыл для себя Наруто, спасибо ![[info]](http://l-stat.livejournal.com/img/userinfo.gif) __kas__-у!
Zeux out. |
|
|
| tweenbots |
[Apr. 13th, 2009|11:55 pm] |
Это прекрасно: http://www.tweenbots.com/.
К слову, а кто-то на КРИ собирается в этом году? Я вот зачем-то собираюсь и даже доклад видимо читаю - интересно, кто из знакомых будет. |
|
|
| ... |
[Mar. 5th, 2009|11:02 pm] |
| [ | Tags | | | tech | ] |
| [ | music |
| | David Arkenstone - The Temple of Poseidon | ] |
(навеяно чьим-то блогом) Я умею не программировать на С++.
Более того, скоро я кажется разучусь программировать на С++ - по крайней мере, на содержимое периодически возникающих в моем списке recommended в google reader С++-related блогов мне без отвращения/содрогания смотреть часто непросто, пару лет назад я все воспринимал несколько иначе.
Впрочем, ругать С++ вроде как вышло из моды лет 10-15 назад; жаль, я не успел. Сейчас насколько я понимаю модно ругать C# (по крайней мере, вчера кажется я увидел где-то аргументацию выбора C# в качестве языка "потому что legacy"), надо что ли приобщаться...
Смотрел вот всякие разные скриптовые языки. Почему-то все любят писать много странного кода - т.е. скриптовых языков с кодом < 500 Kb - раз, два и все. При этом вообще мало где (даже если кодобаза метр-два) понимание "garbage collection" выходит за рамки "malloc/free с вкрученным поверх mark&sweep", что для меня было неожиданностью. В итоге с одной стороны хочется для пет прожекта написать что-то более соответствующее моим предпочтениям, с другой есть дофига других интересных задач и не очень много времени на то чтобы все это делать :) В итоге невероятным усилием воли заставил себя пока что оставить tinyscheme и вернуться к вопросу через несколько месяцев.
Еще вот в тот, другой блог всякое пишу. Удивительно, но оказывается писать один-два поста впрок гораздо проще, чем один пост "на сегодня" - сейчас я обычно в субботу ночью перечитываю приготовленный неделю назад пост и публикую, а в воскресенье пишу следующий. Уже написал кое-что про frustum culling (и будет еще чуть-чуть), про смешной баг с работы - потом еще буду писать про память, про lock-free, про SPU всякого - ну а дальше уже лето наступит, поглядим :) Так что знайте, те, кто не добавил блог в свой любимый feed reader - я вас ненавижу! |
|
|
| SPU adventures |
[Feb. 14th, 2009|12:25 am] |
| [ | Tags | | | tech | ] |
| [ | music |
| | In Flames - The Jester's Dance | ] |
В порядке реализации
fragment shader patching
push buffer generation
job manager
vertex morphing (blend shapes)
batch culling (пока не occlusion)
batch sorting
particle update
particle render
Скоро видимо 90% ppu time будет в игровом коде, ура-ура. Ну или по крайней мере в коде, к которому лично я отношения никакого не имею :) SPU кода уже написал 200 кб того который живет в движке и еще небось 100 в экспериментах всяких.
Сделал себе в начале года где-то полуавтоматический edit & continue - функция, которая перезагружает job с хоста. Если вызывать каждый кадр, то в студии f7 - и через секунду новый код слинкован (через секунду а не через 20 потому что в студии открыт только нужный проект(ы)) и уже выполняется. Это приводит к тому, что отлаживать printf-ами/другими способами модификации кода часто становится очень удобно и быстро, оптимизировать небольшими кусками - очень просто, и даже профилировать иногда можно выключая в реалтайме куски кода (разумеется, зависит). Очень много радости, а фича вполне простая - кроме функции перезагрузки (экран кода, единственный ньюанс - сначала проверять дату модификации, чтобы файл не лочить каждый кадр) нужно откуда-то знать путь к файлу с кодом job-а - на это ушла еще пара часов. Я даже брейкпойнты в коде для (редкой) отладки дебаггером теперь ставлю, добавляя в код CRT_BREAK() (аналог __debugbreak)... |
|
|
| unit testing |
[Jan. 1st, 2009|02:25 pm] |
Я вот недавно написал некоторый кусок функциональности и тесты для него. В процессе я вдруг понял, что тест, который я сейчас пишу - не сработает, потому что соответствующая функциональность (точнее, обработка соответствующего corner case) просто не была реализована.
Иначе говоря, тесты даже не потребовалось запускать, они и так сделали свое дело.
Писать тесты на C99 чуть сложнее, чем на С++:
- во-первых, я еще не сделал поддержку fixtures, ну и не очень понятно как ее внятно делать - впрочем, пока обхожусь, эээ, одним макросом, заменяющим один fixture (декларация данных и инициализация). В принципе, с некоторым macro magic можно сделать на макросах совсем fixture - типа, #define SIMPLE_FIXTURE_DEFINE ... (data def), #define SIMPLE_FIXTURE_INIT, #define SIMPLE_FIXTURE_TERM, TEST_FIXTURE(SIMPLE_FIXTURE, test name).
- во-вторых, без внешних обвязок нельзя сделать автоматическую регистрацию тестов, т.к. глобальные переменные в C нельзя инициализировать чем-то кроме compile-time constants. Это упрощает все (нет работы до main, на которую влияет пользователь - ну, кроме bss clear & relocation fixup...), но приходится писать ручную регистрацию. У меня это 2+N строчек на файл с N тестами, и +1 строчка в главный файл, который тесты собственно запускает. При этом при добавлении нового теста забыть добавить его сложно, т.к. компилятор дает warning (static функция не используется), можно только забыть добавить целый файл. |
|
|
| Поток сознания, или краткая история 2008 года |
[Dec. 29th, 2008|12:09 am] |
| [ | Tags | | | life | ] |
| [ | mood |
| |  sleepy | ] |
Если вам показалось, что это пост в жж - не обманывайте себя, это наверняка галлюцинация. Впрочем даже если нет... У вас бывает такое, что пишете ответ в форум на пост(ы) - развернутый, скажем, поясняете что-то - а потом закрываете окно? У меня вот часто бывало на понятно каком форуме. Ответ как бы уже написан, в смысле для меня нажал я "отправить" или нет - разницы на самом деле никакой. Мысли выпущены на волю, оформлены в виде поста - дойдут они до адресата или нет уже не так важно. Я внезапно понял, что для меня личный блог - это когда думаешь мысль или испытываешь опыт (так говорят?), и потом вместо "закрыть" нажимаешь "отправить". В итоге то что я тут пишу - на самом деле только для меня, а вы через стекло зачем-то меня разглядываете сверху. Кстати, мне кажется что с постами про тек часто почти та же история.
( Я предупреждал... ) |
|
|
| КРИ 2008 - 7 |
[Apr. 24th, 2008|01:02 am] |
| [ | Tags | | | kri2008, tech | ] |
| [ | music |
| | Wintersun - Battle Against Time | ] |
9. DirectX. Цели на будущее (день третий, 17:00, Галактика 4+5)
Последний доклад от Чаза. Было еще два, меня на них не было. Чаз рассказывал про светлое будущее, в этот раз обошлось без особых проблем - доклад он знал :)
Тут было очень много всякого про GPGPU, про то что Direct3D как платформа победила всех в области parallel computing, и лет через 5 direct3d-style computing будет везде, ну и еще очень много всякого.
В качестве дополнительного реквеста от девелоперов было названо более внятное multi thread поведение - возможность разные части запускать параллельно.
Еще девелоперы не любят проблему с комбинаторным взрывом числа шейдеров, и ее собираются решать - правда, как, Чаз не сказал :) (в ответ на мой вопрос сказал, что как только будет что анонсировать, они сразу же...)
Были вопросы про то, когда будет тесселяция не через хаки - тесселяция кажется скорее всего будет в следующем API. Следующее API не будет требовать Windows 7 - по кр. мере, сказано было, что они постараются, чтобы новое API работало как на текущей OS, так и на OS предыдущего поколения.
Был, ээээ, странный (это эвфемизм, да) вопрос про generic shadowing solution в DX Next. Кажется, не будет у нас такого! (thank god)
В общем, я особо больше ничего не помню, плюс я уже превысил примерно двухлетнюю норму по количесту постов, так что пора закругляться.
На всех остальных докладах я не был, и очень хочу увидеть похожие summary по некоторым, в частности "Дзен" Плахова и докладу про единую технологическую платформу от ДДимы. Это был намек :)
Весь текст последних 7 постов написан по памяти, так что если я что-то там напутал, не обессудьте. |
|
|
| КРИ 2008 - 6 |
[Apr. 24th, 2008|12:50 am] |
| [ | Tags | | | kri2008, tech | ] |
| [ | music |
| | After Forever - Empty Memories | ] |
8. Как закалялся Crysis. Эволюция разработки (день третий, 16:00, Сатурн)
Второй из лучших докладов. Лид программист рассказывал про разработку - рассказывал про всякое, честно и без рекламы :)
40 программистов, 20 игровой код и 20 движок примерно.
Для игрового кода - SCRUM. Спринт длиной 2 недели. Команда разбита на группы, спринт - per group, группа состоит из людей, работающих над одной фичей - это не только программисты, а и артисты.
Для R&D SCRUM не взлетел совсем, потому что во-первых редко есть одна цель для всей команды, а типично есть один человек, который работает над одной подсистемой, другой над другой, etc., во-вторых большую часть занимает оптимизация и отладка, которая не вписывается в SCRUM. Используется ad-hoc схема.
Изначально пытались сделать большой план на все, он достаточно скоро начал очень сильно отличаться от реального положения дел, на него забили.
Размер репозитория - 600 Gb, из них 60 Gb - репо для кода. Кода всего 1.7 миллионов строк.
Для отслеживания крашей сначала использовался софт для трекинга багов (не помню, какой), это было не очень удобно - добавляются в среднем 2-3 краша, в результате из-за того, что баг через систему проходит достаточно медленно, краши чинились медленно. Перешли на отдельный мейлинг лист для крашей, счастливы.
Шейдеры тоже убер, на игру порядка 3 миллионов (если я правильно запомнил...) комбинаций. Шейдеры собираются на 5 8-core (2 CPU, 4 core per CPU) машинах, полная сборка кеша идет 2 часа. Если кеш не собран, идет компиляция на лету, вроде.
Есть централизованные билды. Билд - это актуальный образ игры (exe + данные) и редактора. Размер билда - гигабайты (около 6-8 Gb вроде). У каждого билда есть уникальный номер.
Билды собираются на специальном фарме, там несколько 8-core машин, у каждой 4 Gb RAM + 2 или 4 Gb RAMDISK для временных файлов - сильно ускоряет компиляцию. Билды для сборки кода не используют IncrediBuild. Это т.н. full build, он делает clean checkout, и собирает все. Есть еще fast build, он забирает только новые файлы.
Система контроля версий - Perforce для всего. Изначально был SourceSafe для кода и AlienBrain для данных, потом для кода перешли на perforce, потом и для данных тоже из-за того, что база alienbrain корраптилась периодически. Perforce на Windows Server не взлетел, пришлось ставить линукс - из-за вроде бы количества одновременных соединений. Я как-то упустил момент про количество бранчей, кажется таки есть основной бранч, но каждая группа работает свою итерацию (2 недели те) в своем, и мержит.
Есть внутренняя QA команда, которая каждый день тестирует билд. Она в основном тестирует игру, редактор тестируют дизайнеры. В конце спринта (четверг-пятница) коммиты замораживаются, QA активно тестирует билд на краши, коммитать можно только фиксы к крашам. С редактором - есть несколько дизайнеров, которые хорошо знают редактор, они с выходом нового билда его быстро прогоняют на основные тесты, чтобы посмотреть, им можно вообще пользоваться, или нет.
В итоге, билд может быть помечен как пройденный тесты - это значит, что он достаточно стабилен для использования в продакшене. Непрошедшие тесты билды не используются, билды, собранные локально на машине конкретных людей аналогично не используются.
Скорости сети не хватает, чтобы утром все смогли забрать билд за вменяемое время, поэтому билд после сборки автоматически копируется на компьютеры.
Используются pak файлы, и в билде все ассеты в пак файлах. Если художник хочет редактировать ассеты, он достает их из сорс контроля, если путь от фолдера до файла в FS и до файла в пак файле совпадает, то берется файл из FS. Таким образом художник тестирует измененные ассеты в билде, затем коммитит ассеты - они попадут в следующий билд.
Редактор является оболочкой над игрой, и соответственно требует ресурсов сильно больше. Из-за этого редактор перестал влезать в память. На 32-bit OS для 32-bit приложения доступно порядка 1.7 Gb памяти, на 64-bit OS для 32-bit - порядка 3, этого все равно было мало для некоторых уровней. Решение - весь тулсет работает в 64-bit. Игра также поддерживает 64-bit, Crysis - одна из первых игр, умеющих нативно работать в обоих режимах.
Кажется после альфы ввели обязательный кодревью - надо получить аппрув от двух программистов.
Обязательное требование - отмапленный рабочий диск в J:\, это позволяет избавиться от проблем с абсолютными путями (абсолютные пути к ресурсам совпадают на разных компьютерах). |
|
|
| КРИ 2008 - 5 |
[Apr. 23rd, 2008|10:30 pm] |
| [ | Tags | | | kri2008, tech | ] |
| [ | music |
| | Entwine - Losing the Ground | ] |
7. Анимационная система CryEngine2 (день третий, 15:00, Галактика 1+2)
Доклад похож в чем-то на прошлогодний доклад про архитектуру современного 3D движка - достаточно много воды и что ли рекламы... Было немного рассказано о том, как устроен пайплайн - типа, анимация экспортируется из пакета в промежуточный формат, который потом компилируется resource compiler в финальный формат - движок умеет грузить и то и то, в релизе только финальный формат. Ну там еще всякое было, я опять же не помню уже, потому что было не интересно.
Из фич анимационной системы - есть блендинг, есть отдельное оперирование разными частями скелета, есть граф анимаций (конечный автомат), есть всякие IK контроллеры - look, aim, foot IK.
Всего анимаций в несжатом виде порядка гигабайта, после сжатия - 30 Mb.
Основной источник анимационных данных - mocap, у них есть внутренняя студия. Типично сначала анимация снимается с обычных работников (скажем, с аниматоров), специально обученные актеры использовались редко - только если качество неудовлетворительное.
Анимация семплится и оптимизируется выкидыванием кейфреймов. Реализованы два метода - выкидывание на основе локального threshold (упрощение кривой локального translation без использование информации об остальной модели), и анализ мировой ошибки движения вертексов (выкинули кейфрейм, перескинили нужные части модели, посчитали ошибку). Преимущественно используется первый, проблем серьезных с ним не было.
Для экспорта изначально был комплект скриптов на MaxScript, сейчас как я понимаю для экспорта они полностью перешли на COLLADA - либо для 3dsmax все еще скрипты, а COLLADA как доп. средство для остальных пакетов, было не очень ясно.
Из-за этого доклада я пропустил доклад cppguru, а жаль. |
|
|
| КРИ 2008 - 4 |
[Apr. 23rd, 2008|09:57 pm] |
| [ | Tags | | | kri2008, tech | ] |
| [ | music |
| | Children of Bodom - Towards Dead End | ] |
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.
Код шейдера с точностью до некоторых локальных #ifdef-ов кроссплатформенный, т.е. является одновременно HLSL (PC, XBox360) и Cg (PS3). |
|
|
| КРИ 2008 - 3 |
[Apr. 23rd, 2008|09:34 pm] |
| [ | Tags | | | kri2008, tech | ] |
| [ | music |
| | Haggard - In a Pale Moon's Shadow | ] |
5. О некоторых особенностях приготовления брюквы (день второй, 16:00, Нептун)
Один из лучших докладов, на которых я был. Речь шла о commodity. Commodity - это такой товар, который, не обладая качественными отличия от остальных товаров в схожей области, обязан удовлетворять определенным рамкам качества, и на который есть спрос (точно наврал, ну да и фиг с ним). Вот есть брюква гнилая - и спелая. Гнилую брюкву продавать неэтично. Поэтому надо учиться из гнилой брюквы делать спелую.
Например, игры типично неэффективно используют диапазон значений яркости. Можно снять скриншот, и посмотреть гистограмму в Photoshop. Дальше добавить один mad в шейдер, сделав им remap в полный диапазон. Картинка магическим образом преображается. Еще можно делать HDR. Еще можно делать разный HDR в разных частях экрана. Еще можно забыть про HDR, и сделать кривую цветокоррекции. Кусочно-линейную. И отдать ее артистам. И сделать ее per-zone.
Еще в играх есть звук. Оказывается, что звук в игре с reverb и без - это две большие разницы. Без - это гнилая брюква, с - спелая. Еще был какой-то эффект, название которого я забыл, суть вроде в том, чтобы добавлять шум от окружения.
Игры с однокнопочным геймплеем могут цеплять, а могут и не цеплять. Самый впечатляющий пример игры, которая цепляет - пупырчатые пакеты, на которых можно лопать пупырышки. Можно попытаться взять игру с таким геймплеем, и попробовать сделать до состояния "цепляет". Игра в стиле "мышь бегает перед кошкой, кошка сшибает мышь лапой". 2D арт рисовать уже никто не умеет, поэтому нужно сделать модели, заанимировать, затекстурировать. Сделать звук. Написать некоторое количества кода, про такую игру. Сделать несколько итераций, пока не начнет цеплять.
Пусть у нас есть две игры, игра с 30 спартанцами и игра с 300 спартанцами. Разница между ними - в количестве. Оказывается, что для того, чтобы брюква была спелой, при подобном изменении масштабов количественные улучшения в техпроцессе не спасают, обязательны качественные. Там была всякая конкретика, я ничего уже не помню - не бейте пианиста, он играет как умеет...
Я тут написал какие-то запомнившиеся мне тезисы - но этот доклад надо слушать вживую. Боря потрясающе интересно рассказывает, мне даже немного стыдно, что дерзнул записать святое на бумаге. |
|
|
| КРИ 2008 - 2 |
[Apr. 23rd, 2008|09:06 pm] |
| [ | Tags | | | kri2008, tech | ] |
| [ | music |
| | Sirenia - The Fall Within | ] |
2. Программирование - открытый форум "Профилирование, оптимизация и производительность проекта" (день первый, 15:00, Сатурн)
Как и в прошлом году, форум был так себе.
3. Экспорт графических ресурсов для Next-Gen платформ (день второй, 10:00, Сатурн)
На свой доклад пришлось таки прийти ;-) Иначе в 10 утра ни за что бы не встал... Преклоняюсь перед теми, кто пришел! Надеюсь, было не слишком скучно.
Презентацию можно скачать здесь.
4. Оптимизация производительности DirectX10 Graphics (день второй, 13:00, Юпитер)
Доклад делал Чаз Бойд, это, вроде, мастермайнд DX10, ну и работает архитектором в Microsoft.
Почему-то на каждый второй слайд Чаз смотрел так, как будто видит его впервые в жизни, с выражением "что за фигня тут написана?". Ну и слайды пропускал.
Иначе рассказывал относительно обычные для DX10 вещи. Пожалуй, только две вещи в его презентации я еще не видел в других - 1. кеш стейт объектов (об этом я упоминал в блоге), 2. для constant buffers можно выделить по аналогии с выделением памяти набор CB размером 32 байта, набор размером в 64, etc., и при рендере брать наиболее подходящий по размеру, который использовался позже всего - либо тот, который уже заполняли этими же данными, если данные не поменялись и буфер не был использован кем-то еще.
Презентацию, которую он показывал, можно скачать вот здесь: D3D10 - Getting from 0 to 60 Hz (автор Kevin Gee - это все объясняет... в том смысле, что презентацию делал не Чаз, поэтому и путался так... небось действительно ее в первый раз на докладе увидел :)).
После доклада я попытался задать несколько конкретных вопросов - как именно работает UpdateSubresource (грубо говоря, кто менеджит память, в которую копируются данные для последующего DMA, в какой момент конверсии всякие, etc.), почему создание стейт блоков такое медленное, и почему в D3D10 нет DIPUP/DPUP. Относительно адекватный ответ получил только на последний - политика партия такова, что если можно что-то сделать без спец. функциональности, и не проиграть в производительности (сомнительно кстати, с user mode драйвером можно сделать очень эффективный immediate rendering, как показывает OpenGL), то это надо сделать. В общем, типичный Архитектор. |
|
|
| КРИ 2008 - 1 |
[Apr. 23rd, 2008|08:45 pm] |
Кратко про доклады, на которых я был. Я запросто мог наврать в деталях, потому что либо неправильно понял, либо уже что-то забыл, либо еще почему-то... :)
1. Визуализация дождя и большого числа повреждений сцены (decals) на примере шутера TimeShift (день первый, 13:00, Сатурн)
Про decals не было, было только про дождь. На уровне выбирается регулярная сетка в плоскости XZ (если Y - up), в каждой точке сетки кастится вертикальный луч.
Луч уперся в какой-то треугольник. В треугольник вписывается окружность. Запоминается: 1. позиция точки пересечения, 2. радиус окружности, 3. нормаль (? а может и не сохраняется). Это будем называть контрольной точкой (не помню оригинального названия).
В рантайме про дождь есть 5 основных эффектов: потоки воды; капли, стекающие по шлему глав. героя; мокрые поверхности; брызги-всплески на мостовой и прочей геометрии; струи дождя и капли в slow-mo.
Потоки воды - геометрия с текстурой и с UV scrolling.
Капли - кажется, несколько full screen квадов с UV scrolling.
Мокрые поверхности - специальный шейдер, конкретики не было.
Для брызг делается функция, зависящая от запомненных параметров (позиция, радиус) и времени, результат работы функции - точка внутри той самой окружности, и scale. Дальше в получившейся точке рисуется моделька всплеска с указанным скейлом. Скейл дополнительно уменьшается с удалением от камеры. Поскольку, зная время, можно однозначно восстановить картину брызг, то брызги генерируются каждый кадр заново.
Для дождя так же берутся контрольные точки вокруг камеры, для каждых двух, соседних по стороне (не по диагонали), берется максимум из высот точек пересечения, и рисуется квад, соединяющий вертикальные прямые, пущенные через две контрольные точки. Низ квада по высоте совпадает с максимумом двух высот. На квад натягивается спец. текстура, забейканная в Maya из какой-то модельки с капельками. Дождь так же генерится каждый кадр.
Текстура скроллится по вертикали. Есть два режима отображения - slow-mo капли и струи дождя, они отличаются только коэффициентами тайлинга у этой текстуры и тем, что в случае slowmo капли рисуются в общий distortion buffer, чтобы потом получить refraction-like эффект (капли, стекающие по шлему и прочее также рисуется в него).
Есть ряд проблем. Есть разные проблемы с тем, что сетка точек либо слишком разреженная, либо случайно скажем две соседние контрольные точки попадают в две дырки в крыше, и получается непонятно откуда взявшийся квад с дождем. Эти проблемы решались дополнительной collision геометрией. Также из-за багов в других местах пришлось сделать флаг на коллижен геометрию, который делал ее "прозрачной" для дождя.
Если игрок смотрит вверх, он видит регулярную сетку. Это решалось стягиванием верхних вершин ближайших квадов к камере, нижние оставались на месте. Получается, что квады вокруг игрока на самом деле не вертикальные, а наклонные. [не помню, стягивание view-dependent или нет]
Плавный переход между slowmo и обычным режимом сделан просто - в процессе перехода рисуются оба дождя, с плавным fadein одного и fadeout другого.
Дождь рисовался после всей прозрачной геометрии, поэтому сортировки никакой не было.
Данные дождя на уровень из public demo (как я понял) занимали, если не ошибаюсь, порядка 1.5 Mb, 10 байт на контрольную точку. Это статические данные о контрольных точках на весь уровень, без учета генерящейся геометрии.
Время разработки - 4 человекомесяца, 2 человека - художник и программист. Изначально художник прототипировал это в Maya. |
|
|
| Расчет глубины пикселя. |
[Aug. 26th, 2007|05:37 pm] |
В процессе оптимизации демки для PS3 выяснилось, что было бы неплохо оптимизировать шейдер для частиц. В вершинном шейдере происходит расчет позиций 4 вершин (частицы - билборд), а-ля point sprite, но размер указывается в world space, и частицы можно крутить. В пиксельном шейдере считается глубина, читается глубина из depth texture, и разница с коэффициентом используется как множитель к альфе.
( Выглядит шейдер так: )
crossposted to blog.gamedeff.com |
|
|
| PS3 - hands-on experience |
[Aug. 23rd, 2007|12:04 am] |
кликабельно
| Как прекрасно, когда новый runtime - lean & mean. Нагромождения стейтов превратились в удобные и быстрые state objects, дорогие по разным причинам установки шейдерных констант завернули в constant buffers. Потерь устройства нет, вся память - полностью виртуализирована. Depth-текстуры - поддерживаются официально. Если текстура скажем формата A8R8G8B8, то каждый компонент можно рассматривать как unsigned int, как fixed point, как signed int, etc. Ну и конечно - отлично, когда наконец-то есть возможность генерировать геометрию прямо на GPU! Не говоря уже о легализации хака R2VB.
( Read more... )
|
|
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/syndicated.gif){kind=small}
