Notifications
Clear all

Procedural planets : Part II


NevilClavain
(@krakoukass)
Warrant Officer Registered
Joined: 8 years ago
Posts: 203
Topic starter  

A little hello to the few that sometimes come hang out here !
 
 
Many weeks passed while I was fighting with my piece of code. I'm quite happy with the recent progress I made, essentially on the fractal/noise code on GPU. As my first implementation of Perlin noise was working well, but definitely too slow, I switched on Wombat GPU perlin noise implementation (Thanks to FluffyFreak for the link), allowing me to keep a decent framerate.
 
Among the many links I followed while searching informations about fractal and noising, someone wrote that "fractals are beasts incredibly difficult to master" (or something like that). And hell that's true, bloody true. and when you work on it on GPU side, you just enter in a Wooooorld Of Pain.
 
One of the most challenging point was to combine multiple fractals calls to alternate plains and mountainous area, which is something that I have not been able to get on my previous planet engine version, 4 years ago. I now have pleasant flat coast and plains, and here and there I can see some isolated mountain ranges, which is more realistic than endless succession of hills and mountains as that was previously the case in 2012.
 
Another succesful milestone was to correctly manage collision between ships (or other physical bodies) and the planet's terrain. As the planet terrain elevation is computed only on GPU side, and the physics engine (Bullet) run only on CPU side, the only way to get it working is to execute on GPU a pass rendering the elevation map of the portion of land located under the body, retrieve the result on the CPU side, and submit it to Bullet API. I had big doubts about the efficiency of this method, so I was really surprised to see that in fact it works damn well  !!
 
Finally I spent some time on shaders generating global planet's textures. To obtain a nice rendering I implemented some computations about Temperature and humidity (as in SOA project), to get realistic colors combinations on global planet textures. As I play with shaders inputs for temperature and humidity distribution algorithms, I can get different types of earth-like planets : temperate and various climates (Earth), desertic and arid planet (Dune, Jakku), warm and luxurious vegetation planet, or planet in full glacial era (Hoth). See those screengrabs just bellow...
 
Still no lighting, fog or atmospheric effects actually, this should come later.
 
Next step is texture splatting implementation (detailled textures) for planet's terrain.
 
-Nev-
 
planet2.jpg
 
planet7.jpg
 
planete5.jpg
 
planete9.jpg
 
Desert & hot planet
 
planete11.jpg
 
frozen planet
 
planete13.jpg
 
Warm and moist world
 
planete15.jpg


Quote
DarkOne
(@sscadmin)
Supreme Dark Emperor Admin
Joined: 8 years ago
Posts: 7883
 

Nice work and I guess what a learning experience at the same time. I take it that your FPS will drop once you start laying higher detailed meshes for the planet?

I can't remember if it was UDK or Unity but I swear I saw a pretty good planet/world creation script that could make life easier. Granted you loose the whole customization of your own engine but could speed your progress, but could also limit you on your overall vision of your game engine as well.

Is that distance indicator in the last pic accurate too? Nice.


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 8 years ago
Posts: 1306
 

Very nice! I've also been looking at that SOA article lately but mine is currently all CPU side.

 

Well done on getting it all integrated with Wombat, doing stuff on the GPU is just a f@#king nightmare at times!


ReplyQuote
NevilClavain
(@krakoukass)
Warrant Officer Registered
Joined: 8 years ago
Posts: 203
Topic starter  

 

 

 I take it that your FPS will drop once you start laying higher detailed meshes for the planet?

 

Yes. Actually it decrease to 80 - 100 fps, depending on the machine it running on.

I didnt posted screensgrab from low altitude because actually it renders quite ugly without details textures and I still have cracks and gaps between terrains patchs.

 

 

 

Is that distance indicator in the last pic accurate too? Nice. 

 

Yes. This planet is sized like earth (around 12000 km diameter). Having real-sized planets is an essential point for me and I hope I'll be able to hold it to the end.


ReplyQuote
Geraldine
(@geraldine)
Rear Admiral Registered
Joined: 8 years ago
Posts: 3459
 

Yaay! XFrontier is back? Maybe? Possibly? Regardless, fine work Nevil!


ReplyQuote
NevilClavain
(@krakoukass)
Warrant Officer Registered
Joined: 8 years ago
Posts: 203
Topic starter  
Hi,

 

Some screengrabs for the code generation planet surface details.

 

I'm using automatic textures composition (AKA texture splatting technique). 

 

Obviously I'm far from Elite Dangerous or Infinity terrain's rendering quality, but I like the way that textures are combined and blended. As for global textures, the shaders take account of temperature and humidity to assign color weight for each possible texture sample.

 

