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!