I am an experirenced opengl dev making 3D tools (but not games) for a while now, and my potential next project is a voxel editor similar to Voxedit or the editor in sandbox.game.

I am looking for resources how to make similar rendering editor, when I searched the net and even youtube tutorials, I can see there are tutorials but most of them are solely focused on terrain generation and rendering and all of them are not even complete, missing the part of the actual edit of the voxels like adding, delete, ALL of them.

Do you guys know any resources, links, books, opensource code (that is easy to understand) that I can refer to for me to start the project running?
Like what i said, I am an experienced OpenGL dev, but I just need a guide on how to start with voxel world (editor that is).

I can recommend Paul Bourke's mc article. Dated, and it's advisable to read about other polygonisation techniques, but it's fairly simple, well-written and helped me when I was first starting out rendering voxels.

Magica Voxel has good usability and all those features, but only for low resolution. I would use it as the reference when learning what users expect from previous experience with voxel editors.

When I made my own voxel engine for infinite space in high resolution, I used fixed-size regions of axis aligned bounding boxes for compression. The advantage is that you can dynamically use one visual box per compressed box until a background thread has completed an optimized polygon model for the whole 30x30 meter region. Reducing draw calls to a few large chunks will make GPU rendering super fast so that you can have 256 lightsources at the same time for global ambient occlusion. By merging many small boxes and randomly flipping L shapes to get more matches, the volume will eventually become near optimal in compression. It also allow getting rid of limitations to size and resolution when it's just a list of integer boxes in the file.

SuperVGA said:

I can recommend Paul Bourke's mc article. Dated, and it's advisable to read about other polygonisation techniques, but it's fairly simple, well-written and helped me when I was first starting out rendering voxels.

Great idea. However, the source code on Bourke's site is not complete, because on that page he does not tell you how to fill in the grid cube data. If one wants the whole code, check out tesselate_adjacent_xy_plane_pair(): https://github.com/sjhalayka/marching_cubes/blob/master/marching_cubes.h​​

The code takes two 2D bitmaps and spits out triangles by making grid cubes.

taby said:

SuperVGA said:

I can recommend Paul Bourke's mc article. Dated, and it's advisable to read about other polygonisation techniques, but it's fairly simple, well-written and helped me when I was first starting out rendering voxels.

Great idea. However, the source code on Bourke's site is not complete, because on that page he does not tell you how to fill in the grid cube data.

Grid cube data? It's exactly polygonising a scalar field, so I'm not sure I'd call it incomplete. It's great at demonstrating just that.

Of course it doesn't come all around the concept of voxels for the purpose if building with little cubes, but that doesn't subtract from its value, IMO…

Sorry, I didn't mean to sound like I was disparaging the guy. I too learned about Marching Cubes from his page. On his page he also recommends that one sorts the vertices before interpolation. He doesn't say that I'm the one who showed that him that this was the solution. The reason is to get rid of cracks in the mesh, and it works because if you don't sort the vertices, you get a different output, because for each vertex pair in the cubes the operation order is different. If you sort the vertices, the same order of operation occurs whenever that vertex pair is considered (and on average this is many times), and so the same answer is given every time. This is all when using float. Using double does not generate cracks.

taby said:

Sorry, I didn't mean to sound like I was disparaging the guy. I too learned about Marching Cubes from his page. On his page he also recommends that one sorts the vertices before interpolation. He doesn't say that I'm the one who showed that him that this was the solution. The reason is to get rid of cracks in the mesh, and it works because if you don't sort the vertices, you get a different output, because for each vertex pair in the cubes the operation order is different. If you sort the vertices, the same order of operation occurs whenever that vertex pair is considered (and on average this is many times), and so the same answer is given every time. This is all when using float. Using double does not generate cracks.

No problem - I guess there are different ways to go about getting introduced to voxels. I just remembered doing this first, and I agree, the resulting mesh does get a bit wonky.

Yes, the reason I even stumbled upon the cracks was because after you do Taubin smoothing or whatnot, the cracks turn to gaping holes. And I used float instead of double because the STL file consists of a whole bunch of floats and ints.

As for using booleans for voxels, it's going to turn the mesh into an ugly piece of ****. Voxels should be floats, not booleans.

It is also possible to accelerate the Marching Cubes algorithm by converting it to a geometry shader. You'll need to use OpenGL 4 for this kind of thing. In fact, I am waiting from experts on how to perform the feedback transform to read the triangles generated by the geometry shader, so it's not all good until I get a solution from them.

Hi,

At first, octree looks like a good idea, but don't do it. It will s*ck on the long run. Read this: https://0fps.net/2012/01/14/an-analysis-of-minecraft-like-engines/​

For storing voxel images, I recommend Model 3D: https://gitlab.com/bztsrc/model3d/-/blob/master/docs/voxel_format.md​ Has an stb-style, dependency-free single header, for both C and C++. It is very space-efficient and easy to read format. An example voxel image is here https://bztsrc.gitlab.io/model3d/​ (click on Models / Geometry / Notre Dame). More than half a million colorful voxels stored in a file as small as 17k. The SDK also automatically converts voxels into triangle meshes for your application, source code here: https://gitlab.com/bztsrc/model3d/-/blob/master/m3d.h#L3838​ Although admitedly this is not the best solution, but performs face culling and it is lightning fast and supports skeletal animations on voxel blocks. If you want, you can stream-read blocks to support infinite voxel worlds (however for that you need to store the world in blocks in the file).

Furthermore it has a converter which can convert virtually all voxel formats into m3d (Minecraft schematics, Magicavoxel, binvox, Qubicle, etc.), and there's export support for Goxel (another voxel editor).

As an extra, you can also use this SDK to load any models, not just voxel images, the converter supports 3ds, dae, gltf, fbx, etc. you name it; and there's a Blender exporter plugin too.

Cheers,
bzt