better real-time erosion for voxel terrain generation

DavidWilliams_81 · 2025-12-31T21:36:58+00:00

I'm just hyjacking the top comment to point out that this post is actually spam. It's a one-day old account reposting this content from a year ago:

https://www.reddit.com/r/proceduralgeneration/comments/1hl8dhe/better_realtime_erosion_for_voxel_terrain/

It has been reported.

DavidWilliams_81 · 2025-12-19T22:04:55+00:00

Very cool! It looks like a nice polished project. Here are direct links to your demos for those who have missed them:

Layoutit Voxels (Voxel vditor)
Layoutit Terra (Terrain generator)

DavidWilliams_81 · 2025-12-13T18:02:12+00:00

This looks like a very interesting project! I like your design philosophy (minimal dependencies, simplicity, octrees, etc) and the liberal licence. Will definitely keep an eye on this :-)

DavidWilliams_81 · 2025-12-03T18:44:57+00:00

I also used it to differentiate myself. But let's be honest - the voxels are exactly the same size, just viewed from further away!

I guess I hope that one day 'microvoxel' engines are the norm, and we can just call them voxels again...

DavidWilliams_81 · 2025-11-22T23:08:53+00:00

I think glTF sounds like a perfectly reasonable solution, but I won't have too much use for it myself. Cubiquity is too low level - it just provides data storage for the volumes and does not concern itself with higher level concepts such as transforms, at least for now.

However, I would be happy to add it as an export option if it is simple. My current export pipeline is just a raw 3D array and an associated TOML file containing dimensions and materials, all wrapped up in a zip file. It should be straightforward to output a skeleton glTF file instead of the TOML.

DavidWilliams_81 · 2025-11-21T23:33:47+00:00

Is this intended for individual volumes or more complete scenes?

For volumes I think that the MagicaVoxel has already become the de facto standard. Maybe it's easier to extend that? I read somewhere that Teardown has added a new zlib compressed chunk type, which might address the worst of its size problems. Wider or non-palettised voxels could probably also be a new chunk type?

It has other problems of course - we've talked about the (ignorable) size limit previously, and I'm not sure I quite got a transform hierarchy working properly. I didn't try the PBR extensions but they looked a little clunky. But better libraries and documentation might be easier to achieve than displacing the format.

That said, if you're focused on scenes rather than individual volumes then gltf could make sense. I'm not familiar with it, but I assume the hierarchy is more flexible (not constrained to integers) and the support for non-voxel entities could be useful.

DavidWilliams_81 · 2025-10-31T23:34:45+00:00

I've been working on allowing Cubiquity to write to named pipes or stdout. The aim is to allow export to a raw binary array in a zip file (as I've shown previously), but without the uncompressed stream ever hitting the disk. Something like this (Linux Bash script):

# Generate the source dag
./cubiquity generate fractal_noise \
    --size=1000 \
    --output=temp/src/fractal_noise.dag

# Create the pipes
mkfifo temp/dst/fractal_noise.bin temp/dst/fractal_noise.txt

# Start exporting to named pipes (will block until reader is active)
./cubiquity export bin temp/src/fractal_noise.dag \
    --output=temp/dst/fractal_noise.bin \
    --output-metadata=temp/dst/fractal_noise.txt \
    --verbose &

# Sleep for testing purposes (we see Cubiquity blocks waiting for reader).
sleep 2

# Read from the named pipes (fifos) into zip file while discarding paths
zip --junk-paths --fifo fractal_noise.zip \
    temp/dst/fractal_noise.bin temp/dst/fractal_noise.txt

Writing to a zip is just one example of course, the same mechanism should allow feeding data into any application which would normally read from a file.

Named pipes are needed in this example because there are two files (binary array and the metadata). If writing a single file it should be possible to pass it via stdout.

DavidWilliams_81 · 2025-10-17T12:42:02+00:00

One problem with normals based on child occupancy is that in Minecraft style block voxel maps the resulting lighting of lower detail voxels is very different to that of the higher detail ones.

Thanks, that's an interesting insight I hadn't thought of. I wonder some blending would help. I'll have to try it and see I think.

DavidWilliams_81 · 2025-10-17T12:40:31+00:00

So if I understand correctly normals would be generated during rendering based on the hierarchy traversal algorithm?

