Space Graphics Toolkit & Planets

SgtTerrainPlanet Heights manipulation at runtime?

I am trying to implement a runtime mesh manipulation effect built on the SgtTerrainPlanet asset. My problem is, all of the SgtTerrain height manipulation examples (SgtHeightmap, SgtSimplex, SgtSine) schedule their heights jobs via the SgtTerrainPlanet BuildHeightsDelegate, which as far as I can tell causes the entire Mesh Stack comprising the planet to be rebuilt. I'm wondering if there's a way to just key in locally to subsets of the Mesh stack that comprise a SgtTerrain planet without rebuilding the entire structure... I think maybe this is possible using the SgtTerrain "Areas" feature? Or I can simply pass in a subset of points rather than the full SgtTerrainPlanet when I call HandleScheduleHeights, but I'm not sure how to create subsets of points, especially when an area of interest crosses over the boundary between two SgtQuads...

Basically, I want to let a player drag their finger/mouse over the terrain and create a gravity well along this path (I am using SgtTerrainPlanet as a spacetime surface in my game, not as a planet). This raises another issue around data storage size, i.e. keeping the storage size of user input fixed over time as user input accumulates. My (primitive) solution thus far has been to build a separate octree structure around the SgtTerrainPlanet that keeps track of the touch time in each sector, but this is very granular and not very performant. I think it would be more efficient to write directly to the SgtTerrainPlanet data structure (e.g. store in a UV channel whether a triangle has been touched), but because the dynamic LOD disposes/allocates meshes continuously, this data doesn't persist.

My current thinking is to try to write to a heightmap file, i.e. use the heightmap in "reverse", get the collision location from SgtTerrainPlanet/SgtCollider, reverse the projection mapping to the heightmap, and store the input data there... but honestly I am just starting with this approach and have no idea how to implement it.

Any advice to get me pointed in the right direction would be much appreciated...

@Darkcoder thank you for the update yesterday, it's looking good in HDRP! And, once again, thank you for an amazing asset!

 

How can I use the Debris Grid as Floating Object?

 

The terrain surface is designed to be static, and is generated based on the current set of terrain modifiers. If you modify these or modify the terrain meshes then things will go out of sync and probably not work, or the changes will be very quickly overwritten.

What you describe is best done using a custom shader with vertex displacement. The terrain shader was compiled using the Better Shaders asset though, so you can't directly modify it so easily. You could still experiment with any shader though, since there is no vertex displacement performed with the terrain shader. Once your modifications are done you could copy+paste it into the compiled terrain shader. Keep in mind the atmosphere is rendered on top and has no knowledge of any vertex displacement of the surface, so you should only displace the vertices up close where the atmosphere is completely transparent.

Glad you like the HDRP improvements! This compatibility code is now used by all my assets, so any future changes will be much easier to maintain and deploy.

I'm not sure if you can, or maybe you can add SgtFloatingObject to the debris grid root. I'll check it out when I'm back next week.

 

I can do itwith floating object but i need spawner. The probleme is the objects are spawning in the debris grid, but i want it to spawn in the floating root

 

so it need to spawn inside an object that hasent floating object, like sgt floating root

 

Is there a simple way to get a texture coordinate on a SgtTerrainPlanet object from a world-space raycast hit generated by a SgtTerrainCollider?

My two ideas are:
1.) Write functions that reverse the sequence of SgtTopology function calls generated by SgtTerrainHeightmap (i.e. pass the WorldPos coords from the Raycast Hit into (reverse) Hermite, and pass the return from that into (reverse) Sample_Cubic_Equirectangular

2.) Attach the Texture2d rendering on the SgtTerrainPlanet object directly to the sharedMesh property of the MeshCollider object stored in the SgtTerrainCollider object, so that I can use the built in raycasthit texturecoord method.

 

Btw, Carlos Wilkes can you ad a timer float in the floating spawners. Tgat means that the speawner will be spawn after x seconds. That can Improve the Performance so much (I guess)!

 

