Thank you! I'm doing my best to create my "dream" voxel engine (within the confines of my abilities as a software engineer).
I'm considering at some point when my voxel engine is fully functional and multi-platform (Windows, Linux and maybe other OSs), I may release the voxel engine as a SDK in closed source form (object code, C++ headers, SPIR-V shader code) under a licence where free games could use it for free and commercial games would pay royalty per copy of games sold.
Yeah I'm currently planning on open sourcing my engine. what can I say, I like free stuff, I assume everybody else does as well. royalties is a pretty fair way of doing it, personally I prefer paying for a onetime license (if just for the current version).
I'm using a tree data structure (tetrahexacontree) of voxel volumes (chunks). Each voxel volume is 16x16x16 voxels in size. The tree data structure is only limited by RAM and it grows in size on the fly if something is placed outside of the tree data structure.
P.S. The tree data structure and voxel volumes primarily reside in host RAM (CPU side) where changes are made. The tree data structure and voxel volumes are also maintained / updated in buffers (parallel arrays) on the GPU RAM where the ray marching is done. The tree data structure on both CPU and GPU side consists of an array of tree nodes and an array of voxel volumes with nodes and volumes being indexed by offsets into said arrays (rather than pointers which GLSL does not support).
No need to worry about the pointer thing if the programming language you are using doesn't have them. I'm a C++ programmer, so that's why I mentioned pointer.
Yes, the volumes are stored in an array in (CPU) RAM and are modified by the CPU during volume generation, block add, remove, etc. After the volumes are modified by the CPU, updates are sent to GPU RAM via Vulkan graphics API buffers. (There will be some compute shader updating going on later, but right now it's all done CPU side.)
A tetrahexacontree is like an octree except at each node it subdivides space into 64 children (4x4x4) instead of 8 children (2x2x2) with an octree. The tetrahexacontree I've implemented is a sparse data structure. One can think of it as a squashed octree in that for a given amount of leaf nodes, it has half the depth. Less depth means better performance for ray marching because there is less moving up and down the tree (via a stack). My implementation of the tetrahexacontree has voxel volumes (16x16x16 voxels) for leaf nodes.
With a large scene loaded, I'm seeing a tetrahexacontree depth of four.
Here's a screen shot with tetrahexacontree nodes and volumes shown as wireframe cubes:
The blue lines are a corner of the tetrahexacontree root node, green wireframe cubes are nodes in between the root node and the voxel volumes, and the red wireframe cubes are the voxel volumes.
I'm planning on a full creative mode besides easy ways to build things in regular player mode (beyond building things one voxel at a time which would be tedious).
← Return to game
Comments
Log in with itch.io to leave a comment.
This project is so underrated.
Thank you! I'm doing my best to create my "dream" voxel engine (within the confines of my abilities as a software engineer).
I'm considering at some point when my voxel engine is fully functional and multi-platform (Windows, Linux and maybe other OSs), I may release the voxel engine as a SDK in closed source form (object code, C++ headers, SPIR-V shader code) under a licence where free games could use it for free and commercial games would pay royalty per copy of games sold.
Yeah I'm currently planning on open sourcing my engine. what can I say, I like free stuff, I assume everybody else does as well. royalties is a pretty fair way of doing it, personally I prefer paying for a onetime license (if just for the current version).
And the list gets longer! lol
How do you handle the voxels? chunks? octree's? one giant array? I'm just curious.
I'm using a tree data structure (tetrahexacontree) of voxel volumes (chunks). Each voxel volume is 16x16x16 voxels in size. The tree data structure is only limited by RAM and it grows in size on the fly if something is placed outside of the tree data structure.
P.S. The tree data structure and voxel volumes primarily reside in host RAM (CPU side) where changes are made. The tree data structure and voxel volumes are also maintained / updated in buffers (parallel arrays) on the GPU RAM where the ray marching is done. The tree data structure on both CPU and GPU side consists of an array of tree nodes and an array of voxel volumes with nodes and volumes being indexed by offsets into said arrays (rather than pointers which GLSL does not support).
P.S.P.S. I hope I didn't make that confusing in the way I explained it. Feel free to ask more questions.
So the volumes are stored in RAM, and updated by the GPU? (The last bit about the pointers and whatnot has my scratching my head.)
No need to worry about the pointer thing if the programming language you are using doesn't have them. I'm a C++ programmer, so that's why I mentioned pointer.
Yes, the volumes are stored in an array in (CPU) RAM and are modified by the CPU during volume generation, block add, remove, etc. After the volumes are modified by the CPU, updates are sent to GPU RAM via Vulkan graphics API buffers. (There will be some compute shader updating going on later, but right now it's all done CPU side.)
I do know what pointers are. I don't work with them yet, I'm still learning c++
(I'm still reading the rest of your reply)
So just curious, How is your tetrahexacontree differ from a sparse voxel octree?
A tetrahexacontree is like an octree except at each node it subdivides space into 64 children (4x4x4) instead of 8 children (2x2x2) with an octree. The tetrahexacontree I've implemented is a sparse data structure. One can think of it as a squashed octree in that for a given amount of leaf nodes, it has half the depth. Less depth means better performance for ray marching because there is less moving up and down the tree (via a stack). My implementation of the tetrahexacontree has voxel volumes (16x16x16 voxels) for leaf nodes.
Hmm so its just an octree, with more children per leaf? what's the depth?
With a large scene loaded, I'm seeing a tetrahexacontree depth of four.
Here's a screen shot with tetrahexacontree nodes and volumes shown as wireframe cubes:
The blue lines are a corner of the tetrahexacontree root node, green wireframe cubes are nodes in between the root node and the voxel volumes, and the red wireframe cubes are the voxel volumes.
Yes, it's just a octree with more children per node.
Here's an animated gif showing a scene with and without tetrahexacontree wireframe display (click image to see large version) :
Everything I am seeing looks so amazing. You are doing great, keep up the awesome work!
Thank you!
looks good
Thank you!
I'm planning on a full creative mode besides easy ways to build things in regular player mode (beyond building things one voxel at a time which would be tedious).
Interesting.
Thank you!