[OpenSCAD] Getting more information

Dan Shriver tabbydan at gmail.com
Thu Jul 4 12:21:22 EDT 2019


Thanks.
Ok that makes sense if you meant start>end is degenerate; I typically
thought of "degenerate" as in more than one thing being the same such as
start = end.  I have changed all my loops to have increment specified as 1.

On the preview:
If I do render before preview does that mess things up? And if so how do I
fix it?  I have now done preview; thrown together; preview and find I can
still see my object but when I try to rotate it or zoom in and out things
aren't behaving like they did with render.  For instance, zoom in and out
the X Y Z axis get bigger and smaller but the object stays the same size.
Rotating around also doesn't seem to behave the same as it did for render.

The manual page you sent has this tidbit

"When you select 'Thrown together' from the view menu and *compile* the
design (*not* compile and render!) you will see a preview with the
mis-oriented polygons highlighted. Unfortunately this highlighting is not
possible in the OpenCSG preview mode because it would interfere with the
way the OpenCSG preview mode is implemented.)"

I did select Thrown Together and I did a preview before and after.  I'm
assuming compile is included in both render and preview.

On Thu, Jul 4, 2019 at 11:44 AM adrianv <avm4 at cornell.edu> wrote:

> If you write [a:1:b] then this steps from a to be in increments of 1.  If
> b<a
> then you get zero steps and nothing happens.  This is exactly what you
> expect this syntax to do.  It is always correct and it won't produce any
> warnings. If you write general code (such as might be in a library) it may
> encounter degenerate cases where a>b and you want the loop to do nothing.
> If, on the other hand, you're coding up a specific model, you probably
> don't
> want to write a loop that does nothing.
>
> If you write [a:b] then it steps from min(a,b) to max(a,b) in steps of 1.
> If a>b most likely you have a bug in your code.  The latest version of
> OpenSCAD warns about this but doesn't tell you where the problem is.
>
> So by changing all occurrences of [a:b] to [a:1:b] you will make your code
> behave in what is arguably the correct manner.  But it doesn't mean you
> code
> is actually correct.  It depends on why you had a>b.   Does that clear
> things up?
>
>
> DanS wrote
> > Thanks for the tips!
> >
> > I'm not sure I understand "It could be a degenerate case, in which case
> > you
> > can solve the problem by replacing every occurrence of [a:b] in your code
> > with [a:1:b]"
> >
> > I thought the way loops worked in openscad was [start:increment:end] or
> if
> > two arguments were used they were assumed to be only start and end and
> > increment was assumed to be 1.
> > I will try your suggestion but don't understand why it would sometimes be
> > a
> > problem and sometimes not.  I'd like to understand it since it would give
> > me a better picture how to use OpenSCAD.  When you say "degenerate" do
> you
> > mean in the case start = end; or do you mean the interpreter sometimes
> > screws up and interprets two arguments as [start:increment] and gives end
> > some weird garbage value?
> >
> > On Thu, Jul 4, 2019 at 11:03 AM adrianv <
>
> > avm4@
>
> > > wrote:
> >
> >> DanS wrote
> >> > I'm still trying to debug my own code but am frustrated in that I
> can't
> >> > see
> >> > where the problem exists.  I get some errors and other messages from
> >> > OpenScad but unfortunately they don't point to what it was in my code
> >> that
> >> > triggered it:
> >> >
> >> > ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
> >> > violation! Expr: e_below != SHalfedge_handle() File:
> >> >
> >>
> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
> >> > Line: 426
> >>
> >> I don't recognize this error specifically, but typically if you get
> >> errors
> >> relating to polyhedra it means you have constructed an invalid
> polyhedron
> >> with the polyhedron module.  You can select View->Thrown Together in
> >> preview
> >> which will show reversed faces.  But otherwise you just have to work
> >> through
> >> your construction.
> >>
> >>
> >> > Likewise, I sometimes get this warning:
> >> >
> >> >
> >> > DEPRECATED: Using ranges of the form [begin:end] with begin value
> >> greater
> >> > than the end value is deprecated.
> >>
> >> Yeah, this one is extremely annoying.  There appears to be no way to get
> >> OpenSCAD to give you more information about this.  It can be anywhere in
> >> your code, or anything that you include.  It could be a degenerate case,
> >> in
> >> which case you can solve the problem by replacing every occurrence of
> >> [a:b]
> >> in your code with [a:1:b].  But if it's a mistake in your code, that
> will
> >> just cause the loop to not run---it won't tell you where the problem is.
> >>
> >>
> >>
> >>
> >> --
> >> Sent from: http://forum.openscad.org/
> >>
> >> _______________________________________________
> >> OpenSCAD mailing list
> >>
>
> > Discuss at .openscad
>
> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> >>
> >
> > _______________________________________________
> > OpenSCAD mailing list
>
> > Discuss at .openscad
>
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20190704/041f5868/attachment.html>


More information about the Discuss mailing list