Hi Darkcoder,

congratz on putting out version 4!
New features I just discovered and really like are e.g. Jovian flow, ocean waves and floating massive!

Unfortunately, raycasts are still not working properly:

Today I came accross another weird behavior when trying to spawn a lot of floating objects (cubes for testing).
In the code, I set a specific sgtPosition for each object, but (only!) the LocalZ variable wont be what it should be on runtime.

This is the code:

Code (CSharp):

1.  
2.  
3. int objectsToSpawn = 1000;
4. long cubeDistanceGlobalZ = 1;
5.  
6. for (int objCount = 0; objCount < objectsToSpawn; objCount++)
7. {
8.     GameObject cube = GameObject.CreatePrimitive(PrimitiveType.Cube);
9.     SgtFloatingObject sgtFlwObj = cube.AddComponent<SgtFloatingObject>();
10.  
11.     SgtPosition sgtPos = new SgtPosition();
12.    
13.     // 1. set local offset, should be the same on every cube
14.     sgtPos.LocalX = 2.02;
15.     sgtPos.LocalY = -0.68;
16.     sgtPos.LocalZ = 4.86;
17.  
18.     // 2. set global variation
19.     sgtPos.GlobalX = 0;
20.     sgtPos.GlobalY = 0;
21.     sgtPos.GlobalZ = objCount* cubeDistanceGlobalZ;
22.  
23.     sgtFlwObj.Position = sgtPos;
24.  
25. }
26.  

After running it:

Cube[0] has LocalZ = 4.8600001335144
Cube[1] has LocalZ = 4
Cube[2] has LocalZ = 8
Cube[3] - Cube[42] has LocalZ = 0
Cube[43] has LocalZ = 128.

Hopefully you can help!

 

Hi!

I have an issue with the SgtFloatingSpeedometer class. I've extended it to use larger velocity brackets instead of only just m/s but because there is a division of the current distance by the Time.deltaTime value, when it gets to AU/s you can see it jumping up and down. The issue is here:

Code (CSharp):

1.                
2. var distance = Position.Distance(ref expectedPosition, ref currentPosition);
3. var delta    = Helper.Divide(distance, Time.deltaTime); // Time.deltaTime is not constant on LateUpdate()
4.  

Because of it, if the scene chokes during one frame for whatever dark reason Unity chooses, then it will have a larger deltaTime on the next update, which makes delta be smaller, sometimes much smaller, thus showing a much slower speed on that update.

for example, I recorded some values in one of my tests:

Speed: 132.5 AU/s Delta: 1987000680144.74 Distance: 4995717213.83365 DeltaTime: 0.0025142
Speed: 159.6 AU/s Delta: 2394071278817.2 Distance: 5907849808.26041 DeltaTime: 0.0024677
Speed: 40.6 AU/s Delta: 608557002221.76 Distance: 7005464570.74958 DeltaTime: 0.0115116
Speed: 195.5 AU/s Delta: 2933203557554.15 Distance: 8092708772.59749 DeltaTime: 0.002759

By the way, switching to FixedUpdate obviously gives a constant 0.2 for the delta which translates in a 100x slower speed??

Question is how would we go about calculating the current speed a different way?

My current approach to solve these discrepancies was to create my own Warp class that just calculates the speed by just getting the current distance, compare to total distance, and divide by time passed since warp started. By adding the deltaTime on each update I get rid of the jitter on the division.
I modified the SmoothStep function code to actually have a max speed and an acceleration linear curve which made testing very deterministic, but now the warping looks way too much like Eve, so yeah, looking for other options or I guess I just remove the max speed.

Any thoughts?

 

Whoa! Supercalifragilistic!

 

Using 2019.2.21f1 DRP. I have SGT and SGT Planets and both seem to be working okay. Tried to install Solar System Pack on top and the prefabs in most scenes have missing scripts and well the planets are pink.
Suggestions on ho to fix?

 

