Jink Engine

[phibermon]

Are you generating planets in one go or are you also using some post-processing?
When I was tinkering around the idea of procedural planet generation I never managed to generate a planet that would have so much diversity as earth does.
For instance if you go look at our "little blue marble" you can find areas with high peaked mountains and also areas with high but smooth sided mountains. You can find areas with smooth sores areas with cliffed coasts.
I never managed to convince any of the algorithms that I tried to be able to generate such diversity. I either got all mountains to be spiky or smooth but not both at the same time.

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.


In terms of variation of terrain I'm using concepts from the terrain generation tool L3TD - where the lowest level of detail is like a a patchwork of 'biomes' (to use minecraft terminology) which are used at the inputs for detail generation - then to make things more realistic I could have pre-rendered heightmap templates for mountain ridges and the such that are 'stamped' onto the heightmap.


Then to make the terrain more seemless I was going to use hydraulic and/or thermal erosion passes to blend things together.


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'


I was thinking one cool hack would be to not process erosion on certain flat plain style areas - perhaps blending the generated heightmap with raster techniques as seen in the impressive lithosphere tool (http://lithosphere.codeflow.org/)


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.


it's really difficult - possible of course but of those systems that do this well already? the developers are not very forthcoming on their approaches.

What is your plan for doing planetary physics? Are you planning to implement multi-body physics or will you use SOI (sphere of influence) approach as KSP (Kerbal Space Program) does?

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

Aren't you a bit grim about all this?
Good things take time to be built. Yes you are working on this project for 8 years which actually isn't so long especially when you take into account that you are basically working on this alone. Even a half dozen sized team of experienced AAA game developers would probably spend at least a couple of years working on similar project.
So don't be too hard on yourself. Instead be very proud of yourself for this.

I guess my confidence isn't very high of late - thank you very much for your kind words, they're very much appreciated

[SilverWarior]

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.

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'

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

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

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.