[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
> 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
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
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
> 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 :-)
More information about the Discuss