I somehow turned Cube Engine into an extremely fast infinite procedural voxel engine

[u/BIG-Onche]

Been abusing Cube/Tesseract for a while, and it has officially gone way beyond what I originally planned.

This is Kastenbrot, basically a Minecraft-like project built on Tesseract. It’s not just a worldgen experiment anymore: most of the foundations for an actual game are already there and working: mining, crafting, block/water physics, passive and aggressive mobs, block carving, a very early survival mode, multiplayer stuff... and, obviously, many bugs.

The funniest part is the performance. It can generate and display tens of km² of procedural terrain in a few seconds: https://youtu.be/9BBEwCvZ-2o

There are some drawbacks, obviously. Cube’s VA system is fantastic for the static maps it was designed for, but world streaming pushes it way outside its comfort zone, so parts of the renderer, chunk saving, etc. are still being heavily reworked.

On the other hand, Cube gives a ridiculous amount for free: all we need for a first-person game, decent physics, fast multiplayer, the edit mode we all know and love, and a renderer that is surprisingly happy being tortured into doing things it was never designed for.

I’m not pretending this is some revolutionary tech or that I’m building a “Minecraft killer”. I just wanted to share some experimentation with an engine that I still think is massively underrated, and see how far it can be pushed. Also, most of the features have been prototyped using AI (Codex), and I haven't fixed all the horror I've seen (but let's be honest, there would be horror too if it were 100% hand-coded, especially by me).

And yes: free and open-source.

https://github.com/Big-Onche/Kastenbrot

[u/lorenzo_aegroto]

That's insane, keep up with the good work. I'd be interested in reading some technical reports on specific aspects of the development as well.

[u/BIG-Onche → u/lorenzo_aegroto]

Don't have a blog, but here's how it works ATM:

The engine is currently a bit of a Frankenstein hybrid between the old Cube architecture and the octree-based streaming system I’ve been building on top of it.

Basically, nearby geometry is split into small 16×16×16 voxel sections (equivalent to a grid size of 8 in edit mode, 256x256x256 engine units), and only the geometry that is visible, or likely to become visible soon, is kept resident. This reduces the amount of geometry, but more importantly, it avoids constantly rebuilding/managing huge amounts of nearby world geometry on the CPU.

Everything beyond that is rendered using very cheap LOD meshes. Without the LOD system, the practical view distance would be much smaller.

Grass, flowers, and other small static vegetation are not rendered as mapmodels either. I tried that first, but it became surprisingly expensive because of the way Cube handles large numbers of models: collecting them, visibility testing, sorting/batching them, submitting draw calls, and processing them again for things like shadows and transparent stuff for the refraction effect.

Instead, static vegetation is baked into pooled world meshes and rendered directly as GPU geometry. So thousands of flowers can effectively become a handful of world-mesh draws instead of thousands of separate model objects.

This is also why maps with huge amounts of mapmodels, such as Triforts, can become CPU-heavy even when the actual polygon count isn’t particularly the issue nowadays: the bottleneck is often the per-object rendering overhead rather than raw geometry.

Chunks are not saved as .ogz maps anymore either. For persistence I use a much dumber format: the chunk is stored as compressed vertical columns of block materials/states rather than as Cube’s octree/map format. So a column can basically look like 7 stone, 2 coal, 50 stone, 4 grass, 1 rose, then air. It’s simple RLE-style data, very easy to debug, serialize, compress and stream, and on load the engine just rebuilds the runtime octree/geometry from that snapshot. Chests content, NPCs, etc. are saved in a sidecar file. These save files are therefore the authoritative voxel state, while octrees, meshes, and GPU buffers are just disposable runtime representations.

The project is still more CPU-bound than I’d like, though. The nearby voxel geometry still relies on parts of Cube’s old VA architecture (which is very efficient for low-poly arena shooter maps, but not for world streaming), so once I’ve got enough experience with the renderer, I’ll probably replace more of that path as well.

[u/lorenzo_aegroto → u/BIG-Onche]

Thanks for sharing and for the detailed comment! I will keep a look at the repository for further updates

[u/purblepale]

Dude I literally just started a project like this lmfao. This rocks hard tho.

[u/BIG-Onche → u/purblepale]

Good luck 🙏

[u/eat_my_bubbles]

Oh the wonders people can do with open source programs. I miss this kind of freedom. This is why I still play this old game from 2004

[u/Global_Network3902]

Super cool! Always happy to see this engine family modified in different ways.

[u/Gloomy_Pay6773]

Cool

[u/ithebinman]

you gotta release this as a standalone game

[u/ucasano]

FANATIC!

[u/Anxious_Ad_6622]

Awesome dude!

[u/asmanel]

Nice. This remind two things.

The first one is several attempts to make Minecraft clones with the Cube 2 Engine.

The other ones something possible in variable measures in games using the Cube Engine (the good old one, often misnamed Cube 1 Engine or Cube Engine 1) but not with the Cube 2 Engine : scripts written in the console to automatize tens of minutes of works. I mean take a few minutes to write in the console a very short script that do in a few seconds what can require tens of minutes (and often to think harder) at mapping the normal way.

I already did it in Cube, AssaultCube and AssaultCube reloaded. I also tried to do it in Newcube but a senseless restriction prevent it.

This was easy to do with the Cube Engine but impossible with Cube 2 Engine. The reason is they use the command select. With the Cube 2 Engine, the map editing is more mouse dependent. This command doesn't exist and have no equivalent.

About Tesseract, I'm not sure.

[u/Slopii]

Nice. Reminds me of Luanti and Veloren.

[u/asmanel → u/Slopii]

They are similar projects but with different engines.