Go to bottom


category: code [glöplog]
Hi all,

This may be something we have discussed again in the past, but as technology changes I think we can talk about it once again: I would like to make a fast voxeliser. What I mean by that is a process where you take a 3d model and convert it into a 3d volume so that all voxels within the model are 1 and the rest us 9. By fast I dont mean realtime (but would be cool to!), but, say, a few secs for 512^3.

You'd do this on the gpu, somehow. I imagine by rendering slice by slice (with backface culling off) into a 3d texture. Would there be something easier or faster. And what about a 3d volume where each voxel is the shortest distance to an empty voxel. How could that be generated without image postprocessing so to speak?

added on the 2013-04-05 23:17:00 by Navis Navis
Might not be the thing you search at all, but Blender has a remesh modifier - that is able to "minecraftify" a model. HTH? O_o;
added on the 2013-04-05 23:48:25 by mog mog
A kind of inverse marching cubes.
added on the 2013-04-05 23:49:22 by Adok Adok
yes, in a way.
added on the 2013-04-05 23:54:17 by Navis Navis
navis; this does what you describe http://www.cs.princeton.edu/~min/binvox/

added on the 2013-04-05 23:56:15 by rale rale
http://maverick.inria.fr/Publications/2008/ED08a/solidvoxelizationAuthorVersion. pdf

some ideas here... good midnight read :-)
added on the 2013-04-06 00:07:21 by Navis Navis
Damn that thing is fast.
added on the 2013-04-06 00:12:55 by Preacher Preacher
In "GPU Pro 3" theres also an article about it called "Practical Binary Surface and Solid Voxelization with Direct3D 11" by Michael Schwarz. He also has another article called "Fast parallel surface and solid voxelization on GPUs" on his homepage.

The models are not "filled", but only a solid voxel shell and could therefore be stored quite efficiently with e.g. sparse voxel octrees. It's not exactly what you asked for but might be interesting to take into consideration ...
> The models are not "filled", but only a solid voxel shell

Like a chocolate easter bunny? ;)
added on the 2013-04-06 19:54:57 by Salinga Salinga
There's more on this topic by Schwarz iirc - you want the thing with the front face/back face rendering and XOR. It's pretty damn fast (realtime) and if you compact 32 binary voxels into one cell for one axis you can get away with a 512x512x16 texture :).
added on the 2013-04-06 21:22:04 by las las
here's just an idea. for a simple uniform algorithm for random voxels. with collision detection, inside a mesh if you know you are inside it (a hollow surface) start with a box that is 0 length and scale each side of the box. when it hits an triangle-edge (of the mesh) stop, move each corner of the box slightly in a random way, dont decrease the volume but keep the length of the side. when volume doesnt change (with or without an epsilon value depending on the mesh structure) start on next box, but place it randomly inside the mesh like the first one, excluding the previous box volume. then one could schange the algorithm for box with equal side-lengths or not for a slightly different type of voxel-effect. use ray to trace against each triangle of the mesh or a better option. if this is too intensive hack together an invertible marching cubes like Adok mentioned.
added on the 2013-04-06 21:30:21 by rudi rudi
+1 the depth peeling/XOR algorithm. Works like a charm and is pretty fast.
added on the 2013-04-06 21:36:38 by Noobody Noobody
Render a model to 6 depth buffers from each axis / direction and with 3 look ups you get a position for a cube. Has a lot of flaws, but might work for some simple models.
added on the 2013-04-06 21:36:45 by xernobyl xernobyl
can you elaborate more on the depth peeling xoring thing please?
added on the 2013-04-06 22:23:49 by Navis Navis
Navis: I think Smash' presentation at GDC 2012 about generating SDFs from triangle meshes in uncovering static could be useful.
added on the 2013-04-06 22:48:55 by p01 p01
Dear friends,

Sorry for digging out this thread but it fits the topic I want to talk about.

The program our company sells internally stores the 3D model as a set of cuboids. As a new functionality, my boss wanted that I add import of DXF and IFC files. I worked on this for half a year and I am pleased with the result but my boss is not. Because we use cuboids in our program, I developed a mesh voxelizer. Basically it takes a look at the center of each voxel and determines whether the voxel should be set by scanning all the faces and checking whether the face intersects with the voxel. To achieve this, I rotate the face and the center point of the voxel so that they are in planes parallel to the XY plane, then I check the Z distance and, if it is within the limit, I check whether the center point of the voxel is inside the polygon determined by the face. It works very well but my boss is still unhappy simply because it does not look perfect - which is impossible to achieve with a voxelizer, voxel graphics will always look more coarse than the original mesh!

Now I wonder how I should explain that to my boss, as she keeps insisting that I should spend my sparetime conducting further research and finding a "better" mesh voxelizer.
added on the 2017-07-25 13:43:51 by Adok Adok
added on the 2017-07-25 13:51:36 by Adok Adok
Do you render the voxels as unit cubes or do you create a smoother surface with something like marching cubes?
added on the 2017-07-25 14:41:06 by xTr1m xTr1m
Provide a drawing on paper and some lego. Explain that there are different ways to arrange the lego on the paper to recreate the shapes, but however you do it, it's still going to look like lego.
added on the 2017-07-25 15:53:49 by psonice psonice
xTr1m: There is no other way in this case than to use unit cubes.

psonice: Thanks, I tried something similar with pen and peper but maybe it will really help if I use actual Lego bricks.
added on the 2017-07-25 16:50:01 by Adok Adok
xTr1m: There is no other way in this case than to use unit cubes.

Then it'll always look shit.
...but maybe it will really help if I use actual Lego bricks.

Or minecraft.
added on the 2017-07-25 17:44:50 by xTr1m xTr1m
dunno about the speed/realtime requirements or what GPU is used but you can like render those cubes the size of a pixel and load more detailed data/do MC as mentioned above. surely any midrange GPU can render 2 million cubes still at a slightly acceptable FPS :)
added on the 2017-07-25 18:37:52 by Maali Maali
Maali: We currently use 120x120x120 voxels, that is roughly 1.7 million. Depending on the size of the model that might make one voxel one pixel but it is not always the case. We chose this resolution as a good compromise between running time and quality of the result.
added on the 2017-07-25 19:44:46 by Adok Adok
What I forgot to mention is that we also have a zooming function. So what appears to be one pixel in the preview can become something larger when you zoom in and so on.
added on the 2017-07-25 20:09:21 by Adok Adok
our gpu voxeliser trivially does 512^3 on an animating mesh per frame in realtime these days
added on the 2017-07-25 20:53:34 by smash smash


Go to top