Roadmap

This is the current outline for the upcoming Volume Component features. This page is ordered by the priority, so the topics will be tackled top down.

Green: in progress
Yellow: next

Paging

For real large worlds, paging is a must. The paged data could be the dualgrid or the actual meshes of the chunks.

Also the volume source needs to be paged, as it's not reasonable to hold a giant memory block of the texture data in memory. With procedural sources, this would work, as they naturally require not a lot of memory.

Multiple Materials

Currently, just one material for the whole volume can be used. To achieve better visuals, it would be great, if different textures in different areas could be used in the triplanar texturing. So a green island in the desert could be done. Transvoxel uses IDs stored beside the density values in the 3D grid which can be painted in the editor. The IDs reference a single texture in a texture array. This approach makes sense and could be adapted.

Marching Cubes 33

A next thing is a Marching Cubes 33 implementation. This would solve the problem that the normal Marching Cubes is internally ambiguous. Here is a public domain implementation of the over 750 needed table entries! The homepage isn't very clear about the license, but I asked him via E-Mail and he confirmed. This would be optional as it will increase the loading time.

Done since creation of this page

Editing capabilities

The only serious way to create the 3D textures needed for the terrain I'm aware of, is Acropora . But this program is not free So an editor would be awesome. For this, a few parts are still missing:

Some intersection with rays. For editing, intersection with the actual volume should be good which doesn't sound that hard.

Also a way of updating the volume data during runtime is needed ("add sphere here coming from a brush").

And the third thing is the update of the chunks. A chunk needs some milliseconds (like... 15-25ms on my dualcore?) to be created, might be practicable or not, has to be tried.

A serialization is needed which exports a 3D grid of density data. This will be done with clamped 16 bit floats and deflated so it won't be as big as a full blown 3D texture.

And a way to (de-)serialize the editing-project is needed to save and load the world-project. But this depends on how the editing works. If it only acts on the discreet grid, no other project data is to be saved. But if the editor offers the editing and buildup of complete CSG trees, then they need to be saved. Wheras this would actually be a task of the editor, not the component I guess...