Empathy List Archives

RK

Roland Koebler

Tue, Jun 30, 2015 10:08 PM

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

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

BS

Ben Simons

Thu, Jul 2, 2015 8:51 AM

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

PF

Peter Falke

Thu, Jul 2, 2015 12:54 PM

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

--
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!

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!

BS

Ben Simons

Thu, Jul 2, 2015 2:27 PM

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

--
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!

DM

doug moen

Thu, Jul 2, 2015 3:21 PM

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

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

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

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

BS

Ben Simons

Thu, Jul 2, 2015 8:21 PM

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

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

PF

Peter Falke

Thu, Jul 2, 2015 9:02 PM

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

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

--
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!

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!

TP

Torsten Paul

Thu, Jul 2, 2015 9:05 PM

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.

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.

BS

Ben Simons

Thu, Jul 2, 2015 9:15 PM

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

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

PF

Peter Falke

Thu, Jul 2, 2015 9:23 PM

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

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

--
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!

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!

discuss@lists.openscad.org

color in renderer for visualization