I'm not trying to be argumentative, I'm just not seeing that behavior.  I
recently modeled a camera lens which was eight cylinders all stacked,
face-to-face, atop each other.

And this works, fine:

p = [ 0.1, 0.1, 0.1 ];

union()
{

cube( p );

translate( [ 0.1, 0, 0 ] )
cube( p );
}

I'm just a confused old man.

On Thu, Sep 2, 2021 at 1:06 PM nop head nop.head@gmail.com wrote:

Perhaps it works because of the grid snap.

On Thu, 2 Sept 2021 at 19:20, Leonard Martin Struttmann <
lenstruttmann@gmail.com> wrote:

For simple models, aligned to the axis, with simple measurements it tends to work.

When you introduce rotations, cones, disparate radii (which are really lots of lines at different angles) it will bite you in the arse.

You may get a 'CGAL ERROR: assertion violation!' and then you will remember this discussion.

At some stage you will try to export something and you will get an error saying the object is not manifold.

It may also not be apparent that there is a problem until you use the STL in some circumstances.

You may want to import() the STL to do a CSG operation, then you get a CGAL https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Importing_Geometry#Notes  Error.

You may upload it to Shapeways and it tells you it has self-intersections.

Other software may tell you there are degenerate faces.

Then you will post your STL here, and I will send you something like this:

and tell you that you should embed the cylinder into the other object.

Browse:

https://www.google.com/search?q=OpenSCAD+%22self+intersection%22

https://www.google.com/search?q=OpenSCAD+%22degenerate%22

https://www.google.com/search?q=openscad+%22non+manifold%22

https://www.google.com/search?q=openscad+%22CGAL+ERROR%22

Not all of those issues will be due to breaking the rule of thumb, but a good majority will.

As a bonus, if you follow the rule of thumb, you will not get z-fighting https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#What_are_those_strange_flickering_artifacts_in_the_preview?  on preview.

Everyone who thinks they may get serious about 3D modelling should start to learn about manifoldness https://www.google.com/search?q=shared+face+manifold&source=lnms&tbm=isch&sa=X .

From: Leonard Martin Struttmann [mailto:lenstruttmann@gmail.com]
Sent: Fri, 3 Sep 2021 03:55
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: Module Disappears In Render

"The rule of thumb with multiple objects, either clearly separated or embed part of one within the other, don't just park them touching side to side."

MichaelAtOz, this statement confuses me.  I stack objects, face-to-face, vertically and horizontally all the time with no problems.  Have I just been lucky up until now? Or, is there a specific context that I'm missing?

On Wed, Sep 1, 2021 at 5:42 PM MichaelAtOz oz.at.michael@gmail.com wrote:

Yes, as that node was evaluated (and got an error) the node was then cached, so subsequent F6 don't get evaluated again, so no error.

If you think something is strange, it is always worth doing Design/Flush-cache.

Sharing a point (2D) is also non-manifold, as is sharing a single edge (3D).

The rule of thumb with multiple objects, either clearly separated or embed part of one within the other, don't just park them touching side to side.

From: Leonard Martin Struttmann [mailto:lenstruttmann@gmail.com]
Sent: Thu, 2 Sep 2021 05:45
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: Module Disappears In Render

Wow!  Yes, just that single error the first time.

Thanks, everyone!

On Wed, Sep 1, 2021 at 11:20 AM Jordan Brown openscad@jordan.maileater.net wrote:

On 9/1/2021 8:18 AM, Leonard Martin Struttmann wrote:

My only questions, then, are: Why did outerRing(), by itself, render successfully and produce an STL that Cura is happy with?  That is, why did the problem only occur when another module is introduced?

CGAL is what really dislikes objects that aren't perfectly formed, and doesn't get involved unless there's more than one object.

Also, why are there no warnings or errors?

In 2021.01 I get:

Parsing design (AST generation)...
Saved backup file: C:/Users/Jordan/Documents/OpenSCAD/backups/unsaved-backup-QApaZXoi.scad
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron.
Geometries in cache: 19
Geometry cache size in bytes: 1412968
CGAL Polyhedrons in cache: 1
[...]

But I don't get the error when I F6 again.  I assume that either the bad result has been cached, or the "suppress duplicate error reports" stuff is getting involved.

I have one suggestion and a pointless rant:

Suggestion:  caching the results of renders that encountered errors is probably bad.

Pointless rant:  CGL is too darned picky about its polyhedra.

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient

Virus-free.  http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

--
This email has been checked for viruses by AVG.
https://www.avg.com

Thanks!  I'll save this discussion in my "OpenSCAD Notes" file for those
times.  Again, thanks

On Thu, Sep 2, 2021 at 6:18 PM MichaelAtOz oz.at.michael@gmail.com wrote:

On 9/2/2021 11:03 AM, nop head wrote:

Remember that while 0.1 cannot be represented precisely, it can be
represented repeatably.

If you made a stack of 0.1 cubes by successively adding 0.1, I'd expect
all to be well because the top Z values of the cubes would have been
calculated using the same values as the bottom Z values of the next
cubes up.

It's a little trickier if you made a stack of cubes by multiplying the
cube number by 0.1, but I think all would still be well, even without
grid snap.  All of the top Z values would have been calculated using the
same numbers, as would all of the bottom Z values.  Those top Z values
would either all be the same as the bottom Z values of the next layer,
or would all be different.  In either case, you're OK.

I think the same would be true of any stack of cubes, no matter how
calculated and no matter how they are spaced:  because the Z coordinates
of any particular top or bottom face would all be the same, they would
either be all the same as the face of the adjoining layer, or all different.

Of course, that's also true of X-axis and Y-axis stacks, not just Z-axis
stacks.

I think, but I'm less sure, that the same would be true of any array of
face-to-face array of cubes, no matter how calculated.

I'm pretty sure that would all still be true as you translate the cubes,
and as you scale them.  Because the same operation happens to all of the
Z coordinates of the cubes, they would continue to be cleanly either all
the same or all different from the coordinates of the adjoining faces.

As you rotate them, however, things might change.  If the coordinates of
adjoining faces are exactly the same, they will continue to be exactly
the same after rotation.  If, however, they are not the same, they
might stay different or they might become the same, and bad things could
happen.  Grid snap would sometimes fix problems, and sometimes not.

Behavior of skew is left as an exercise for the reader.

On Fri, Sep 3, 2021, at 2:00 PM, Jordan Brown wrote:

That's not true because of the representation of geometry in OpenSCAD. In that stack of cubes, the height of each cube is not represented by the number 0.1, it is represented by a difference in Z coordinates. OpenSCAD's 64 bit floating point numbers have a fixed number of bits of precision (53 bits), so as the magnitude of a number gets larger, bits of precision are lost at the low end. There are more floating point numbers between 0.0 and 0.1 than there are between 10.0 and 10.1, so in the latter case, the difference of 0.1 is represented by fewer bits of precision. 10.1 - 10.0 == 0.09999999999999964, which is different from 0.1.

Multiplication will give you more accurate results than iterative addition of 0.1.
10*0.1 == 1 while iteratively adding 0.1 ten times gives you a different number, 0.9999999999999999

On 9/4/2021 3:33 PM, Doug Moen wrote:

All of that is true, except for the "that's not true" part. :-)

I set up a very special case:  a stack of cubes, stacked by successively
adding 0.1.

Yes, the first cube starts at Z=0 and ends at Z=0.09999999999999964. 
But the next cube starts at Z=0.09999999999999964, and continues to
0.09999999999999964 + 0.09999999999999964.  And so on.  The top face of
each cube will precisely match the bottom face of the next cube.  The
binary representation of 0.1 is not equal to 0.1, and the binary
representation of 0.1 plus itself is not equal to 0.2 (and may not be
equal to the binary representation of 0.2), but it is equal to a
separately calculated sum of the binary representation of 0.1 and the
binary representation of 0.1.

