Лекция #15. Тени - tips & tricks. [Лектор - Семен] (5 стр)

Автор: Арсений Капулкин

[20:18] <CEMEH> Другой подход к этому у Д. Кармака.
[20:19] <CEMEH> Кармак фантазирует о так называемых shadow mips.
[20:19] <CEMEH> Это когда следующий уровень shadow map в два раза больше предыдущего по площади в мире и включает предыдущий.
[20:19] <CEMEH> Мечта в том, чтобы срендерять их как mip-уровни shadow map, и чтобы железо выбрало, сравнило и отфильтровало их само.
[20:20] <CEMEH> Механизмами, во многом похожими на обычные mip-уровни
[20:20] <CEMEH> В железе этого нигде нет. Но вдруг Кармака послушают.
[20:20] <CEMEH> И наконец подход, который кажется самым практичным...
[20:20] <CEMEH> Сделать одну текстуру, разделить ее на N частей.
[20:21] <CEMEH> В эти N частей среднерять такие расширяющиеся (каскадные, отсюда название) shadow map, и выбрать между ними через dependent read в pixel shader.
[20:22] <CEMEH> Отмечу, что эти куски тоже могут быть (и должны быть) перспективными.
[20:22] <CEMEH> Сразу становится много возможностей по выбору качества, и даже ужасный dual frustrum таким ужасным не выглядит.

[20:23] <CEMEH> [23:20] <Zeux> Какие-нибудь пейпры есть по данному методу?
[20:23] <CEMEH> А вот нету :)
[20:23] <CEMEH> Все говорят о Cascaded Shadow Maps, а пейперов толком и нет.
[20:23] <CEMEH> Только старые про Adaptive Shadow Maps
[20:23] <CEMEH> Однако, мужики из Futuremark уже уверенно говорят, что мол у них в новом 3dmark Cascaded SM

[20:24] <CEMEH> [23:21] <_VirT_> Идея в том, чтобы ближние объекты запихать в одну тукстуру, дальние в другие?
[20:24] <CEMEH> Да :)

[20:24] <CEMEH> [23:22] <ZFail> новый это уже выпущенный?
[20:24] <CEMEH> Угу

[20:25] <CEMEH> Значит, у меня остался последний пункт - это те же content creation tips.
[20:26] <CEMEH> Про флаги уже не говорю, они обязательны.
[20:26] <CEMEH> Точно также можно дать в руки яркость на ресиверах, и нельзя - на кастерах.
[20:26] <CEMEH> Но вот тут хочу остановиться на возможности убирать самозатенение как на важном инструменте.
[20:27] <CEMEH> Если дизайнеры могут убирать самозатенение на объекте - то это сразу помогает бороть алиасинг.
[20:27] <CEMEH> Т.е. мы убираем неприятные некрасивые тени, и оставляем красивые.
[20:27] <CEMEH> И инструмент - в руках у моделлера.
[20:27] <CEMEH> Кроме того, если убрали самозатенение, можно и упрощать теневую геометрию опять же.
[20:28] <CEMEH> Надо делать это выборочно, понятное дело.
[20:28] <CEMEH> По shadow map у меня все :)

[20:29] <ZFail> что-то непонял как убирать самозатенение
[20:29] <CEMEH> ZFail, знаешь про индексные тени?
[20:29] <ZFail> да, понял

[20:29] <_VirT_> Итак, каков вердикт? Что в конечном варианте лучше всего использовать? На твое усмотрение.
[20:29] <CEMEH> Вердикт будет позже.
[20:30] <CEMEH> Про shadow map - если PSM работает, хорошо. Cascaded тяжелее, но контролируемее.
[20:30] <_NexiliaN_> ну cascade это уже скорее чистый кодинг
[20:31] <CEMEH> _NexiliaN_, там гораздо больше раздумий в красивой реализации полного шейдинга.
[20:31] <CEMEH> Распределять объекты по фруструмам, генерить объекты так, чтобы можно было их маленький кусок рендерять и т.д.

