Thanks for posting about IceSL. There are some interesting ideas in here
that I'd ideally like to see also in OpenSCAD.

quote: "Our software lets triangle meshes and analytical primitives be
combined through CSG operations."

This is something I've always wanted. I read "analytical primitives" as
including mathematically correct spheres, cylinders and cones that are not
faceted approximations. I've wanted this since the first time I saw a
sphere in OpenSCAD.

ImplicitCAD is an OpenSCAD clone with analytical primitives. The project
ran into trouble with generating STL files, since they couldn't find an
efficient algorithm for converting the analytic implicit function represent
to meshes. However, you can quite easily slice this representation.

A slicer is a big complex program: generating the slices is only a small
part of the job. There is also generating the skin vs generating the
interior fill pattern, generating support structure, wipe towers,
generating the tool path, with all the hardware dependencies that that
implies.

Much easier and more practical than building an entire slicer is to output
a voxel file instead of a mesh file. If open source slicers supported the
SVX file format, then it would be feasible to build an analytic version of
OpenSCAD that bypasses STL mesh generation and slices directly to SVX.

quote: "This process allows for other interesting features, such as slice
shaders: Small programs that can select the material being used in every
point of space."

There was a project at MIT exploring this same idea. But instead of
building a CSG language into a slicer, they defined the standard interface
between the CSG language processor and the GCODE generator (printer driver)
to be a voxel stream, so you don't have to generate the entire voxel file
before you can start printing the first layer. This architecture supports a
modular toolchain, which is what we want: the IceSL all-in-one architecture
is not a good one for us. And they demonstrated some really cool effects by
controlling the material at every point in space.
http://spec2fab.mit.edu/Spec2Fab.pdf

The Spec2Fab people released some GPL'ed code in 2013, but not everything
you'd need to reproduce their work. Then they went silent while they tried
to figure out how to commercialize the work and get rich.

Anyway, I would like the open source 3D printing community to support voxel
representations as inputs to slicers, one way or another. I figure the SVX
file format is probably the best way forward, since it exists, it is
simple, it's an open standard, and there's already a good reason to use it:
Shapeways supports it, and some models that Shapeways can print are too
complex and fine grained to be represented as meshes, you have to use
voxels.

Once voxels are accepted as input to 3D printers, then we can introduce
analytic primitives, with which you can do really cool things.

quote: "The time between modelling and printing is greatly reduced,
allowing users to perform small adjustments while quickly previewing the
result object and G-code ."

So this is a benefit that you get from the IceSL all-in-one architecture,
or the MIT modular voxel stream architecture, that you don't get from SVX
files.

quote: "CSG operations between triangle meshes are notoriously difficult to
achieve. This is essentially due to numerical issues in the intersection of
geometric primitives. OpenSCAD relies on the CGAL library 4 – an excellent
choice since it provides robust numerical computations for geometry
processing. However, the price to pay is a long processing time. Giving
away numerical robustness is however not an option: The slicing process
cannot recover from holes or cracks in the geometry."

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.

quote: "Comparatively CSG operations are much simpler to perform in a ray-
tracing context [GAC+89]: The CSG operations can be performed along the
ray, after computing the ray–primitive intersections independently. This
has been used to perform CSG on polygonal models, converting back and forth
between a ray–based representation of the geometry and a polygonal model
[WLC10]."

This is interesting. I think it implies that our preview can be made more
accurate than it currently is, that render() shouldn't be necessary to make
the preview look correct. It sounds like a lot of work to implement, but
with excellent results. With this design, the preview is perfectly
accurate, there's no difference between F5 and F6 in the view pane. The GPU
is leveraged to make the preview fast. And the same code can also generate
voxels for output, without going through the expensive F6 rendering process
(CSG on meshes).

Reading this stuff just makes me think that STL and AMF need to die, and
the community needs to move forward to a voxel based future.

On 2 July 2015 at 16:21, Ben Simons zuiopl@hotmail.com wrote:

On 07/02/2015 07:27 PM, doug moen wrote:

But you can't generate first-layer voxels until you determine whether
upper-layer features will require support structures. The slicer (which
knows the printer's geometry requirements) must analyze the entire
object to add those additional, non-model voxels, before hot goo hits
the platform.

AFAICT, every single slicer project has started with the fundamental
premise that all preceding slicers are way too complex, so there's
good reason to keep geometric modeling and tool path generation entirely
separate.

--
Ed
softsolder.com

The software I'm referring to is called "openfab". I don't know in detail
how it works. It's a network protocol whereby a modelling program (like
OpenSCAD) communicates with a slicer, as an alternative to generating an
STL or SVX file, then loading it into the slicer. The authors claim that
the 3D printer can start working more quickly if the modeller and the
slicer are communicating via openfab, than if they are communicating via a
file. And I believe they described the communication as a pipeline. "We
describe a streaming architecture for OpenFab; only a small fraction of the
final volume is stored in memory and output is fed to the printer with
little startup delay." Anyway, it seems plausible that something like
OpenFab could work as described. I assume the protocol allows two way
communication.

Your point about support material is a good one; I don't know for sure if
or how they implement that. The goals of OpenFab are to enable a modular
toolchain, enable the creation of "metamaterials" by interleaving different
materials at the micrometer level, and have high performance. By reading
between the lines, I think that 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. So support might
be in a different stage of the pipeline than you expect, while preserving a
modular system.

They originally proposed to turn this into an open standard. I haven't seen
any movement since 2013, and I can't access the original paper right now,
as OpenFab.mit.edu is down.

http://cfg.mit.edu/content/openfab-programmable-pipeline-multi-material-fabrication

On 2 July 2015 at 21:32, Ed Nisley ed.nisley@pobox.com wrote:

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

Hi, Alan.
I've thought about your argument for fixed point, but I'm not convinced.

I can come up with my own argument for why floats are generally better
than fixed point. However, I wouldn't trust my argument either.

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?

I agree that fixed point has an advantage for translations. You can
translate
a fixed point object along a fixed point vector exactly, with no loss of
information.
However, floating point works better for the other affine transformations.
Fixed point loses precision if you scale down, whereas floating point can
scale
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.

Since fixed point is generally worse than floating point for affine
transformations
(except for translate), I figure that you'd need dictionary handling just
as much
in a fixed point CSG engine.

I don't really know how valid my argument is, since I've never built
a CSG engine.

On 3 July 2015 at 04:30, Alan Cox alan@lxorguk.ukuu.org.uk 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:

Here is a conference paper from 1998 that describes
how fixed point works better than floating point for certain kinds of
CSG computations.
http://www.cc.gatech.edu/~jarek/papers/ExactCSG.pdf

I don't understand the paper well enough yet to see what the implications of
this might be for OpenSCAD.

On 3 July 2015 at 07:21, doug moen doug@moens.org 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: