Discuss manifoldness, co-incident faces edges etc
On Sat, Nov 16, 2019, at 10:19 PM, Michael Marx wrote:
In my experience this is not 'detecting' corruption, it asks that for all STLs.
It does seem to handle bad STLs (I mean really bad like some of the 3D scans), better when you do unify them, but for others it doesn't seem to do much if anything.
It has not fixed the non-manifold edge, see Render/Show-non-manif-edges (and vertices), (show-non-faux-edges & show-vertex-dots are good too).
Thank you for correcting me on this.
According to my understanding of the 3MF standard, the way that the 2-cubes model is supposed to be represented in an OBJ file is by duplicating the shared vertices in the vertex list. This way, if you perform a "2-manifold" check on the faces, then it tests out as manifold.
The OBJ file that I created did not have the shared vertexes duplicated, and as you have pointed out, "Show-non-manif-edges" shows the problem.
I created another OBJ file that represents the 2-cubes model using the correct technique, and meshlab consider it to be manifold. For what it's worth, my slicer considers this file to be valid and slices it without problem. Here it is:
first cube
vn 0.000000 0.000000 0.785398
v 0.000000 10.000000 10.000000
vn 0.000000 -1.570796 0.000000
v 0.000000 0.000000 10.000000
vn 0.785398 0.000000 0.000000
v 10.000000 0.000000 10.000000
vn 1.570796 0.000000 0.000000
v 10.000000 10.000000 10.000000
vn 0.785398 0.000000 0.000000
v 10.000000 10.000000 0.000000
vn 1.570796 0.000000 0.000000
v 10.000000 0.000000 0.000000
vn -1.570796 0.000000 0.000000
v 0.000000 10.000000 0.000000
vn -0.785398 0.000000 0.000000
v 0.000000 0.000000 0.000000
second cube
vn 0.000000 0.000000 0.785398
v 10.000000 20.000000 10.000000
vn 0.000000 -1.570796 0.000000
v 10.000000 10.000000 10.000000
vn 0.785398 0.000000 0.000000
v 20.000000 10.000000 10.000000
vn 1.570796 0.000000 0.000000
v 20.000000 20.000000 10.000000
vn 0.785398 0.000000 0.000000
v 20.000000 20.000000 0.000000
vn 1.570796 0.000000 0.000000
v 20.000000 10.000000 0.000000
vn -1.570796 0.000000 0.000000
v 10.000000 20.000000 0.000000
vn -0.785398 0.000000 0.000000
v 10.000000 10.000000 0.000000
first cube
f 1//1 3//3 4//4
f 3//3 1//1 2//2
f 8//8 5//5 6//6
f 5//5 8//8 7//7
f 8//8 3//3 2//2
f 3//3 8//8 6//6
f 3//3 5//5 4//4
f 5//5 3//3 6//6
f 5//5 1//1 4//4
f 1//1 5//5 7//7
f 8//8 1//1 7//7
f 1//1 8//8 2//2
second cube
f 9//9 11//11 12//12
f 11//11 9//9 10//10
f 16//16 13//13 14//14
f 13//13 16//16 15//15
f 16//16 11//11 10//10
f 11//11 16//16 14//14
f 11//11 13//13 12//12
f 13//13 11//11 14//14
f 13//13 9//9 12//12
f 9//9 13//13 15//15
f 16//16 9//9 15//15
f 9//9 16//16 10//10
On 11/16/2019 7:19 PM, Michael Marx wrote:
To me (not someone who studies this topic mathematically) it boils
down to: is it two objects or one?
What says that the surface of one cube is a continuation of the
surface of the other? Or not?
And for me that then boils down to "why do you care?".
If they overlap by a micrometer, the strongest substance in the world is
still going to have an awfully weak joint. You better not be expecting
it to survive; if you want a joint you better make it thicker.
If they are separated by a micrometer, the best 3d printer in the world
is likely to still have them touch a bit, and so have an awfully weak
joint. You better not expect them to be separate; if you want them to
be separate you better make the gap bigger.
All values of separation / overlap below a tenth of a millimeter or
so[*] are the same: they might touch, or they might not.
[*] If your reaction is "but my printer can do that level of
accuracy", divide by ten and restart.
If they overlap by a micrometer, is the slicer going to say "that's too
small to print", and print as two perimeters, or is it going to say
"every part of the model deserves to be printed, even if we have to
overflow the bounds to print it", and print as one perimeter? Once
you've answered that question, great, apply that answer to the "zero"
case and I'll be happy.
(Abstractly, I like the "color inside the lines" answer. Never let the
plastic out of the lines; if the space between the lines is less than
the minimum extrusion width, don't print. Practically, I like the
"overflow" answer, so that if I scale a model down small things turn
into hairlines rather than disappearing. I have a small model
https://xkcd.com/878/ where this is important, where I have rectangles
that are about 0.25mm thick. Either answer is reasonable. Probably it
should be a configurable item on the slicer.)
I understand that there may be algorithmic problems with the "zero"
case. But I can't see how there are any practical problems.
When printed (on what printer?), is the resulting object 1 or 2 pieces?
I created another OBJ file that represents the 2-cubes model using the correct technique, and meshlab consider it to be manifold. For what it's worth, my slicer considers this file to be valid and slices it without problem. Here it is:
--
Kenneth Sloan
KennethRSloan@gmail.com
Vision is the art of seeing what is invisible to others.
On Sat, Nov 16, 2019, at 1:44 PM, nop head wrote:
How do voxel formats cope with different target machines, who's voxels might be different sizes?
I don't know what algorithms people use for this. Other people have created slicers for driving 3D printers from voxels, but I've only seen closed source commercial solutions so far, not academic papers or algorithms. But I can speculate.
You could use an interpolation method like trilinear interpolation to resample the voxel grid at the printer resolution. This gives you a density field: a function that maps each point in 3D space onto a density value between 0 and 1.
Then, you could use dual contouring to generate each slice, mapping the density field at a specific Z coordinate onto a set of 2D polygons.
The benefits are that the voxel files are significantly smaller than the mesh files (based on tests done by Shapeways), and the slicing algorithm scales better for large complex models, since you don't need to load the entire voxel grid into memory to generate a slice.
How does a voxel format represent the two cubes problem if the junction doesn't lie on a voxel boundary?
The only general purpose voxel format for 3D printing I have documentation for is the Shapeways SVX format.
https://abfab3d.com/svx-format/
SVX uses a density grid representation. Instead of a minecraft style representation, where each voxel is either on or off, voxels contain a density value between 0% and 100%. Then, see above.
There is an algorithm for determining if a 3MF file is valid, and if it is valid, then there is a documented algorithm that slicers must use for interpreting the file.
Yes but they seem to have chosen the wrong interpretation of self intersections. I.e. exclusive oring overlapping solids instead of unioning them. So at least slicers will be consistent, i.e. consistently wrong, so forcing people to fix their models if they slice it with a compliant slicer before publishing.
I agree with you. I'm glad that we have a standard interpretation of meshes, it's better than chaos. However, what I need in order to deal with the current situation is: a good mesh repair tool that will use the correct interpretation of self intersections to repair meshes, and, 3D modeling tools that will generate meshes that don't contain self intersections.