I have always assumed, based on what has been written on this forum in the
past, that OpenSCAD functions like rotate(), translate(), scale(), etc are
just front ends for multmatrix(). Am I mistaken there and the actual
implementation of rotate() is independent of multmatrix()? It is always
possible to force special values like sin(90)->sin(pi/2)==1, but is it
actually done? From the code references Torsten has given, I at least am not
able to ascertain that, and thus I remain sceptical. Kudos to nophead for
finding a workaround, but I am looking for more.
I am looking for information that is trustworthy enough that I can build an
exception handler on it, an exception handler that lays to rest CGAL
assertion violations, once and for all. I have learned enough by now that I
can do just that manually - at least if the .stl files are small enough. But
I also want to do that under program control, and with large files, so that
others can benefit as well. So I need more accuracy.
X86 hardware provides accuracy these days for floating point operations
better than 1E-19 decimal or not worse than 2^-65 binary. OpenSCAD, on the
other hand, for the script known as issue1258
https://github.com/openscad/openscad/blob/master/testdata/scad/3D/issues/issue1258.scad
, suffers from accuracy not better than 1E-5 decimal, or 2^-18 binary, which
is a 47 binary digits difference. It is this big loss in precision that is
at the heart of degenerate triangles, and all that flows from it.
wolf
--
View this message in context: http://forum.openscad.org/Rounding-Errors-tp21821p21938.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I have always assumed, based on what has been written on this forum in the
past, that OpenSCAD functions like rotate(), translate(), scale(), etc are
just front ends for multmatrix(). Am I mistaken there and the actual
implementation of rotate() is independent of multmatrix()? It is always
possible to force special values like sin(90)->sin(pi/2)==1, but is it
actually done? From the code references Torsten has given, I at least am not
able to ascertain that, and thus I remain sceptical. Kudos to nophead for
finding a workaround, but I am looking for more.
I am looking for information that is trustworthy enough that I can build an
exception handler on it, an exception handler that lays to rest CGAL
assertion violations, once and for all. I have learned enough by now that I
can do just that manually - at least if the .stl files are small enough. But
I also want to do that under program control, and with large files, so that
others can benefit as well. So I need more accuracy.
X86 hardware provides accuracy these days for floating point operations
better than 1E-19 decimal or not worse than 2^-65 binary. OpenSCAD, on the
other hand, for the script known as issue1258
<https://github.com/openscad/openscad/blob/master/testdata/scad/3D/issues/issue1258.scad>
, suffers from accuracy not better than 1E-5 decimal, or 2^-18 binary, which
is a 47 binary digits difference. It is this big loss in precision that is
at the heart of degenerate triangles, and all that flows from it.
wolf
--
View this message in context: http://forum.openscad.org/Rounding-Errors-tp21821p21938.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
