Voxelizer
category: code [glöplog]
At the moment we use CPU. I read that GPU is 1000 times faster than CPU. I will try to get some library to use GPU with C#. Thanks for suggestion.
There's OpenTK if you're used to GL, SharpDX if you're used to DX. And yes, nowadays it's a bad decision to use a CPU, this task is clearly suited for GPUs.
How about Cudafy? We use C# at our company.
Sure, why not. In the end you have to try and evaluate. Voxelizing is one thing, but rendering graphics with an "GeneralPurposeGPU" API is, although doable in theory, a lot harder than with a graphics API like OpenGL or DirectX.
...in the end you still have to draw the cubes.
my volexizer uses a 2D grid of parallel lines that intersect the meshes by pairs of, that gives a binary length encoding of the volum, by sorting intersections. at the end I run a matrix based smooth surface rendering with marching cubes. ("lifemorph.ned" in -Dead Deer- adds a volum interpolation between meshes)
I do not need a library to output graphics. I only need the GPU to perform some calculations and return me an array of type bool.
sounds like you don't need to ask questions on pouet then either!
Quote:
...but my boss is still unhappy simply because it does not look perfect...
hmm...
Quote:
At the moment we use CPU.
I'm starting to see a pattern.
Quote:
she keeps insisting that I should spend my sparetime conducting further research and finding a "better" mesh voxelizer.
Sound reasonable
Quote:
...in the end you still have to draw the cubes.
Obviously!
Quote:
I do not need a library to output graphics.
*sigh* I'm out of here...
Are calculating and displaying only the shell voxzels or everything including the insides? Adok
xTr1m: Sorry, but have you understood what it is all about? It is a program that calculates things. So it needs the data (cuboids) in its own internal data structure. The drawing is done using Kitware VTK so I have no choice to use anything else. What I need is to make the calculation faster. And originally, I wanted to make sure that there is no way to achieve better looking results based on the premise that we must use cuboids.
Navis: My algorithm first calculates the shell voxels and then "fills" the resulting voxel model. The size of the cuboids is not constant, and my algorithm is clever enough to create large cuboids when there is a lot of space to be filled and smaller cuboids only if it is really necessary. I am not sure if my explanation is easy to understand but all in all, the filling routine seems to be efficient. The slow thing is the code that checks whether a voxel has been hit by a polygon face. As much as I understood Smash and xTr1m, this could be sped up by factor 1000 if I used the GPU.
Navis: My algorithm first calculates the shell voxels and then "fills" the resulting voxel model. The size of the cuboids is not constant, and my algorithm is clever enough to create large cuboids when there is a lot of space to be filled and smaller cuboids only if it is really necessary. I am not sure if my explanation is easy to understand but all in all, the filling routine seems to be efficient. The slow thing is the code that checks whether a voxel has been hit by a polygon face. As much as I understood Smash and xTr1m, this could be sped up by factor 1000 if I used the GPU.
To express myself more clearly:
The point is not to optimize the code that displays the graphics. I can't modify this code.
The point is to optimize the code that generates the array element_set. This is a three-dimensional array of bool with default size 120x120x120. If an element is true, this means that the respective voxel is to be set, otherwise not.
(And originally, my question was not about speed but about the "visual quality" of the result, i.e. it should resemble the original polygon mesh as much as possible. IMHO what I have is already optimal in this aspect and I just have to find a way to explain to my boss that it cannot be done better.)
The point is not to optimize the code that displays the graphics. I can't modify this code.
The point is to optimize the code that generates the array element_set. This is a three-dimensional array of bool with default size 120x120x120. If an element is true, this means that the respective voxel is to be set, otherwise not.
(And originally, my question was not about speed but about the "visual quality" of the result, i.e. it should resemble the original polygon mesh as much as possible. IMHO what I have is already optimal in this aspect and I just have to find a way to explain to my boss that it cannot be done better.)
using spheres can afford little by tessellating faces and decals about normals, instead of cubes, tessellation can be done two regardless to length of the faces, that is to populate among a unit. if it's necessary to put a cube in each plain of the subject to voxelize.
-Dead Deer- : "Beethoven.ned"
note that such a tessellation requieres splitting edges and remising by cases. a simple hash table of pairs.
Adok: now it's clear. You didn't mention that the drawing code is separated and out of control.
In that respect, sure, use any GPGPU api that suits you.
In that respect, sure, use any GPGPU api that suits you.
Also, an actual screenshot of a voxelized model would be good to have. You say your voxelizer is optimal but who knows, maybe there's some rounding or similar error left that makes the result look worse than it should.
my text corrector is not working properly (macOS safari).
Adok:
"The size of the cuboids is not constant, and my algorithm is clever enough to create large cuboids when there is a lot of space to be filled and smaller cuboids only if it is really necessary" <- octree
"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." <- brick maps
Knowing what you're actually doing will help, because then you can go look at how other people are doing this already ;)
"The size of the cuboids is not constant, and my algorithm is clever enough to create large cuboids when there is a lot of space to be filled and smaller cuboids only if it is really necessary" <- octree
"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." <- brick maps
Knowing what you're actually doing will help, because then you can go look at how other people are doing this already ;)
he's probably trying to do this:
all this coffee on my screen now... thank you maali! :D
all this coffee on my wall now because i was about to drink it but then i had to hail ze fuhrer!
