Empathy List Archives

B

Bananapeel

Fri, Feb 6, 2015 5:24 PM

adrian wrote

Still, after generating the code, I would have expected that the data
vertices and faces would have been cached and not have to redo them every
time the POV changes.
A

F5 does not generate a polygon, for that you need F6 - which gives much
better performance when it's done.

F5 uses some trickery to display the shapes without calculating much
beforehand.

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11530.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

adrian wrote > Still, after generating the code, I would have expected that the data > vertices and faces would have been cached and not have to redo them every > time the POV changes. > A F5 does not generate a polygon, for that you need F6 - which gives much better performance when it's done. F5 uses some trickery to display the shapes without calculating much beforehand. -- View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11530.html Sent from the OpenSCAD mailing list archive at Nabble.com.

MK

Marius Kintel

Fri, Feb 6, 2015 5:36 PM

The reason it’s slow is due to how preview works.

This is hard to explain, but in essence, having intersections as the negative objects in difference is expensive.
The preview rendering algorithm only allows having primitive objects as negatives, and everything else has to be unpacked.
For example:
A - BC - DE
becomes:
A-B-D + A-B-E + A-C-D + A-C-E

..and if A is more complex:
A+B - CD - EF
becomes:
A-C-E + A-C-F + A-D-E + A-D-F + B-C-E + B-C-F + B-D-E + B-D-F

As you can see, all combinations has to be rendered, which can take some time, especially on older GPUs, and especially on low-end Intel GPUs.
As Torsten hinted at, we could optimize rendering a lot, but it could be better to optimize the design.

In your particular case, you’re essentially doing this:

(A+B+C) - (A+B+C)*X - (A+B+C)*Y - (A+B+C)*Z - (A+B+C)*W
..where A,B and C are spheres and X, Y, Z, W are extruded letters
(ignoring the torus for simplicity)

I’ll make a mental leap and say that this is equivalent to
(A+B+C) - X - Y -Z -W

i.e., your intersections are not necessary.
Try that and you’ll see a substantial speedup

-Marius

The reason it’s slow is due to how preview works. This is hard to explain, but in essence, having intersections as the negative objects in difference is expensive. The preview rendering algorithm only allows having primitive objects as negatives, and everything else has to be unpacked. For example: A - B*C - D*E becomes: A-B-D + A-B-E + A-C-D + A-C-E ..and if A is more complex: A+B - C*D - E*F becomes: A-C-E + A-C-F + A-D-E + A-D-F + B-C-E + B-C-F + B-D-E + B-D-F As you can see, all combinations has to be rendered, which can take some time, especially on older GPUs, and especially on low-end Intel GPUs. As Torsten hinted at, we could optimize rendering a lot, but it could be better to optimize the design. In your particular case, you’re essentially doing this: (A+B+C) - (A+B+C)*X - (A+B+C)*Y - (A+B+C)*Z - (A+B+C)*W ..where A,B and C are spheres and X, Y, Z, W are extruded letters (ignoring the torus for simplicity) I’ll make a mental leap and say that this is equivalent to (A+B+C) - X - Y -Z -W i.e., your intersections are not necessary. Try that and you’ll see a substantial speedup -Marius

R

runsun

Fri, Feb 6, 2015 8:13 PM

Just for reference, this code (preview) runs very fast the very first time or
after cash flush (less than 1 sec) on my Toshiba Satellite (probably 8 yr
old) with AMD 64 Athlonx2 + 2GB RAM

Software: Linux Mint 17 MATE 64bit + OpenSCAD 2015.02.01.nightly

$ Runsun Pan, PhD
$ -- OpenScad_DocTest: doc and unit test ( Github , Thingiverse )
$ -- Linux Mint 17 MATE 64bit + OpenSCAD 2015.02.01.nightly

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11534.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Just for reference, this code (preview) runs very fast the very first time or after cash flush (less than 1 sec) on my Toshiba Satellite (probably 8 yr old) with AMD 64 Athlonx2 + 2GB RAM Software: Linux Mint 17 MATE 64bit + OpenSCAD 2015.02.01.nightly ----- $ Runsun Pan, PhD $ -- OpenScad_DocTest: doc and unit test ( Github , Thingiverse ) $ -- Linux Mint 17 MATE 64bit + OpenSCAD 2015.02.01.nightly -- View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11534.html Sent from the OpenSCAD mailing list archive at Nabble.com.

