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-
Desert & hot planet
frozen planet
Warm and moist world
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.
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!
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.
Yaay! XFrontier is back? Maybe? Possibly? Regardless, fine work Nevil!
That's it! I'm hiring you to do Pioneers terrain from now on 😛
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 😀
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.
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.
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 ???
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).
Up for progress news
Thoses days I added a small tweak in my planet's shader to implement sand beaches over the seas edge :
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 - :
Latest Post: Nice to meet you Our newest member: selotgwacor Recent Posts Unread Posts
