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, то советую сразу думать о чисто диффузном освещении, потому что оно гораздо сложнее, чем чисто зеркальное, а в жизни встречается гораздо чаще.
Тема в архиве.