MK

Marius Kintel

Fri, Feb 6, 2015 8:32 PM

On Feb 6, 2015, at 15:13 PM, runsun runsun@gmail.com wrote:

Just for reference, this code (preview) runs very fast the very first time or
after cash flush (less than 1 sec) on my Toshiba Satellite (probably 8 yr
old) with AMD 64 Athlonx2 + 2GB RAM

You probably didn’t set useFor=1

-Marius

On Feb 6, 2015, at 15:13 PM, runsun <runsun@gmail.com> wrote: > Just for reference, this code (preview) runs very fast the very first time or > after cash flush (less than 1 sec) on my Toshiba Satellite (probably 8 yr > old) with AMD 64 Athlonx2 + 2GB RAM > You probably didn’t set useFor=1 -Marius

R

runsun

Fri, Feb 6, 2015 9:51 PM

Indeed. Setting it to 1 slows it down (~3sec), and after the preview the
computer becomes sticky (unable to pan or zoom), followed by crash of
openscad. :(

$ Runsun Pan, PhD
$ -- OpenScad_DocTest: doc and unit test ( Github , Thingiverse )
$ -- Linux Mint 17 MATE 64bit + OpenSCAD 2015.02.01.nightly

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11538.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Indeed. Setting it to 1 slows it down (~3sec), and after the preview the computer becomes sticky (unable to pan or zoom), followed by crash of openscad. :( ----- $ Runsun Pan, PhD $ -- OpenScad_DocTest: doc and unit test ( Github , Thingiverse ) $ -- Linux Mint 17 MATE 64bit + OpenSCAD 2015.02.01.nightly -- View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11538.html Sent from the OpenSCAD mailing list archive at Nabble.com.

MK

Marius Kintel

Fri, Feb 6, 2015 11:00 PM

On Feb 6, 2015, at 16:51 PM, runsun runsun@gmail.com wrote:

Indeed. Setting it to 1 slows it down (~3sec), and after the preview the
computer becomes sticky (unable to pan or zoom), followed by crash of
openscad. :(

I think the crash has been fixed. Did you try a recent dev snapshot?

-Marius

On Feb 6, 2015, at 16:51 PM, runsun <runsun@gmail.com> wrote: > Indeed. Setting it to 1 slows it down (~3sec), and after the preview the > computer becomes sticky (unable to pan or zoom), followed by crash of > openscad. :( > I think the crash has been fixed. Did you try a recent dev snapshot? -Marius

A

adrian

Sat, Feb 7, 2015 1:02 AM

Sorry Marius, what do the operations mean? I'm not familiar with them.

A

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11540.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Sorry Marius, what do the operations mean? I'm not familiar with them. A -- View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11540.html Sent from the OpenSCAD mailing list archive at Nabble.com.

MK

Marius Kintel

Sat, Feb 7, 2015 2:31 AM

On Feb 6, 2015, at 20:02 PM, adrian adrianh.bsc@gmail.com wrote:

Sorry Marius, what do the operations mean? I'm not familiar with them.

It was just meant as an illustration
In my notation:
A+B = union() { A(); B(); }
A-B = difference() { A(); B(); }
A*B = intersection() { A(); B(); }

-Marius

On Feb 6, 2015, at 20:02 PM, adrian <adrianh.bsc@gmail.com> wrote: > Sorry Marius, what do the operations mean? I'm not familiar with them. > It was just meant as an illustration In my notation: A+B = union() { A(); B(); } A-B = difference() { A(); B(); } A*B = intersection() { A(); B(); } -Marius

discuss@lists.openscad.org

Why is for so slow?