Jink Engine

[SilverWarior]

I'm currently brainstorming abstractions for generation parameters for planets - trying to come up with a fairly small set that will give rise to everything from rocky barren moons to lush vegetation filled oceananic worlds - I freely admit that I'm stealing heavily from concepts in 'Spore' here.

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.

So I started doing some post-processing to smoothen or roughen different regions. For this I created another texture/height map which would control smoothing/roughing process.
And it performed quite well. The only problem was that this smoothing/roughing effect was also applied to the regions where it wasn't desired (it could roughen the valleys which would then become all spiky and ugly.

Because of that I started thinking of doing this post-processing in multiple stages for areas of different elevations. F
or instance all areas with elevation between 20 and 40 were considered as costal regions (sea level is at 30). All areas with elevation between 40 and 100 were considered as valleys. All regions with elevation between 100 and 150 were considered as hill regions. And all areas with elevation above 150 were considered as mountain regions.
Now this has been producing much more desirable results but the planet generation time has been increased greatly (even up to 15 minutes). Now this became a little concerning.
While it wasn't great concern since my plan was to be generating planets in neighboring solar systems in the background during the gameplay and you probably would not be able to reach those neighboring solar system before the planets are already generated (traveling between solar systems would take time - no warping between them).

Any way in the end I realized that wile my terrain generation algorithm can make very detailed 2D height maps with all the above mentioned variations projecting such height map onto a sphere actually screws up lots of that details especially when you are getting closer to the poles.
So I put this algorithm of mine aside and started thinking about creating a new one which would be working with spherical coordinates instead of a 2D coordinates from the very beginning. But I never got it implemented as I could not wrap my head around on how to actually make a 3D sphere from these spherical coordinates

planets and associated physics are the very last part of the engine to create

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?

Since it's so close to completion I'm now creating a website with documentation, examples, tutorials and all the usual gubbins that will get used be roughly nobody.

How long have I been working on this and posting about it now? like 8 years here? it's like duke nukem forever but hopefully it'll go down a bit better.

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.

[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.