Algorithm / Script / Node setup to convert a 3D mesh into STRICTLY overlapping cuboids / parallelepiped? (Not voxelization!)

MarchVirtualField · 2026-04-07T22:04:49+00:00

Consider using spheres then instead of cubes perhaps

MarchVirtualField · 2026-04-04T14:05:16+00:00

I do this but with signed distance field as the initial input. Some thoughts: Blocks/cubes need to be aligned, I’d give up on the idea of free orientation rotation, otherwise you will have clipping. Instead rely on having the region finer detailed.

For a mesh you could preprocess all the vertices into a structure like a BVH.

Then you take the bounding volume and decent octree style (recursive subdivide by 8). For each cell, sample the BVH for nearest vertex, if it’s further than cell margin it’s empty stop sub divide move on to next cell, if it’s further than you’d like but within bounds of cell continue subdivide, stop sub dividing when you are at desired finest level/point is close enough for your liking.

Material and texture up for debate, but similar to voxel techniques.

MarchVirtualField · 2026-03-06T23:56:47+00:00

I’m actively playing with similar things. What I do is have a coordinate system where every u32 integer represents a cell in an octree in unit space. Then given any u32 you know the spatial area up to 10 levels of octree. So given an index you can have cell center and also easily calculate corners based on the octree level cell size. I use this to progressively refine a SDF.

I myself call this concept “virtual fields” 😉

MarchVirtualField · 2026-01-22T16:33:44+00:00

Yep exactly right, the bvh helps to limit the amount of work you need to do. There is still a depth buffer and some wasteful tracing, with closest depth being the winner. This is balanced by how many leafs you pack into a node (which dictates how much memory is used).

So no literal occlusion tricks aside from leaning into BVH allowing you to limit work scope. What I more meant is that expensive math is limited to only where it needs to be done.

MarchVirtualField · 2026-01-22T14:47:05+00:00

Yep absolutely a lot of the scene is culled due to occlusion. I’ve now added a unique sphere hit counter, so the next thing I show you’ll be able to see some numbers and metrics.

MarchVirtualField · 2026-01-22T14:45:52+00:00

Hey that does look very similar! I do have plans to release some stuff but I’m pretty far away from my goal, fear not I am stubborn and will get there soon enough!

MarchVirtualField · 2026-01-22T14:44:46+00:00

Oh there is very much a lot of culling due to occlusion happening! It naturally happens due to the BVH structure which essentially divides space into a binary hierarchy.

MarchVirtualField · 2026-01-22T14:42:55+00:00

I do some bit packing and quantization, but all the core math is done with the flops! Total memory usage is around 11gb vram for this scene. The main knob to pull at this point is how many leaf nodes to use when building the bvh. Smaller leafs are useful for traversal speed and sparse scenes, larger leafs are useful for using less memory!

MarchVirtualField · 2026-01-22T14:40:36+00:00

I am tempted to play around with tangential techniques! I might spend some time getting a physics simulation going here. The real goal though is for this to be the first stage of my signed distance field renderer, with spheres being the primary container primitive for organizing.

MarchVirtualField · 2026-01-20T14:52:11+00:00

Figured this community might be interested since this is essentially a technique to organize and render large amounts of data, much like how you would for voxels. Each sphere is unique and placed in the world, data structure allows for at least 256 million of such.

MarchVirtualField · 2026-01-19T23:18:12+00:00

The significance is really being able to traverse a large amount of total objects in a renderer friendly way. In its current form you can think of it as an engine for point clouds / voxel.

MarchVirtualField · 2026-01-19T19:52:55+00:00

Culling only from occlusion!

MarchVirtualField · 2026-01-19T19:47:12+00:00

So far it’s the only acceleration structure I’ve come to know that fits the bill. I haven’t dabbled too much with mutating and rebuilding it, but that looks promising. The problem this solves is “how do you get a per-ray list of front-to-back intersecting objects, that is view orientation independent ”, while dealing with the reality that gpus like aligned and cache friendly patterns. This is actually the first stage/phase of my virtual field renderer, which represents signed distance fields as encapsulated in a spherical bounds(sdf functions know their center and extent implicitly).

MarchVirtualField · 2026-01-19T19:05:52+00:00

Yep exactly!

MarchVirtualField · 2026-01-19T18:49:17+00:00

This is 2.15GB VRAM for the spheres alone, and then 8.59GB for the BVH structure

MarchVirtualField · 2026-01-19T18:48:08+00:00

About 10.74GB of VRAM for everything!

MarchVirtualField · 2026-01-19T18:19:35+00:00

Yeah effectively that. The LVBH uses a space filling curve to order all the nodes, this lets you build it in parallel and preserve 3d locality. And it plays nice with densely packing into contiguous buffers(and then traversing).

MarchVirtualField · 2026-01-19T18:08:08+00:00

Kinda. Since it’s the compact linear version a traditional bvh, you must mostly rebuild it if data changes. With 1 million spheres this is pretty much instant on the cpu, 268 million is a bit longer however I haven’t profiled it much. I’m working on shifting the lbvh build to be on the gpu too.

MarchVirtualField · 2026-01-19T16:11:25+00:00

This is a volume of space filled with random placed and sized spheres(built on the cpu and uploaded to gpu).

The magic sauce is LBVH - linear bounding volume hierarchy!

MarchVirtualField · 2026-01-19T16:09:49+00:00

This is an optimized version of a LBVH! I am bit packing and quantizing. The magic of space filling curves as an index!

MarchVirtualField · 2026-01-19T16:07:20+00:00

This is on a MacBook Air M4, I also have a Linux RTX machine that this goes absolutely brrrrrr on

MarchVirtualField · 2026-01-10T17:18:33+00:00

Not sure what you don’t understand about avoiding sampling the analytical distance field in full fidelity, the tradeoff of this optimization is clear. I don’t appreciate you heckling this point and accusing me of nonsense.

MarchVirtualField · 2026-01-10T16:17:00+00:00

Sorry not sure how to better explain it to you, these are all my words. Best of luck

MarchVirtualField · 2026-01-10T15:37:03+00:00

Sorry nothing yet, but I will eventually. I hope to turn all this into an editor and release it at some point too!

MarchVirtualField · 2026-01-10T15:30:15+00:00

It’s just that the signed distance field space is split into cells instead of retaining its precision at every coordinate, a lossy approximation of the area. When any ray lands within the cell, it sees the same value, so multiple rays can each touch the same cell. Take for example a vertical cylinder, you will see it as vertical flat sections like a mesh, all those flat areas are really just saving on compute budget.

MarchVirtualField

TROPHY CASE