[OpenSCAD] General approach

arnholm at arnholm.org arnholm at arnholm.org
Mon Jul 8 06:55:27 EDT 2019


On 2019-07-08 11:23, Parkinbot 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?

Being convinced no alternative exists, one stops looking for it?

> 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 ...

For your theory to hold you need to use exact arithmetic at all levels 
and not just in parts. OpenSCAD doesn't do that so all you really get is 
floating point precision anyway. All theory aside, what matters is 
practice, try it for yourself. AngelCAD uses my Carve fork via xcsg 
https://github.com/arnholm/xcsg . I suggest you try AngelCAD to see if 
the theory holds (the AngelCAD binary bundles xcsg). Link to 
documentation and download at https://arnholm.github.io/angelcad-docs/ .

All talk of 'grid' requirement is a misunderstanding the way I see it, 
unless you talk about the special case of explicit coordinate matching 
from an STL polygon soup, where there are no shared vertices. Boolean 
operations don't work on polygon soups, they work on polyhedra. This is 
true in both CGAL and Carve. In AngelCAD/xcsg there are no grids.

Carsten Arnholm








More information about the Discuss mailing list