So today I got nerd sniped by the algorithm and watched couple videos about people writing voxel engines and I also remembered all the good times I had chasing bits when writing cache aware tree structures some time ago.

Now I'd like to write my own toy, using WebGL (either through Rust, or just manually hammering together the HTML + JS needed). I have no intention of making this into a game, just a browser based voxel viewer would scratch my itch :).

So I'd like to bounce a couple ideas of you guys who actually tried to write something like this before:

My idea was to use a tree data structure similar to an octree ("64-tree"?), but try to fit as much data as possible into a single cache line (seems that 128B is common on modern GPUs (??)), my first (well, actually more like fifth) idea of node layout looks like this:

• 32bit child offset (this node index + child offset is the index of the first expanded child, all node's children appear one after another in the array, only expanded children are included)
• 32bit parent offset (this node index - parent offset is the index of this nodes's parent, used for stack-less traversal)
• 64x1bit child expanded bit mask
• 64x5bit = 320bit child texture (for non-expanded children this is the final texture, for expanded ones this would be the majority texture inside the subtree, used for LOD)

This is still less than half of the target 128B. Only way to fit more children in would be to either use a non-binary tree side -- instead of 2**3 = 8 for octree or 4**3 = 64 in the example above, I could theoretically use 5**3 = 125 children -- or have a unequal side lengths -- eg. 8*4*4=128, but both of those options feel kind of ugly. I could also include more data in the nodes (no idea what would be useful, though), or just go with 64B nodes instead.

What do you think about all this mind salad? Any fun feature opportunities I missed? Any obvious improvements to make?

Hello,

I want to create a voxel game engine with better organization. I'm exploring a different approach where the world is delimited, but all its parts are simulated or loaded dynamically.

Obviously, this will increase memory usage, so I've decided to create a library to manage all the chunks and voxels efficiently. The purposes of this library are:

• Establish a database for chunks to retrieve, add, and modify them.
• Ensure memory efficiency by using as little space as possible.
• Additionally, incorporate entity storage.

To optimize the chunk representation, I plan to use an unsigned short array (2-byte integer). This array will serve as a pointer to another array containing voxel information such as block ID, state, and more.

Furthermore, there will be a buffer for fully loaded chunks, represented by an array of unsigned shorts. However, other chunks will either be optimized using an Octree structure or indicated as consisting entirely of the same block ID.

The decision on whether to use the Octree structure or the raw format for chunks is determined by a buffering algorithm. This algorithm adjusts the priority of chunks every time a voxel is accessed (GET) or modified (SET). Chunks that are less frequently accessed are moved down the priority list, indicating they can be optimized. Conversely, frequently accessed chunks remain at the top and are stored in raw format for faster access.

What do you think of this? Code will be OpenSource...

Say you have a 2x2x2 volume of the same block and on one of the corners of its top face there is a block. Is it better to generate two large triangles for the 2x2 face even if part of it is covered by the block or is it better to generate 4 triangles so that part of the mesh isn’t covered?

I’m using the bevy game engine, and I’m not sure if the render pass has the rays from the camera keep going after it hits an opaque point. Like I’m not sure if the ray will hit a mesh that’s fully opaque, and will continue meaning that if do just generate large faces even with overlap, the ray will have to do a few more calculations for no reason. And even if the ray does do that, is that performance decrease offset by less data being sent to the GPU and less calculations for the faces.

I would benchmark it, but it seems like an easy thing to accidentally micro benchmark and just get useless results regarding the performance. So I wanted to see if there’s any research on the subject first or anything obvious that I’m missing first.

I don’t know if this will have a large effect, but I’m using RLE with Z-Ordering (which honestly feels like an oct tree which is crazy) so calculating large faces like 2x2 or 4x4 is easy, if the run is a power of 8 and the starting position is a multiple of 8, you’re golden.

This is the place to show off and discuss your voxel game and tools. Shameless plugs, progress updates, screenshots, videos, art, assets, promotion, tech, findings and recommendations etc. are all welcome.

• Voxel Vendredi is a discussion thread starting every Friday - 'vendredi' in French - and running over the weekend. The thread is automatically posted by the mods every Friday at 00:00 GMT.
• Previous Voxel Vendredis

hello everyone! recently, i would like to remake minecraft. i don’t know if it is better or worse to make it using metal since i am on a macbook, or i should just use opengl. Thank you!

I'm not super up to date on smooth isosurface algorithms, but I've been watching gameplay footage from enshrouded and I think they've got a really impressive result. Does anyone know what algorithm they used for their voxel world? I haven't been able to find much online.

I'm guessing Dual Contouring or Manifold Dual Contouring, but again, I'm not super up to date on the SOTA. I've become really interested in these hi-fi voxel worlds, but the tech they use is beyond me. Any learning resources would also be really appreciated. Beyond the meshing, I'd be really curious to learn how to handle lighting and LOD at this sort of scale.

This is the place to show off and discuss your voxel game and tools. Shameless plugs, progress updates, screenshots, videos, art, assets, promotion, tech, findings and recommendations etc. are all welcome.

• Voxel Vendredi is a discussion thread starting every Friday - 'vendredi' in French - and running over the weekend. The thread is automatically posted by the mods every Friday at 00:00 GMT.
• Previous Voxel Vendredis

I have a Minecraft clone with torchlight data.

A problem I encountered is that there is not an easy way to propagate torchlight if I have multiple torch falloff rates.

I am using fast flood fill lighting to propagate torchlight : (https://www.reddit.com/r/gamedev/comments/2k7gxt/fast_flood_fill_lighting_in_a_blocky_voxel_game/)

What do I mean by a falloff rate? I am talking about how fast the light goes from 100% (15) to 0% (0). For example, if the falloff rate is 3, the light value will go down 3 values for every voxel it propagates until it reaches 0.

Is there a way to propagate torchlight on a single channel if I have different torches with different falloff rates? The only way I can think to do it, would be to trace the light back to each torch, get the falloff rates of each said torch and propagate each one individually.

Hi guys, I'm working on my own implementation of the transvoxel algorithm, and I feel as though I completely understand it, yet I'm still running into an issue.

Of course I'm following the dissertation from this website and using the triangulation tables provided.

I'm trying to get a very small case of this working where two chunks of different levels of detail are meeting one another. For the face of higher detail, the first 6 bits are set. That produces a transvoxel configuration like this:

https://preview.redd.it/lv6yhj811dtc1.png?width=149&format=png&auto=webp&s=df00cb470fcf99da85a5e1371a7111a7724fdefe

The cell case index for this would be 63 in decimal, or 111111 in binary since the first 6 digits are set. If you go to the cell class lookup table for index 63, you find a value of 0x0B.

https://preview.redd.it/7dh570sk1dtc1.png?width=753&format=png&auto=webp&s=36930c8d6b97f3163be45af980246e91c2141ca6

Okay, so 0x0B is cell class 11, but if we go to the dissertation (page 41) and look at cell class 11... it makes no sense as to how that could possibly be the cell class for the above configuration:

https://preview.redd.it/xr5zh9os1dtc1.png?width=1143&format=png&auto=webp&s=fbf3a5ca5c3031b946d364258af05a928abccc6e

And the same seems to hold true for other transvoxel configurations, so I think I am missing something. Am I calculating my transvoxel cell index incorrectly?

Ollo

I'm an experienced programmer but new to voxels. I've been tinkering with an idea for a few years of a particle based game, not far away in idea from powder.

It's a physics sim essentially that is designed to create some emergent behaviour and a large amount of freedom through a carefully design set of particles and some rules for interactions between them.

For example, particles have 6 sides and can be 'bonded' on any side to another particle. They have forces between them and can move freely.

I was originally planning to divide the world up in 1m chunks, with particles being able to be any size but probably 1/16 or 1/32 of an in game 'meter'.

Im not even sure if this fits the idea of voxels, because the particles are not set into a specific grid but are free to be in any position. They will probably be rendered at first as just sprites and hopefully meshes if possible.

The main issue I'm having is that because the particles can move freely, indexing them in an effective manner seems complicated. My plan was to use oct trees, but I wanted to know if anyone here has any advice for this kind of voxels game.

Just in case anyone finds this bit of information interesting, in 2022 I happened to ask an employee of Euclideon a couple of questions regarding their renderer, in relation to my own efforts I published in 2021.

That employee confirmed that UD's implementation is different but close enough that they considered the same optimization tricks at various points, and even hinted at a piece of the puzzle I missed. He also mentioned that their videos didn't showcase cage deformations or skinned animation due to artistic decisions rather than technical ones.

In case you want to read about it in a bit more detail, I updated my writeup. I only posted it now because it was only recently that I got around to try implementing his advice (though, alas, it didn't help my renderer much). Still, in case anyone else was wondering about those things, now there is an answer 🙂

Hello everyone!

Recently, i've started to develop a voxel game in Unity with a friend. I'm using Magicavoxel to create models, and Unity as game engine, while he uses a Blender tool to convert a standard 3D model to a voxel 3d model.

I've heard that, Magicavoxel's obj import isn't optimal, and i'm very concerned about project optimization, and as far as i've read, the MagicaVoxel Toolbox doesn't work on the 2022 and 2023 versions of Unity.

So that's why i ask you guys, what's tools you use, how optimal they are, and what's your mindset regarding this topic.

Here is a high level overview of how my engine currently functions:

• First I generate a 256x256x256 voxel world with perlin noise, which is represented as a simple 3d array where each voxel takes up a byte.
• Then this world is copied over into video memory, and sits in a vulkan buffer. Every frame, the following process occurs:
  • In a compute shader, in parallel I loop over every single voxel in the world, and update it based on it's surroundings. For example if the block only has air underneath it, it will fall. This is like 3D falling sand.
  • In a second compute shader I raytrace the scene
  • In a third compute shader I do postprocessing and noise reduction

Now I want to make my world size much larger. However, i run into some issues:

• I can't just load in a larger world because, for example, if I make it 3000x3000x3000, that takes 27GB to represent. Not many graphics cards have that much video memory
• If i try to implement dynamic loading of sections of the world, surely this will cause lag? I'll have to copy half a GB of new data all the time. Also, i'm not sure how I would implement this?

It is not important that the whole world is updated every frame, this would be prohibitively expensive. That part can just be done in an area around the player (but again, how to implement this?). If it's important, I plan to make my game isometric.

So, any ideas?

This is the place to show off and discuss your voxel game and tools. Shameless plugs, progress updates, screenshots, videos, art, assets, promotion, tech, findings and recommendations etc. are all welcome.

• Voxel Vendredi is a discussion thread starting every Friday - 'vendredi' in French - and running over the weekend. The thread is automatically posted by the mods every Friday at 00:00 GMT.
• Previous Voxel Vendredis

This is the place to show off and discuss your voxel game and tools. Shameless plugs, progress updates, screenshots, videos, art, assets, promotion, tech, findings and recommendations etc. are all welcome.

• Voxel Vendredi is a discussion thread starting every Friday - 'vendredi' in French - and running over the weekend. The thread is automatically posted by the mods every Friday at 00:00 GMT.
• Previous Voxel Vendredis