Does extrusion or CSG make the most correct mesh?
I have found that some of the STL's can't be processed after Netfabb in
Meshlab because the polygons are not all welded and gaps appear if i try
subdivision.
I am using CSG and perhaps extrusion could be easier to fix geometrically?
What are your techniques for post processing and error correction of mesh,
what programs do you use in combination with openscad?
I figure most of the STL's can go straight to a printer perhaps via netfabb,
so if i want some smoothed spirographs i should try and get them done right
in openscad and not work on them after in Meshlab?
--
View this message in context: http://forum.openscad.org/Does-extrusion-or-CSG-make-the-most-correct-mesh-tp13605.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
You shouldn't need to post process files from OpenScad. Best to program
manifold objects to start with.
The best way to make smooth shapes from mathematical functions is to use
recursive functions / list comprehension to make lists of vertices and
faces to pass to polyhedron. That is fast so you can have enough facets to
make it smooth.
On 25 August 2015 at 11:41, ufomorace ant.stewart@yahoo.com wrote:
I have found that some of the STL's can't be processed after Netfabb in
Meshlab because the polygons are not all welded and gaps appear if i try
subdivision.
I am using CSG and perhaps extrusion could be easier to fix geometrically?
What are your techniques for post processing and error correction of mesh,
what programs do you use in combination with openscad?
I figure most of the STL's can go straight to a printer perhaps via
netfabb,
so if i want some smoothed spirographs i should try and get them done right
in openscad and not work on them after in Meshlab?
--
View this message in context:
http://forum.openscad.org/Does-extrusion-or-CSG-make-the-most-correct-mesh-tp13605.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You do sometimes have to post-process STL files generated by OpenSCAD,
because OpenSCAD sometimes writes out bad STL (ie, files that OpenSCAD
can't itself read). You can reproduce this fairly simply, by doing CSG
operations on spheres. This was discussed in an email thread earlier this
year.
On 25 August 2015 at 09:07, nop head nop.head@gmail.com wrote:
You shouldn't need to post process files from OpenScad. Best to program
manifold objects to start with.
The best way to make smooth shapes from mathematical functions is to use
recursive functions / list comprehension to make lists of vertices and
faces to pass to polyhedron. That is fast so you can have enough facets to
make it smooth.
On 25 August 2015 at 11:41, ufomorace ant.stewart@yahoo.com wrote:
I have found that some of the STL's can't be processed after Netfabb in
Meshlab because the polygons are not all welded and gaps appear if i try
subdivision.
I am using CSG and perhaps extrusion could be easier to fix geometrically?
What are your techniques for post processing and error correction of mesh,
what programs do you use in combination with openscad?
I figure most of the STL's can go straight to a printer perhaps via
netfabb,
so if i want some smoothed spirographs i should try and get them done
right
in openscad and not work on them after in Meshlab?
--
View this message in context:
http://forum.openscad.org/Does-extrusion-or-CSG-make-the-most-correct-mesh-tp13605.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Yes anything that creates vertices too close together breaks OpenScad STL
generation, but if you don't use CSG and just form polyhedra with maths you
have complete control over whether it is a valid mesh or not.
On 25 August 2015 at 16:59, doug moen doug@moens.org wrote:
You do sometimes have to post-process STL files generated by OpenSCAD,
because OpenSCAD sometimes writes out bad STL (ie, files that OpenSCAD
can't itself read). You can reproduce this fairly simply, by doing CSG
operations on spheres. This was discussed in an email thread earlier this
year.
On 25 August 2015 at 09:07, nop head nop.head@gmail.com wrote:
You shouldn't need to post process files from OpenScad. Best to program
manifold objects to start with.
The best way to make smooth shapes from mathematical functions is to use
recursive functions / list comprehension to make lists of vertices and
faces to pass to polyhedron. That is fast so you can have enough facets to
make it smooth.
On 25 August 2015 at 11:41, ufomorace ant.stewart@yahoo.com wrote:
I have found that some of the STL's can't be processed after Netfabb in
Meshlab because the polygons are not all welded and gaps appear if i try
subdivision.
I am using CSG and perhaps extrusion could be easier to fix
geometrically?
What are your techniques for post processing and error correction of
mesh,
what programs do you use in combination with openscad?
I figure most of the STL's can go straight to a printer perhaps via
netfabb,
so if i want some smoothed spirographs i should try and get them done
right
in openscad and not work on them after in Meshlab?
--
View this message in context:
http://forum.openscad.org/Does-extrusion-or-CSG-make-the-most-correct-mesh-tp13605.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nop head: "Yes anything that creates vertices too close together
breaks OpenScad STL generation".
This is a bug in OpenSCAD. Generated STL files should always be valid.
At the very least, OpenSCAD should be able to read any STL file that
it generates, and that will be my criterion for fixing the bug.
Whether other programs can successfully read OpenSCAD generated STL
files is not guaranteed, since those other programs could have bugs or
limitations that we have no control over.
In the majority of cases, the problem is caused by a bug in the
export_stl() function, which throws away most of the information in
each floating point number, and only prints a crude ASCII
approximation of the number, instead of printing an accurate
representation.
In a small minority of cases, the problem is caused by the conversion
from CGAL exact rational numbers to 64 bit floating point numbers. I
expect this situation is quite rare, compared to the bug in
export_stl(), but to completely fix the problem, I think we'll need to
switch to a new geometry kernel that represents the rendered model
using 64 bit floats instead of using rationals. This new kernel will
also be a lot faster.
The bug in export_stl() is fixable, but it's complicated, so there is
a lot of reading ahead.
Here are lines containing the bug:
output << " outer loop\n";
BOOST_FOREACH(const Vector3d &v, p) {
output << " vertex " << v[0] << " " << v[1] << "
" << v[2] << "\n";
}
output << " endloop\n";
The problem lies in the use of 'output << v[i]' for outputing a
floating point number. By default, a C++ stream prints a floating
point number with a precision of '6', meaning that at most 6 decimal
digits are used to represent the number. But in this case we are
printing 64 bit floating point numbers, which have 53 bits of
mantissa. In order to print a 64 bit floating point number accurately,
that is to print the number without losing any information, up to 16
decimal digits are required. Obviously, capping the precision at 6
throws away most of the information in the floating point number.
This is actually a complex and subtle problem. There is an algorithm
for printing floating point numbers accurately. It was first described
by the paper "How to print floating-point numbers accurately" by Guy
Steele and Jon White in 1990. This algorithm determines the minimum
number of decimal digits required to uniquely characterize the
floating point number, such that it can be distinguished from
neighbouring floats. There is a sister algorithm, "How to read
floating-point numbers accurately", which reads this decimal
representation and exactly reconstructs the original 64 bit binary
float.
OpenSCAD uses boost::lexical_cast<double>(string) to convert a decimal
floating point string representation to a 64 bit double precision
float. Based on my code review of the Boost and C libraries, this
works correctly: it uses the "How to read floating-point numbers
accurately" algorithm to read the float, using David Gay's
implementation of strtod() on the platform I checked.
Unfortunately, there seems to be no function in the C or C++ standard
that prints a floating point number accurately, using the shortest
representation that works, in accordance with the algorithm. And that
means we'll need to import code from an open source library to do the
job. In theory, we might be able to solve the problem by specifying a
precision of 16, but I've experimented with that, and in many cases
you get way more than the minimum number of decimal digits required to
uniquely specify the number. This would lead to unnecessary bloating
of the size of STL files, and I don't think people will be happy with
that. So I think we need to use the algorithm.
There are several open source implementations of the algorithm on the
internet, but the most popular and trusted implementation is "dtoa" by
David Gay, so I propose to use that.
http://www.netlib.org/fp/dtoa.c
The netlib approach to version control is very old school. Here is the
change log for dtoa.c:
http://www.netlib.org/fp/changes
You'll note that the code is being actively maintained, and was
originally written in 1990. It takes a long time to shake all the bugs
out of an algorithm this subtle, which is why I don't trust the more
recent implementations quite as much, even though they claim to be
faster.
In order to make David Gay's dtoa work correctly on intel platforms,
it is necessary to execute the
_control87(PC_53, MCW_PC);
instruction first, which forces the use of double precision (53 bit)
rounding precision in floating point computations. A side effect of
executing this during OpenSCAD initialization is that floating point
computations will be performed consistently on Windows and Linux
platforms, with the same results, which I do not think is the case
currently. That might be a useful change. It will probably help with
unit testing.
The bug also exists in the AMF export. In that case, the AMF standard
is very precise, and we are required to output 64 bit floats in
ASCII, using the "How print floating point numbers accurately"
algorithm.
Doug Moen.
On 25 August 2015 at 13:20, nop head nop.head@gmail.com wrote:
Yes anything that creates vertices too close together breaks OpenScad STL generation, but if you don't use CSG and just form polyhedra with maths you have complete control over whether it is a valid mesh or not.
On 25 August 2015 at 16:59, doug moen doug@moens.org wrote:
You do sometimes have to post-process STL files generated by OpenSCAD, because OpenSCAD sometimes writes out bad STL (ie, files that OpenSCAD can't itself read). You can reproduce this fairly simply, by doing CSG operations on spheres. This was discussed in an email thread earlier this year.
On 25 August 2015 at 09:07, nop head nop.head@gmail.com wrote:
You shouldn't need to post process files from OpenScad. Best to program manifold objects to start with.
The best way to make smooth shapes from mathematical functions is to use recursive functions / list comprehension to make lists of vertices and faces to pass to polyhedron. That is fast so you can have enough facets to make it smooth.
On 25 August 2015 at 11:41, ufomorace ant.stewart@yahoo.com wrote:
I have found that some of the STL's can't be processed after Netfabb in
Meshlab because the polygons are not all welded and gaps appear if i try
subdivision.
I am using CSG and perhaps extrusion could be easier to fix geometrically?
What are your techniques for post processing and error correction of mesh,
what programs do you use in combination with openscad?
I figure most of the STL's can go straight to a printer perhaps via netfabb,
so if i want some smoothed spirographs i should try and get them done right
in openscad and not work on them after in Meshlab?
--
View this message in context: http://forum.openscad.org/Does-extrusion-or-CSG-make-the-most-correct-mesh-tp13605.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Added to that I think OpenScad still snaps vertices to an arbitrary grid
without topological awareness, which also causes bad meshes when vertices
are close. I may be wrong but I don't remember it being fixed.
On 26 August 2015 at 20:44, doug moen doug@moens.org wrote:
nop head: "Yes anything that creates vertices too close together
breaks OpenScad STL generation".
This is a bug in OpenSCAD. Generated STL files should always be valid.
At the very least, OpenSCAD should be able to read any STL file that
it generates, and that will be my criterion for fixing the bug.
Whether other programs can successfully read OpenSCAD generated STL
files is not guaranteed, since those other programs could have bugs or
limitations that we have no control over.
In the majority of cases, the problem is caused by a bug in the
export_stl() function, which throws away most of the information in
each floating point number, and only prints a crude ASCII
approximation of the number, instead of printing an accurate
representation.
In a small minority of cases, the problem is caused by the conversion
from CGAL exact rational numbers to 64 bit floating point numbers. I
expect this situation is quite rare, compared to the bug in
export_stl(), but to completely fix the problem, I think we'll need to
switch to a new geometry kernel that represents the rendered model
using 64 bit floats instead of using rationals. This new kernel will
also be a lot faster.
The bug in export_stl() is fixable, but it's complicated, so there is
a lot of reading ahead.
Here are lines containing the bug:
output << " outer loop\n";
BOOST_FOREACH(const Vector3d &v, p) {
output << " vertex " << v[0] << " " << v[1] << "
" << v[2] << "\n";
}
output << " endloop\n";
The problem lies in the use of 'output << v[i]' for outputing a
floating point number. By default, a C++ stream prints a floating
point number with a precision of '6', meaning that at most 6 decimal
digits are used to represent the number. But in this case we are
printing 64 bit floating point numbers, which have 53 bits of
mantissa. In order to print a 64 bit floating point number accurately,
that is to print the number without losing any information, up to 16
decimal digits are required. Obviously, capping the precision at 6
throws away most of the information in the floating point number.
This is actually a complex and subtle problem. There is an algorithm
for printing floating point numbers accurately. It was first described
by the paper "How to print floating-point numbers accurately" by Guy
Steele and Jon White in 1990. This algorithm determines the minimum
number of decimal digits required to uniquely characterize the
floating point number, such that it can be distinguished from
neighbouring floats. There is a sister algorithm, "How to read
floating-point numbers accurately", which reads this decimal
representation and exactly reconstructs the original 64 bit binary
float.
OpenSCAD uses boost::lexical_cast<double>(string) to convert a decimal
floating point string representation to a 64 bit double precision
float. Based on my code review of the Boost and C libraries, this
works correctly: it uses the "How to read floating-point numbers
accurately" algorithm to read the float, using David Gay's
implementation of strtod() on the platform I checked.
Unfortunately, there seems to be no function in the C or C++ standard
that prints a floating point number accurately, using the shortest
representation that works, in accordance with the algorithm. And that
means we'll need to import code from an open source library to do the
job. In theory, we might be able to solve the problem by specifying a
precision of 16, but I've experimented with that, and in many cases
you get way more than the minimum number of decimal digits required to
uniquely specify the number. This would lead to unnecessary bloating
of the size of STL files, and I don't think people will be happy with
that. So I think we need to use the algorithm.
There are several open source implementations of the algorithm on the
internet, but the most popular and trusted implementation is "dtoa" by
David Gay, so I propose to use that.
http://www.netlib.org/fp/dtoa.c
The netlib approach to version control is very old school. Here is the
change log for dtoa.c:
http://www.netlib.org/fp/changes
You'll note that the code is being actively maintained, and was
originally written in 1990. It takes a long time to shake all the bugs
out of an algorithm this subtle, which is why I don't trust the more
recent implementations quite as much, even though they claim to be
faster.
In order to make David Gay's dtoa work correctly on intel platforms,
it is necessary to execute the
_control87(PC_53, MCW_PC);
instruction first, which forces the use of double precision (53 bit)
rounding precision in floating point computations. A side effect of
executing this during OpenSCAD initialization is that floating point
computations will be performed consistently on Windows and Linux
platforms, with the same results, which I do not think is the case
currently. That might be a useful change. It will probably help with
unit testing.
The bug also exists in the AMF export. In that case, the AMF standard
is very precise, and we are required to output 64 bit floats in
ASCII, using the "How print floating point numbers accurately"
algorithm.
Doug Moen.
On 25 August 2015 at 13:20, nop head nop.head@gmail.com wrote:
Yes anything that creates vertices too close together breaks OpenScad
STL generation, but if you don't use CSG and just form polyhedra with maths
you have complete control over whether it is a valid mesh or not.
On 25 August 2015 at 16:59, doug moen doug@moens.org wrote:
You do sometimes have to post-process STL files generated by OpenSCAD,
because OpenSCAD sometimes writes out bad STL (ie, files that OpenSCAD
can't itself read). You can reproduce this fairly simply, by doing CSG
operations on spheres. This was discussed in an email thread earlier this
year.
On 25 August 2015 at 09:07, nop head nop.head@gmail.com wrote:
You shouldn't need to post process files from OpenScad. Best to
program manifold objects to start with.
The best way to make smooth shapes from mathematical functions is to
use recursive functions / list comprehension to make lists of vertices and
faces to pass to polyhedron. That is fast so you can have enough facets to
make it smooth.
On 25 August 2015 at 11:41, ufomorace ant.stewart@yahoo.com wrote:
I have found that some of the STL's can't be processed after Netfabb
in
Meshlab because the polygons are not all welded and gaps appear if i
try
subdivision.
I am using CSG and perhaps extrusion could be easier to fix
geometrically?
What are your techniques for post processing and error correction of
mesh,
what programs do you use in combination with openscad?
I figure most of the STL's can go straight to a printer perhaps via
netfabb,
so if i want some smoothed spirographs i should try and get them done
right
in openscad and not work on them after in Meshlab?
--
View this message in context:
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
O> In the majority of cases, the problem is caused by a bug in the
export_stl() function, which throws away most of the information in
each floating point number, and only prints a crude ASCII
approximation of the number, instead of printing an accurate
representation.
That's just a symptom of the underlying problem.
The bug in export_stl() is fixable, but it's complicated, so there is
a lot of reading ahead.
Iterate over each point. Enter each point into a dictionary along with
its STL file value. If any two points have the same STL value then adjust
them by the smallest amount possible so they don't clash but preserve
ordering. Iterate this as needed jiggling other points so it all fits
correctly and in order.
Write out the STL using the dictionary values instead of the 'exact'
values internally used.
A fancier approach is to identify points that will resolve to the same
value and simplify the mesh, but that's way way harder geometry that
jiggling points.
Alan
Just use old good sprintf() to specify number of digits as the first step?
On 26.08.2015 22:44, doug moen wrote:
nop head: "Yes anything that creates vertices too close together
breaks OpenScad STL generation".
This is a bug in OpenSCAD. Generated STL files should always be valid.
At the very least, OpenSCAD should be able to read any STL file that
it generates, and that will be my criterion for fixing the bug.
Whether other programs can successfully read OpenSCAD generated STL
files is not guaranteed, since those other programs could have bugs or
limitations that we have no control over.
In the majority of cases, the problem is caused by a bug in the
export_stl() function, which throws away most of the information in
each floating point number, and only prints a crude ASCII
approximation of the number, instead of printing an accurate
representation.
In a small minority of cases, the problem is caused by the conversion
from CGAL exact rational numbers to 64 bit floating point numbers. I
expect this situation is quite rare, compared to the bug in
export_stl(), but to completely fix the problem, I think we'll need to
switch to a new geometry kernel that represents the rendered model
using 64 bit floats instead of using rationals. This new kernel will
also be a lot faster.
The bug in export_stl() is fixable, but it's complicated, so there is
a lot of reading ahead.
Here are lines containing the bug:
output << " outer loop\n";
BOOST_FOREACH(const Vector3d &v, p) {
output << " vertex " << v[0] << " " << v[1] << "
" << v[2] << "\n";
}
output << " endloop\n";
The problem lies in the use of 'output << v[i]' for outputing a
floating point number. By default, a C++ stream prints a floating
point number with a precision of '6', meaning that at most 6 decimal
digits are used to represent the number. But in this case we are
printing 64 bit floating point numbers, which have 53 bits of
mantissa. In order to print a 64 bit floating point number accurately,
that is to print the number without losing any information, up to 16
decimal digits are required. Obviously, capping the precision at 6
throws away most of the information in the floating point number.
This is actually a complex and subtle problem. There is an algorithm
for printing floating point numbers accurately. It was first described
by the paper "How to print floating-point numbers accurately" by Guy
Steele and Jon White in 1990. This algorithm determines the minimum
number of decimal digits required to uniquely characterize the
floating point number, such that it can be distinguished from
neighbouring floats. There is a sister algorithm, "How to read
floating-point numbers accurately", which reads this decimal
representation and exactly reconstructs the original 64 bit binary
float.
OpenSCAD uses boost::lexical_cast<double>(string) to convert a decimal
floating point string representation to a 64 bit double precision
float. Based on my code review of the Boost and C libraries, this
works correctly: it uses the "How to read floating-point numbers
accurately" algorithm to read the float, using David Gay's
implementation of strtod() on the platform I checked.
Unfortunately, there seems to be no function in the C or C++ standard
that prints a floating point number accurately, using the shortest
representation that works, in accordance with the algorithm. And that
means we'll need to import code from an open source library to do the
job. In theory, we might be able to solve the problem by specifying a
precision of 16, but I've experimented with that, and in many cases
you get way more than the minimum number of decimal digits required to
uniquely specify the number. This would lead to unnecessary bloating
of the size of STL files, and I don't think people will be happy with
that. So I think we need to use the algorithm.
There are several open source implementations of the algorithm on the
internet, but the most popular and trusted implementation is "dtoa" by
David Gay, so I propose to use that.
http://www.netlib.org/fp/dtoa.c
The netlib approach to version control is very old school. Here is the
change log for dtoa.c:
http://www.netlib.org/fp/changes
You'll note that the code is being actively maintained, and was
originally written in 1990. It takes a long time to shake all the bugs
out of an algorithm this subtle, which is why I don't trust the more
recent implementations quite as much, even though they claim to be
faster.
In order to make David Gay's dtoa work correctly on intel platforms,
it is necessary to execute the
_control87(PC_53, MCW_PC);
instruction first, which forces the use of double precision (53 bit)
rounding precision in floating point computations. A side effect of
executing this during OpenSCAD initialization is that floating point
computations will be performed consistently on Windows and Linux
platforms, with the same results, which I do not think is the case
currently. That might be a useful change. It will probably help with
unit testing.
The bug also exists in the AMF export. In that case, the AMF standard
is very precise, and we are required to output 64 bit floats in
ASCII, using the "How print floating point numbers accurately"
algorithm.
Doug Moen.
On 25 August 2015 at 13:20, nop head nop.head@gmail.com wrote:
Yes anything that creates vertices too close together breaks OpenScad STL generation, but if you don't use CSG and just form polyhedra with maths you have complete control over whether it is a valid mesh or not.
On 25 August 2015 at 16:59, doug moen doug@moens.org wrote:
You do sometimes have to post-process STL files generated by OpenSCAD, because OpenSCAD sometimes writes out bad STL (ie, files that OpenSCAD can't itself read). You can reproduce this fairly simply, by doing CSG operations on spheres. This was discussed in an email thread earlier this year.
On 25 August 2015 at 09:07, nop head nop.head@gmail.com wrote:
You shouldn't need to post process files from OpenScad. Best to program manifold objects to start with.
The best way to make smooth shapes from mathematical functions is to use recursive functions / list comprehension to make lists of vertices and faces to pass to polyhedron. That is fast so you can have enough facets to make it smooth.
On 25 August 2015 at 11:41, ufomorace ant.stewart@yahoo.com wrote:
I have found that some of the STL's can't be processed after Netfabb in
Meshlab because the polygons are not all welded and gaps appear if i try
subdivision.
I am using CSG and perhaps extrusion could be easier to fix geometrically?
What are your techniques for post processing and error correction of mesh,
what programs do you use in combination with openscad?
I figure most of the STL's can go straight to a printer perhaps via netfabb,
so if i want some smoothed spirographs i should try and get them done right
in openscad and not work on them after in Meshlab?
--
View this message in context: http://forum.openscad.org/Does-extrusion-or-CSG-make-the-most-correct-mesh-tp13605.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
.
Doug Moen has assigned the problem of mesh correctness to the number of
digits available for calculation / used in data storage. That is the issue
on the surface, but it cannot be the real one. The real one is that "As a
consequence of the discreteness of the number system of the computer, the
simplest laws of algebra are no longer valid on the computer" (from Peter
Henrici, Essentials of Numerical Analysis, John Wiley and Sons, 1964,
opening sentence of chapter 1.2). I substantiate this with three pages from
the book, containing examples.
http://forum.openscad.org/file/n13620/NumAnal-8.jpeg
http://forum.openscad.org/file/n13620/NumAnal-9.jpeg
http://forum.openscad.org/file/n13620/NumAnal-10.jpeg
When you do matrix operations like rotations, you operate on terms like
ab-cd, which lead to large rounding errors if ab approximately equals
cd, even if the individual a,b,c,d are widely different. This situation
arises e.g. if points are too close to each other (the sphere example
earlier in the thread). Rounding errors in rotations (see
https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation) may lead to
the unit vectors being no longer orthogonal. For my own work I restrict
myself to defining a rotation as rotate(deg_a,[x,y,z]) where either x or y
or z may take the value 1, all other are always zero, in the hope that this
leaves the unit vectors of the shape upon which rotate() operates
orthogonal, even when the shape has been rotated many times.
Unfortunately, as long as rounding is allowed inside the computer, such as
in floating point operations, this problem will not go away, irrespective of
how many digits are used. Double precision (64 bits) is not good enough,
Long precision (80bits) may do the trick, which is why Intel has used Longs
for their co-processors since the 80286 (or was it 80386) processor days.
There are of course libraries for infinite precision work, but somewhere a
compromise is unavoidable . . .
Wolf
--
View this message in context: http://forum.openscad.org/Does-extrusion-or-CSG-make-the-most-correct-mesh-tp13605p13620.html
Sent from the OpenSCAD mailing list archive at Nabble.com.