[OpenSCAD] General approach

arnholm at arnholm.org arnholm at arnholm.org
Sun Jul 7 21:59:23 EDT 2019


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. The original is 
at https://github.com/folded/carve and my fork is at 
https://github.com/arnholm/carve. My fork fixes some compiler warnings 
and makes carve MSVC compatible, plus replaces some deprecated C++ 
features (auto_ptr) with modern equivalents (unique_ptr).

I use Carve in AngelCAD, so indeed it is possible. You can compare the 
features of AngelCAD and OpenSCAD to verify.

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

All you need to do is a bit of software re-design, i.e. define the API 
(Application Programming Interface) between the application (=OpenSCAD) 
and the library (=CGAL today). I.e. what is the minimum set of features 
used by OpenSCAD. Such a C++ API will have floating point vertices since 
that is what the application generates anyway. Defining the API is stage 
1.

Stage 2 is to implement the API back-end using CGAL and check that 
OpenSCAD still works as before. Stage 3 is to implement the API back-end 
using Carve (eliminating 'rational numbers').

> Obviously this
> will hold only up the point, where STL imports are involved,

STL import is a different animal which isn't directly related to 
coordinate representation, importing STL is a problem regardless of 
whether one employs floating point or 'rational number' coordinates 
internally.

The issue with STL import to a modeller (as opposed to a slicer) is that 
it is a 'polygon soup' with zero topological information, requiring 
extensive coordinate matching. Such matching is prone to failure as it 
is a matter of subjective interpretation. For this and other reasons, I 
have chosen to do STL import in 2 stages, first convert to OBJ/OFF/AMF 
in a separate application (polyfix, ref 
https://github.com/arnholm/angelcad/releases ) that does 
interpretations/repairs and establishes a topology. Then import from 
OBJ/OFF/AMF into AngelCAD.

OpenSCAD could choose to do it differently, e.g. one could declare STL 
import as a legacy feature and promote formats such as OBJ (or whatever) 
as better alternatives.

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

See above. As you say this was discussed before and like now I was told 
it could not be done. Therefore, I did it :-)

Carsten Arnholm



More information about the Discuss mailing list