On the dark side, as the camera move there's an unpleasant "texture popping" effect. This is of course the result of terrain code roughly selecting different LOD patch according to camera position. Need to find an idea to attenuate this effect.

 

 

-Nev-

 

surface00.jpg

 

surface02.jpg

 

surface03.jpg

 

surface04.jpg

 

surface05.jpg


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 8 years ago
Posts: 1306
 

That's it! I'm hiring you to do Pioneers terrain from now on 😛


ReplyQuote
NevilClavain
(@krakoukass)
Warrant Officer Registered
Joined: 8 years ago
Posts: 203
Topic starter  

 

 

That's it! I'm hiring you to do Pioneers terrain from now on  😛

 

Before that I must increase my skills in openGL 4.x  😀


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 8 years ago
Posts: 1306
 

It looks like for the texture splatting you're using the same UV ranges for each tile, so 0..1, that's ok for the highest detail terrain patches but for lower detail ones you can use texture repeating so that the texels stay the same size.

 

eg:

LOD 0 UV == 0..1 // highest detail

LOD 1 UV == 0..2 // the geometry is twice the size so you repeat the texture twice, this way each texel stays the same size as for LOD 0

LOD 2 UV == 0..4 // 1,2,4,8,16,32... hmm this sequence is familiar! 😉

LOD 3 UV == 0..8 // etc

 

It does mean that you need to know the highest detail LOD you're going to use but you can usually work that out if you know the radius of your planet and have a highest detail polygon size in mind like 1m, 10m or 100 metres.


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 8 years ago
Posts: 1306
 

Also on Pioneer I've recently stopped using neighbour matching methods to avoid triangle splits and instead starting us "skirts" on the terrain patch.

This is pretty minor rendering overhead, though if you ever find yourself fillrate bound then it can be a good thing to optimise, but it means there's a lot less inter-patch linking, testing, checking and logic for the GeoMipMapping.


ReplyQuote
NevilClavain
(@krakoukass)
Warrant Officer Registered
Joined: 8 years ago
Posts: 203
Topic starter  

It looks like for the texture splatting you're using the same UV ranges for each tile, so 0..1, that's ok for the highest detail terrain patches but for lower detail ones you can use texture repeating so that the texels stay the same size.

 

eg:

LOD 0 UV == 0..1 // highest detail

LOD 1 UV == 0..2 // the geometry is twice the size so you repeat the texture twice, this way each texel stays the same size as for LOD 0

LOD 2 UV == 0..4 // 1,2,4,8,16,32... hmm this sequence is familiar! 😉

LOD 3 UV == 0..8 // etc

 

It does mean that you need to know the highest detail LOD you're going to use but you can usually work that out if you know the radius of your planet and have a highest detail polygon size in mind like 1m, 10m or 100 metres.

 

bit hard to apply in my proper case : in fact all textures used for splatting are regrouped in a single huge 2048x2048 texture (Iam using a matrix of 16x16 elements of 128x128). The U axis is temperature and the V axis is humidity.

The shader compute 4 sub textures uv coords set to sample and blend, according to the vector [T, H] provided as input (from a texture previously rendered).

Is there a way to configure the renderer to have automatic texture repetition for another UV range then [0...1] ?

 

 

 

Also on Pioneer I've recently stopped using neighbour matching methods to avoid triangle splits and instead starting us "skirts" on the terrain patch.

 

 

I also planned to use skirts, but thinking of it I dread getting some visual glitches on each covered holes once I will compute lighting for planet's surface ???


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 8 years ago
Posts: 1306
 

Ah I see, now if you're using a texture atlas then you would have to recompute the UV range repitition yourself, which will vary by mip level so can be non-trivial.

 

Skirts should be ok so long as you copy the edge data from the inner vertices, or generate the neighbours edge vertices within that patch.

The system I used for Pioneer needs some refinement, but it copies the colour, and normals from the inner vertices along each edge so that lighting shouldn't be affected (much).


ReplyQuote
NevilClavain
(@krakoukass)
Warrant Officer Registered
Joined: 8 years ago
Posts: 203
Topic starter  

Up for progress news

 

Thoses days I added a small tweak in my planet's shader to implement sand beaches over the seas edge :

 

surface06.jpg

 

surface07.jpg

 

this reminds me that the summer holidays are still far...   *sigh*

 

 

 

 

beyond that I started working on the lighting of the planet and terrain patches via the addition of bump mapping in the shaders - quite complex topic

 

setting up a test shader that accentuates the terrain relief information (bump normales computation result) - for test purpose bump factor is a bit amplified here - :

 

surface08.jpg


ReplyQuote