3D explorer improvements

Very quick one: as I mentioned at the end of this post, I was not fully statisfied with the client-side performance of the sole SolidParticleSystem - the one that "held" the sytems' particles.

Looks like this is fixed -or at least improved- and here's how.

Previous SolidParticleSystem

The previous system SPS was unique, in the sense that it held the systems visual definition both at LOD_SYSTEM and LOD_STAR. While this was convenient in terms of particles management, it came at a certain cost:

• A particle was assigned an IcoSphere mesh with a subdivision level. This had to be done across all particles because you could not know in advance which visual LOD a particle was going to have, given the "sliding nature" of the LOD bubbles.
• This resulted in the SPS to have a rather massive incides count (around 3 million for a 3/6 LOD range).
• This large count resulted in the client-side lag/FPS drop observed when moving to a new cube: the engine (likely CPU-side?) was struggling to re-assign/re-activate particles. Since I did observe this happen on my Intel i9-12900HK (a nice little CPU), I think other people might have had even more noticeable lags.

The client, upon receiving the appropriate data from the server stream, would either:

• Delete a LOD_SYSTEM system: make the particle invisible
• Delete a LOD_STAR system: make the particle invisible
• Add a LOD_SYSTEM system: assign position to the particle
• Add a LOD_STAR system: assign position, size and colour to the particle
• Upgrade a LOD_SYSTEM system: at the same position, add colour and size information
• Downgrade a LOD_STAR system: at the same position, remove colour and size information

All within the same SPS. Again, nice since there's only one group of entities to manage, but problematic because of the weight of the resulting geometry.

The improvements

There are now two solid particle systems: one for LOD_SYSTEM and one for LOD_STAR. The number one consequence of this is that the management/"juggling" is slightly more involved; but the geometry complexity is so much lighter that it is a small price ot pay. At a 3/6 LOD range, the total number of indices goes down to around 1.2 million, which is about a 60% reduction!

A rough outline of what happens now for the two modified steps:

The LOD_SYSTEM SPS can now have very low-poly meshes assigned to each particle - given that this SPS is by far the one with the most particles, the resulting positive effect on the scene performance is quite massive.
This even allows the LOD_STAR SPS to actually get a boost in poly counts, so that the stars that are close by look nicer. :-)

Hell, now I'm thinking about doing this

For more immersion, more range at a cheap cost, maybe I will introduce a LOD level even further out, with the lowest possible polygon count primitive, such as a CreatePolyhedron of type 0.

That's probably for later though, as the Rust backend needs to be changed.

How to avoid particle overflow

The two new SPS now have a maximum fixed amount of particles each, defined by the server and sent during initialisation of the client. The calculation of this "particle budget" is easy to compute: simply multiply the total number of cubes within the rendering range and multiply it by the galaxy's overall density. The only drawback is that there may be more particles made available that can ever be used; in fact this is almost a certainty.

But since the number of systems evolves as one moves throughout the galaxy, we must plan for the worse-case scenario which is: all cubes have maximum density. Better safe than sorry.

There is probably a more elegant way of doing it; however, I needed a quick & dirty way to avoid the server sending yet more systems data to an already full client-side particle system, hence creating a particle overflow - usually manifesting as anything from invisible systems (bad) to a client-side crash (Very bad). Harr harr harr

Clickable stars

Oh and stars can now be clicked, which displays the same information as the data explorer.