ideas for transitioning from Scaled planets to non-scaled on approach

Hi there,

I've managed to create my own QuadSphere with QuadTree based level of detail subdivision based on distance to the player (GitHub link) and I've also, based on an old video by the Kerbal Space Program team, setup a scaling system for objects further than 6000 units from the player and a floating origin. These two things work great on their own:
Example of QuadSphere:

Example of Scaled Space and Floating Origin (stars and orbiting planets are being scaled down and rendered closer based on the Pythagorean theorem and double-byte precision implementations of Vector3 and Quaternions):

But now I'm trying to combine the two such that I can transition the planets from Scaled Space to non-scaled. Unfortunately, I'm finding this doesn't work well when I use planet scales like those of Earth with a radius of 6,350,000 metres as I'm never close enough to the planet's centre to transition to non-scaled space and if I try to base it off distance to the surface of the planet, I end up with a planet that suddenly intersects with other objects in Scaled Space... anyone have experience with this and suggestions on how to handle the transition? Maybe @simitro could offer some advice since you already have an Asset that does this?

 

KSP did explain float origin mechanics in their video. I did watch it too while ago. 6k meters should not make you trouble with scaling. Hence you are probably doing something wrong at basics.

I think if you struggle with such mechanics already, you may need take few steps back and do something simpler first, as you will struggle later as well, without fully understanding what is going on. I suggest you do some floating origin mocups first, on smaller scale.

On other hand, while is not wrong to ask, I wouldn't be really expecting somebody who is selling asset, to answer how things work publicly. But you maybe should ask question in his forum thread.

 

Thanks for the reply. My reason for asking this question is that I have gone back through the scaling scripts and reimplemented them in several different ways, but I'm still having this issue. Because the planet can never get it's centre within the 6000 unit space where things are real scale, I can never actually reach the planet. Also, unfortunately, this all works perfectly for smaller objects like asteroids and moons with a radius of 1000 units so I'm just trying to understand what approach I might take to handle this and what the KSP folks were using the layer in between scaled and local space for.

 

You probably got issue with scaling up and loosing precision.
Multiple solutions to that.
Some of them are double precision float, additional frame reference.
Topic rolled many times over on the forum. Please search for solution.

 

Hi @Antypodish , possibly you missed in the original post where I said I'm using double byte precision Vector3 implementation. The scene uses two values, 1 is the "Real Space" coordinates and the other is the Unity coordinates. I'm also uses separate frame references (also mentioned in original post). I wouldn't have posted here if I hadn't already searched for a solution.

 

Not sure if there is such thing.

But double byte means 2 bytes. Which is otherwise 16 bits. = a Word.
Float and int is 32 bits = 4 bytes = 2 Words.
Double precision floating point is 64 bits, which is 8 bytes = 4 words.

Hence I think you need recap the topic, ensuring you understand it well, before heading on deep space.

 

ok, so now I think you're just trolling me here... I've got a functional Vector3 using doubles instead of floats. That isn't the issue, nor is it part of the question I'm asking.

 

Not trolling.
You are using wrong terms. Which makes me think, you don't understand fully the topic.
Which may be potentially reason for your issue.

Anyway, we can throw words in a wind here, without seeing actual code.
Specially scaling bit.

 

so, I've gone back and watched the KSP video from 2013 as well as some other show off videos (one and two) where someone managed to get this working and I noticed that they all shared one major difference from my implementation; they split their planet's surface into multiple meshes whereas I had mine all combined. I've not had time to test this change (though it should be a simple modification for my implementation), but I can imagine that this allows for the scaling of individual parts (Quads) of the planet independently as well as moving these Quads onto different layers independent of each other. I'm fairly confident this will solve the problem as I'll no longer be working with one, huge planet, but instead, multiple, smaller Quads which WILL fit within the 6000 unit non-scaled space area as the player approaches. I'm posting this answer in case anyone else stumbles upon this question in the future and is struggling with a similar issue.

 

They have split into quads. But not because of scaling issue.
The reason for quads, they acting as terrain LOD to keep less polygons in rendering.
While you may discover on the way, where you got issue with scaling, you probably will figure out, that is either issue of the scaling factor, or problem with an offset of your planet.

Make sure, that GameObject transform position reads correct value from double float.

But again, if I were you, I would try make a prototype first, with scale of few hundreds units first, to test, before going big scale.

 

I'm really confused by your response here... it makes it seem like you didn't look at my first post because there I show that I have a QuadSphere with QuadTree LoD already (and it includes a link to the GitHub repo that contains all the code).

