Quote Originally Posted by phibermon View Post
My current design is an attempt to generate successive levels of detail that are deterministic based upon the previous level of detail - this would go hand in hand with mip-map levels in a way and allow for distant planets to be rendered in low detail before moving onto generating the next level of detail.
That was also my goal when I started thinking about creating my own algorithm that would use spherical coordinates and actually store all the data in a tree based fashion. But I haven't got far enough with implementation as I switched to other more pressing ideas like my Silver GUI library that unfortunately hasn't seen any progress for the past six months or my texture making program which needs a major core rewrite in order to allow myself to include few more desired features that can't be implemented at current state.

Quote Originally Posted by phibermon View Post
There's lots of problems here of course - even with my GPU implementation of hydraulic erosion I'm very limited in the number of passes I can process on a planetary scale to keep things 'real-time'
Quote Originally Posted by phibermon View Post
The key goal here is to not have to rely on generating the entire planet at any given detail level just to see one part of it while still ensuring the end result is identical for any given seed.
Yes doing things in real time can become quite difficult due to the large amount of processing required. That is why initially I wasn't even thinking about trying it. But my latest design idea is moving in this direction. I figured that until I put this idea into implementation the computer would probably be strong enough for it to work

Quote Originally Posted by phibermon View Post
You know I honestly don't know - KSP seems to function well at the large scales but performance isn't great (although I attribute a lot of that to unity) if you've got thoughts on the matter then I welcome them
The main problem with KSP is that it is using PhysicsX engine in software mode. Why?
Main problem is that PhysicsX uses single stage physical simulation. What does this means? Since in KSP all ships are made from connected parts physics are calculated in a way that you first calculate new position of root object based on the forces applied to it and then proceed calculating new position for other objects in a tree like manner. This is limiting the processing of any such ship to a single thread. Also until the latest versions KSP only used single world physics simulation (all ships were simulated in a single thread) while in latest version of KSP it is possible to simulate separate ships in separate threads.

Now it KSP would be perhaps using some different physics engine that uses two stage simulation there would not be so much performance issues. Why?
Because with two stage physics simulation you use first stage to just calculate new objects position and store that information without moving of those objects right away. Because of this there is no need for your to calculate physics for multiple connected objects in any specific order so you can easily spread the work across multiple threads. And once you have calculated new position for all object you actually move all those objects to their new position but you do this in the second stage.

So as noted above the main advantage of two stage physical simulation is the ability to spread the work across multiple threads.
But it does come with its own disadvantages. Main disadvantage is the increased memory requirements as you need to be able to store both old and new position at the same time.
And the second disadvantage is that second stage also requires some processing time so that the cumulated time to simulate physics and move one part/object to new location is actually higher than in one stage physical simulation. But with clever implementation of double buffering it is possible to reduce that to minimum.

And even if you could not reduce the additional time needed by the second stage so that processing physics and moving one part/object to new position would take twice as long you could still get almost 50% better overall performance if you can spread all that physics simulation to four separate threads.
Frankly I'm guite surprised why there aren't many physics engine that actually utilize this two stage physics simulation approach.

If I would be better at math I would probably try and make Pascal based two stage physics engine but I'm actually pretty bad at math
But if you are interested I'm prepared to work with you on implementing one provided that you take care about math and I'll try to take care about logical part of implementation

Quote Originally Posted by phibermon View Post
I guess my confidence isn't very high of late - thank you very much for your kind words, they're very much appreciated
That is understandable due to recent events in your life that you mentioned before. But stay strong.