Terrestrial planet surface real-time render progress

Well well well since I had started working on atmospheric effects and volumetric clouds I got naturally sucked in back into procedural surfaces. The tools and experiments page has been deactivated for quite a while (and still is), so yet another case of I could not help myself.

First some visuals

That being said, I think progress is actually nice but judge for yourselves.

Then a few brief explanations

First, this tool not will be made available from the 3d explorer just yet. The reasons are technical and worker-related (see below). However, it will be made reachable from the details modals/pop-ins for satellites and subsatellites:

All videos start with one visible underlying data bit: the assigned tectonic plates. This is interesting as it show how an extremely coarse data set can end up with reasonably smooth transitions between colours, elevations and overall terrain nature & feel.

Compounds and colours

The main improvement in this version is that the renderer now takes the crust's chemical composition into account. The colours shown in the videos are therefore fully procedural and data-driven, rather than hand-painted or manually assigned. For now, these are still crust-only colours: atmospheric composition, scattering and cloud effects are not yet merged into the surface pass.

I am particularly happy about this because it is the very first step towards the visual manifestation of all the work previously done on procedural generation.

3D explorer integration

Briefly going back to the 3D explorer, here's how it is probably going to work:

1. Proximity triggers the server push of surface-related data over websocket.
2. The data travels through workers and ends up at the offscreen renderer worker
3. At this stage, it is likely that the renderer worker will spawn a worker dedicated to the planetary surface. Actually potentially one worker per, in the case of subsatellites. Now this may exceed the number of cores on many machines, but distant surfaces are calculated so quickly per frame that it should not matter that much. Gotta love LOD (see image below).
4. Another solution could be to have one worker dedicated to the one being close, and one worker to all the others.
5. How the renderer worker accesses the mesh/colours/etc is another problem: either by message passing or via shared ArrayBuffers. I am leaning towards the latter at the moment but we'll see…

On a i9 14900HX this is how long a low-LOD surface takes to be fully rendered. Now arguably this is a powerful CPU but this is not representative of all machines - yet it gives a useful upper-bound sanity check:

Code upgrade and caching

I will also have to get around and upgrade the code from using generational-arena to slotmap, especially its dense version which hopefully will reduce cache misses even further, improve memory locality and reduce cache pressure.

Slot map does also seem to have less memory overhead than generational-arena, which is always a win given how small caches are.

Qui trop embrasse…

Yeah yeah I know, I got asked questions about when the units/volumes would come online. The truth is that there are several work streams I have to try and take care of in parallel:

• Units, modules, entities.
• "Stand-alone" planetary crusts renderer
• Atmospheric volumetric effects
• Crust/atmosphere rendering merge
• Then integration in the 3D explorer

Comme dirait l'autre once more, on est pas rendus! 8-}