Your comment of "But not because of scaling issue" doesn't make sense because what I'm saying is that their Quads are not all part of the same mesh, but of their own, independent meshes whereas mine was all one mesh. Because theirs is made up of a separate mesh for each Quad, they can scale each of these independently or apply them to individual layers without moving the entire planet.

Also, in my original post, you can see the prototype in the video. I'm thinking you simply don't understand the questions here and while I appreciate you trying, possibly it is outside your knowledge area?

 

With all respect.
I am not obligated to dig out through all files, to find out, where your relevant part of code is, weather for scaling or not.
Is in your interest, to assist and guide, where the relevant point in a code is. You could simply write file and number to line of code.

You trying to find what is the issue with scaling. I pointing out, where problem may not be, to eliminate possible options.

I have been there, I have done that in past. I choose my own path.

Sorry I am out.
I hope you get someone more suitable to assist in your problem.

 

I'm interested in the matter so go on, I just made the cubesphere "plate" display correctly on ground position, now I have to implement scale and subdivisio so I'm following ...

 

Once I've completed changes to my QuadSphere implementation, I'll update GitHub and post a video. This should actually simplify the entire mesh creation process so I might spend some extra time now to add in triangle caching (was putting it off until later once I was sure things worked properly) so it may take some extra time for me to post an update on progress.

 

Apologies for no updates here. I was sick for a week and the changes I've needed to make are taking longer than I expected. Good news is that I've succeeded in splitting all the Quads into their own objects, making a Cache for the possible Triangles on the mesh, and optimising other aspects of the rendering and distance lookup. The bad news is that I broke the neighbour subdivision across QuadSphere Faces so I'm working to fix that. Hopefully should have a further update in a week

 

ok, so I've completed the changes needed and I've uploaded a new video and all the code to GitHub at: https://github.com/bicarbon8/QuadSphere

The updated video can be found at:

Next I'll be integrating this into my Space Game to see if this works better for scaling

 

You could also consider having the player fly through something like a cloud layer that obscures their view while you then make any otherwise jarring transitions.

 

What would be the fun in that, flying through cloud? not even skylink on switch does that, the fun is in seamless, just like flight simulator.

I want to see if it's scale to earth size planet, which is the upper limit I'm shooting for

 

ok @neoshaman , so I've just finished testing a 6 million unit radius planet (with 100000 unit high mountains) using my QuadSphere implementation and my Space Game (though the QuadSphere has been further modified to support skirts around the base of each Quad to mask any subdivision / unification render timing issues in the Level of Detail switching process; I figure this is fine as games like Elite Dangerous and No Man's Sky use the same thing). I've had to go back to the drawing board with my scaling system and, instead of dynamic scaling based on distance, I've had a look at how Kerbal Space Program does it and I may end up switching to a static scaled layer with it's own camera and floating origin that is entirely separate from the main, non-scaled, scene. This shouldn't impact the existing implementation though because it would simply use a 1/6000 scaled scene where all movement of the Player is transferred to the scale layer camera and displayed on the main view using a negative depth value (I was already using this for my skybox). Here's a video of the test I ran with the 6000000 unit radius planet:

 

Quite the good job, 6000km radius is more a test limit of robustness than a practical gameplay consideration, even star citizen limit themselves to 1/6th that size for gameplay. But if it can handle such a big size that helps a lot, and also open to actual earth mapping (need to put all these dsm heightmap to use lol).

Thanks for doing that, I needed a test bed to evaluate the implication to design procedural circulation (road, path, etc ... between POI) using local only generation. I was wondering at that size, what is teh minimal grid unit on the ground and how many subdivision of quad to get there? What's the final max number of quad generated in whole when on ground, and how many division a single quad had?

In the scene editor the game is wildly jittering while the view is smooth lol

 

for the 6,000,000 unit radius QuadSphere I used a Quad subdivision of 51 (that means there will be 51 vertices per edge plus one on each corner for a total of 53) and a maximum number of Subdivision levels of 10 which means that at the highest level of subdivision, the distance between each vertex in a Quad would be 221 units for a non spherified QuadSphere (assuming I got my maths right, which is doubtful), so somewhere less than that.

The jittering you are seeing in the scene editor window is due to me using a rather small floating origin (1000 units) when travelling at a rather high speed (30,000 units per second or more). This leads to the ship moving very quickly between those 1000 units it is allowed to move away from the origin and then it is brought back to the origin and all scene objects are shifted by 1000 units. It works very well from the camera's perspective, but looks a bit mental in the scene editor.

 

Okay thanks!

 

great work! Doing very similar stuff for an orbital dogfighting game with Newtonian mechanics. I use 1000m as my origin shift threshold as well.

 

@bicarbon8 Have you seen this for scaling space and planets?