color in renderer for visualization

classic Classic list List threaded Threaded
38 messages Options
12
rk
Reply | Threaded
Open this post in threaded view
|

color in renderer for visualization

rk
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:

1. 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.

2. Add color-support to CGAL.
   If CGALs color-support isn't sufficient, CGAL could be extended, and
   then (1) could be done.

3. 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. ;)

4. 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.

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: color in renderer for visualization

nophead
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 <[hidden email]> 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:

1. 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.

2. Add color-support to CGAL.
   If CGALs color-support isn't sufficient, CGAL could be extended, and
   then (1) could be done.

3. 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. ;)

4. 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.

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: color in renderer for visualization

bobc
In reply to this post by rk
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.
Reply | Threaded
Open this post in threaded view
|

Re: color in renderer for visualization

bobc
In reply to this post by nophead
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...
Reply | Threaded
Open this post in threaded view
|

what do we need to do to speed up F6?

yvette
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: color in renderer for visualization

tp3
In reply to this post by rk
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.

> 1. 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.
>
> 2. 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...

> 3. 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

> 4. 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.
>
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.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
tp3
Reply | Threaded
Open this post in threaded view
|

Re: color in renderer for visualization

tp3
In reply to this post by bobc
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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

doug.moen
In reply to this post by yvette
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

doug.moen
In reply to this post by yvette
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.

On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

doug.moen
In reply to this post by yvette
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.

On 30 June 2015 at 14:37, Yvette S. Hirth, CCP, CDP <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rk
Reply | Threaded
Open this post in threaded view
|

Re: color in renderer for visualization

rk
In reply to this post by nophead
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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

BenZ
In reply to this post by doug.moen
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

Peter Falke
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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

BenZ
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 <
[hidden email]>:
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

doug.moen
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.
    1. Refactor OpenSCAD so that it is easy to plug in an alternate 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.

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 <[hidden email]> 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 <
[hidden email]>:
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

BenZ
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.

  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 <
[hidden email]> 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 <
[hidden email]>:
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

Peter Falke

2015-07-02 22:21 GMT+02:00 Ben Simons <[hidden email]>:
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 <
[hidden email]> 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 <
[hidden email]>:
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

tp3
In reply to this post by BenZ
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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

BenZ
In reply to this post by BenZ
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.

  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 <
[hidden email]> 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 <
[hidden email]>:
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org






_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: what do we need to do to speed up F6?

Peter Falke
In reply to this post by Peter Falke
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:

2015-07-02 23:02 GMT+02:00 Peter Falke <[hidden email]>:

2015-07-02 22:21 GMT+02:00 Ben Simons <[hidden email]>:
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 <
[hidden email]> 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 <
[hidden email]>:
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




--
[hidden email]

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!



--
[hidden email]

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12