Войти
ПрограммированиеФорумГрафика

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

Страницы: 1 2 3
#30
15:19, 25 июня 2018

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


#31
15:25, 25 июня 2018

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

#32
16:11, 25 июня 2018

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

#33
17:11, 25 июня 2018

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

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

#34
17:14, 25 июня 2018

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

#35
17:25, 25 июня 2018

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

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

#36
17:33, 25 июня 2018

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

#37
18:02, 25 июня 2018

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

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

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

#38
19:15, 25 июня 2018

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

  • Shadow map источника света,
  • Diffuse map                                      screen space
  • Normal map(мировые координаты)  screen space
  • Z-Buffer                                          screen space

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

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

    #39
    4:19, 26 июня 2018

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

    Страницы: 1 2 3
    ПрограммированиеФорумГрафика

    Тема в архиве.