Dearest community,
First, a playground: https://playground.babylonjs.com/#2X0QTL#3 with a flycamera QWEASD
I am trying to implement something similar to the ROAM algorithm on an icosphere. First in a pure-js version (the one from the playground); the goal with this initial version would be to get the quality right. Then, once quality is ok, implement the algorithms in a little wasm using rust. Which hopefully will be faster although frankly I am not 100% convinced it will be.
About quality: obviously many things are wrong, most notably the cracks between subdivided and non subdivided triangles.
My approach has so far be very naive (including the noise implementation, the absence of neighbour tracking, no cleaning up unused vertices, etc). Any thoughts on improvements? Is this approach completely wrong?
Many thanks!
NB/edit: people who know of this will find it obvious why I am trying to come up with something like this 
2 Likes
Just wanted to say that this is a neat demo!! I also went to play around with your procedural galaxy app-- it’s SO stunning.
This is the first I’ve heard of ROAM, so I can’t offer much implementation advice. Have you already considered using WebGPU and compute shaders (along with something like this)? Is it possible to use them in the first place?
1 Like
Thanks!
If you have used the 3D explorer of one of the galaxies, and you got close enough: 1) to a star 2) to one of its planetary satellites, then it will become evident that such a dynamic LOD would be extremely useful for me
It is only a first step, though, as each vertex then needs to be mapped to a more clever procedural bit to generate nicer surfaces
and no I havent yet considered compute shaders. any feeling as to the kind of performance it might offer against pure js and/or wasm?
1 Like
Yes, when I was playing with the 3D explorer, I saw the potential with the icospheres right away Will be very cool!
The compute shaders should outperform both WASM and especially pure JS. But you might hit some issues if you send the new vertex data from the GPU back to the CPU… just to send it back to the GPU for rendering. Lol. The thread I linked in my original comment indicates there’s a way to avoid this, though.
Of course, compute shaders are WebGPU-only, so you’ll probably want to provide some fallback JS or WASM version for clients to use if they’re on a browser that doesn’t support WebGPU.(Forewarning: I am not read up on what it takes to support WebGPU and WebGL in the same app, so it might be way trickier than that.)
I think it’d be worth a shot! Or a fun challenge, at least.
1 Like
I see… well maybe I shall try compute shaders. however, how easy would it be to enrich them with procedural logic (which should not be too hard to do in rust/wasm, for example).
The one drawback I see to both wasm and compute shaders is the nearly constant going to and fro between js and the “other, faster world”. It would indeed be interesting to see how both “faster” solutions compare.
One thing though - I have tried to activate webgpu on the 3d explorer, to no avail and with weird errors. But that is for the “other thread” I think, not this one