color in renderer for visualization
On 07/02/2015 10:04 PM, doug moen wrote:
support material generation can be implemented in their system as a
"fablet", which means it's an independent module, and doesn't have to be
hard coded into the slicer.
OK, but then a "support fablet" must accumulate the entire model before
it emits the first layer, which means the fancy bidirectional pipeline
clogs with anything other than the sort of bracket-shaped lumps I design.
That fablet must also know everything the slicer knows, too, in order
to generate the proper support shapes with the correct spacings. I
suppose the fablets could all use the same configuration file, but that
quickly degenerate into arguments about which non-relational DB will
support concurrent updates from various fablets along the toolchain.
I'm not seeing how this is a big win for anything other than objects in
a simplified Master's Thesis / Physics 101 3D printing universe.
However, as a rule of thumb, MIT folks know far more than I do about any
given subject. Perhaps this is one of those "Wait... what?" moments we
all have. [grin]
--
Ed
softsolder.com
The problem is not one of the spatial accuracy of a single point but rather one of repeatable calculations where a tangent or intersection will not give consistent results as it approaches numerical limits.
Simply moving to doubles delays but does not solve the problem.
As the article says the correct solution is to not rely on the calculation to get the value but instead use it to determine the decision about what topological 'side' it's on.
For example - Imagine the problem where two concentric cylinders (with different radii) are aligned along Z and the smaller is shifted in X until it just touches the outer surface of the larger. A grazing blow if you will.
As you traverse the two edges, approaching the collision, the two calculations for XY position will eventually wobble as you run out of numerical precision.
A topological solution would keep the knowledge of what is 'inside' and not let the numerical instability of a naive math calc create uncertainty as the edges eventually meet and a gap is formed.
The key idea in the paper is this:
"do not use extended precision to compute or represent vertices, but only to compute the exact answers to all topological questions. The coordinates of the vertices of the resulting solid are approximated a posteriori using floating point calculations. They are not used for establishing the topology of the boundary, nor to store intermediate results."
So once you've determined the sign of the expected result - use a float to calculate it. The paper looks excellent.
Some work has recently been done in Inkscape's 2geom library to make this work well for 2D curve basis functions.
I know it seems to work well in FreeCAD which uses the OpenCASCADE engine.
I would have assumed CGAL did it perfectly also... but I guess this is not its primary focus and (because its a general tool) it has to accept many more primitives than just CSG ones. ?
But the docs on the section "3D Boolean Operations on Nef Polyhedra" in CGAL4.6.1 suggest they have indeed implemented the halfspaces talked about in the paper.
-
http://doc.cgal.org/latest/Nef_3/index.html#Chapter_3D_Boolean_Operations_on_Nef_Polyhedra
Maybe OpenSCAD is using a different part of the library ?
On 7/4/2015 12:04 AM, doug moen wrote:
Hi Jon. After skimming the article whose link I just posted, I gather that the problem is not with the absolute amount of precision
in a floating point number, but with the numerical behaviour of floats
during CSG operations.
With a naive implementation of CSG operations, numbers that should be
equal aren't, due to floating point approximation and loss of precision.
So gaps open up in a polyhedron, making it non-manifold and not 3D-printable.
You fix that, and other things go wrong.
Models acquire additional facets that shouldn't be there.
Maybe you fix that as well using "dictionaries" or some other technique.
But now "A union B" produces a different result than "B union A",
and that might mess up some other algorithm that depends on union.
On 3 July 2015 at 07:42, jon <jon@jonbondy.com> wrote:
Alan:
You say:
"Floats mean the accuracy of your object varies with distance, it means that merely translating a valid object in space can create an invalid object or lose detail. "
I understand why what you say is true in THEORY. With 15 digits of precision, one would have to move a 1 mm cube to the moon to encounter this problem. Have you really encountered this problem in real life in a realistic model (with feature details of 0.1 mm and maximum model size of 200 mm)?
Jon
On 7/3/2015 4:30 AM, Alan Cox wrote:
I really hope this isn't true. I think it is really important to the
OpenSCAD project to get that 1000x speedup of F6 that we all want, by
switching to a floating point geometry engine. Yes, the algorithms need to
be more complicated to achieve numerical stability, but someone has already
done the work, we just need to find the best open source engine to replace
CGAL.You don't want floats. They have all the wrong properties. You want fixed
point integer. Floats mean the accuracy of your object varies with
distance, it means that merely translating a valid object in space can
create an invalid object or lose detail.Even if you use floats you can't use them as floats instead you must
use them with a dictionary so they are not really "float" but dictionary
entries, each of which represents a point in space, and processed to
avoid ambiguities. Fixed point is actually faster, even without using
vectorising instructions.(The dictionary handling is something many STL conversion and
scaling/modification tools ignore entirely and one reason STL tools are
generally completely crap)Alan
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10150 - Release Date: 07/03/15
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10151 - Release Date: 07/03/15
I assume that something simple like "round all computed values to 0.01
mm" also fails. That is, limit point locations to a 3D grid which has a
resolution much greater than our ability to print at the moment.
On 7/3/2015 9:28 AM, Mark Schafer wrote:
The problem is not one of the spatial accuracy of a single point but
rather one of repeatable calculations where a tangent or intersection
will not give consistent results as it approaches numerical limits.
Simply moving to doubles delays but does not solve the problem.
As the article says the correct solution is to not rely on the
calculation to get the value but instead use it to determine the
decision about what topological 'side' it's on.
For example - Imagine the problem where two concentric cylinders (with
different radii) are aligned along Z and the smaller is shifted in X
until it just touches the outer surface of the larger. A grazing blow
if you will.
As you traverse the two edges, approaching the collision, the two
calculations for XY position will eventually wobble as you run out of
numerical precision.
A topological solution would keep the knowledge of what is 'inside'
and not let the numerical instability of a naive math calc create
uncertainty as the edges eventually meet and a gap is formed.
The key idea in the paper is this:
"do not use extended precision to compute or represent vertices, but
only to compute the exact answers to all topological questions. The
coordinates of the vertices of the resulting solid are approximated a
posteriori using floating point calculations. They are not used for
establishing the topology of the boundary, nor to store intermediate
results."
So once you've determined the sign of the expected result - use a
float to calculate it. The paper looks excellent.
Some work has recently been done in Inkscape's 2geom library to make
this work well for 2D curve basis functions.
I know it seems to work well in FreeCAD which uses the OpenCASCADE engine.
I would have assumed CGAL did it perfectly also... but I guess this is
not its primary focus and (because its a general tool) it has to
accept many more primitives than just CSG ones. ?
But the docs on the section "3D Boolean Operations on Nef Polyhedra"
in CGAL4.6.1 suggest they have indeed implemented the halfspaces
talked about in the paper.
-
http://doc.cgal.org/latest/Nef_3/index.html#Chapter_3D_Boolean_Operations_on_Nef_Polyhedra
Maybe OpenSCAD is using a different part of the library ?
On 7/4/2015 12:04 AM, doug moen wrote:
Hi Jon. After skimming the article whose link I just posted,
I gather that the problem is not with the absolute amount of precision
in a floating point number, but with the numerical behaviour of floats
during CSG operations.
With a naive implementation of CSG operations, numbers that should be
equal aren't, due to floating point approximation and loss of precision.
So gaps open up in a polyhedron, making it non-manifold and not
3D-printable.
You fix that, and other things go wrong.
Models acquire additional facets that shouldn't be there.
Maybe you fix that as well using "dictionaries" or some other technique.
But now "A union B" produces a different result than "B union A",
and that might mess up some other algorithm that depends on union.
On 3 July 2015 at 07:42, jon <jon@jonbondy.com
mailto:jon@jonbondy.com> wrote:
Alan:
You say:
"Floats mean the accuracy of your object varies with distance, it
means that merely translating a valid object in space can create
an invalid object or lose detail. "
I understand why what you say is true in THEORY. With 15 digits
of precision, one would have to move a 1 mm cube to the moon to
encounter this problem. Have you really encountered this problem
in real life in a realistic model (with feature details of 0.1 mm
and maximum model size of 200 mm)?
Jon
On 7/3/2015 4:30 AM, Alan Cox wrote:
I really hope this isn't true. I think it is really
important to the
OpenSCAD project to get that 1000x speedup of F6 that we
all want, by
switching to a floating point geometry engine. Yes, the
algorithms need to
be more complicated to achieve numerical stability, but
someone has already
done the work, we just need to find the best open source
engine to replace
CGAL.
You don't want floats. They have all the wrong properties.
You want fixed
point integer. Floats mean the accuracy of your object varies
with
distance, it means that merely translating a valid object in
space can
create an invalid object or lose detail.
Even if you use floats you can't use them *as* floats instead
you must
use them with a dictionary so they are not really "float" but
dictionary
entries, each of which represents a point in space, and
processed to
avoid ambiguities. Fixed point is actually faster, even
without using
vectorising instructions.
(The dictionary handling is something many STL conversion and
scaling/modification tools ignore entirely and one reason STL
tools are
generally completely crap)
Alan
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-----
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2015.0.6037 / Virus Database: 4365/10150 - Release
Date: 07/03/15
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto: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
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10151 - Release Date:
07/03/15
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10152 - Release Date: 07/03/15
I have made an image in support of what I'm trying to say.
I hope you can see its not the position of any given vertex, or a datum point on the curve.
Rather its the two tangents approaching equality which determines where the new vertex will be.
http://i58.tinypic.com/m99cg8.jpg
Numerical precision needs to be infinite to calculate it. Of course this isn't how it happens but it illustrates why it doesn't work. I hope. The paper is not too bad to read actually....
On 7/4/2015 1:33 AM, jon wrote:
I assume that something simple like "round all computed values to 0.01 mm" also fails. That is, limit point locations to a 3D grid which has a resolution much greater than our ability to print at the moment.
On 7/3/2015 9:28 AM, Mark Schafer wrote:
The problem is not one of the spatial accuracy of a single point but rather one of repeatable calculations where a tangent or intersection will not give consistent results as it approaches numerical limits.
Simply moving to doubles delays but does not solve the problem.As the article says the correct solution is to not rely on the calculation to get the value but instead use it to determine the decision about what topological 'side' it's on.
For example - Imagine the problem where two concentric cylinders (with different radii) are aligned along Z and the smaller is shifted in X until it just touches the outer surface of the larger. A grazing blow if you will.
As you traverse the two edges, approaching the collision, the two calculations for XY position will eventually wobble as you run out of numerical precision.
A topological solution would keep the knowledge of what is 'inside' and not let the numerical instability of a naive math calc create uncertainty as the edges eventually meet and a gap is formed.The key idea in the paper is this:
"do not use extended precision to compute or represent vertices, but only to compute the exact answers to all topological questions. The coordinates of the vertices of the resulting solid are approximated a posteriori using floating point calculations. They are not used for establishing the topology of the boundary, nor to store intermediate results."So once you've determined the sign of the expected result - use a float to calculate it. The paper looks excellent.
Some work has recently been done in Inkscape's 2geom library to make this work well for 2D curve basis functions.
I know it seems to work well in FreeCAD which uses the OpenCASCADE engine.
I would have assumed CGAL did it perfectly also... but I guess this is not its primary focus and (because its a general tool) it has to accept many more primitives than just CSG ones. ?But the docs on the section "3D Boolean Operations on Nef Polyhedra" in CGAL4.6.1 suggest they have indeed implemented the halfspaces talked about in the paper.
- http://doc.cgal.org/latest/Nef_3/index.html#Chapter_3D_Boolean_Operations_on_Nef_Polyhedra
Maybe OpenSCAD is using a different part of the library ?On 7/4/2015 12:04 AM, doug moen wrote:
Hi Jon. After skimming the article whose link I just posted, I gather that the problem is not with the absolute amount of precision
in a floating point number, but with the numerical behaviour of floats
during CSG operations.
With a naive implementation of CSG operations, numbers that should be
equal aren't, due to floating point approximation and loss of precision.
So gaps open up in a polyhedron, making it non-manifold and not 3D-printable.
You fix that, and other things go wrong.
Models acquire additional facets that shouldn't be there.
Maybe you fix that as well using "dictionaries" or some other technique.
But now "A union B" produces a different result than "B union A",
and that might mess up some other algorithm that depends on union.
On 3 July 2015 at 07:42, jon <jon@jonbondy.com> wrote:
Alan:
You say:
"Floats mean the accuracy of your object varies with distance, it means that merely translating a valid object in space can create an invalid object or lose detail. "
I understand why what you say is true in THEORY. With 15 digits of precision, one would have to move a 1 mm cube to the moon to encounter this problem. Have you really encountered this problem in real life in a realistic model (with feature details of 0.1 mm and maximum model size of 200 mm)?
Jon
On 7/3/2015 4:30 AM, Alan Cox wrote:
I really hope this isn't true. I think it is really important to the
OpenSCAD project to get that 1000x speedup of F6 that we all want, by
switching to a floating point geometry engine. Yes, the algorithms need to
be more complicated to achieve numerical stability, but someone has already
done the work, we just need to find the best open source engine to replace
CGAL.You don't want floats. They have all the wrong properties. You want fixed
point integer. Floats mean the accuracy of your object varies with
distance, it means that merely translating a valid object in space can
create an invalid object or lose detail.Even if you use floats you can't use them as floats instead you must
use them with a dictionary so they are not really "float" but dictionary
entries, each of which represents a point in space, and processed to
avoid ambiguities. Fixed point is actually faster, even without using
vectorising instructions.(The dictionary handling is something many STL conversion and
scaling/modification tools ignore entirely and one reason STL tools are
generally completely crap)Alan
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10150 - Release Date: 07/03/15
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org" moz-do-not-send="true">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" moz-do-not-send="true">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10151 - Release Date: 07/03/15<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org" moz-do-not-send="true">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" moz-do-not-send="true">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10152 - Release Date: 07/03/15<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10151 - Release Date: 07/03/15
Nicely done, Mark!
On 7/3/2015 10:16 AM, Mark Schafer wrote:
I have made an image in support of what I'm trying to say.
I hope you can see its not the position of any given vertex, or a
datum point on the curve.
Rather its the two tangents approaching equality which determines
where the new vertex will be.
http://i58.tinypic.com/m99cg8.jpg
Numerical precision needs to be infinite to calculate it. Of course
this isn't how it happens but it illustrates why it doesn't work. I
hope. The paper is not too bad to read actually....
On 7/4/2015 1:33 AM, jon wrote:
I assume that something simple like "round all computed values to
0.01 mm" also fails. That is, limit point locations to a 3D grid
which has a resolution much greater than our ability to print at the
moment.
On 7/3/2015 9:28 AM, Mark Schafer wrote:
The problem is not one of the spatial accuracy of a single point but
rather one of repeatable calculations where a tangent or
intersection will not give consistent results as it approaches
numerical limits.
Simply moving to doubles delays but does not solve the problem.
As the article says the correct solution is to not rely on the
calculation to get the value but instead use it to determine the
decision about what topological 'side' it's on.
For example - Imagine the problem where two concentric cylinders
(with different radii) are aligned along Z and the smaller is
shifted in X until it just touches the outer surface of the larger.
A grazing blow if you will.
As you traverse the two edges, approaching the collision, the two
calculations for XY position will eventually wobble as you run out
of numerical precision.
A topological solution would keep the knowledge of what is 'inside'
and not let the numerical instability of a naive math calc create
uncertainty as the edges eventually meet and a gap is formed.
The key idea in the paper is this:
"do not use extended precision to compute or represent vertices, but
only to compute the exact answers to all topological questions. The
coordinates of the vertices of the resulting solid are approximated
a posteriori using floating point calculations. They are not used
for establishing the topology of the boundary, nor to store
intermediate results."
So once you've determined the sign of the expected result - use a
float to calculate it. The paper looks excellent.
Some work has recently been done in Inkscape's 2geom library to make
this work well for 2D curve basis functions.
I know it seems to work well in FreeCAD which uses the OpenCASCADE
engine.
I would have assumed CGAL did it perfectly also... but I guess this
is not its primary focus and (because its a general tool) it has to
accept many more primitives than just CSG ones. ?
But the docs on the section "3D Boolean Operations on Nef Polyhedra"
in CGAL4.6.1 suggest they have indeed implemented the halfspaces
talked about in the paper.
-
http://doc.cgal.org/latest/Nef_3/index.html#Chapter_3D_Boolean_Operations_on_Nef_Polyhedra
Maybe OpenSCAD is using a different part of the library ?
On 7/4/2015 12:04 AM, doug moen wrote:
Hi Jon. After skimming the article whose link I just posted,
I gather that the problem is not with the absolute amount of precision
in a floating point number, but with the numerical behaviour of floats
during CSG operations.
With a naive implementation of CSG operations, numbers that should be
equal aren't, due to floating point approximation and loss of
precision.
So gaps open up in a polyhedron, making it non-manifold and not
3D-printable.
You fix that, and other things go wrong.
Models acquire additional facets that shouldn't be there.
Maybe you fix that as well using "dictionaries" or some other
technique.
But now "A union B" produces a different result than "B union A",
and that might mess up some other algorithm that depends on union.
On 3 July 2015 at 07:42, jon <jon@jonbondy.com
mailto:jon@jonbondy.com> wrote:
Alan:
You say:
"Floats mean the accuracy of your object varies with distance,
it means that merely translating a valid object in space can
create an invalid object or lose detail. "
I understand why what you say is true in THEORY. With 15
digits of precision, one would have to move a 1 mm cube to the
moon to encounter this problem. Have you really encountered
this problem in real life in a realistic model (with feature
details of 0.1 mm and maximum model size of 200 mm)?
Jon
On 7/3/2015 4:30 AM, Alan Cox wrote:
I really hope this isn't true. I think it is really
important to the
OpenSCAD project to get that 1000x speedup of F6 that
we all want, by
switching to a floating point geometry engine. Yes, the
algorithms need to
be more complicated to achieve numerical stability, but
someone has already
done the work, we just need to find the best open
source engine to replace
CGAL.
You don't want floats. They have all the wrong properties.
You want fixed
point integer. Floats mean the accuracy of your object
varies with
distance, it means that merely translating a valid object
in space can
create an invalid object or lose detail.
Even if you use floats you can't use them *as* floats
instead you must
use them with a dictionary so they are not really "float"
but dictionary
entries, each of which represents a point in space, and
processed to
avoid ambiguities. Fixed point is actually faster, even
without using
vectorising instructions.
(The dictionary handling is something many STL conversion and
scaling/modification tools ignore entirely and one reason
STL tools are
generally completely crap)
Alan
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-----
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2015.0.6037 / Virus Database: 4365/10150 - Release
Date: 07/03/15
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto: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
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10151 - Release Date:
07/03/15
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10152 - Release Date:
07/03/15
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10151 - Release Date:
07/03/15
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6037 / Virus Database: 4365/10152 - Release Date: 07/03/15
I found the OpenFab paper on archive.org, since it has otherwise
disappeared from the web.
https://web.archive.org/web/20150325142628/http://openfab.mit.edu/pdf/openfab.pdf
I may have misremembered some things about the paper (it was 2013).
However, it is a very interesting paper, and is worth discussing for the
technical approach that they use to do things that can't currently be done
using OpenSCAD.
The pipeline has both a "surface" stage and a later "volumetric" stage, and
they do discuss how support is implemented.
On 3 July 2015 at 09:19, Ed Nisley ed.nisley@pobox.com wrote:
On 07/02/2015 10:04 PM, doug moen wrote:
support material generation can be implemented in their system as a
"fablet", which means it's an independent module, and doesn't have to be
hard coded into the slicer.
OK, but then a "support fablet" must accumulate the entire model before it
emits the first layer, which means the fancy bidirectional pipeline clogs
with anything other than the sort of bracket-shaped lumps I design.
That fablet must also know everything the slicer knows, too, in order to
generate the proper support shapes with the correct spacings. I suppose the
fablets could all use the same configuration file, but that quickly
degenerate into arguments about which non-relational DB will support
concurrent updates from various fablets along the toolchain.
I'm not seeing how this is a big win for anything other than objects in a
simplified Master's Thesis / Physics 101 3D printing universe.
However, as a rule of thumb, MIT folks know far more than I do about any
given subject. Perhaps this is one of those "Wait... what?" moments we all
have. [grin]
--
Ed
softsolder.com
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
What would be convincing is empirical evidence: someone has built
a fixed point CSG engine and shown that it works better than a floating
point CSG engine. Marius and others have talked about replacing CGAL with a
faster engine, which we preferably don't build from scratch, but just borrow
from another open source project. Do we know of any existing fixed point
CSG engines?
Not open source ones. It's actually a bit more complicated than that
however. Many CSG engines can be plugged into different types. You can
run CGAL in fixed point if you write the correct glue.
However, floating point works better for the other affine transformations.
Fixed point loses precision if you scale down
So do 3D printers. You are completely correct, and for some uses I don't
doubt float is right for this property. 3D printers just happens not to
be one of them.
with negligible loss of precision. Rotation requires sine and cosine.
If you compare 64 bit floats with 64 bit fixed point (32 bits before and
after
the binary point), then sine has 32 bits of precision with fixed point, but
it has 53 bits of precision with floating point. So rotations are much more
accurate with floating point.
Although you can compute 64:64 int faster than float on many processors.
Alan
On Fri, 03 Jul 2015 07:42:19 -0400
jon jon@jonbondy.com wrote:
Alan:
You say:
"Floats mean the accuracy of your object varies with distance, it means
that merely translating a valid object in space can create an invalid
object or lose detail. "
I understand why what you say is true in THEORY. With 15 digits of
precision, one would have to move a 1 mm cube to the moon to encounter
this problem. Have you really encountered this problem in real life in
a realistic model (with feature details of 0.1 mm and maximum model size
of 200 mm)?
The one you hit with the current engine is the "it's valid at 0,0 but
when you lay out 60 of them for a 3D print you get a CGAL error". The
root cause is a just touching edge but your objects behave differently
due to distance.