I checked it out and indeed the debris grid doesn't work with the origin shifting system. I'll see what I can do when I have more time. However, the way this component works means it won't work for truly massive debris grids. Perhaps the current system could be made to work up to Kuiper belt sized grids, but probably not anything galactic sized.

The intended way to make asteroids and such using the origin shifting system is with nested spawners. This is described in the Spawning Hierarchy section of the documentation HERE.

Both approaches should work. Approach 1 is probably easiest, though you don't have to un-deform the point because that new position is merely to relax the vertex distribution, the UV for a given point is still the same. You can see the code in SgtTerrainPlanet.cs GetCoords method to see how to calculate this from a local terrain point.

I'll check out the raycast issue soon.

The position issue can be fixed by adding: sgtFlwObj.PositionSet = true; I'll see if I can modify the code so this is auto set when you set the Position property.

As you can see, the speed calculation itself is very simple - it just factors in the position delta and time delta. Since the time delta is set by Unity before Update, the challenge is when other systems interact with the position. Most of these issues are from Rigidbody velocity and interpolation, since that occurs in FIxedUpdate and there is little control over it. The warp code though is much simpler and uses Time.deltaTime, so it should work the same. The warp updates in Update and the speedometer updates in LateUpdate so any fluctuations in Time.deltaTime should cancel out. Perhaps there's something else like the Rigidbody position that's causing the position to change during the warp?

The latest versions of these assets and packs are made for at least Unity 2019.4.12f1. The local documentation for older versions should contain links to older versions of these packs.

 

Hey everyone,

Version 4.0.2 & 4.0.3 of Space Graphics Toolkit & Planets is now out!

• Fixed Universe/Floating Massive demo scene.
• Fixed SgtTerrainFeature.Scale setting.
• Removed SgtJovianScatteringTex.Mie setting.
• Removed SgtJovianScatteringTex.Rayleigh setting.
• Added Scattering Terms setting to Jovian shader.
• Added Scattering Strengths setting to Jovian shader.
• Removed Scattering Mie setting from Ring shader.
• Removed Scattering Strength setting from Ring shader.
• Added Scattering Terms setting to Ring shader.
• Added Scattering Strengths setting to Ring shader.
• Added DETAIL / Fade Bound setting to Planet shader.
• Added BAKED DETAIL / Fade Bound setting to Terrain Planet shader.
• Improved SgtRing depth sorting.
• Fixed SgtOcclusionScaler against jovians.
• Fixed SgtOcclusionScaler against atmospheres.

In this version I rewrote the atmospheric scattering code to be faster, more flexible, and to allow it to look better.

Before, you could only specify the Mie (front scattering) and Rayleigh (front+back bi-directional scattering) to get something like this:



With this new system, you can add up to 4 layers of Mie scattering, you can specify the strength of each layer, allowing you to make something like this:



Although I removed the Rayleigh scattering, you can invert any of the layers to make it back-scatter. You can still achieve the same look as before, but you now have the ability to create new looks.

This new system has also been added to the Ring and Jovian features.

Enjoy

 

Why does the Gravitational Lensing of my Singularity not eorking on Objrct in URP?

 

Have you read the "Black Holes (URP)" section of the documentation HERE?

 

I need to set the render queue to 2001? If yes than it doesnt work.

 

and what can i do with the category in the spawner

 

And the opaque texture?

It allows you to create one SgtSpawnList with a list of prefabs, then all spawners can use this by name. Without this you must specify the list of prefabs for all spawners which may not be ideal.

 

1.opaque texture is on

2.ok thanks

 

It works for me, at least in Unity 2021.2.15f1:

New project:


Enable opaque texture:


Change the background materials to RenderQueue 2001.

 

For me its not work, which material did you change the renderqueue to 2001? Only the Backdrop or Black Hole or both?

 

Or do I need to update the unity version to latest?

 

The Black Hole is already on Transparent + 1 (3001). I'm talking about the background materials (BackgroundBillboard6, and BackgroundBillboard8 used in the "06 Black Hole" demo scene).

