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.
I admit, I just talk, very probably I'll not find time to do something.
But I'll provide some funding if someone will bite into it.
So, all the OpenScad Devs can ignore the following if they want, because
it looks like a lot of work (Teaser: There is a glow from the light of the
ultimate solution at the horizon).
I googled "use gpu for cgal" and came across this interesting paper which
describes dropping the CSG stuff altogether and go directly to slicing
(yes, slicing !!)
They even mention OpenScad and give some "shoulder knocking" for the
decision to use CGAL by the OpenScad devs.
http://webloria.loria.fr/~slefebvr/icesl/icesl-whitepaper.pdf
I could live with the inaccurate preview and go right to slicing. Whoever
wants the STL has to wait, so be it.
And there is another paper about an algo which uses the GPU (about factor
10 faster).
http://www.comp.nus.edu.sg/~tants/gdel3d.html
Please be patient with me, I just googled it, no idea really.
I believe that OpenSCAD F6 is at least a thousand times slower than it
should be (this is model dependent). And this is fixable.
Here are some tasks for the "speed up F6" project.
1. Get rid of implicit unions wherever feasible, and especially at the
top level. This means that the final result of F6 may be a model with
overlapping top level polyhedra. This will provide a massive speedup for
models that work by overlapping a large number of top level objects,
especially spheres. The commands for exporting to a file (STL, etc) will
now need an option for whether you want to perform a top level union. This
will slow down STL export if the option is selected, but many slicers don't
require this.
2. Replace CGAL with a fast floating point CSG engine.
3. F6 should use multiple cores. I haven't looked at all of the
candidate replacement CSG engines, but I suspect that this is something
that needs to be handled in our rendering code, not in the engine per se
(except that the engine needs to be thread safe). Rendering all of the
children in a group should become a parallel operation that can be
distributed across multiple cores.
4. F6 should use the GPU. I haven't investigated this at all.
1. Refactor OpenSCAD so that it is easy to plug in an alternate engine.
Of these, #1 get rid of implicit union is the low hanging fruit.
Did I miss anything?
Doug Moen.
Thanks for the explanation.
I knew games are bad!!! ;-)
But I still wonder a bit about the astonishing difference. It is a factor
of thousand or more. Well, I leave it to the experts.
These games lie.
They just draw the hairs so that they are partly within and partly outside
the scull.
Openscad actually calculates the intersection of a hair and the scull to
make a real 3d model.
And that is a slow process as it calculates the intersection points with a
very high precision.
I didn't looked into the details.
But can someone explain me why there are games which calculate moving
hairs of a character surrounded by a detailed landscape and all over the
screen some orks or similiar shooting at you with 50 or more fps?
Meanwhile we wait in OpenScad Minutes(!) for the result?
BobC is investigating changes to OpenSCAD that will make it easier to
replace CGAL with an alternate geometry engine.
That's another step towards faster F6.
http://forum.openscad.org/Building-OpenSCAD-without-CGAL-td12880.html
what needs to be done to speed up rendering using F6?
now it's all single-threaded, which i believe is the majority of the
"complicated stuff seemingly takes eons to rendah" issue.
i recently installed a mid-range GPU card (Nvidia 760x) and the results
are dramatic decreases (for some software) in render time. but no bennies
using OpenSCAD.
i'm sure others have requested F6 improvements, and iirc i read a missive
somewhere that indicated a new rendering library or other software needs to
be setup in OpenSCAD, and that this is a non-trivial issue.
can i help with this in any way? please lmk.
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu
schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