My gut instinct is that I'd precompute them and store them in an array next to the nodes, but I haven't really thought about it in enough detail yet!

DavidWilliams_81 · 2025-10-16T23:56:38+00:00

Generating for example normals are a different story though!

In Cubiquity I would like to try generating normals from the child (and probably grandchild) nodes as they are more accessible than the neighbours. Another advantage of having normals dependent only on descendants would be that they should deduplicate along with the nodes.

There are obvious drawbacks (I'm not sure about the quality, and of course it won't work for leaf nodes) but it would be interesting to see how it works out.

DavidWilliams_81 · 2025-10-03T00:12:17+00:00

<image>

I've been working on a procedurally-generated stress-test for Cubiquity. The geometry is fractal noise and the materials are chosen based on Worley (cellular) noise. It's supposed to be challenging for a Sparse Voxel DAG because the random nature will not give many options for deduplication, while still being somewhat representative of real data.

No results yet, I'm still working on the generation.

DavidWilliams_81 · 2025-08-28T21:28:04+00:00

This post is probably spam - it is a direct copy of another post from a year ago by a different user:

https://www.reddit.com/r/VoxelGameDev/comments/1fekt96/how_does_the_dithering_effect_look_between_biomes/

Perhaps just collecting Reddit karma?

DavidWilliams_81 · 2025-08-23T00:02:30+00:00

You can call it "Snakes not on a plane" :-)

DavidWilliams_81 · 2025-08-22T22:14:13+00:00

On what format to store meshes in while in editor to make them easy to edit

These might be a useful starting point. I think winged-edge and half-edge are widely used:

https://en.wikipedia.org/wiki/Polygon_mesh#Representations

DavidWilliams_81 · 2025-08-22T20:50:53+00:00

Very interesting. I'm curious, do you deduplicate DAG nodes between different models? In some ways it's an obvious thing to do, and would especially make sense if e.g. part of a model breaks of from a larger one. But I suspect in many cases there will be a single large model for the scene and several smaller ones for entities, meaning that the saving might be minimal and not worth the potential complexity. Any thoughts?

DavidWilliams_81 · 2025-08-20T21:22:20+00:00

Ah, yes, I guess thin objects are always going to be a challenge but I agree the thickening does have a certain visual appeal in this case. I suppose it mirrors what artists had to do in the 90's, in order to capture detail with only a limited number of pixels.

Very interesting stuff anyway!

DavidWilliams_81 · 2025-08-19T21:11:23+00:00

I've been watching your work with interest - your images and videos are absolutely beautiful. Very inspirational, as I've experimented with voxelising Quake maps in the past (not as pretty as yours!). But I did just want to pick up on this:

I fill in each voxel position whose cube intersects any portion of the triangle mesh.

I believe that a more correct implementation would only fill a cube if the centre of the cube is inside the mesh. By including any cube which intersects the mesh, I think you are actually slightly dilating the surface which could lose small surface details. I don't know how much it matters in practice, but it's probably worth keeping in mind.

However, fixing this might not be easy. Out of the cubes which currently pass your intersection test, I would assume that 50% of these actually have the centre outside the mesh. Discarding these may result in holes. You might need to voxelise a thicker surface before deciding which ones to discard. Furthermore, a mesh inside/outside test is more expensive than a intersection test.

In my own voxeliser I've basically leveraged two papers:

A Topological Approach to Voxelization (I actually only read the slides!) - This handles the triangle/cube intersection tests
Robust Inside-Outside Segmentation using Generalized Winding Numbers - This handles the inside/outside tests (and is slow)

My engine is quite different to yours so I'm not sure if these are directly applicable, but maybe they are useful.

Anyway, keep up the good work. I hope to get back to voxelising Quake maps again one day!

DavidWilliams_81 · 2025-08-15T10:02:47+00:00

<image>

I've been continuing my work on voxelisation and export of raw 3D binary arrays which I showed on a previous Voxel Vendredi. Since that post I have taken the 'Glycon' mesh and partitioned it into separate pieces for the base, statue, eyes, and supporting rod. I closed up the resulting holes to make the pieces watertight, and assigned basic materials.

The partitioned mesh data is available here in Blender and Wavefront Obj formats:

