Real Time Procedurally Generated Terrain
by Bill Vee · 09/09/2012 (5:31 pm) · 15 comments
After a little over a year and a half more of research into generating terrain for video games I have come to the conclusion that height based terrains like T3D ,and virtually every other 3d game engine have, are simply out dated.
As it turns out one game engine has a very well developed non-height based terrain system.
The C4 game engine has a very good system based off marching cubes. However it is less than stellar with its multi-player capabilities. After purchasing a license and understanding C4's implantation of the marching cubes method of terrain generation it was clear that this would not work for T3D. So I started from scratch and implemented marching cubes in T3D. This is the results so far after about a months worth of work in T3D.
The terrain is generated on the fly and is saved to disk for faster retrieval. It only generates a normal terrain right now , no caves or overhangs, but as you can see "digging" into the terrain is possible. The method to generate each terrain cell is very CPU intensive and will only get more so when I get it to generate terrains like Minecraft but once the cell is generated and saved to disk, loading it again is very fast.
Right now there is little optimization. It is mostly a proof of concept.
The videos were made on my laptop with Fraps and the second I started capturing the video it loses about 10 frames per second. When not using Fraps the terrains is generated quickly enough to keep the player at the center of the generated terrain and catching up to the "edge" of the generated terrain is not easy to do.
As it turns out one game engine has a very well developed non-height based terrain system.
The C4 game engine has a very good system based off marching cubes. However it is less than stellar with its multi-player capabilities. After purchasing a license and understanding C4's implantation of the marching cubes method of terrain generation it was clear that this would not work for T3D. So I started from scratch and implemented marching cubes in T3D. This is the results so far after about a months worth of work in T3D.
The terrain is generated on the fly and is saved to disk for faster retrieval. It only generates a normal terrain right now , no caves or overhangs, but as you can see "digging" into the terrain is possible. The method to generate each terrain cell is very CPU intensive and will only get more so when I get it to generate terrains like Minecraft but once the cell is generated and saved to disk, loading it again is very fast.
Right now there is little optimization. It is mostly a proof of concept.
The videos were made on my laptop with Fraps and the second I started capturing the video it loses about 10 frames per second. When not using Fraps the terrains is generated quickly enough to keep the player at the center of the generated terrain and catching up to the "edge" of the generated terrain is not easy to do.
About the author
#2
Did you use an existing codebase for the marching cubes, or did you implement from scratch?
This is really good work BTW!
09/09/2012 (6:04 pm)
You could speed it up for multicore machines by doing the calcs in threads.Did you use an existing codebase for the marching cubes, or did you implement from scratch?
This is really good work BTW!
#3
09/09/2012 (8:09 pm)
Any chance of you planning on throwing this up for others to look at/make use of at some point? Because oh man, that's too amazing to pass up on. Very awesome work thus far.
#4
Did you have issues (repetition and seams) with the built-in RNG? A while ago I worked on endless procedural terrain, and a Mersenne-Twister RNG worked way better than any of the built-in ones.
Also, what sizes are the chunks you load? Did you have a floor and a ceiling or do your chunks go on for eternity in all 3 dimensions?
Very exciting stuff! :)
09/10/2012 (12:08 am)
Awesome work, Bill! Looks brilliant! How do you do the texturing? Do you use a custom shader? I understand that convincingly texturing voxel based geometry can be quite the task.Did you have issues (repetition and seams) with the built-in RNG? A while ago I worked on endless procedural terrain, and a Mersenne-Twister RNG worked way better than any of the built-in ones.
Also, what sizes are the chunks you load? Did you have a floor and a ceiling or do your chunks go on for eternity in all 3 dimensions?
Very exciting stuff! :)
#5
-with all you guys showing off real nifty visions and work :)
09/10/2012 (12:37 am)
Very interesting stuff, and my it seems like it's terrain month...-with all you guys showing off real nifty visions and work :)
#6
09/10/2012 (2:33 am)
That's some very cool work there, Bill. I was going to say 'don't tell Frank' but it seems I'm late to the party. Looking forward to seeing where you go with this. 
#7
am loving the tunneling as well as the on the fly terrain,
really very very nice, am going to have to keep an eye on this one :-)
09/10/2012 (3:19 am)
That really is very nice, is it TorqueScript or C++?am loving the tunneling as well as the on the fly terrain,
really very very nice, am going to have to keep an eye on this one :-)
#8
You might want to move it on a separate thread.
If you plan to use a lightmap, you have to implement some kind of Dynamic lightmapping as well.
09/10/2012 (4:26 am)
Looks great so far.You might want to move it on a separate thread.
If you plan to use a lightmap, you have to implement some kind of Dynamic lightmapping as well.
#9
09/10/2012 (5:38 am)
Nice looking stuff!!!!!
#10
09/10/2012 (5:38 am)
**DOUBLE POST**
#11
I am experimenting with threading but my current code is less than thread safe.
@ Frank Carney
I am using a heavily modified version of PolyVox. It is a great base to draw on. I would highly recommend reading as much about marching cubes first before diving into PolyVox. I suggest starting with Polygonising a scalar field by Paul Bourke. If you can get you head around that then the rest is easy.
@ Konrad Kiss
I use a custom Tri-Planer shader for texturing. There are seams but only between the hi and low detail version of each chunk. But when just hi detail is used no seams are possible on the geometry or texture. For the geometry each "border" vertexs are shared between each chunk ,as for textures as long as the texture is seamless then the terrain will be too. The shader uses the world position of each pixel to calculate it's value so no stretched out pixels on any surface. While I say Tri-Planer it can actually use 6 different textures, 1 for the "floor" 1 for the "ceiling" 1 for east facing 1 for west facing 1 for north and 1 for south. While the east-west and north-south are trivial and currently use the same texture,1 for each pair, the floor and ceiling are useful for having grass on the floor and rocks or dirt on the ceiling.
The size of the chunks in the video are 16 X 16. I have experimented with bigger chunks , 64 X 64, and while no noticeable performance issues arise from generating each chunk there is one when you "edit" a chunk, up to 8 chunks must be recalculated and it can be very noticeable.
As for RNG , I use a single seed number that generates several other seeds that are used for things like land type , ridged-multifractal , billow and terrace calculations that I hope eliminate any possibility of repetition.
The only limit on it is in the vertical. In the video I limit the chunks from z=0 to z = 6 * chunk size (16) or 6 * 16 = 96. But the x and y dimensions are effectively only limited by floating point precision . I could remove the z limit for non-traditional environments without much problem.
@ - David (Robert) Pemberton
Both C++ and script. Mostly C++.
09/10/2012 (6:00 am)
@ Frank Carney & Ivan MandzhukovI am experimenting with threading but my current code is less than thread safe.
@ Frank Carney
I am using a heavily modified version of PolyVox. It is a great base to draw on. I would highly recommend reading as much about marching cubes first before diving into PolyVox. I suggest starting with Polygonising a scalar field by Paul Bourke. If you can get you head around that then the rest is easy.
@ Konrad Kiss
I use a custom Tri-Planer shader for texturing. There are seams but only between the hi and low detail version of each chunk. But when just hi detail is used no seams are possible on the geometry or texture. For the geometry each "border" vertexs are shared between each chunk ,as for textures as long as the texture is seamless then the terrain will be too. The shader uses the world position of each pixel to calculate it's value so no stretched out pixels on any surface. While I say Tri-Planer it can actually use 6 different textures, 1 for the "floor" 1 for the "ceiling" 1 for east facing 1 for west facing 1 for north and 1 for south. While the east-west and north-south are trivial and currently use the same texture,1 for each pair, the floor and ceiling are useful for having grass on the floor and rocks or dirt on the ceiling.
The size of the chunks in the video are 16 X 16. I have experimented with bigger chunks , 64 X 64, and while no noticeable performance issues arise from generating each chunk there is one when you "edit" a chunk, up to 8 chunks must be recalculated and it can be very noticeable.
As for RNG , I use a single seed number that generates several other seeds that are used for things like land type , ridged-multifractal , billow and terrace calculations that I hope eliminate any possibility of repetition.
The only limit on it is in the vertical. In the video I limit the chunks from z=0 to z = 6 * chunk size (16) or 6 * 16 = 96. But the x and y dimensions are effectively only limited by floating point precision . I could remove the z limit for non-traditional environments without much problem.
@ - David (Robert) Pemberton
Both C++ and script. Mostly C++.
#12
Thanks for the link. It is on my list of things to check out. I was thinking rather than actually building the terrain that I use PolyVox to build objects like cliffs, overhangs, caves, arches, etc. That sway I can get the speed of the terrain generation and augment it with features made out of polyvox. It would be like a shapebase object. I was also thinking of creating procedural shapebase objects to accomplish the same task.
09/10/2012 (9:48 pm)
@Bill,Thanks for the link. It is on my list of things to check out. I was thinking rather than actually building the terrain that I use PolyVox to build objects like cliffs, overhangs, caves, arches, etc. That sway I can get the speed of the terrain generation and augment it with features made out of polyvox. It would be like a shapebase object. I was also thinking of creating procedural shapebase objects to accomplish the same task.
#13
I look forward the next stage ;)
09/11/2012 (5:38 am)
Awesome! I just discover PolyVox with your blod, it is very exciting.I look forward the next stage ;)
#14
09/20/2012 (9:17 pm)
@Bill Vee - Do you plan to make this an open source asset?
#15
09/21/2012 (4:46 am)
@Benjamin - I don't know yet. I have a lot more to do on it. 
Associate Steve Acaster
[YorkshireRifles.com]