New forum member, extruding along path
gasstationwithoutpumps wrote
Here is a simplified example of problems with rounded_sweep with a
high-resolution path. It comes in 2 files: one modified from the output
of
the inkscape plugin, the other a generic cookie-cutter module that can be
used with any suitably edited inkscape output.
In the code you note that the blue object succeeds and the red one fails,
where the only difference is a smoothness parameter. I investigated the
situation.
For the red object, you have a profile that makes a step of 1.6e-4, that is
0.16 microns if your units are mm. The offset() function has a "zero" test
that uses a fuzz value of 1e-4. In general, my understanding is that
details finer than about 1e-4 cannot be handled properly, and that locations
are rounded to a grid of about this size.
I understand that this situation arises naturally as a result of your bezier
curves and wasn't something you intended to do. I can change the 1e-4 to
1e-6 and then the red object works. Another way to make it work is to just
scale it up. I did a factor of 100 and it worked fine. This doesn't
really address the underlying problem, though. You don't actually need a
0.16 micron step there. Maybe the code should round it to zero? I'm not
sure.
--
Sent from: http://forum.openscad.org/
Revar has posted an update to BOSL2 with some changes I made that should work
for gasstationwithoutputs' case out of the box. I quantize the path and I
adjusted the tests so they should work properly with the quantized path. It
works on the posted test case.
Regarding documentation and clarity, I have been thinking of renaming the
module from rounded_sweep to offset_sweep. I'm wondering, cgriffith, if
that name is more clear to you and might be more easily understood, since
what it really does is a sweep operation from a sequence of offsets.
Rounding is only one application, so I thought that "rounded" might prevent
a user from recognizing the full applicability, as perhaps happened in this
case.
cgriffith wrote
@gasstationwithoutpumps
I am glad to hear you got a working solution, but I would still like to
know
why that particular path presents problems when used with rounded_sweep.
Maybe someone closer to that algorithm can explain
@adrianv
You had asked a very important question that I have been trying to find a
good way to answer. Let me first say that the documentation for BOSL and
BOSL2 are the best I have seen; examples and pics of results are so
helpful.
I really appreciate the hard work you have put in. I can't say what I
would
change because I feel it is my own inability to comprehend some of the
content or my own lack of imagination to see how something could be used,
not a fault of the documentation. Seriously, thank you so much for your
valued work.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
yes, offset_sweep is more descriptive. Thank you again for your hard work on
a very nice set of documentation.
--
Sent from: http://forum.openscad.org/
adrianv wrote
Revar has posted an update to BOSL2 with some changes I made that should
work
for gasstationwithoutputs' case out of the box. I quantize the path and I
adjusted the tests so they should work properly with the quantized path.
It
works on the posted test case.
Regarding documentation and clarity, I have been thinking of renaming the
module from rounded_sweep to offset_sweep. I'm wondering, cgriffith, if
that name is more clear to you and might be more easily understood, since
what it really does is a sweep operation from a sequence of offsets.
Rounding is only one application, so I thought that "rounded" might
prevent
a user from recognizing the full applicability, as perhaps happened in
this
case.
This was exciting news, so I tried out the code—indeed the small example I
had posted ran just fine!
Unfortunately, when I tried the full version of the cookie cutter, I got an
assertion failure:
CGAL error in CGAL_Nef_polyhedron3() … e->incident_sface() !=
SFace_const_handle() … SM_const_decorator.h Line:330
after about half an hour.
I've no idea what that assertion failure means. There were no problems with
the preview (other than it taking 6 minutes to run), so I'm not sure where
to look for problems. I could comment out parts of the code to try to do
binary search to find the problematic section, but with the very slow
processing of OpenSCAD, I'm not sure I have the patience.
Incidentally, why does the Console window (on macos) not allow copying? I
often want to copy numbers that I've echoed to the console, or (as here)
want to record an error message accurately.
gasstationwithoutpumps.wordpress.com
www.thingiverse.com/gasstationwithoutpumps/things
Sent from: http://forum.openscad.org/
I am able to copy console content. I simply highlight what I want,
right-click, select copy from pop-up menu.
regarding your path, I believe you need to pay close attention to the number
and closeness of the bezier points. As noted earlier in this thread, your
particular path has lots of unecessary points. This leads to degredation of
performance and might be causing issue for offset_sweep.
--
Sent from: http://forum.openscad.org/
gasstationwithoutpumps wrote
This was exciting news, so I tried out the code—indeed the small example
I
had posted ran just fine!
Unfortunately, when I tried the full version of the cookie cutter, I got
an
assertion failure:
CGAL error in CGAL_Nef_polyhedron3() … e->incident_sface() !=
SFace_const_handle() … SM_const_decorator.h Line:330
after about half an hour.
I've no idea what that assertion failure means. There were no problems
with
the preview (other than it taking 6 minutes to run), so I'm not sure where
to look for problems.
I do think that you would benefit from trying to simplify all of your
profiles. You don't need to define cookie cutters with submicron resolution
like your first example does. Are you using a super high resolution SLS
printer? Because that's the only reason you'd benefit from resolution even
approaching (by which I mean 100-1000 times coarser than) what you're
including in your model. I would suggest that the beziers should be sampled
not more than every 0.1mm, for example. And as you've seen, using the
sampling that you are using makes things slow.
My first question is whether you can process your model with your
"smoothness" parameter smaller. Does it only fail when you increase that
parameter? (And why did you want it so large anyway?) Another thing you
might try would be quantizing all of your inputs to 1/1024. OpenSCAD
apparently does this internally---it cannot represent geometry finer than
that---and this could create problems with polyhedron generation if it leads
to degenerate faces. So try wrapping all of your data vectors with
quant(point_list, 1/1024).
In regards to the meaning of the error message, weird error messages like
that that arise when constructing a polyhedron mean that the polyhedron is
somehow invalid. It either intersects itself or has reversed or invalid
faces. I would be willing to take a look at your full code and try to see
what the cause of the problem is and to make sure it's not a bug in
rounded_sweep(). You can attach files to your reply rather than including
it inline in your message.
I could comment out parts of the code to try to do
binary search to find the problematic section, but with the very slow
processing of OpenSCAD, I'm not sure I have the patience.
This strategy will probably not work. Presumably rounded_sweep() is
producing an invalid polyhedron. The question is: why? If you want a
divide-and-conquer strategy, this is how I tested your small example: I
used a subset of your full profile. I discovered I could process most of
the profile but that a certain part (with the 0.16 micron step) was causing
the failure. If you can decrease your point density so the run time is not
so slow---and that doesn't fix the problem---then this testing strategy
might be tolerable.
--
Sent from: http://forum.openscad.org/
cgriffith wrote
I am able to copy console content. I simply highlight what I want,
right-click, select copy from pop-up menu.
That works and it shows the command-C shortcut, but the shortcut doesn't
work. How should I report this minor bug?
cgriffith wrote
regarding your path, I believe you need to pay close attention to the
number
and closeness of the bezier points. As noted earlier in this thread, your
particular path has lots of unnecessary points. This leads to degradation
of
performance and might be causing issue for offset_sweep.
I am generating the Bezier path from the Inkscape plugin, and inserting
points on each segment of the Bezier path uniformly (same number of points
on each segment). Unfortunately, this results in some points being very
close together and some being very far apart, because the segments produced
by Inkscape are of very different lengths. I could try writing a
"simplify" routine that thins out points that are too close together, but
coming up with good criteria for that is difficult. (I already use
simplify_2dpath, but that is not enough.)
gasstationwithoutpumps.wordpress.com
www.thingiverse.com/gasstationwithoutpumps/things
Sent from: http://forum.openscad.org/
adrianv wrote
I do think that you would benefit from trying to simplify all of your
profiles. You don't need to define cookie cutters with submicron
resolution
like your first example does. Are you using a super high resolution SLS
printer? Because that's the only reason you'd benefit from resolution
even
approaching (by which I mean 100-1000 times coarser than) what you're
including in your model. I would suggest that the beziers should be
sampled
not more than every 0.1mm, for example. And as you've seen, using the
sampling that you are using makes things slow.
My first question is whether you can process your model with your
"smoothness" parameter smaller. Does it only fail when you increase that
parameter? (And why did you want it so large anyway?) Another thing you
might try would be quantizing all of your inputs to 1/1024. OpenSCAD
apparently does this internally---it cannot represent geometry finer than
that---and this could create problems with polyhedron generation if it
leads
to degenerate faces. So try wrapping all of your data vectors with
quant(point_list, 1/1024).
I'll try that quantification—I had not seen that function before in
OpenSCAD. Ah, I see it is defined in BOSL2/math.scad
I'll try reducing the "smoothness" parameter, but some of the curves are
rather low-poly with small values. What I want is a way to get more or less
uniform sampling along the arc length adjustable from about 0.1–0.5mm,
despite the Bezier segments from Inkscape being so variable in length.
gasstationwithoutpumps.wordpress.com
www.thingiverse.com/gasstationwithoutpumps/things
Sent from: http://forum.openscad.org/
The problem with the assertion failures is not from the complexity of the
curves—even if I used very angular curves, with only 5–10 straight line
segments, I still got assertion failures.
By noting which objects did not get rendered, I reduced the problem to two
objects, each of which renders separately, but when unioned, I get the
assertion failures. I've tried translating the objects by small amounts,
which changes which assertion fails, but does not remove the assertion
failures.
I'll work on trying to create a small test case.
The profiles that are being used have fine resolution because they are being
created by the round_corners() function from a small number of
points—setting $fs larger to reduce the number of points on the profile sped
things up, but just led to getting the assertion failure sooner.
gasstationwithoutpumps.wordpress.com
www.thingiverse.com/gasstationwithoutpumps/things
Sent from: http://forum.openscad.org/
I have created a test case that causes the assertion failure with none of the
problems of close-together points in the definition. The preview works
fine, but the rendering gets an assertion failure.
test-assertion.scad
http://forum.openscad.org/file/t2612/test-assertion.scad
gasstationwithoutpumps.wordpress.com
www.thingiverse.com/gasstationwithoutpumps/things
Sent from: http://forum.openscad.org/