acwest wrote

To loop over an empty array you want to write for(i=[0:-1]) and because of
how ranges work, this range is the same as [-1:0], so it will give you -1
and 0.  I'm not sure how anybody thought it could ever be desirable for a
range [a:b] to be interpreted as [b:a], but that's the situation.  My
understanding is that the warning is a preliminary step to changing the
behavior.

But if you just always write [a:1:b] then everything will work the way it
should.  The loop for(i=[0:1:-1]) will correctly loop over an empty array,
giving no loop steps.

--
Sent from: http://forum.openscad.org/

I think I based my answer on an older version of the code, the case I had
in mind works properly now.

On Thu, 4 Jul 2019, 13:41 adrianv, avm4@cornell.edu wrote:

The warning is new in a recent version of the code.  But the code behavior is
the same.  If v=[] and you write for(i=[0:len(v)-1]) then the loop will go
over -1 and 0.

acwest wrote

--
Sent from: http://forum.openscad.org/

I'm sure I used to get the same warning with for (i = v) as well, but I can
no longer replicate that behaviour (even in 2015.03)

On Thu, 4 Jul 2019, 14:07 adrianv, avm4@cornell.edu wrote:

So it seems like I only get the:

DEPRECATED: Using ranges of the form [begin:end] with begin value greater
than the end value is deprecated.

warning under a special case:
and the message appears partway through a bunch of other debug messages
(suggesting it built one structure, and then later hits the error doing the
difference or the later mirror.  Also nothing is drawn because there is a
problem somewhere.
I should mention I DO have loops where start is greater than end, but in
the cases I intend to be that way, I have an index value of -1.  I have
also recoded things so the other case [start: end] always uses [start: 1:
end] when end is intended to be >  start.

difference() {
arches2(16);
mirror([0,0,1]) {
arches2(16,true); //subtract a SOLID version
}
}
mirror([0,0,1]) {
arches2(16);
}

If I do arches2(16)  I can render the object and it looks fine.  Likewise
when I preview -> thrown together that I don't see any purple / pink facets
only purple pink edges.

If I union arches2(16) with a cube I get the: "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" message
I also get that message (twice) if I simply do this:

arches2(16,2);

mirror([0,0,1]) {
arches2(16,2);
}

arches2(16) does a skin over a bunch of 16 vertex polygons (that you can
roughly view as being horsehoes, wishbones, arches).  The second numeric
argument represents a thickness (it has a default value), a boolean
argument (default false) determines if the object is "solid" (that is not
horseshoe shaped but a convex polygon with no concavity, also with fewer
vertices)

So I'm confused how to approach debugging this.

On Thu, Jul 4, 2019 at 2:12 PM A. Craig West acraigwest@gmail.com wrote:

DanS wrote

I have seen behavior with regards to debug message that suggest to me that
the code is not necessarily executed in order.  Does anybody know?

You mean a step value of -1?  Like you wrote [10:-1:0]?  Nothing wrong with
that, and it should not trigger the message.  The warning message is just
for ranges that look like [a:b] where a>b.  Note also that it is only a
warning message.  You can still run your code to completion.  OpenSCAD will
count such a range starting at b and ascending to a.  (It will not start at
a and go by steps of -1 down to b.)

Unioning with a cube is supposed to be a test of validity of your
polyhedron.  I recall previously someone else said it might have to do with
rounding errors.  Have you tried simplifying your model until it works?  It
sounds like arches2(16) is producing an invalid result.

You said it's a skin over "a bunch" of 16 vertex polygons.  So what happens
if you skin the first two only.  Can you union the result with a cube?  Does
it look ok in thrown together mode?

I do not know what it means that you got pink edges in "thrown together"
view.  I haven't seen that.

--
Sent from: http://forum.openscad.org/

yes, I've simplified it to where it seems to work.  So I know it breaks
down where I do "wave" which interpolates between one curve and another
using sin() (to give a smooth curve rather than a linear transition).

I'll try a smaller set of interpolations that might be easier for me to
view completely.

Earlier in the email thread I took a snapshot of the pink edges

[image: image.png]

moving around the model I didn't see any pink / purple facets.  There may
have been some present, I find it hard to investigate the whole thing
because it is big and as I rotate or zoom in / out sometimes I can't see
anything; I do know if there are pink/purple facets they are in the vast
minority as I think I viewed most of the facets

On Thu, Jul 4, 2019 at 5:42 PM adrianv avm4@cornell.edu wrote:

DanS wrote

Is it possible that you have very skinny facets showing up in pink between
larger facets?  It just takes a single bad facet to ruin your entire model.

If the interpolation process is at fault can you use a simpler polygon as
the base for the interpolation?

--
Sent from: http://forum.openscad.org/

So I was taking your idea of doing less.  Instead of 105 transition steps I
did 15.
If I union it with a cube it only works if they don't touch at all, if they
do touch it seems to blow up and render nothing.

If I take the more simple version and do Preview -> Thrown together I don't
see any pink / purple facets (but the edges are all pink purple) the one
thing that strikes me as very odd is that each arch should be planar.  I
would intuitively expect no triangles on the ends yet all the vertices on
the ends are part of triangles.  Of course, it might also do those
triangles if all the vertexes are planar, I just don't know.

[image: image.png]

On Thu, Jul 4, 2019 at 6:39 PM adrianv avm4@cornell.edu wrote:

I don't think you should see purple edges. Do they meet or is there a hole
through which you can see the purple interior?

On Thu, 4 Jul 2019, 23:51 Dan Shriver, tabbydan@gmail.com wrote: