Re: Render problem with model
I believe that the "may not be 2-manifold" error usually or always means
that two objects share an edge.
I wasn't able to duplicate the problem using the program you supplied,
but that might be because you included Stall6BackWall.stl and the import
calls for Stall1MezzanineWall.stl.
If you were able to narrow it down, it would be good to strip out the
parts that are not part of the problem.
I'm sorry, I put the wrong scad file in the zip file. Here is the
corrected zip file.
Jordan,
If I understand you correctly, my problem may be a coincident edge, so
if I move the array of bricks slightly, the problem might go away, right?
Thanks for the info.
Bill Lugg
On 8/16/22 22:26, Jordan Brown wrote:
I believe that the "may not be 2-manifold" error usually or always
means that two objects share an edge.
I wasn't able to duplicate the problem using the program you supplied,
but that might be because you included Stall6BackWall.stl and the
import calls for Stall1MezzanineWall.stl.
If you were able to narrow it down, it would be good to strip out the
parts that are not part of the problem.
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.
Thanks again for the clarification.
Bill Lugg
On 8/16/22 22:26, Jordan Brown wrote:
I believe that the "may not be 2-manifold" error usually or always
means that two objects share an edge.
I wasn't able to duplicate the problem using the program you supplied,
but that might be because you included Stall6BackWall.stl and the
import calls for Stall1MezzanineWall.stl.
If you were able to narrow it down, it would be good to strip out the
parts that are not part of the problem.
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.
In my experience, Cura and Prusa Slicer can handle these models without
issue.
On Wed, Aug 17, 2022 at 12:31 PM 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/17/2022 10:29 AM, Jordan Brown wrote:
Some people tell me that 2-manifold is a practical requirement for 3D
models, but I don't buy it.
I should have said "I'm not convinced". I don't have a solid enough
understanding of 3D geometry to be sure that it isn't a requirement, but
I haven't seen any arguments that convince me that it is a requirement.
On Wed, Aug 17, 2022 at 10:46:48AM -0700, Jordan Brown wrote:
On 8/17/2022 10:29 AM, Jordan Brown wrote:
Some people tell me that 2-manifold is a practical requirement for 3D
models, but I don't buy it.
I should have said "I'm not convinced". I don't have a solid
enough understanding of 3D geometry to be sure that it isn't a
requirement, but I haven't seen any arguments that convince me that
it is a requirement.
Lets simplify things a bit and go 2D.
Suppose we have a "shapes" definition language. We specify the line
segments that delineate the object.
Now I define segments [0,0] - [1,0], [1,0] - [0,1] and
[0,1] - [0,0]. That's a simple triangle.
But computers are stupid. It is useful for the computer to know on
which side is "object" and on which side is "nonobject". Purely
mathematical the lines only define two regions. One "everything but
the triangle" and the other is the triangle.
So we agree that looking from first to second point in a segment, the
object will always be on the left. That is the case in the above
example.
But if I reverse the second segement:
[0,0] - [1,0], [0,1] - [1,0], [0,1] - [0,0].
Now that's no longer true. Remember "computers are stupid" or at
least: "algorithms are much simpler if you can assume.... ".
So that's what's in the standard for STLs, but then in 3D.
I have just a couple of hours ago submitted a question on why that
file causes openscad to do it wrong with such a simple case.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
On 8/17/2022 11:13 AM, Rogier Wolff wrote:
Now that's no longer true. Remember "computers are stupid" or at
least: "algorithms are much simpler if you can assume.... ".
I am sure that there are algorithms that are simpler or faster if they
can require that objects be 2-manifold. But that doesn't mean that
non-2-manifold objects are ambiguous or cannot be processed, only that
they would need different algorithms.
Straying into areas that I really am not competent in...
In 2D, and sticking with your "object is on the left" requirement, if
two objects touch at a single point (does that make them
non-1-manifold?) then there is an ambiguity: does the outer perimeter
enclose both objects, or does each object get its own perimeter? When
the ant is walking along the edge, with an object on his left, and comes
to this juncture, does he bear right onto the next object, or does he
take a hard left and stay on the same object he's on now? (Clearly he
should not take the middle road, because then the object would be on his
right.)
OK, that's an ambiguity, but is it an important ambiguity? We know
the inside-outside status of the entire universe, except for the
zero-size point where they touch. Mathematically that point might be
interesting, but in any practical sense it isn't. A slicer, for
instance, could handle it either way and be reasonably correct. (I
think it would be slightly more right to not connect the objects,
because the extrusion should always fit inside the object, and can't fit
through that zero-size junction.)
If you don't have the object-on-the-left requirement, it's harder, but
I'm not convinced that it's impossible. In 2D, I'm convinced that it's
always possible to tell what is "inside" and what is "outside" in any
union of polygons.
In my brief experiences with Lychee, it cannot handle STLs that have
this warning. It reports a problem that it can't fix and I've found
Meshlab only occasionally can fix the problems Lychee identifies.
Bill Lugg
On 8/17/22 11:37, Father Horton wrote:
In my experience, Cura and Prusa Slicer can handle these models
without issue.
On Wed, Aug 17, 2022 at 12:31 PM 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 Wed, Aug 17, 2022 at 12:40:43PM -0700, Jordan Brown wrote:
On 8/17/2022 11:13 AM, Rogier Wolff wrote:
Now that's no longer true. Remember "computers are stupid" or at
least: "algorithms are much simpler if you can assume.... ".
I am sure that there are algorithms that are simpler or faster if they
can require that objects be 2-manifold. But that doesn't mean that
non-2-manifold objects are ambiguous or cannot be processed, only that
they would need different algorithms.
Straying into areas that I really am not competent in...
In 2D, and sticking with your "object is on the left" requirement, if
two objects touch at a single point (does that make them
non-1-manifold?) then there is an ambiguity: does the outer perimeter
I think it is 2-manifold, even in 2D: "Divides the universe
(2D-universe in this case) into two separate parts".
Definitively not 2-manifold example would be [0,0] - [1,0] or
[0,0] - [1,0], [1,0] - [0,1]
Yes, there is a line, and in the second case, "the shortest way to the
beginning" might seem logical to you as the "obvious" way to close the
path, but as long as that last line segment is not actually listed, it
is formally undefined. Of course, the practical cases are where there
is a nanometer size hole somewhere....
enclose both objects, or does each object get its own perimeter? When
the ant is walking along the edge, with an object on his left, and comes
to this juncture, does he bear right onto the next object, or does he
take a hard left and stay on the same object he's on now? (Clearly he
should not take the middle road, because then the object would be on his
right.)
For whomever is READING the file, it doesn't matter. The requirement
is that the object stays on the left. So either you define two objects
and take the hard-left and later define another object with the other
half, or you define one object and take the right turn.
Just to make sure everybody knows what we're thinking about:
square (10);translate ([10,10]) square (10);
OK, that's an ambiguity, but is it an important ambiguity?
No.
We know
the inside-outside status of the entire universe, except for the
zero-size point where they touch. Mathematically that point might be
interesting, but in any practical sense it isn't. A slicer, for
instance, could handle it either way and be reasonably correct. (I
think it would be slightly more right to not connect the objects,
because the extrusion should always fit inside the object, and can't fit
through that zero-size junction.)
A slicer might care:
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.
rotate (-45) square (10); translate (sqrt(200),0) rotate (10) square(10);
Now at sqrt(200) you still pass 4 endpoints of edges but now you go
from inside to out!
If you don't have the object-on-the-left requirement, it's harder, but
I'm not convinced that it's impossible. In 2D, I'm convinced that it's
always possible to tell what is "inside" and what is "outside" in any
union of polygons.
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.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.