[20:31] <_VirT_> А еще такое. Можно заранее делать расчет карты для статичных источников света и статичной геометрии. Такое применяется?
[20:32] <CEMEH> Редко. Народу жалко текстур. Чаще комбинируют с лайтмапами, чем такое.
[20:33] <_VirT_> так можно хорошо делать тени на персонажах от статики.
[20:33] <CEMEH> _VirT_, обычно легче таки рендерять в персональную shadow map персонажа геометрию.
[20:34] <CEMEH> Обычно это легче, чем хранить много текстур с предрассчитаными sm на диске.
[20:34] <CEMEH> В реалтайме их генерить уже веселее. Это было в трике выше.
[20:34] <_VirT_> почему много? для одного источника 1 текстура.
[20:34] <CEMEH> Ну она большого разрешения.
[20:34] <CEMEH> И текстура на источник - уже достаточно много.
[20:35] <CEMEH> Детальный shadow map - он типично большой.
[20:35] <CEMEH> Начинаются с 512x512, и 1024x1024 - не редкость.
[20:35] <CEMEH> А бывает больше.
[20:35] <_VirT_> ладно. соглашусь с опытом :)

[20:32] <_NexiliaN_> кстати а динамические лайтмапы уже в играх были?
[20:33] <cppguru> что такое динамические лайтмэпы? это как у фрустума?
[20:33] <CEMEH> Были такие, в которые рендерят по ходу жизни.
[20:33] <_NexiliaN_> только врадли это уже будут lightmap's )
[20:33] <_NexiliaN_> скорее attmaps )

[20:35] <CEMEH> Так, 5 минут перерыв и PRT.
[20:42] <CEMEH> Значит, основная ссылка по PRT это хом-пейдж главного энтузиаста.
[20:43] <CEMEH> Peter-Pike Sloan, из MS Research
[20:43] <CEMEH> Именно благодаря ему мы имеем PRT в D3DX.
[20:43] <CEMEH> Или он нас.
[20:43] <CEMEH> http://research.microsoft.com/~ppsloan/
[20:44] <CEMEH> Общая идея PRT - в том, чтобы отрендерять сцену со всеми эффектами (тени, ambient occlusion, environment lighting и т.д.) в постпроцессе для всех положени дирекшнал-источника на сфере
[20:44] <CEMEH> И результирующую функцию освещения в точке разложить по сферическим гармоникам.
[20:45] <CEMEH> Сферические гармоники - это такие функции на сфере, которые представляют собой удобный базис
[20:45] <CEMEH> Они все ортогнальны в смысле скалярного произведения (оно для них интеграл по сфере от произведения)
[20:45] <CEMEH> И чем дальше уровень гармоники, тем они высокочастотнее.
[20:45] <CEMEH> Т.е. если мы возьмем меньше коэффициентов, мы получим более размытую картинку и все
[20:45] <CEMEH> [23:42] <cppguru> каковы вообще возможности PRT?
[20:46] <CEMEH> Ну общая идея на пальцах такая.
[20:46] <CEMEH> Долго-долго дрочим над объектом в препроцессе, а потом в реалтайме суммированием ряда с коэффициентами умеем осветить его с любого направления.
[20:46] <CEMEH> Ты это хотел услышать?
[20:47] <CEMEH> Значит, эти сферические гармоники в общем случае выглядят примерно так - sin^n*P(cos)
[20:47] <CEMEH> P() - полиномы
[20:47] <CEMEH> [23:44] <_VirT_> это если источник как-бы вне объекта?
[20:47] <CEMEH> Да, в оригинале - только для directional-источников.
[20:48] <CEMEH> Можно думать об этом как о динамических лайтмапах, которые очень размытые и считаются per-vertex
[20:48] <CEMEH> Чем более четкими их хотим сделать - тем больше членов гармонического ряда надо учитывать.
[20:49] <CEMEH> Для вершины хранится набор коэффициентов, и они умножаются на функции гармоник в vertex shader.
[20:49] <CEMEH> Это классическая реализация, которая в D3DX.
[20:49] <CEMEH> Значит, чем она мне не нравится.
[20:49] <CEMEH> Как и другие алгоритмы в D3DX, скажем, Progressive Mesh
[20:49] <CEMEH> Жесткостью реализации.
[20:50] <CEMEH> В таких вещах типично есть миллионы трюков, и я постоянно выбираю и модифицирубю.
[20:50] <CEMEH> Представьте себе shadow mapping в D3DX? :)
[20:50] <CEMEH> Т.е. плоха не сама реализация. Я этому Peter-Pike более-менее верю.
[20:50] <CEMEH> Плоха ее жесткость.
[20:50] <CEMEH> PRT - очень динамичная область.

