[OpenSCAD] General approach

Parkinbot rudolf at digitaldocument.de
Sun Jul 7 17:24:09 EDT 2019

All this discussion leads far away from the origin of the thread. It may
explain, why in very rare cases extrusions fail, when vertices are to close
(even not identical) or a Boolean operation leads to a CGAL error. But I
dare to say that in 99.99% of all problems people have when sweeping,
skinning, or constructing polyhedra, there are computational or logical bugs
involved and not snap-to-grid effects. 

I only mentioned this category of possible errors, because they can indeed
occur if e.g. mirrored, translated or rotated versions of skinned objects
are unioned, or symmetries are constructed by use of Boolean operations in a
more general sense, since the thread originator asked to get some opinion on
this technique. 

cacb wrote
> Which is the same as assuming floating point coordinates everywhere. It 
> seems the use of 'rational numbers' in CGAL adds no real benefits in 
> precision, but instead adds cost in the form of lost performance and 
> increased memory consumption. Add the unpredictable grid stuff in 
> OpenSCAD and it is questionable if anything is gained compared to 
> computing with floating point numbers everywhere.

Carsten, as CGAL is a piece of software on its own, and there seems no
floating point number alternative in sight, one would have to change/adopt
the number representation and arithmetics (!) in OpenSCAD in order to avoid
all this problems and gain a sort of seemless representation. Obviously this
will hold only up the point, where STL imports are involved, or floating
point numbers come into play for similar reasons. This theme has been
discussed extensively a while ago, without concrete results - no way to do
away with it. 

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

More information about the Discuss mailing list