Planetary surfaces - In progress and todos

This post is to briefly talk about several items that are either in progress or on my to-do list (more or less distant and/or feasible). Collectively, they embody the consequence of making procedural planetary surfaces be "not fully random", i.e., be at least partially determistic and starting from the physical characteristics of a telluric planet. The task at hand is very interesting and I am trying to make it as good as I can. This list includes:

• Overall intensity tectonic activity of the crust: is the crust a raging fiery inferno or is it dead as a dodo?
• Procedural elevation determined of course by simplified tectonic plate movement, but also at least partially from their "chemical composition" and state (solid, liquid, etc.)
• Climate generation and its impact (if any!) of the crust.
• Craters. Lots of craters. Big rock big boom.
• Texturing and colours: I know it's been a long time coming and I've already mentioned it several times, but this comes last, once the "data layer" feels good. Eye candy last.
• … all the while thinking about platenary resource heatmaps - I will probably make a separate post about this.

Most of this data is already available in the data explorer and the 3D explorer, when you request the details of a planet or satellite. Clicky clicky.

The great approximation

In the first post of this series, I started touching on how elevations (mostly that, to be honest) were generated. I introduced the use of several (more or less) noisy fields across the surface of the sphere, and so on.

With a budget of 16ms, there isn't time to accurately simulate stuff. So part of the exercice is to come up with semi-realistic characteristics or aggregate of characteristics for vertices - ones that are good enough to approximate real phenomena. Sometimes this approximation is very rough - but --always-- the naming of variables/properties can sometimes take a while :-P

The Age of the vertex

…and so the first one I identified was the age of a vertex. By that is meant: given any arbitrary point at the surface of the sphere, what is its geological age? How long has it been around at the surface of the planet, affected by processes including tectonic ones but also including others, before being lost to the mantle again?

It is arguably a fuzzy definition, but one I find useful enough to open opportunities on fronts such as:

• Erosion: obvious!
• Recency of tectonic processes
• and probably others that I haven't though about just yet :-)

But we have a problem, since vertices are not neighbour aware. The reason for this is performance, as neighbour awareness is expensive. The only exception to this rule applied to vertices is to eliminate cracks between triangles of a different subdivision level: a vertex has to know which edge it is the midpoint of, and which vertices are its "parents" i.e., which vertices form the edge it is the midpoint of.

Another problem is that plates lack any real definition; they have no borders or boundaries. In fact, their existence is solely manifested by the very vertices they mathematically (and randomly) take over as their own. What is indeed known about plates, however, is the following:

1. their surface fraction of the global sphere;
2. their rotation axis around the sphere;
3. their angular speed.

And with these three properties, it is then possible to approximate how long it takes for a vertex belonging to the plate to travel across it. Mix and match with a dot product, the vertex boundary score, and you get an age gradient across the virtual plate that can be used to calculate the age of vertices that belong to it. The approximation is wrong since it assumes the following:

The current dev version is being tested for this addition to vertices. Let's see how just wrong this is 8-}

The great denormalisation

As of writing this, the Tool & Experiments page lists a planetary surface tool version that makes very, very heavy use of normalised data or scores. This means almost all internal values are expressed over ranges of [0,1] or [-1,1]. Compression, for example, was/is expressed over a range of [-1,1].

And while this is very convenient and, to some degree, satisfying (probably fast as well)… this becomes a source of confusion and scale issues once the completely denormalised data from a planetary composition comes into play. See this abbreviated mineral compound composition, for example:

As one can see, even though some of these values are normalised, they become hardly usable in conjunction with a plate's mass in kg, its density or its "thickness".
As a consequence, I have (almost) reluctantly started to move away from 100% normalised values and started introducing actual (albeit wrong) physical values - SI units are now the rule to express phenomena, scale or characteristics such as: mass (kg), height (m), velocity/speed (m/s), duration (s), pressure/compressive and tensile strength (Pa), and others.

Django model consequences

The consequence of this is that I now need to update a specific Django model: Compound. Yes, this is one of the models used to literally print rust files as once_cell::sync::Lazy structures.

The extra fields are not much of a problem in themselves; however, more work is required to obtain the right values for each compound, and I have 308 of them.

In terms of usage, they will most likely be used to determine macro geological consequences that will emerge as a result of tectonic activity at a given vertex, and against that vertex "composition" in terms of compounds. Although the calculations are absolutely not accurate or even correct in scientific terms, my hope is that they can be used for effects such as: elevation can be stronger than expected; cracks and opens into chasms, etc.

This is on top of other characteristics such as melting and vaporisation points; arguably not always useful, but nice in the case of, say, a telluric planet unfortunate enough to be a mere few million kilometres away from a Type-O or Type-A star. The crust could end up being white hot because of the star luminosity, with almost everything melting - including metals. Iron rain, anyone? Climates based around titanium oxide storms? :-P A bit far-fetched, and I honestly do not know if I can "model" that, but I will definitely try!