[20:52] <CEMEH> [23:49] <dotprod> ок, как я понял PRT на сферических гормониках хорошо подходят для создания ambient эффектов
[20:52] <CEMEH> В некотором смысле да, это размытые такие освещения.
[20:52] <CEMEH> Но они зависят от направления, и в этом плюс.
[20:52] <CEMEH> Они не делают четких теней, да.
[20:52] <CEMEH> Методики для четких - лучше классические. И "разное".

[20:52] <CEMEH> [23:50] <ZFail> если ПРТ пер верекс, то как там осветится большая плоскость? тень на ней будет от объектов
[20:53] <CEMEH> Надо тессилировать плоскость, чтобы получать вменяемую картину.

[20:53] <CEMEH> [23:50] <_VirT_> что с прозрачностью?
[20:53] <CEMEH> Ортогональные концепции. Никак друг на друга не завязаны.

[20:54] <CEMEH> Значит, тени от PRT для десятка-другого гармоник уже достаточно четкие.

[20:54] <CEMEH> [23:52] <dotprod> эх, PRT подходит для чисто статических сцен. интересно какой получается оверхед по данным для сцен средней сложности?
[20:55] <CEMEH> Ну вот представь, что в вершине хранится 10 лишних флоатов, и ты тратишь несколько десятков инструкций vertex shader.
[20:55] <CEMEH> Терпимо, на самом деле. Со скрипом.

[20:55] <CEMEH> [23:52] <_VirT_> получается какая-то карта для каждого объекта?
[20:55] <CEMEH> Да, карта коэффициентов гармоник для каждой точки.

[20:56] <CEMEH> Да, важный момент - очень большая проблема в том, что PRT только для статических сцен.
[20:56] <CEMEH> Чтобы два объекта стали затенять друг друга, надо их слить в один, и т.е. связать намертво.
[20:56] <CEMEH> Если посмотреть на статьи, то там идет прогресс в сторону dynamic PRT.
[20:57] <CEMEH> Т.е дополнительные коэффициенты, чтобы описывать некие деформации объектов.
[20:57] <CEMEH> Но это все далеко от глобальных теневых взаимодействий.
[20:58] <CEMEH> Ладно, и типс & трикс.
[20:58] <CEMEH> 1) PRT можно считать per-pixel. Это не так страшно, как кажется.
[20:58] <CEMEH> И получается качественный скачок.
[20:58] <CEMEH> Нужно использовать лукап-текстуры для гармоник и т.д.
[20:58] <CEMEH> Пейперов не знаю :(
[20:59] <CEMEH> 2) PRT может быть не 2D, а 1D.
[20:59] <CEMEH> Скажем, солнышко ходит, как известно, по кругу.
[20:59] <CEMEH> Всего один угол. Это позволяет резко увеличить точность.
[20:59] <CEMEH> Т.е. всю статику от такого солнышка можно и посчитать.
[20:59] <CEMEH> С более-менее приемлемой четкостью теней.
[21:00] <CEMEH> Да еще и env lighting в нагрузку.

21 февраля 2006

Комментарии [2]