Yep, it literally says that in the article

Amazing resource, thank you!

Amazing!

thanks :)

Very cool! Based on the video you're also doing some hierarchical subdivisions?

The hierarchical subdivision is done only at the rendering steps to reduce the number of polygons. A better rendering would be anyhow required, but I was more curious if the rest of the game would be fine with different and dynamic levels of water. The units seem to behave fine, but due to performance being rather poor I did not polish the code...

It's true that it makes it more complicated on the GPU side in general, but specifically in this scenario everything works out just fine, mostly because all updates effectively ping-pong between flow & water height buffers, and you never change both in the same kernel.

Interesting, thanks! Is it kinda like the Gibbs phenomenon?

Take a look at the other reply, which says it's actually not dispersion. My mistake!

Yeah I've seen it, no worries! :)

It's not as much about experience as it is about trade-offs. I've worked a lot with Vulkan and it's an incredible API, but when you're working alone and you don't have the goal of squeezing 250% performance out of your GPU on dozens of different GPU architectures, your performance becomes pretty much independent of a specific graphics API (unless your API doesn't support some stuff like multi-draw-indirect, etc).

See my answer to artemonster above.

I'm using WebGPU as a nice modern graphics API that is at the same time much more user-friendly and easier to use compared to e.g. Vulkan. I'm using a desktop implementation of WebGPU called wgpu, via it's C bindings called wgpu-native.

My browser doesn't support WebGPU properly yet, so I don't really care about running this thing in browser.

That's a fascinating approach.

And it gets me a bit sad about the state of WebGPU, however hopefully that'll be resolved soon... I also on Linux am impatiently waiting for WebGPU to be supported on my browser.

> It's a mega-kernel, so you'll get poor occupancy past the first bounce

Sure! If you look into the to-do list, there's a "wavefront path tracer" entry :)

> new origin should be along the reflected ray

I've found that doing it the way I'm doing it works better for preventing self-intersections. Might be worth investigating, though.

It probably works better when the reflected ray is almost tangent to the surface. But that should be an epsilon case.