That is, 0.1+0.1 may or may not be equal to 0.2, but is always equal to
0.1+0.1.

But see below for the more general answer.

Yes.  Say that you stack ten 0.1 unit cubes by successively adding 0.1. 
Indeed, the top face of the topmost cube may well be at something like
0.9999999999999999.

Now you place an eleventh cube at Z=1.  That cube extends from Z=1 to
Z=~1.1.  With these numbers, that means that there is a microscopic gap
(or actually an attoscopic gap :-) between the tenth and the eleventh.

But we shouldn't assume that the representation is always a tiny bit
less than the true number.  Perhaps it is sometimes a tiny bit more.

You are still OK, because all of the corner points in the top face of
the tenth cube are at some particular Z value (call it Z1), and all of
the corner points in the bottom face of the eleventh cube are at some
particular Z value (call it Z2).  If Z1 and Z2 are the same, you're OK
because the two faces precisely match.  If they are different, you are
OK because they either do not touch, or they overlap.  Grid snap doesn't
affect that, because (I assume) grid snap will snap all of the points
the same way - again, they will either all match, or not touch, or overlap.

You should be OK with any stack of cuboids (of constant X-Y dimensions,
aligned in X and Y), no matter what the heights of the cuboids are and
no matter how they are spaced, because the top and bottom faces of each
cuboid are perfectly parallel with the XY plane.  You can never get just
one edge shared; either none of the edges are shared or they are all shared.

I'm pretty sure that this behavior is preserved across translation and
scaling - again, the points will either all match, or will all not
match, because the top and bottom faces remain perfectly parallel to the
XY plane.  I'm pretty sure that it is not preserved across rotation or
skewing; while points that match will stay matched, points that are
not matched might become matched, and that result could be different
for different corners of the cubes.

On 9/4/2021 5:48 PM, Jordan Brown wrote:

I grabbed your binary approximation of 0.1 without paying close enough
attention to context.  That number is the difference between 10.1 and
10, which is different from 0.1.  (As you say.)

But the same concept still applies, no matter what the exact values are.

Okay, let's introduce some notation. "~0.1" means the closest binary approximation of the number 0.1 in IEEE 64 bit floating point. It's not exactly equal to "0.1", it is actually 0.1000000000000000055511151231257827021181583404541015625

Now suppose we start at 0, and repeatedly add ~0.1 to our total. But we will do the addition using IEEE floating point arithmetic, which does not produce exact results.

The first numbers in our sequence are ~0, ~0.1, ~0.2
Because of the binary representation of floating point, x+x is always exactly the same as 2*x, there is no rounding or floating point imprecision in the result.

But when we add ~0.1 a third time, we get an imprecise result. ~0.1 + ~0.2 == ~0.30000000000000004. When we added ~0.1 to our running total, our total did not increase by ~0.1, it instead increased by a slightly larger value, ~0.10000000000000003, and this is due to floating point imprecision.

Here is the same numeric sequence printed in a less ambiguous format:
0.00000000000000000000000000000000000000000000000000000000
0.10000000000000000555111512312578270211815834045410156250
0.20000000000000001110223024625156540423631668090820312500
0.30000000000000004440892098500626161694526672363281250000

If the final addition had been performed exactly, the final value would have instead been:
0.30000000000000001665334536937734810635447502136230468750

This means that the individual cubes in your stack do not all have the same height.

On Sat, Sep 4, 2021, at 8:48 PM, Jordan Brown wrote:

I'm pretty sure the imprecision with floating point numbers is irrelevant,
because OpenSCAD merges points that are within ~0.00003 of each other.

On Sat, Sep 4, 2021, 6:57 PM Doug Moen doug@moens.org wrote: