[1.12.x] Parallax - PBR Terrain and Surface Objects [2.0.7] (2024)

Parallax Development Update

It's been a while since I've posted progress on my projects, so this is quite a meaty one!

What am I working on?

Over the last few months, I've been rewriting the entire mod from scratch including the shaders and architecture with the goal of massively improving performance, memory usage and eliminating annoying bugs. I've been successful so far with all of these to the point where I feel like I can share my progress. I can't provide any detailed analysis just yet as the mod is still evolving, but here are some of the key changes that are coming.

Performance - Terrain Shader

Performance is key with Parallax. Its original goal was to provide a terrain shader that was more flexible than and outperformed the stock shader. On some systems this is true, but we can do better than that! With the upcoming rewrite, both tessellation performance and texture performance are hugely improved. Not only does the current public version of Parallax use too much GPU bandwidth (something the KSP 2 terrain shader is notoriously terrible for), but it also does far too much in the wrong shader stages which worsens performance, more so on systems running OpenGL because of its awful vertex performance. Expect some major improvements to the terrain shader which will free up performance for things that matter more!

Not only that, but the CPU usage for functions that support the terrain shader have already been massively optimized. Because KSP is so dated, its terrain is not detailed enough to support tessellation at a high enough density that looks good. I've written two mesh subdivision methods over the years to try and counter this, but they have been limited. None of the previous methods have satisfied all of these requirements:

1. Gapless mesh (no T junctions)
2. Fast / efficient
3. High mesh detail
4. Multithreaded

But now after a month of two of experimenting, I've written a multithreaded subdivision scheme using the Unity Jobs system which achieves all four of these requirements. It's also entirely asynchronous which means aside from rendering the mesh at higher detail, there's zero performance loss from the subdivision itself! And it runs in realtime. Here's a gif:

Note that the framerate of this video is low because it's a gif. Here's the link to a video that shows this more smoothly:https://i.imgur.com/96HPeBE.mp4

Performance - Scatter System

The scatter system is where most of my time is being spent right now, and there are already a number of optimizations and improvements on the way!

Firstly, instead of doing everything in 'world space' coordinates (which is bad, really bad), the scatter data generation is now entirely in mesh-space. This means that the days of the scatters becoming disconnected from the ground are gone! I've also managed to significantly reduce the VRAM usage of the scatter system by changing how the scatters are applied, which now only apply to visible quads. With the previous implementation this wasn't possible and you were actually generating and storing scatter information for quads that weren't even visible, but thanks to Harmony and some guidance from @Gotmachinethis isn't the case anymore.

The scatter shaders themselves have also been rewritten from the ground up. These include a much more streamlined process without the baggage that the previous shaders had - and there was quite a bit, especially since a lot of calculations were done to get around working in world space coordinates all the time. There are further improvements to VRAM usage here by reducing the memory required for each individual scatter object by around 88%. Before, an object's position, rotation and scale were stored as a 4x4 matrix using 64 bytes. This is absolutely unacceptable but sadly a byproduct of using the wrong coordinate system - this has now been reduced to just 8 bytes to store a float3 position, a float rotation and an unsigned integer index (for some internal processing needed elsewhere for aligning objects with the terrain). Combined with the VRAM usage I mentioned earlier, this will be a major part in improving performance and supporting lower tier hardware!

Quality Improvements

With the changes coming to the terrain mesh subdivision, the quality of the terrain tessellation is much better. The current public Parallax version also has a mistake in the biplanar texturing coordinates used for sampling mipmaps which results in slightly blurrier textures. This has been fixed, so expect a noticeable quality bump in the textures themselves. I've also added (cheap) reflection support to the shader which will massively improve the colouration of the terrain on atmospheric bodies which will be more noticeable when Scatterer is not installed.

On the scatter system side of things I've rewritten the procedural noise system and moved it from relying on the terrain system to generating it on the GPU. Not only is this much faster, but the improved implementation allows for much finer detail that isn't tied to the number of vertices in the terrain. This isbig newsfor RSS players but applies to stock scales too. Check out the detail we can get now!

Ignore the cubes - as you can see, things are still very WIP. You can see here there is this weird pixelation of the procedural noise - this is a result of precision errors given the scales we are working at but there is a very nifty workaround for this too. On the technical side, I pass the 'direction to the planet center' to the GPU and it generates the noise from these spherical directions. Since these can be stored CPU-side as doubles, we can define a minimum procedural noise 'frequency' (which is really how large or small the noise appears) and multiply it before the lossy conversion to floats on the GPU. This means we'll have a minimum frequency which we can most likely safely set to 100 (larger for larger planets) which will make these precision errors much, much less prevalent. So, long story short - the pixelation can be largely ignored here. Again, WIP!

However this improvement to how the noise is generated (and the types of noise available) is huge for modders who right now are very limited in how scatter placement and dynamics can vary.

There are 5 noise types that will be available on release and I'm considering adding more if they're required:

There aremost likelythings that I've forgotten here, since there are seriously a whole bunch of improvements on the way! I'm looking forward to being able to share more in the future and excited to release it when it's ready.

As for when it releases, I'm aiming for within a few months at most if all goes well - but there's a lot going on in my life at the moment, so I can't promise anything!

o7

Edited May 5 by Gameslinx