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

x-posted from zeux.livejournal.com

Кратко про доклады, на которых я был. Я запросто мог наврать в деталях, потому что либо неправильно понял, либо уже что-то забыл, либо еще почему-то… :)

1. Визуализация дождя и большого числа повреждений сцены (decals) на примере шутера TimeShift
2. Программирование – открытый форум “Профилирование, оптимизация и производительность проекта”
3. Экспорт графических ресурсов для Next-Gen платформ
4. Оптимизация производительности DirectX10 Graphics

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.

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), то это надо сделать. В общем, типичный Архитектор.