Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGL + Rust: Basic Water Tutorial

chinedufn.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: WebGL + Rust: Basic Water Tutorial

#11

Post by milancurcic »

spullara wrote: post #10

It doesn't look like water to me. This looks a lot more like water: http://madebyevan.com/webgl-water/

Because it's not solving for the water surface elevation and velocity, only for light reflection and refraction from a pre-set surface.

> The way that the water appear to move comes from slightly altering the point on the refraction and reflection textures that we sample from every frame. > > These slight offsets comes from sampling a du/dv map, which is just a texture that encodes different x and y offsets.

The app in the link you posted does indeed look like it's solving at least a shallow water system of equations, and looks very excited to me as a wave physicist.

Re: WebGL + Rust: Basic Water Tutorial

#12

Post by chinedufn »

spullara wrote: post #10

It doesn't look like water to me. This looks a lot more like water: http://madebyevan.com/webgl-water/

Totally agree that there's room to look more water-y (depending on your application's needs).

One thing that can be done is playing around with the numbers / uniforms in the fragment shader to change the look. For many use cases you can get pretty far with that without actually changing the implementation in this demo.

If a more physically based level of realism is needed (like the water ripples on click in the demo that you linked) you can use techniques like height simulation based on a wave equation [1].

You'll of course need to balance realism with realtime feasibility - but often times getting a much better look comes down to tweaking some numbers until things look good!

[1] - https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch01.ht...

Re: WebGL + Rust: Basic Water Tutorial

#17

Post by ridiculous_fish »

Question about code like this:

    fn render_reflection_fbo(
        &mut self,
        gl: &WebGlRenderingContext,
        state: &State,
        assets: &Assets,
    ) {
        gl.bind_framebuffer(...);
        gl.viewport(...);

        gl.clear_color(...);
        gl.clear(...);
Setting the viewport and clear color sure look to be mutating, but they are being called on a shared reference (&WebGlRenderingContext).

Why is it designed this way? Is this design considered sound, or is it a hack?

Re: WebGL + Rust: Basic Water Tutorial

#18

Post by chinedufn »

ridiculous_fish wrote: post #17

Question about code like this: fn render_reflection_fbo( &mut self, gl: &WebGlRenderingContext, state: &State, assets: &Assets, ) { gl.bind_framebuffer(...); gl.viewport(...); gl.clear_color(...); gl.clear(...); Setting the viewport and clear color sure look to be mutating, but they are being called on a shared reference (&WebGlRenderingContext). Why is it designed this way? Is this design considered sound, or is it…

Glad you asked!

There's a recent issue [1] in the wasm-bindgen repo that explains this, but essentially:

- In this demo the WebGLRenderingContext was created on the Rust side (technically by calling a light JS shim), but it could've just as well have been passed in from JS.

- This means that JS could very easily have had access to the WebGLRenderingContext.

- This means that we cannot guarantee that it is immutable. Who is to say that there isn't a line of JS `gl.mutated! = true;` that we don't know about? We have no guarantees that whoever instantiated this WebAssembly module isn't doing something funky.

- So we treat most DOM / JS APIs as if they have interior mutability, so more or less you can think of them as `RefCell`'s [2]

---

As an aside. When you work with WebGL you're just making calls to the GPU and your state on the GPU gets mutated. The object just controls state (WebGlRenderingContext) does not get mutated (aside from maybe a couple things that I'm forgetting..?).

As in.. `gl.viewport` doesn't actually mutate `gl`. But again.. just a small aside!

In general the idea here is that we can't guarantee that there is only one mutable reference so there is no point in calling these things `&mut`, even for things that really do mutate.

---

So yup! Interior mutability without runtime checks for many of the APIs is "the right way" in today's idiomatic Rust + WASM + DOM access since you can't guarantee that there isn't foul play going on from whoever instantiated the module.

---

Does this cause issues? It hasn't (noticeably) for me yet but I'm only a couple months into using `web_sys` so I haven't worked with every single DOM API.. so grain of salt!

[1] - https://github.com/rustwasm/wasm-bindgen/issues/1061

[2] - https://doc.rust-lang.org/std/cell/struct.RefCell.html

Re: WebGL + Rust: Basic Water Tutorial

#19

Post by swaggyBoatswain »

spullara wrote: post #10

It doesn't look like water to me. This looks a lot more like water: http://madebyevan.com/webgl-water/

Related note, the creator of that also made figma, which is a webgl + rust + webassembly application for UX design (similar to apple sketch)

Re: WebGL + Rust: Basic Water Tutorial

#20

Post by azakai »

swaggyBoatswain wrote: post #19
spullara wrote: post #10

It doesn't look like water to me. This looks a lot more like water: http://madebyevan.com/webgl-water/

Related note, the creator of that also made figma, which is a webgl + rust + webassembly application for UX design (similar to apple sketch)

I believe Figma is C++ + WebGL + WebAssembly on the client, and Rust (and probably others) on the server.

https://www.figma.com/blog/building-a-professional-design-to...

https://www.figma.com/blog/rust-in-production-at-figma/

Post reply on HN