The author mentions simplicity in their Readme. I would be very interested to read their journey and some of the decisions they made where they preferred simplicity. More of this please !
I've been thinking of doing a series of blogs on the journey but .. it's been a journey, which is a lot to write about in full. In short, a few places where I've been able to prefer simplicity:
1. Allocators are all pretty much as simple as you can get. Most memory in the program is bump/arena allocated. There is a buddy-style heap allocator for things that are annoying to arena allocate (strings that can be edited, for example). I make heavy use of temp memory and freelists.
2. Containers are all very straight-forward, and it's definitely a feature. The example I always give here is std::map from C++. On paper, it looks great; it has very good looking properties. In practice, the implementation is a nightmare; it's slow, and has a comically large rebalancing-shaped performance cliff. My containers strive to be simple, with reasonable average and worst-case performance.
3. I wrote my own metaprogramming language instead of using C++ template metaprogramming. Writing an entire programming language sounds like the antithesis of simplicity, but in reality, having a good metaprogramming layer makes your life immeasurably easier in the long run. With strong metaprogramming capabilities, stuff like realtime debug UI and state serialization becomes nearly trivial. Once you start doing versioned data serialization in C++, you quickly realize you need a better compiler (see: protobuf, cap'n proto)
It's actually more efficient to do a hybrid approach, especially at high view distances. Rasterizing triangles is extremely fast, and is basically a perfect primary-ray intersection. Ethan Gore recently did some experiments with raytracing and said that for large scene volumes (his engine comfortably renders the entire 32-bit range, or 4B^3) it turns out to be faster to do raster for primary rays and raytrace shadows/GI.
I've always wondered why voxel engines tend to produce output that looks so blocky. I didn't realize it was a performance issue.
Still, games like "C&C: Red Alert" used voxels, but with a normal mapping that resulted in a much less blocky appearance. Are normal maps also a performance bottleneck?
I originally chose to go with axis-aligned blocks and hard axis-aligned normals because I liked the aesthetic. I've since slightly course-corrected; each voxel has bent normals which follow the surface. How much the normals are bent is artist configurable. This has the effect of smoothing out the look of the surface when viewing from a distance, but still gives the distinct blocky look when up close.
In terms of performance, there is a cost to having fully 3D normals per voxel, but it's certainly manageable. There's a lot of other, more expensive, stuff going on.
Before Minecraft, basically all voxel engines used some form of non-axis-aligned normals to hide the sharp blocks. Those engines did this either through explicit normal mapping, or at the very least, by deriving intermediate angles from the Marching Cubes algorithm. Nowadays, the blocky look has become stylish, and I don't think it really even occurs to people that they could try to make the voxels smooth.
Voxels have been around since the 1980s. The smoothness came from that beautiful CRT and its inability to display crisp images. Normals weren’t really used until early 90s and used heavily by games like Comanche by NovaLogic.
The reason why Minecraft voxels are blocks is because Notch (Markus Persson) famously said he was “Not good at art”. He didn’t implement the triangulation and kept them unit blocks. Games that had voxels AND were triangulated that came before Minecraft were Red Faction, Delta Force, Outcast just to name a few.
The point is, voxels aren’t anything special, no more than a texel, or a vertex, or a splat, a normal, or a uv. It’s just a representation of 3D space (occupied/not occupied) and can just as easily be used for culling as it can for rendering. The Minecraft style because popular because it reminds people of pixels, it reminded people of legos, and Minecraft was so popular
It depends on how the voxels relate to the gameplay.
Regardless of the original intent, in Minecraft the voxel grid itself is a very important aspect of the core gameplay loop. Smoothing the voxel visual representation disguises the boundaries between individual logical voxels and makes certain gameplay elements more difficult or frustrating for the player. When the visuals closely (or exactly) match the underlying voxel grid, it's easy for the player to see which specific voxel is holding back some lava or if they're standing on the voxel they're about to break.
In Minecraft you can, for example, clearly count how many voxels wide something is from a distance, because the voxels are visually obvious.
In Red Faction, you're never concerned with placing or breaking very specific voxels in very specific locations, so it's not an issue.
So your point is, Minecraft uses voxels on a unit scale. Red faction uses voxels differently, so Minecraft wins?
I get the appeal of Minecraft but Notch didn’t invent this stuff as much as you would love to believe. He simply used it in a way that made it easy to understand. To the point where people like you are explaining it to me like I have never played it. I have. I was one of the first testers.
Almost all of Minecraft is ripped off other games. World creation, dwarf fortress. Mining, dig dug. The only original thing was The Creeper.
I don't think this should be understated. LEGO are easy and fun to build with and don't require a lot of artistic talent. The same goes for block-based games like Minecraft.
Can you add more details? This seems to directly contradict GP. GP said ray tracing can do higher voxel counts = ray tracing is more performant (than rasterization).
I did a decent amount of work in MagicaVoxel in the past.
I like that Voxel Max works on iPad. It also allows 3D meshes to be imported and voxelized.
Voxel Max has a good amount of polish these days. It’s my top option with MagicaVoxel a close second.
I’ve also used Qubicle and Goxel. Qubicle is okay for specific things. I really like its masking planes feature. I really don’t like Goxel. It’s UI just feels clunky.
the look and aesthetic of some of your screenshots is awesome. reminds me of ultima online in the best way possible.
It's like looking into the future, will there be a point where you can just render the entire scene in voxels at high enough res where it's indistinguishable from modern 3d graphics?
> the look and aesthetic of some of your screenshots is awesome. reminds me of ultima online in the best way possible
Thank you!
> It's like looking into the future, will there be a point where you can just render the entire scene in voxels at high enough res where it's indistinguishable from modern 3d graphics?
There are two really big problems getting in the way of this.
1. Data size. One of the ways that my engine gets away with rendering such large volumes is by discarding most of the voxel data after it gets generated and converted to triangles. In the context of a traditional 3D pipeline, where artists hand-author content in zbrush, maya, blender, etc, which is then imported and drawn in the engine .. it gets complicated.
2. Animation. Animating voxel data is hard. I'm going to completely gloss over all the details, but current techniques mostly boil down to playing back 3D video, which is problem (1) on steroids.
That all said, many voxel-based techniques are used in commercial 3D game engines today. Unreal Engine just landed a feature that voxelizes foliage in the distance, and just draws the ~1px voxels instead of textured quads. Voxel Cone Tracing is another prominent example. Fluid sims and many volumetric effects are also commonly done using voxel grids.
Funny coincidence on naming. I called the project Bonsai because I tended to it in a similar way that someone tends a bonsai tree; carefully, over years. Not sure of the origin of the Bonxai name
Off the top of my head the CAPITALIZED WARRANTY DISCLAIMER is specific to a subset of states in the US. If you’re outside those jurisdictions (or any other where it is required) then for aesthetic or principled reasons I can see why you wouldn’t kowtow to the legalese spiral.
Maybe don't drop the warranty disclaimer just yet.
> The MMWA requires conspicuous disclosure of warranty terms (e.g., designations like "Full" or "Limited" as prominent titles).
> The common practice of ALL-CAPS WARRANTY DISCLAIMERS (e.g., "AS IS, NO WARRANTY") stems primarily from state adoptions of UCC § 2-316, which requires disclaimers of implied warranties to be "conspicuous" (and suggests all-caps as one way, especially in plain text).
> Surely the warranty and liability disclaimer found in licenses like MIT exists for a reason
Obviously IANAL, but I entirely don't see how the WTFPL (which does not ask the consumer to accept any restrictions) would create an implied contract (which would seem to be a necessary precondition for a warranty obligation)?
IANAL either, so my own legal theories are as creative as yours, but I'd like to offer the following data point: All unrestricted open-source licenses that were written by actual lawyers, from MIT to CC0, have found it necessary to include such a liability clause.
In the sense that when people want to use a piece of MIT-licensed software in another piece of software, they don't in practice find themselves restricted from doing so by the conditions of the license. "Permissive" might be a word I should rather have used.
The MIT license does place one specific license restriction on its users. Specifically: "subject to the following conditions: the above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software"
I've been thinking of doing a series of blogs on the journey but .. it's been a journey, which is a lot to write about in full. In short, a few places where I've been able to prefer simplicity:
1. Allocators are all pretty much as simple as you can get. Most memory in the program is bump/arena allocated. There is a buddy-style heap allocator for things that are annoying to arena allocate (strings that can be edited, for example). I make heavy use of temp memory and freelists.
2. Containers are all very straight-forward, and it's definitely a feature. The example I always give here is std::map from C++. On paper, it looks great; it has very good looking properties. In practice, the implementation is a nightmare; it's slow, and has a comically large rebalancing-shaped performance cliff. My containers strive to be simple, with reasonable average and worst-case performance.
3. I wrote my own metaprogramming language instead of using C++ template metaprogramming. Writing an entire programming language sounds like the antithesis of simplicity, but in reality, having a good metaprogramming layer makes your life immeasurably easier in the long run. With strong metaprogramming capabilities, stuff like realtime debug UI and state serialization becomes nearly trivial. Once you start doing versioned data serialization in C++, you quickly realize you need a better compiler (see: protobuf, cap'n proto)
https://dubiousconst282.github.io/2024/10/03/voxel-ray-traci...
It's actually more efficient to do a hybrid approach, especially at high view distances. Rasterizing triangles is extremely fast, and is basically a perfect primary-ray intersection. Ethan Gore recently did some experiments with raytracing and said that for large scene volumes (his engine comfortably renders the entire 32-bit range, or 4B^3) it turns out to be faster to do raster for primary rays and raytrace shadows/GI.
Still, games like "C&C: Red Alert" used voxels, but with a normal mapping that resulted in a much less blocky appearance. Are normal maps also a performance bottleneck?
I originally chose to go with axis-aligned blocks and hard axis-aligned normals because I liked the aesthetic. I've since slightly course-corrected; each voxel has bent normals which follow the surface. How much the normals are bent is artist configurable. This has the effect of smoothing out the look of the surface when viewing from a distance, but still gives the distinct blocky look when up close.
In terms of performance, there is a cost to having fully 3D normals per voxel, but it's certainly manageable. There's a lot of other, more expensive, stuff going on.
The reason why Minecraft voxels are blocks is because Notch (Markus Persson) famously said he was “Not good at art”. He didn’t implement the triangulation and kept them unit blocks. Games that had voxels AND were triangulated that came before Minecraft were Red Faction, Delta Force, Outcast just to name a few.
The point is, voxels aren’t anything special, no more than a texel, or a vertex, or a splat, a normal, or a uv. It’s just a representation of 3D space (occupied/not occupied) and can just as easily be used for culling as it can for rendering. The Minecraft style because popular because it reminds people of pixels, it reminded people of legos, and Minecraft was so popular
Regardless of the original intent, in Minecraft the voxel grid itself is a very important aspect of the core gameplay loop. Smoothing the voxel visual representation disguises the boundaries between individual logical voxels and makes certain gameplay elements more difficult or frustrating for the player. When the visuals closely (or exactly) match the underlying voxel grid, it's easy for the player to see which specific voxel is holding back some lava or if they're standing on the voxel they're about to break.
In Minecraft you can, for example, clearly count how many voxels wide something is from a distance, because the voxels are visually obvious.
In Red Faction, you're never concerned with placing or breaking very specific voxels in very specific locations, so it's not an issue.
I get the appeal of Minecraft but Notch didn’t invent this stuff as much as you would love to believe. He simply used it in a way that made it easy to understand. To the point where people like you are explaining it to me like I have never played it. I have. I was one of the first testers.
Almost all of Minecraft is ripped off other games. World creation, dwarf fortress. Mining, dig dug. The only original thing was The Creeper.
I don't think this should be understated. LEGO are easy and fun to build with and don't require a lot of artistic talent. The same goes for block-based games like Minecraft.
I’ll have to try some of my assets out in this engine.
> I’ll have to try some of my assets out in this engine.
The asset loading is currently broken in Bonsai after a big rewrite, but it's the next thing on my list to fix! Would love to see your art :)
I like that Voxel Max works on iPad. It also allows 3D meshes to be imported and voxelized.
Voxel Max has a good amount of polish these days. It’s my top option with MagicaVoxel a close second.
I’ve also used Qubicle and Goxel. Qubicle is okay for specific things. I really like its masking planes feature. I really don’t like Goxel. It’s UI just feels clunky.
I've been wanting a good mesh->voxel pipeline. I'll have to check out Voxel Max's facilities there.
The Voxel Max folks have been very helpful in their Discord server too.
It's like looking into the future, will there be a point where you can just render the entire scene in voxels at high enough res where it's indistinguishable from modern 3d graphics?
Thank you!
> It's like looking into the future, will there be a point where you can just render the entire scene in voxels at high enough res where it's indistinguishable from modern 3d graphics?
There are two really big problems getting in the way of this.
1. Data size. One of the ways that my engine gets away with rendering such large volumes is by discarding most of the voxel data after it gets generated and converted to triangles. In the context of a traditional 3D pipeline, where artists hand-author content in zbrush, maya, blender, etc, which is then imported and drawn in the engine .. it gets complicated.
2. Animation. Animating voxel data is hard. I'm going to completely gloss over all the details, but current techniques mostly boil down to playing back 3D video, which is problem (1) on steroids.
That all said, many voxel-based techniques are used in commercial 3D game engines today. Unreal Engine just landed a feature that voxelizes foliage in the distance, and just draws the ~1px voxels instead of textured quads. Voxel Cone Tracing is another prominent example. Fluid sims and many volumetric effects are also commonly done using voxel grids.
https://github.com/facontidavide/Bonxai
Is there some connection between Voxel grids and Bonsai trees that I'm missing??
> The MMWA requires conspicuous disclosure of warranty terms (e.g., designations like "Full" or "Limited" as prominent titles).
> The common practice of ALL-CAPS WARRANTY DISCLAIMERS (e.g., "AS IS, NO WARRANTY") stems primarily from state adoptions of UCC § 2-316, which requires disclaimers of implied warranties to be "conspicuous" (and suggests all-caps as one way, especially in plain text).
- Grok https://grok.com/share/bGVnYWN5_5c7db73a-ffd2-48b2-bb36-296f...
That said, maybe it wouldn't be too hard to argue there is obviously no implied warranty with a crass license like WTFPL.
Obviously IANAL, but I entirely don't see how the WTFPL (which does not ask the consumer to accept any restrictions) would create an implied contract (which would seem to be a necessary precondition for a warranty obligation)?
"I Optimised My Game Engine Up To 12000 FPS" ( https://www.youtube.com/watch?v=40JzyaOYJeY )
https://github.com/vercidium-patreon/meshing