Рендеринг воды (3 стр)

Misanthrope
> в Nvidia SDK есть демка
Мне эта демка упорно напоминает какие-то конкурсные поделки с uraldev за 2006-й год. Ну в плане качества визуализации.
IBets
> Я такое кидал сюда
Там в аннотации написано, что демке надо два титана для правильной работы.

g-cont
Так они в NVIDIA наверняка ушли)). На самом деле этот FFP очень старый чуть ли не 2001 года

g-cont
> конкурсные поделки с uraldev за 2006-й год
там не было тесселяции, не надо ля-ля))

IBets
я такую делал 120fps на иксбоксе:

для начала рекомендую определиться, что именно тебе нужно: рендерить поверхность открытого океана, пену прибоя, считать гидродинамику или рендерить level set.

Suslik
Крутое качество. Для начала поверхность открытого

IBets
> Крутое качество. Для начала поверхность открытого
открытый океан гораздо проще рендерить, чем всё остальное. рекомендую взять ту демку с шейдертоя и, просто варьируя параметры в ней, разобраться, как она работает. основная идея в том, что вся поверхность генерится как несколько гармоник, которые плывут в разные стороны с разной частотой и скоростью. сами гармоники могут быть по сути вообще чем угодно, хоть шумом перлина, хоть текстурой. в том примере с шейдертоя каждая гармоника считается жутко медленно и если просто запечь их в текстуру, то производительность возрастёт раза в 2. у них используется не самый оптимальный raymarching для поиска пересечения луча с поверхностью — гораздо оптимальнее делать сначала грубый поиск по квадратичным шагам, а потом — уточнять методом хорд или бинарным поиском. ещё производительность, считай, в 2 раза выше без потери точности. с производительностью ещё можно делать кучу хаков, так как весь алгоритм исключительно ALU-bound. например, если рендерить воду в 1/2 разрешения, то она рендерится в 4 раза быстрее, потому что рендеришь в 4 раза меньше пикселей, а разница из-за особенностей поверхности не особо заметна.

а рендеринг пены или гидродинамика идут вовсе не после "для начала", это — просто совершенно отдельные темы, особо не связанные.

Suslik у тебя там три аля-слоя воды. То есть ты разбил рендер сложной воды на части.
И можно гибко управлять каждой частью , что бы получить реалистичную воду на берегу.
Это гребни волны.
Пена на берег.
И пена уходящая обратно в воду.

Suslik
> а рендеринг пены или гидродинамика идут вовсе не после "для начала", это —
> просто совершенно отдельные темы, особо не связанные.

Да, пена совершенно иначе делается, я толком и не разобрался как ее связать с динамикой воды, потому привязал к высоте)

IBets
Тебе нужно сначала один раз написать, чтобы понять суть, а потом уже оптимизировать.

Suslik
Ты же вот за Screen Space GI двигаешь. Возникла такая идея. Ограничения задачи. Один направленный источник света.
Имеем

Такой алгоритм:
Освещеннось пикселя узнаем по ShadowMap

если пиксель освещен запускаем луч  reflect(viewDir, worldNormal) ищем пересечение с геометрией при пересечении устанавливаем данному пикселю цвет пикселя с которого расcчитали viewDir(SSR  только закрашивается пиксель наоборот) из Diffuse map ну там mix какой-нибудь
если пиксель в тени  запускаем луч от пикселя в направление источника света(предварительно надо провернуть иначе толка нет пока не знаю каким образом но вероятно в зависимоти от viewDir) и тот же алгоритм как в первом случае

IBets
> если пиксель освещен запускаем луч  reflect(viewDir, worldNormal) ищем
> пересечение с геометрией при пересечении устанавливаем данному пикселю цвет
> пикселя с которого расcчитали viewDir(SSR  только закрашивается пиксель
> наоборот)
ты пытаешься изобрести photon splatting. это очень медленно сходится для диффузного освещения. вообще если думаешь о GI, то советую сразу думать о чисто диффузном освещении, потому что оно гораздо сложнее, чем чисто зеркальное, а в жизни встречается гораздо чаще.