Jump to content

Voxel Terrain Part 3 - Dynamic Components




Took some time to figure out the best approach to do this but I've got it now.

To start with I created components that are all the same size.  I am using 16x16x16 components.  The voxel terrain is 128^3 so dividing that evenly is 8^3 components.  In this image there is 512 of them.  The red are inactive and the green are active (they have a model the represents the surface).  This posed a problem for very large terrains.  I would need a component size small enough so that LOD and real-time editing are fast but too small and the component count would become unmanageable.


So I made an option to create dynamic components.


This means instead of a component being exactly 16m cubed in size (the lowest LOD level would have 4 vertices and two triangles for a flat plane) it would now be resized to have a mesh that is 16 nodes cubed (16x16 vertices for a flat plane regardless of LOD level).  Which mean it now looks like this;


Instead of 512 components there is only 36 and 10 of them are active.  It means I can lower the component size to something really small like 8x8x8 or even 2x2x2.  I can experiment with this to find a balance between speed of LOD updates and editing updates.



And the terrain can be represented by a minimum of 1 component.  It also means I can try creating steaming voxel terrain which would be fun!


I need to finalise the real-time LOD system to work with this and then I can begin making large terrains and test it's performance.



  • Like 2


Recommended Comments

A 4096 voxel terrain took nearly 3 seconds in debug mode to generate.  Without dynamic components it would be 16,777,216 components and would be generating long into the night.  With it, it is only 78!


  • Like 1
Link to comment

Have it working in real-time now.  The small white sphere is the viewer.  It still needs refining, instead of deleting components and then creating a new one I'll probably add the components to a "re-purpose" list.  It will save a bit of time, mainly in the creating of a new model and voxel node memory pools.  Other than that there are a few minor memory leaks.

This is all in debug mode too.


  • Like 1
Link to comment

Promising results with a 4096x4096x4096 terrain.  Takes up about 14GB of memory but the creation and updating process are very fast.


  • Like 1
Link to comment

Thinking about it, 14GB seemed way to high and I was right - the problem was I was setting up a components node pool like this;

voxel_pages = make_shared<VoxelPages>(node->bounds.size);

Using the bounds size when they were only small (16m to 32m) were fine but when I made components as big as the terrain itself (4096m) it wasn't a good idea.  Some components were allocating 2048*2048 page size, so about 4 million nodes at one (1.6GB) and it only used a dozen of them from the pool.

Making each page the size of the component fixed it right up. :D

voxel_pages = make_shared<VoxelPages>(component_size);

The 4K terrain now only uses 800MB.  ^_^

  • Like 2
Link to comment

Fixed a few issues.  I was only allocating enough voxel memory pages for the final level of subdivision that represented the surface.  I didn't take into account the fact that I needed space for the all their parent nodes too.

Also have finally removed double vertices with the TransVoxel method.  In one scene there was 108k vertices, after the fix it went down to 30k.  About a 72% decrease! :D

  • Like 1
Link to comment
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...