color in renderer for visualization
Hi,
I'm trying to use OpenSCAD to create and visualize 3D-models,
both static ones and animated ones. Using different colors
is crucial here.
Unfortunately, there seems to be no way to keep the colors when
rendering the model.
So, I would like OpenSCAD to be able to render in color. I'm a
programmer, so maybe I could even implement it, but I currently
don't know where to start. I don't know the sourcecode, but
I can think of several ways:
-
Transfer the color-information to CGAL.
CGAL seems to have some color support, and the rendered models already
have two colors: yellow as default, and light green for faces resulting
e.g. from "difference()". It it would be possible to communicate the
color to CGAL and use CGALs color-features, this would be the easiest way. -
Add color-support to CGAL.
If CGALs color-support isn't sufficient, CGAL could be extended, and
then (1) could be done. -
Use a different render-backend than CGAL.
I think it would be too much effort to change the backend just to get
colors. But if (1) and (2) do not work, this one would.
And e.g. a POVRay-backend would be cool, even if (1) or (2) work. ;) -
Use render() as workaround.
I shortly noticed, that rendered objects can be colored:- color("red") cube(100);
-> red cube - render() color("red") cube(100);
-> yellow cube ("no color-support") - color("green") render() color("red") cube(100);
-> green cube (yay, color for rendered objects!)
I haven't used this much, and don't know if there are any pitfalls,
but this seems to make it possible to color rendered objects. And
since this seems to work, I think (1) should work, too. - color("red") cube(100);
Can you tell me, if (1) should work and where I would have to start to
implement it? Or, if I should use one of the other ways (or even a
different one), and where to start then?
best regards
Roland
If you just want a picture you don't need to use CGAL, F5 gives a coloured
render. F6 is for making solid models to export but the file formats don't
have colour anyway.
On 30 June 2015 at 13:18, Roland Koebler rk-list@simple-is-better.org
wrote:
Hi,
I'm trying to use OpenSCAD to create and visualize 3D-models,
both static ones and animated ones. Using different colors
is crucial here.
Unfortunately, there seems to be no way to keep the colors when
rendering the model.
So, I would like OpenSCAD to be able to render in color. I'm a
programmer, so maybe I could even implement it, but I currently
don't know where to start. I don't know the sourcecode, but
I can think of several ways:
-
Transfer the color-information to CGAL.
CGAL seems to have some color support, and the rendered models already
have two colors: yellow as default, and light green for faces resulting
e.g. from "difference()". It it would be possible to communicate the
color to CGAL and use CGALs color-features, this would be the easiest
way. -
Add color-support to CGAL.
If CGALs color-support isn't sufficient, CGAL could be extended, and
then (1) could be done. -
Use a different render-backend than CGAL.
I think it would be too much effort to change the backend just to get
colors. But if (1) and (2) do not work, this one would.
And e.g. a POVRay-backend would be cool, even if (1) or (2) work. ;) -
Use render() as workaround.
I shortly noticed, that rendered objects can be colored:- color("red") cube(100);
-> red cube - render() color("red") cube(100);
-> yellow cube ("no color-support") - color("green") render() color("red") cube(100);
-> green cube (yay, color for rendered objects!)
I haven't used this much, and don't know if there are any pitfalls,
but this seems to make it possible to color rendered objects. And
since this seems to work, I think (1) should work, too. - color("red") cube(100);
Can you tell me, if (1) should work and where I would have to start to
implement it? Or, if I should use one of the other ways (or even a
different one), and where to start then?
best regards
Roland
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Better color handling is a periodic request. My recent analysis revealed it
is not as simple as adding a color property to polygons, the CSG engine must
take account of the color property to properly support it.
I had a look for existing knowledge on adding color to CGAL, but drew a
blank. I also found that color properties require more CSG operations, and
CGAL is quite slow already, so I also wanted to look at swapping out the CSG
back end, also on the long term todo list.
Therefore I am building an experimental Openscad using the Carve library for
CSG, and then later will add support for color and material properties. This
development can be found at https://github.com/bobc/openscad/tree/carve_csg.
This is very much work in progress; it builds with carve lib, but does not
produce any useful output yet. I haven't put carve into qmake system yet, so
libcarve needs to be built separately and copied in.
But as nophead says, do you need to render for your purposes? I'm not sure
how you intend the visualization stage.
--
View this message in context: http://forum.openscad.org/color-in-renderer-for-visualization-tp12952p12955.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
AMF supports color.
There is also a significant chicken and egg here which seems to stifle
progress. While Openscad does not support color, there is little incentive
to implement any of the several formats that do support color. The lack of
those export formats is then used to justify not supporting color in
Openscad...
--
View this message in context: http://forum.openscad.org/color-in-renderer-for-visualization-tp12952p12956.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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.
On 06/30/2015 02:18 PM, Roland Koebler wrote:
I'm trying to use OpenSCAD to create and visualize 3D-models,
both static ones and animated ones. Using different colors
is crucial here.
Unfortunately, there seems to be no way to keep the colors when
rendering the model.
Yes, currently that's not supported, but it certainly is quite
a big point on the wish-list.
Have a look at http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-td12667.html
for some recent discussion.
-
Transfer the color-information to CGAL.
CGAL seems to have some color support, and the rendered models already
have two colors: yellow as default, and light green for faces resulting
e.g. from "difference()". It it would be possible to communicate the
color to CGAL and use CGALs color-features, this would be the easiest way. -
Add color-support to CGAL.
If CGALs color-support isn't sufficient, CGAL could be extended, and
then (1) could be done.
There are other CGAL issues (mainly speed) too, so there is the
idea to switch to a different backend for the CSG operations...
- Use a different render-backend than CGAL.
I think it would be too much effort to change the backend just to get
colors. But if (1) and (2) do not work, this one would.
And e.g. a POVRay-backend would be cool, even if (1) or (2) work. ;)
...but it's probably not going to be easy. There are a number of
options, but nothing yet which really screams "Use me, I'm the
perfect solution".
https://github.com/openscad/openscad/wiki/Project%3A-Survey-of-CSG-algorithms
lists some of the contenders, some are old and barely maintained.
OpenCascade is likely able to do the job, but is probably 50 times
larger than OpenSCAD itself :-).
Another recent discussion about that topic:
http://forum.openscad.org/Odd-ternary-behaviour-2015-05-15-nightly-git-5451fab-td12784.html
-
Use render() as workaround.
I shortly noticed, that rendered objects can be colored:- color("red") cube(100);
-> red cube - render() color("red") cube(100);
-> yellow cube ("no color-support") - color("green") render() color("red") cube(100);
-> green cube (yay, color for rendered objects!)
I haven't used this much, and don't know if there are any pitfalls,
but this seems to make it possible to color rendered objects. And
since this seems to work, I think (1) should work, too. - color("red") cube(100);
That's still only working in preview mode. The render() call forces mesh
generation (evaluate CSG ops) so the result is one single mesh, even in
preview mode. The color around render() works as this is then again painted
via the OpenCSG library. Using F6 to force a full render still removes
the color.
Can you tell me, if (1) should work and where I would have to start to
implement it? Or, if I should use one of the other ways (or even a
different one), and where to start then?
I don't know CGAL well enough to say if (1) is actually possible.
From what I see it's not possible with the data structure we currently
use. Maybe there's some additional stuff somewhere in CGAL.
I guess the best way forward is to join forces with Bob (first forum
link) who is currently investigating this topic. I'm not sure what the
best topic to start with is... there's quite a number of possible options.
There's one task (which is likely a bit boring) which was started
by Bob already. That's isolating CGAL again as the code separation
to build OpenSCAD without CGAL seems to have bitrotted quite a bit.
(http://forum.openscad.org/Building-OpenSCAD-without-CGAL-td12880.html)
This would open up easier ways for trying one or more of the other
existing libraries.
I offer to help with the boring part :-)
ciao,
Torsten.
On 06/30/2015 08:28 PM, bobc wrote:
AMF supports color.
There is also a significant chicken and egg here which seems to stifle
progress. While Openscad does not support color, there is little incentive
to implement any of the several formats that do support color. The lack of
those export formats is then used to justify not supporting color in
Openscad...
OpenSCAD supports AMF and SVG (for 2D) exports.
Also OFF is supported which I think can support color too.
OBJ support is not finished yet, but there's a branch in the repo to add
support and OBJ would support color.
So the egg is already there. Or is it the chicken? :-)
ciao,
Torsten.
I believe we need a new rendering engine.
Primarily, it needs to use floating point, instead of dynamically
allocated, variable length rational numbers.
After that, multi-core support and GPU support (eg, OpenCL) would make it
faster.
I was recently looking at the PLaSM rendering engine.
Written in C++, open source with a GPL3 licence.
It uses floating point, claims to be fast, there are conference papers
about the
algorithms they use, and it might be good robust code
due to the long history of the project (since 1997 or so).
One interesting feature of the engine is "progressive preview", where it
shows you progressively more detailed renders of the model during preview.
They haven't released an open source progressive previewer, though, and it
might not be easy to take advantage of the feature. Still, I like the idea
of
progressive preview, since some models will always take an hour to preview
no matter how fast the engine. People will just start creating more complex
models.
No general minkowski sum. Lots of other interesting primitives that we
don't have,
including the ability to use 1D and 2D shape objects. Their cylinder
primitive
is implemented by computing the cartesian product of a 2D circle and a 1D
line segment.
Doug.
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP yvette@dbtgroup.com
wrote:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Here's a link to the project page for speeding up F6.
Actually, it's for the initial research component,
as we haven't chosen a new rendering engine yet.
https://github.com/openscad/openscad/wiki/Project%3A-Survey-of-CSG-algorithms
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP yvette@dbtgroup.com
wrote:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP yvette@dbtgroup.com
wrote:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Hi,
thanks all for the answers.
If you just want a picture you don't need to use CGAL, F5 gives a coloured
render. F6 is for making solid models to export but the file formats don't
have colour anyway.
There are 3 reasons why I think F5/preview alone is not enough:
- In several experiments, F5 did not show correct objects, but F6 did.
(esp.: missing/incomplete difference()-holes, arbitrary ugly points) - Moving/rotating the F5-preview is really slow for larger models,
moving/rotating the F6-rendered view is fast. - Animations of more complex models are really slow without render().
But using F5/preview with render()-wrapped objects should work in most
cases. I really like render(), since this can really speed things up,
and removes the penalties for hull or minkowski. And since this also
supports colors (if added externally), I'm quite happy with this
for the moment. So, most of my models will look like:
module ...(...) {
color(...)
render(...)
...real-model-code
}
But I'm still interested in color-renderers (and faster renderers, of
course), or in render() which uses the colors of its subtree.
Best regards
Roland
Re: [OpenSCAD] what do we need to do to speed up F6?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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP <yvette@dbtgroup.com> wrote:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
2015-07-02 10:51 GMT+02:00 Ben Simons zuiopl@hotmail.com:
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP yvette@dbtgroup.com
wrote:
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
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
--
stempeldergeschichte@googlemail.com karsten@rohrbach.de
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
Re: [OpenSCAD] what do we need to do to speed up F6?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.
2015-07-02 10:51 GMT+02:00 Ben Simons <zuiopl@hotmail.com>:
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP <yvette@dbtgroup.com> wrote:
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
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
--
stempeldergeschichte@googlemail.com
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
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.
- 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. - Replace CGAL with a fast floating point CSG engine.
- Refactor OpenSCAD so that it is easy to plug in an alternate
engine.
- Refactor OpenSCAD so that it is easy to plug in an alternate
- 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. - F6 should use the GPU. I haven't investigated this at all.
Of these, #1 get rid of implicit union is the low hanging fruit.
Did I miss anything?
Doug Moen.
On 2 July 2015 at 10:27, Ben Simons zuiopl@hotmail.com wrote:
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.
2015-07-02 10:51 GMT+02:00 Ben Simons zuiopl@hotmail.com:
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP yvette@dbtgroup.com
wrote:
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
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
--
stempeldergeschichte@googlemail.com karsten@rohrbach.de
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Re: [OpenSCAD] what do we need to do to speed up F6?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.
-
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.
-
Replace CGAL with a fast floating point CSG engine.
-
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.
-
F6 should use the GPU. I haven't investigated this at all.
-
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.
On 2 July 2015 at 10:27, Ben Simons <zuiopl@hotmail.com> wrote:
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.
2015-07-02 10:51 GMT+02:00 Ben Simons <zuiopl@hotmail.com>:
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP <yvette@dbtgroup.com> wrote:
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
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
--
stempeldergeschichte@googlemail.com
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
IceSL is still active:
http://www.loria.fr/~slefebvr/icesl/
2015-07-02 22:21 GMT+02:00 Ben Simons zuiopl@hotmail.com:
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.
On 2 July 2015 at 10:27, Ben Simons zuiopl@hotmail.com wrote:
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.
2015-07-02 10:51 GMT+02:00 Ben Simons zuiopl@hotmail.com:
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP yvette@dbtgroup.com
wrote:
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
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
--
stempeldergeschichte@googlemail.com karsten@rohrbach.de
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
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
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
--
stempeldergeschichte@googlemail.com karsten@rohrbach.de
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
On 07/02/2015 10:21 PM, Ben Simons wrote:
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).
Beware, that glow is sometimes not what you expect ;-)
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 !!)
Yeah, IceSL is very interesting from the technical perspective but...
- IceSL is: Free for non-commercial use
- IceSL is: Currently only distributed for Windows
- IceSL is: Only distributed as binary
bringing the total of my personal interest for the project as such
to about zero.
The idea itself is cool but I still would not see it as the only
or ultimate solution. I guess there's still a good number of use
cases where generating an actual model file is useful.
Also writing a slicer that can handle general models is a huge task
with both slic3r and cura-engine doing some impressive work.
While I see some possible benefits of having a combined modeller and
slicer, in reality (mainly with limited development resources) it's
probably still better to have the higher flexibility due to multiple
projects that can be combined using STL/AMF/... files as interface.
Just looking at how people prefer one slicer over the other shows
we are far away from the one single solution that fits everybody and
every model.
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 http://www.comp.nus.edu.sg/%7Etants/gdel3d.html
Thanks for the link, added to https://github.com/openscad/openscad/wiki/Project:-Survey-of-CSG-algorithms
Please be patient with me, I just googled it, no idea really.
Keep going :-). Collecting more info about the various related topics
won't hurt.
ciao,
Torsten.
Re: [OpenSCAD] what do we need to do to speed up F6?Oh my god,
They (icesl) have 1.3 Mio Euro to spend until 2017-11-30 (If I got it correctly).
http://erc.europa.eu/projects-and-results/erc-funded-projects/shapeforge
Damn, I go to bed now.
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.
-
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.
-
Replace CGAL with a fast floating point CSG engine.
-
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.
-
F6 should use the GPU. I haven't investigated this at all.
-
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.
On 2 July 2015 at 10:27, Ben Simons <zuiopl@hotmail.com> wrote:
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.
2015-07-02 10:51 GMT+02:00 Ben Simons <zuiopl@hotmail.com>:
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP <yvette@dbtgroup.com> wrote:
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
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
--
stempeldergeschichte@googlemail.com
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
This guy published really nice papers on all kind of 3d print stuff:
http://www.antexel.com/sylefeb/research
For example, on clean 2 color prints:
http://webloria.loria.fr/~jhergel/cleanColor.pdf
2015-07-02 23:02 GMT+02:00 Peter Falke stempeldergeschichte@googlemail.com
:
IceSL is still active:
http://www.loria.fr/~slefebvr/icesl/
2015-07-02 22:21 GMT+02:00 Ben Simons zuiopl@hotmail.com:
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.
On 2 July 2015 at 10:27, Ben Simons zuiopl@hotmail.com wrote:
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.
2015-07-02 10:51 GMT+02:00 Ben Simons zuiopl@hotmail.com:
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP yvette@dbtgroup.com
wrote:
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
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
--
stempeldergeschichte@googlemail.com karsten@rohrbach.de
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
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
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
--
stempeldergeschichte@googlemail.com karsten@rohrbach.de
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
--
stempeldergeschichte@googlemail.com karsten@rohrbach.de
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
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:
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.
On 2 July 2015 at 10:27, Ben Simons zuiopl@hotmail.com wrote:
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.
2015-07-02 10:51 GMT+02:00 Ben Simons zuiopl@hotmail.com:
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
On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP yvette@dbtgroup.com
wrote:
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
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
--
stempeldergeschichte@googlemail.com karsten@rohrbach.de
P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
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.
P.S. In case my e-mail is shorter than you enjoy:
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
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
On 07/02/2015 07:27 PM, doug moen wrote:
so you don't have to generate the entire voxel file before you can start
printing the first layer
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:
On 07/02/2015 07:27 PM, doug moen wrote:
so you don't have to generate the entire voxel file before you can start
printing the first layer
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
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Re: [OpenSCAD] what do we need to do to speed up F6?More talk from me:
We know (well, my littleness only since a few hours) the time consuming part is not "cheating" like the games but to calculate the exact model.
I always hated this overlapping stuff, all these "translate([0,0,0.001])" and other methods.
What we do at the moment is, to code inaccurate objects so later we have to expensively recalculate them !!!! Whaaa!!!! My head explodes! :-)
OK, I have nothing programmed which is better (here, three virtual foot kisses for the OpenScad dev crew are appropriate i think) but I also think this is not how it should be.
If we have a object1.attach(object2) method and/or polyhedron(points=[object.getPoints()[1],object.getPoints()[7]"]) (Points are objects then too, so OpenScad knows one point equals the other point),
OpenScad could calculate/merge many objects before the GCS/CGAL process (GCP).
For exact objects (OO style created objects) this would totally speed up things as GCP would find a complete object and would have nothing to do.
Not?
Is this what render() does? Then render() should be on top of documentation.
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:
On 07/02/2015 07:27 PM, doug moen wrote:
so you don't have to generate the entire voxel file before you can start
printing the first layer
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
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Re: [OpenSCAD] what do we need to do to speed up F6?Because I had no rubber cell to let my emotions go, I sprinkled the lawn.
Ok, its CSG not GCS.
What I want to say is: Wouldn't it be better to invest the limited resources toward making it easier for the users AND(!) the CSG engine
instead of optimising the 3D calculating engine?
As a user I would love to no longer be forced to do overlapping stuff. The community would notice it as visible progress.
More talk from me:
We know (well, my littleness only since a few hours) the time consuming part is not "cheating" like the games but to calculate the exact model.
I always hated this overlapping stuff, all these "translate([0,0,0.001])" and other methods.
What we do at the moment is, to code inaccurate objects so later we have to expensively recalculate them !!!! Whaaa!!!! My head explodes! :-)
OK, I have nothing programmed which is better (here, three virtual foot kisses for the OpenScad dev crew are appropriate i think) but I also think this is not how it should be.
If we have a object1.attach(object2) method and/or polyhedron(points=[object.getPoints()[1],object.getPoints()[7]"]) (Points are objects then too, so OpenScad knows one point equals the other point),
OpenScad could calculate/merge many objects before the GCS/CGAL process (GCP).
For exact objects (OO style created objects) this would totally speed up things as GCP would find a complete object and would have nothing to do.
Not?
Is this what render() does? Then render() should be on top of documentation.
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:
On 07/02/2015 07:27 PM, doug moen wrote:
so you don't have to generate the entire voxel file before you can start
printing the first layer
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
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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
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:
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
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
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, 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:
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
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