The steps I'm giving are for version 4.0.0+.

 

Its worked, thx. I just used the wrong material.

 

I hope this is my last question. ._. If an object is spawned with SGT Floating Spawner Orbit, how can I make it so that I type the orbit speed myself and not automatically (with Orbit Angle it would also be better).

 

Is this currently working?

New project - fresh install but it looks like the terrain system is broken in all of the demos? I see an atmosphere but none of the terrain scripts are functioning.

 

The referenced script on this Behaviour (Game Object 'Terrain') is missing!
The referenced script on this Behaviour (Game Object 'Terrain') is missing!
The referenced script on this Behaviour (Game Object 'Terrain') is missing!
The referenced script on this Behaviour (Game Object 'Terrain') is missing!


etc......

 

The whole purpose of the SgtFloatingSpawnerOrbit component is that it procedurally generates the orbit parameters for you.

If you don't want this behavior then use one of the other spawners like SgtFloatingSpawnerSphere.

See here.

 

...ignore me, found the info on activating Burst!

 

OK, new question! How do I get rid of the black in the atmosphere? Its fine when space is the background but it looks pretty bad in front of another planet!

 

I want a orbit with custom angle and speed and not a sphere.

 

Here's a clearer screenshot of the issue. Presumably the black helps the atmosphere blend with a dark background... but not much good for this moon orbiting a gas giant! Is there a way to have transparency instead of black?

 

I'm not sure what is causing that issue based on these pictures alone, can you send me a scene file I can test to see the issue myself?

