[OpenSCAD] General approach

nop head nop.head at gmail.com
Mon Jul 8 06:44:38 EDT 2019


>
> CGAL may be slow, but the architects' decision to build on a rational
> number representation had good reasons .


Yes but OpenSCAD gains zero advantage from this because it converts back to
doubles and snaps to a grid and then feeds the results back to CGAL.

If Carve can do booleans in floating point then OpenSCAD will simply feed
in floats and get floats back. There would be no need to snap to a grid and
if it works in floats, rather than doubles, STL export will work.



On Mon, 8 Jul 2019 at 10:23, Parkinbot <rudolf at digitaldocument.de> wrote:

> 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/
>
> _______________________________________________
> 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/20190708/726c22eb/attachment.html>


More information about the Discuss mailing list