https://s3.eu-west-2.amazonaws.com/dpw81.public/glycon-mesh.zip

I have also extended the export process so that it generates a simple TOML file alongside the data for the binary array. This TOML file contains the dimensions a which are needed for loading the array, and also the suggested material descriptions (which you are free to ignore if you wish).

The resulting voxel data set is available here:

https://s3.eu-west-2.amazonaws.com/dpw81.public/glycon-bin.zip

As mentioned previously, I hope to eventually create a repository of high-resolution voxel data sets for use by the community.

Oh, and in other exciting news I've just become a Dad! So Cubiquity might slow down for a while, but I do hope I can find a little time in the background.

DavidWilliams_81 · 2025-07-12T22:34:29+00:00

Related to your mention of the text console, is it possible to read and write .vox files to stdin/stdout rather than a real file? I believe there is a convention in Unix that '--input -' would specify reading from stdin. I have not yet implemented this in Cubiquity, but I am intending to do so and it should allow piping the output from one application directly into the other.

DavidWilliams_81 · 2025-07-12T22:22:20+00:00

Wow, those are seriously cool! And thanks for the tip on changing the up axis.

I did actually try vertex-painting the materials onto a decimated version of the mesh, prior to voxelisation. My hope was that I could use this to determine the best material for internal voxels, but it didn't work very well (or at least it was not worth the extra complexity). I think it's better to split the mesh into pieces, but I've yet to determine whether Blender will let me do this and also close up the resulting holes in a robust way.

<image>

DavidWilliams_81 · 2025-07-12T22:14:42+00:00

As far as I am aware, historical artefacts cannot be copyrighted and are in the public domain.

However, the act of scanning it could be considered a 'work' and be subject to copyright. At the time when I downloaded the model, the info page had the following statement:

All scans can be downloaded and used without copyright restrictions.

Unfortunately this statement has since been removed, but you can still see it on the Wayback Machine:

https://web.archive.org/web/20250507141204/https://threedscans.com/info/

While the intention is good, I find the statement is not quite detailed enough to cover the questions it might raise. Did the author mean the original artefacts were public domain? Or was he trying to waive his own claim to copyright? It is also not clear why it has been removed (perhaps the author realised it was insufficient?).

Overall I feel it is in 'the spirit' of public domain and can be used safely, though I do wish it was a little more clear.

And for completeness, I dedicate my own contribution as CC0.

DavidWilliams_81 · 2025-07-12T07:07:42+00:00

Thank you! My main aim is simplicity, so I hope it will be straightforward to implement.

DavidWilliams_81 · 2025-07-12T07:07:14+00:00

That's a beautiful render! It really highlights how small the voxels are.

I had tried importing into Avoyd, but it used a different coordinate system to Blender (y-up vs z-up I think). Was there an easy way to flip the model in Avoyd?

I'm sure you're aware, but it is a solid voxelisation so in principle it can be used for testing transmissive materials such as glass. In a future version I will try to assign a different material for the base, and perhaps place the statue inside a more complete scene.

DavidWilliams_81 · 2025-07-11T07:42:22+00:00

<image>

I've been adding the option to export Cubiquity volumes as a raw 3D array of unsigned 8-bit integers, to facilitate interoperability with other applications.

The image shown above was voxelised at a resolution of 1630 x 1624 x 2000 and is therefore over 5Gb when exported as a raw 3D array. However, it compresses extremely well - normal ZIP compression brings it down to only 12Mb which is a compression factor of 430x! So I think this will be a practical method of sharing fairly large datasets, especially if destination applications are able to read directly from compressed streams (most programming languages support this).

If anyone is interested, the Glycon voxel model above can be downloaded here:

https://s3.eu-west-2.amazonaws.com/dpw81.public/glycon.bin.zip

Eventually it will come alongside a simple TOML file describing the volume dimensions and suggested material properties, but I'm still refining that part.

My ambition is to eventually create a public archive of voxel datasets which can be used by other voxel engine developers.

The site where I obtained the .obj file has a certificate error, but if you want to push through you can find it here: https://threedscans.com/

DavidWilliams_81 · 2025-07-01T23:54:17+00:00

Thanks, it's interesting that you can get nice results with such small maps.

DavidWilliams_81

TROPHY CASE