This component just places the spawned object within a sphere (could be radius = 0). You can still use the floating orbit component with your manually set parameters (at least I think you can, I haven't actually tested it).

 

Ahh, that was stupid, realised the jagged edge was just the jovian clipping the edge of the atmosphere! So fixed that!

But....

I'm still looking for a way to get rid of the black shading in the atmosphere as it looks wrong against another planet. Atmospheres aren't black. Is there a setting somewhere to make the dark side of an atmosphere transparent rather than black?

 

Actually they do (it's called extinction), just not as much as in your scene:



The issue with your scene is that you have ambient light, so your moon's dark side never becomes black. However, the atmosphere material doesn't read the scene's ambient color (to give you more flexibility) so it defaults to black. You can manually adjust the atmosphere material (maybe you want to clone it first) so that the ambient color is brighter and more closely matches the dark side of your planet, or you can set the ambient color to black.

Also keep in mind in real life atmospheres are incredibly thin relative to the body they're around, so this amount of dark haze is usually very hard to see.

 

Great thanks, I've killed the ambient light and its much less noticeable. I'll have the ambient fade in when in an atmosphere. Really loving the recent updates to this, your floating point accuracy on the surface was too jittery on older versions so I was using another terrain system... switching back to yours now as the ground textures are rock solid now!

I'm sure I'll have lots more questions

 

Looks great! Feel free to post updates to your project. When it's released I can add it to the first post project list

 

Will do!

Next question! - how can I get the terrain colliders to more accurately match the actual terrain? They seem to follow their own random shape which doesn't match the terrain. In some places above the ground, in other places way below. I've tried changing settings but nothing seems to get them aligned with the ground.

As I'm using a first person controller on the surface I need it to be accurate, or my character sinks into the ground up to his neck... or floats in the air.

 

I got SGT Planets in the Ukraine Mega Bundle and have thus far been really digging a lot of what it has to offer (and will 100% be getting the full version when I've got some disposable funds to throw around again; SpaceEngine-tier graphics out of Unity is worth every penny imo), but have encountered one major sticking point trying to integrate it into one of my existing projects; due to the way atmospheric fog is handled (adding an additional material overtop an existing Renderer), trees made using SpeedTree, Unity's trees, or generators like MTree have some serious artifacts spawned by the fog.

As the fog shader has no knowledge of the alpha cutouts for distant tree billboards, nor those on leaves (and when enabled, vertex offsets for wind effects), blocky fog alphas overlay all the geometry. Additionally, multi-material meshes only get fog on the final material slot (in this case, leaves; tree trunks are in slot 0), but while that's a nuisance it's arguably fixable by splitting the materials into two different meshes, even if that might have a minor performance cost.

That being said, is there a better solution for something like this coming down the line, or should I take a peek through the shaders and see if I can't fix it myself? The most obvious solution that comes to mind would be trying to make the atmosphere shader into something that can be #include'd, and making my existing shaders sample the atmosphere color & intensity at their position before modifying the final output.

The cool method that would make life easier in the long run is likely something along the lines of a pixel shader similar to those used in post-processing effects that overlays atmosphere colors based on the depth map, though it would be a bit complicated when coupled with the multi-camera setup necessary to avoid depth map inaccuracy making a jittery mess of everything. That said, I struggle enough as-is with simpler shader topics, so a rework of the atmosphere shader that could actually handle this sort of thing would be...tricky, to say the least.

 

The collider mesh is at a fixed resolution, whereas the visual mesh has dynamic resolution, so there will be some difference when these resolutions are different. The vertices should converge to the same points though. It looks like in your picture the visual mesh is much lower resolution than the colliders there? You can try reducing the SmallestTriangleSize setting and see if they line up better. You can also ShadedWireframe view in the Scene view.

As you've discovered, the atmosphere shader has no knowledge of the underlying transparency or vertex modifications, so it cannot correctly apply fog. To properly integrate this you would have to make a version of the tree shader that implements the atmosphere shader and then blends it with the transparency, and also have the SgtAtmosphere component send its data to this shader. This would be quite a difficult task to integrate them though. I could make a cutout shader that implements the atmosphere and some feature to send this data, but I wouldn't be able to integrate this with third party shaders.

The best solution is as you say, some kind of screen space atmosphere effect. However, this would require rewriting the atmosphere system entirely, would rely on there being scene depth information, would require some post AA since normal AA is incompatible with this, and probably several other issues. Therefore I have no plans to implement anything like this. If I ever make something like this it would be part of a new separate asset.

In the full SGT asset there is the terrain LOD system which supports realistic sized planets. In this scenario you can use opaque trees at a distance where fog is present, and then swap to transparent objects when you get closer and the fog is minimal or invisible.

 

I think I've got the tech chops to integrate things on my end; by my understanding of the SgtAtmosphere & SharedMaterial systems, I'd *likely* just need to update the existing code a bit to set the Atmosphere shader parameters on all materials a Renderer has, ensure all materials that need to be atmosphere-affected have the requisite parameters set, and feed the atmos params in during the lighting function to modify the final rendered color. It'd be annoying, but far from the end of the world - and likely give some minor performance benefits over the current system, too, since it no longer requires overdraw. That being said - is there any hope of working this out from the generated shader file, or should I get straight to working with the Better Shaders source for it in hopes of integrating things?

As for screen-space atmosphere, I do believe it would be possible, albiet at the cost of builtin AA, as you covered. Shaders can access the camera's depth mask, as well as information on its clipping ranges, which coupled with some vector math could be used to determine the hit point to sample, and either skip rendering on blank space if a material parameter is set or fill it in for the skybox as per usual, allowing for multi-camera setups like mine to work. That said, I would definitely need to figure out the far more basic setup of adding atmosphere to existing shaders before even thinking about tackling something like this, haha

Finally, as for the full asset's terrain LODs & realistic scales - while I definitely hope to find a use case for them at some point, my current project is targeting a radius of around ~6km for an Earth-like world & uses a voxel-based terrain that allows for realtime deformation, excavation, cave systems, etc, and is procedurally generated at runtime rather than by use of a heightmap. That said, using opaque blockouts instead of the existing billboards will definitely help in the interim, and might end up giving better long-range visualization than the billboards anyways; I'll definitely be taking a stab at it later!

 

Since the tree shader you're using wasn't made with Better Shaders, there's probably no benefit to getting it for this shader alone. To integrate this shader with the tree shader you can just look at the SGT_Atmosphere.surfshader file, which is the Better Shaders source file. You can then copy + paste 99% of it across, as it should be clear what's happening. The compiled shader file would be a pain to read

When I have a bit more time I will make the atmosphere shader stackable using Better Shaders so I can make a version of the SGT/Solid shader that implements it. I'll then make the necessary modifications to SgtAtmosphere to send data across, but I imagine you can figure that out.

 

I've tried matching the resolutions and its even worse. This is...

Terrain
Res 128
Detail 1

Colliders
Res 128
Detail 1

"128" colliders look to be much lower resolutions in real terms than "128" terrain... so presumably they are actually using different scale triangles? But I can't adjust the triangles of the collider.


I'm not entirely clear what the purpose is here.... if terrain colliders don't (can't?) match terrain?
They seem to use different systems altogether at the moment, what I really need is a collider mesh that directly copies the visible terrain.

 

OK, so here's the issue. The collider grid isn't in any way aligned to the terrain. its not even oriented the same way, its at 45 degrees - a grid of squares while the terrain is made of diamonds. So there is no way this could ever match the terrain.

I assume this is a bug / not as intended.... as terrain colliders really need to match terrain. Would it be possible to get a terrain collider feature added to SGT that aligns with the terrain?

 

Yeah, I would prefer that as an option too. Can totally afford using exact 1:1 version only constrained by radius, in fact, I do need this approach. Current component seems to be designed to allow an optimization (when you can lower or raise the amount of geometry it just won't match), but many times I'd just choose exact version and being able really align with the graphics. That would be really helpful for many scenarios for me. So if we could ask for such feature, we'd be grateful .

That being said, I really love the colliders are now stable, many thanks for that. But in my case there are a lot of issues like rigidbodies falling through colliders on the edges of hills, etc. Especially if they're steep or jagged because of applied noise, but not only then. Not sure why it happens. Controller can randomly get stuck on a slope and then fall under the surface. Setting collisions to dynamic helps, but not sure it's a reliable fix. If we could really match the surface of the mesh with collider, I'd probably make another one just to safeguard the first, at really small radius around the player.
But still not sure why that happens, the speed of the controller is really small, it's capsule collider kinematic. Does the scale of the planet still make some difference in stability? Or maybe it's because of some weird geometry in colliders trying to match terrain?

There is indeed a huge improvement, but I noticed as well that the shadows are much less stable in URP. I guess it might be an issue with Better Shaders (the author didn't think about such scales?). At the same scale built in still shows shadows, while URP does not. I tried everything, but only switching to legacy render fixed it. Exact same scene, URP - no shadows, built in - they still work. Which isn't great because URP otherwise was much better (and there's no fix for color banding of the atmosphere in built-in stack anymore, Unity removed it).

Another thing I'd suggest would be adding hydraulic erosion option for noise (or other solution for realistic mountain look) and being able to texture the terrain procedurally with microsplat based on slope and height.

Update: Ok, I've looked into it. It seems there are big problems with collider accuracy overall. It's only a heightmap and 1 layer of minor noise but there are points which are not traversable because of how colliders are created. Terrain has no such steep edges here and raising the resolution only makes it worse:




All screens are from the same place. So it seems making colliders match terrain exactly would not only lower the poly count but also fix all those issues. Letting us have such option would simplify the workflow - we could focus on terrain only. And this wireframe terrain is really less complex than even that hardcore mesh collider.

 

I see now. The collider does match the terrain heights as seen here:



However, the points where the heights are sampled are different, which leads to this disparity. This is because the visual mesh sample points are adjusted to reduce distortion at the corners of the cubed sphere, whereas the collider vertices aren't. The reason why they aren't is because I wasn't able to figure out the calculation to un-adjust the local space camera position to align with the vertex adjustment.

When I have more time I'll see if I can figure that out.

In any case, there's no possibility of making the colliders match the visual mesh at all times because updating a MeshCollider is immensely slow, and this would cause your game to run at 0 FPS. Also, switching collider resolution due to LOD would cause all objects on the surface to fall through, which is why a fixed resolution is superior. The only thing to keep in mind is that colliders are only generated in a limited radius around the camera (because MeshColliders are slow), so distant physics objects call fall through if there is no collider there. Also, as with all non-convex MeshColliders, small objects can easily fall through if they move fast.

In scenarios where you need distant objects to interact with the surface, you should use the SgtFloatingObject component (or a custom component based on it), which will directly read the terrain surface heights without colliders.

Better Shaders is (I believe) based on whatever shader Unity's Shader Graph spits out, so any shadow issues with it are probably due to the way it's implemented by Unity.

The terrain heights are generated based on a calculation at a given 3D point, so there is no possibility of erosion because this requires pre-generating a large area and running multiple iterations on it. You can always make your own terrain height modifier component (e.g. based on SgtTerrainSimplex) to see how difficult it can be to make good procedural height data.

Can you send me a demo scene using only SGT example media that demonstrates this issue with the camera already positioned at the problem area?

 

Yes please! The game I am working on is a space simulator where you land on the surface and can walk on foot.

For obvious reasons your asset just isn't capable of running this kind of game if the colliders don't match the terrain correctly. Which is a shame as you are just one step away from star citizen, elite dangerous, kerbal space program etc but for this missing feature.

If only we had the source code to Kerbal to see how they did it in unity!

 

...investigating SGTTerrainObject Might be a workaround at least for my first person controller and the ship landing. I'll cross the bridge of other items falling through the ground later.

 

Cracked it! (sort of), hopefully this is useful info to anyone else.

The problem is connected to me scaling planets via their root transform.

I was using a planet with the root game object scaled at x100 y100 z100 with the SGTTerrainPlanet scaled at 1000 which had terrible collision accuracy.

I've rebuilt the planet at scale x1 y1 z1, SGTTerrainPlanet scale 100000 (so essentially the same size planet) and the colliders are far more accurately matched to the mesh. I've adjusted all the other scales etc. like displacement from 40 up to 4000 to retain all the same landscape heights, and its still working great!

Its not perfect, the player still gets a little taller/ shorter but only by a foot or so, no more sinking underground or flying.

 

I see, so it's that way. Your implementation is complex, especially with the joining/smoothing algorithm. I thought maybe you could copy at least the first lod level around the camera, but indeed seems you'd have to use another algorithm to join both approaches, so performance would drop and the outer/joining areas would be inaccurate again giving probably the same result. No idea how they made it NMS/Star Citizen then. Did they pre-bake terrain and colliders and just save the meshes?

So likely another issue of URP in Unity. Gonna send them bug report as I have it directly recorded - cube doesn't cast shadows on the same surface with same settings in URP. That's helpful, thanks for clarification.

Yes, just figured out what I wrote - erosion is quite intensive, takes multiple passes etc. You noise algorithm is already very good, the best I've seen. I'll try to write some modifications, but as you say, gonna be hard to get good results.

Of course, gonna send you the link as soon as I prepare it.

Kerbal 2 is using microsplat custom implementation btw ; ). Will have better graphics than Elite imo.
But SGT looks much better than first Kerbal from what I've seen, and Kerb2 isn't out yet. I'd assume it has a completely rewritten terrain system, and most likely 1:1 planet size.

Yes, never change the scale of terrain, just radius. My results are so good (except the places I've posted) I only need to fix colliders and implement real texturing at close distance. Maybe in future some kind of fractal noise for a better variety of places. Can do procedural terrain, but not with spherical LOD such as this, completely don't understand the magic clipmap thing SGT does as of yet.
Absolutely SGT is the best at the moment, no better publicly available solution in the entire world, so that's no small feat by Darkcoder. But all this tech will probably get better and better now, for many reasons.
You'll probably experience a lot of other challenges which are not that trivial, but we're getting there.