Crust composition changes

At the moment, a crust's mineral composition is generated from a randomly picked template, and the individual values determined by base ppms plus some seeded variability. That works well enough, but I have a problem: at the moment, those templates completely ignore atmospheres and their sometimes powerful effects on planetary surfaces.

How does this manifest? Well, as aberrations such as:

• Sedimentary minerals at the surface of planets completely devoid of atmosphere. Now there is a trick, as the planet in question may have started with an atmosphere dense and active enough to have had an effect in the past (such as on Mars?). And so sedimentary minerals could be found now in spite of an extremly thinned atmosphere (due to stellar winds or other)
• In a similar fashion, igneous minerals can be found on planets that are tectonically dead. Again, the activity may have stopped more or less distantly in the past, but still.

Long story short, I will review: 1) crust composition to incorporate these factors 2) start creating more varied crust templates, in order to, I hope, get more "realistic" and above all, fun, interesting and challenging crusts!

Climate generation

As may be guessed, this is a big one.

1. For starts, I only have a few faint ideas of where and how to begin, centered around coriolis effects, temperature gradients versus latitude/axial tilt/rotation speed/flux.
2. For seconds, an atmosphere should be considered as having a direct effect on the crust it quite literally envelops: erosion, mineral deposits, elevation changes, glaciation and so on.
3. But a crust can also have an impact on its sibling atmosphere, via outgasing and the like. How much outgasing occurs probably depends on the overall tectonic intensity (volcanism, etc.) and should have a direct effect on the atmopheric composition.

All in all, we are talking about very thight interconnection between two entities that are initially generated separately. Even though this is all very fuzzy at the moment, this is how I think the steps will go (some king of a cyclic computation):

1. Generate crust
2. Generate atmopshere
3. Compute the effect of atmosphere on crust
4. Compute the effect of crust on atmosphere

And then redo 3. and 4. until some sort of equilibrium/convergence is reached. We'll see.

Craters

Of course those should exist. We can see them on the Moon, on Earth itself or even on various moons around the solar system. Plus, they look nice. Hopefully I can make them look nice too! :-)

Several tentative thoughts about crater generation:

• A stellar system should have 1+ "crater epochs". Earth itself was bombarded at various intensities throughout its history: during the Hadean, Archean, Devonian or, much closer to us, the Cretaceous-Paleogene era. Even though none of this is 100% certain, it helps ideas being born nonetheless.
• Each crater epoch gets an intensity (probably overall going down as time passes, to simulate a nascent system's chaotic nature)
• The impact (haha) on a crust can then roughly be evaluated as follows:
  1. apply each epoch's intensity as separate layers
  2. weigh impact strength versus age
  3. derive diameter, elevation change remains, etc. at impact's location

Each impact location could be determined by using various noise fields, combined to reach a certain threshold. Also, depending on the overall LOD applied to the view, smaller craters can be computed on the fly. So viewing a planet from a great distance would only trigger the computation of large craters and getting closer would gradually generate smaller ones. For some crusts, though, this process would be useless, as tectotic activity does have the tendency to erase proof of impact from the surface of a planet. Very efficient, if slow, recycling. :-)

Colours and texturing

Not really in the works yet, as a heavy dependency stands guard: I would like the colour at a given vertex to reflect the mineral composition of that vertex, plus or minus atmospheric effects such as glaciation or liquids.

The major dependency is then: determine the composition+effects at the vertex. I intend to try and do it as follows:

1. Determine local tectonic plate composition (by comparing/matching some of the vertex's characteristics versus other factors such as boundary score, age, compression, climate, etc). This results in N minerals expressed as both absolute quantities (from resource extraction, server-side) but also relative (with sum = 1.0) for client-side rendering.
2. Combine the colours of each mineral to get a nice RGB value
3. Voilà!

In principle, these are simple steps, but they require a lot of work in themselves and that dependency of vertex mineral composition (and/or atmospheric deposits) isn't quite there yet…

Some constraints

My dev setup is somewhat bizarre and/or unusual(?)…: I run a virtualbox on Windows 11, with shared folders so I can work from the Windows host (editors and the like), all the while having code available from within the linux guest. Main goal: the guest is pretty much a replica of the live machine, moins the hardening, etc.

It works fine.

However

It seems some rust crates have some issues compiling when the target is on a mount that is of type vboxsf. Said crates will simply not compile. Creating a quick and dirty project under /tmp and compiling exclusively from there (so all within a standard linux file system) works perfectly.
This is currently slowing down my ability to refactor some code and make it common to the client and server rust features. Hopefully I can find a solution… or be given one! :-) Wait & see.

And that's it for this post

Hopefully I managed to highlight the nice and interesting improvements I am working and planning to work on! I will endeavour to post more details about some of the subjects mentioned above… when the time comes. Thank you for reading!