Procedural Terrain update
by Bill Vee · 10/03/2012 (6:28 am) · 6 comments
I spent the last week optimizing and making the terrain code faster and thread safe.
I like the results so far. Right now I am using 1 thread to do the heavy lifting on the procedural code and having the main thread queue chunks of terrain to be processed and sending them to the processing thread as it becomes available for more work. I can expand this to use more threads but using just 1 right now the difference is very noticeable.
I posted a link to a video on my website showing the new terrain generation speed.
www.dayofwar.com/tiki-view_blog_post.php?postId=13
I have also worked on a user interface to preview a terrain based on user defined settings.
I like the results so far. Right now I am using 1 thread to do the heavy lifting on the procedural code and having the main thread queue chunks of terrain to be processed and sending them to the processing thread as it becomes available for more work. I can expand this to use more threads but using just 1 right now the difference is very noticeable.
I posted a link to a video on my website showing the new terrain generation speed.
www.dayofwar.com/tiki-view_blog_post.php?postId=13
I have also worked on a user interface to preview a terrain based on user defined settings.
About the author
#2
In the case of a huge height map it could be adapted to load it instead of the procedural code I use. After all to get the terrain the way I have it now the code starts with data that can be thought of as a "infinitely" large height map.
I say "infinitely" but the real limit is floating point precision.
You can only do so much with a 32 bit float.
10/03/2012 (8:11 am)
@ Lukas - Yes. When I create a terrain chunk it is saved to file for later retrieval. Overall it becomes faster to load from file than to generate on the fly. In the case of a huge height map it could be adapted to load it instead of the procedural code I use. After all to get the terrain the way I have it now the code starts with data that can be thought of as a "infinitely" large height map.
I say "infinitely" but the real limit is floating point precision.
You can only do so much with a 32 bit float.
#3
This is looking awesome Bill!
10/03/2012 (12:46 pm)
That limits your x and y too unless you keep the player at the origin.This is looking awesome Bill!
#4
10/03/2012 (1:20 pm)
@ Frank - When I said "infinitely" large height map I was referring to the x and y, the z can be ranged. But yes floating point precision becomes very problematic with this style of game but the size of the terrain you can safely use are very large. 
#5
10/04/2012 (4:27 am)
I would be very interested in seing a streamed height map variation of this! :) Would be great for mmos and what not! :) 
#6
10/05/2012 (4:15 am)
I would definitely be interested in this. 
Torque Owner Lukas Joergensen
WinterLeaf Entertainment