Re: Render problem with model
On 8/17/2022 2:20 PM, Rogier Wolff wrote:
A slicer might care [what to do where two polygons touch at a point]:
Sure. But whatever it does - laying perimeter across the junction, or
not - would, in my opinion, be reasonable.
Suppose we have:
rotate (-45) {square (10);translate ([10,10]) square (10);}
Now the point is on the X-axis. And if we're slicing for layers in the
Y direction, at the 10sqrt(2) position, you pass an edge. Four to be
precise. Or rather four endpoints of an edge. Do you go from inside to
outside the object or not? This is tricky.
Yes, cases where you're scanning across a vertex require special care.
Even a simple diamond has a related problem. If you're scanning across
and you come to the left vertex, you need to switch to "inside", but if
you come to the bottom vertex you don't. You need to, somehow, pay
attention to where the line segments go. No, I don't know the right
algorithm for that, but I'm confident that there is such an algorithm.
It's not openscad definitions that are the problem. It is a problem
when openscad exports such wel-defined "jumble of polygons" into a
"language" where it doesn't adhere to the language defnitions.
Sure. But OpenSCAD complains when you do the render, not when you
propose to export the results into some particular form that might have
a 2-manifold requirement.
Notes:
- For this purpose, CGAL is part of OpenSCAD. It's an implementation
detail. - For STL in particular, it's far from clear whether 2-manifold is a
requirement, because it's hard to find a definitive specification.
There are tons of cites to the 1989 specification, but I can't
immediately find an actual copy of it. Particular consumers of
the STL file might require 2-manifold. Notably, OpenSCAD itself
requires imported STLs to be 2-manifold.
I am perfectly willing to accept the notion that working with
non-2-manifold objects is hard. It just doesn't seem meaningless or
impossible.
Auto-fixing a single hole in an STL is not too awful to do algorithmically. The real problem occurs when there is more than one hole. Consider a pair of spheres, separated by a small distance, that both have holes on the side facing each other. It really isn't possible to algorithmically decide whether the correct solution is to close the holes on each sphere, or to bridge the spheres together to seal the holes.
To make this intuitively clear, here's a picture of a 2D slice of the above describes case.
- Revar
On Aug 17, 2022, at 10:29 AM, Jordan Brown openscad@jordan.maileater.net wrote:
On 8/17/2022 7:47 AM, William Lugg wrote:
Sure enough, I added an epsilon factor (0.002") to BrickDepth for each
of the ledges and the warning went away - the render was successful.
Yep. It's one of my largest complaints with OpenSCAD. Some people tell me that 2-manifold is a practical requirement for 3D models, but I don't buy it. Unfortunately, I also don't know nearly enough 3D geometry to work on the question.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 8/21/2022 3:18 AM, Revar Desmera wrote:
On Aug 17, 2022, at 10:29 AM, Jordan Brown
openscad@jordan.maileater.net wrote:
Yep. It's one of my largest complaints with OpenSCAD. Some people
tell me that 2-manifold is a practical requirement for 3D models, but
I don't buy it. Unfortunately, I also don't know nearly enough 3D
geometry to work on the question.
Auto-fixing a single hole in an STL is not too awful to do
algorithmically. [...]
It's not the requirement that the model be closed (watertight?) that
bugs me. It's the "no shared edges" requirement.
The classic example is
cube(10);
translate([10,10,0]) cube(10);
On Aug 21, 2022, at 12:53 PM, Jordan Brown openscad@jordan.maileater.net wrote:
On 8/21/2022 3:18 AM, Revar Desmera wrote:
On Aug 17, 2022, at 10:29 AM, Jordan Brown <openscad@jordan.maileater.net mailto:openscad@jordan.maileater.net> wrote:
Yep. It's one of my largest complaints with OpenSCAD. Some people tell me that 2-manifold is a practical requirement for 3D models, but I don't buy it. Unfortunately, I also don't know nearly enough 3D geometry to work on the question.
Auto-fixing a single hole in an STL is not too awful to do algorithmically. [...]
It's not the requirement that the model be closed (watertight?) that bugs me. It's the "no shared edges" requirement.
The classic example is
cube(10);
translate([10,10,0]) cube(10);
Yeah, vertical shared edges are fairly easy to handle in a slicer. It gets handled as a side effect of doing the outline path inset.
There is, however, a case when a horizontal shared edge happens to be exactly at a slice layer and none of the attached faces align with the slice, where it becomes a degenerate line in the layer slice geometry. Depending on how the slicer handles it, that either looks just like a hole, or gets completely removed from the extrusion for that layer. It can be detected and accounted for, but requires a particularly smart slicer that can handle single-line extrusions as well as extrusion loops.
rotate([90,-45,0]) {
cube(10);
translate([-10,-10])
cube(10);
}
I, uh, may have written a slicer. Or two.
- Revar