[OpenSCAD] General approach

Parkinbot rudolf at digitaldocument.de
Mon Jul 8 05:23:02 EDT 2019


cacb wrote
> On 2019-07-07 23:24, Parkinbot wrote:
>> Carsten, as CGAL is a piece of software on its own, and there seems no
>> floating point number alternative in sight,
> 
> Actually, that is not true. There is at least one surface mesh / 
> floating point vertex based alternative, namely Carve. 

Carsten, how could one miss this? 
But even without having had a closer look into Carve and your adapation, I
dare to doubt that a pure floating point representation approach on both
sides, OpenSCAD and the rendering part, will be able to do away with the
snap-to-grid problem, because the problem rather *arises* with the use of
floating point representation. Any translation within a non aequidistant
grid will suffer from a snap-to-grid result. As floating point arithmetic is
not commuative (e.g. a+b-c = a-c+b will not hold) Boolean operations will
have to deal with snap-to-grids all the time. So two operations will not
have the same result with respect to translation. What does this mean for a
union operation? Or for a symmetric object construction scheme as proposed
by the thread starter. 
CGAL may be slow, but the architects' decision to build on a rational number
representation had good reasons ... 



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



More information about the Discuss mailing list