Apple M1 migtation

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Apple M1 migtation

nophead
I have always known that OpenCSG difference was a lot more expensive than union. Union simply draws the objects on top of each other. Difference does some tricks drawing negative objects.

With Bob's object the slow draw speed was because the arc section has a lot of facets. It gets unioned with the rest and then the holes and text are subtracted. That makes OpenSCG draw very slow. Shortening the arc so that it doesn't intersect the screw holes means it can be unioned outside the difference. It then draws very quickly, problem solved.

What puzzles me though is why does OpenCSG care how many facets there are? We know it can draw the arc very fast in a union. Why do subsequent differences slow down when it is simply drawing negative pixels over the top? Why does it care what complexity the thing it is drawing over has when it has already been drawn as pixels?


On Sun, 10 Jan 2021 at 05:02, MichaelAtOz <[hidden email]> wrote:
oops...I keep forgetting I'm using S/W rendering on my VM.

> -----Original Message-----
> From: Discuss [mailto:[hidden email]] On Behalf Of MichaelAtOz
> Sent: Sun, 10 Jan 2021 14:29
> To: 'OpenSCAD general discussion'
> Subject: Re: [OpenSCAD] Apple M1 migtation
>
> I don't think it is restricted to Mac.
> I've just compared my complex model in RC5 v's 2019.05.
> In 2019.05 preview repaint is bad at ~5s, ie, click view/front icon, 5s to repaint.
> In RC5 it is unusable.
>
> The repaint overwhelms the GUI handling.
> I got to the point where I clicked the close X,
> but as I had unsaved changes, I got the 'do you want to save'
> dialogue, but as that overlayed the viewport, it went to
> repaint, clicking 'cancel' typing Esc was ignored.
>
> I pulled up another windows, then minimised it,
> OpenSCAD repainted the editor & console (in ~3s), tries to
> repaint the viewport, and never gets to repaint
> the dialogue box.
>
> I think this needs fixing before release.
> I'll raise an Issue with further info.
>
>
> > -----Original Message-----
> > From: Discuss [mailto:[hidden email]] On Behalf Of caggius
> > Sent: Sat, 9 Jan 2021 21:21
> > To: [hidden email]
> > Subject: Re: [OpenSCAD] Apple M1 migtation
> >
> > I am also having a love hate relationship with my new M1.
> >
> > The primary purpose of buying a new computer was to reduce the long CGAL
> > rendering (F6) times of some of my larger models (WW2 Spitfire Cockpit
> > Instruments) on my 2012 I7 Macbook.  Some can take 40+ minutes.
> >
> > A lot of this could possibly be down to the way that I use OpenScad and not
> > understanding any of the tuning options.
> >
> > The M1 will F6 render faster than the i7 at around 175% so good news there.
> >
> > However the big problem that I have is that trying to change the viewpoint
> > in preview mode on my more complex models has dropped from around 4 or 5fps
> > to around 2 seconds per frame making it totally unusable.
> >
> > Any thoughts or suggestions ?
> > <http://forum.openscad.org/file/t3083/Screenshot_2021-01-09_at_10.png>
> >
> >
> >
> > --
> > Sent from: http://forum.openscad.org/
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


--
This email has been checked for viruses by AVG.
https://www.avg.com


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

OpenCSG slowness

nophead
My 3D printer now has around 5000 entries in the CSG rendering chain. Most of these are + and by adding some renders I can make them all +, so it's just a list of Polysets to be drawn.

It now takes about 2s seconds to draw each frame and that makes panning almost impossible due to a small mouse move making a big difference. I.e. it is too sensitive. When the update rate is reasonable I can compensate but when it lags two seconds it always overshoots massively. It would be nice if the image panned the same distance the cursor moves instead of a big multiple. Then I could just move the cursor the right amount and the image would eventually catch up.

Who does it take 2 seconds for a reasonably modern laptop to draw 5000 polyhedra?

Yesterday I was looking at a VBO branch, by I think, thehans, but the artefacts had timed out and today the branch seems to have gone. Is that likely to speed up preview by an order of magnitude that I need?

Now that we have mouse click jumping to code location could the CSG products dump use meaningful names instead of cube123, etc,? It would make finding un render()ed differences and intersections easier. Although OpenCSG unions are much faster than differences when you have thousands of them the time adds up.

A lot of things in my model are not visible when assembled. For example a PCB in an enclosure but it is still drawn with all its components and each connector pin is a +hull object in the list. Is there anyway it can cull these invisible polyhedra?

On Sun, 10 Jan 2021 at 09:55, nop head <[hidden email]> wrote:
I have always known that OpenCSG difference was a lot more expensive than union. Union simply draws the objects on top of each other. Difference does some tricks drawing negative objects.

With Bob's object the slow draw speed was because the arc section has a lot of facets. It gets unioned with the rest and then the holes and text are subtracted. That makes OpenSCG draw very slow. Shortening the arc so that it doesn't intersect the screw holes means it can be unioned outside the difference. It then draws very quickly, problem solved.

What puzzles me though is why does OpenCSG care how many facets there are? We know it can draw the arc very fast in a union. Why do subsequent differences slow down when it is simply drawing negative pixels over the top? Why does it care what complexity the thing it is drawing over has when it has already been drawn as pixels?


On Sun, 10 Jan 2021 at 05:02, MichaelAtOz <[hidden email]> wrote:
oops...I keep forgetting I'm using S/W rendering on my VM.

> -----Original Message-----
> From: Discuss [mailto:[hidden email]] On Behalf Of MichaelAtOz
> Sent: Sun, 10 Jan 2021 14:29
> To: 'OpenSCAD general discussion'
> Subject: Re: [OpenSCAD] Apple M1 migtation
>
> I don't think it is restricted to Mac.
> I've just compared my complex model in RC5 v's 2019.05.
> In 2019.05 preview repaint is bad at ~5s, ie, click view/front icon, 5s to repaint.
> In RC5 it is unusable.
>
> The repaint overwhelms the GUI handling.
> I got to the point where I clicked the close X,
> but as I had unsaved changes, I got the 'do you want to save'
> dialogue, but as that overlayed the viewport, it went to
> repaint, clicking 'cancel' typing Esc was ignored.
>
> I pulled up another windows, then minimised it,
> OpenSCAD repainted the editor & console (in ~3s), tries to
> repaint the viewport, and never gets to repaint
> the dialogue box.
>
> I think this needs fixing before release.
> I'll raise an Issue with further info.
>
>
> > -----Original Message-----
> > From: Discuss [mailto:[hidden email]] On Behalf Of caggius
> > Sent: Sat, 9 Jan 2021 21:21
> > To: [hidden email]
> > Subject: Re: [OpenSCAD] Apple M1 migtation
> >
> > I am also having a love hate relationship with my new M1.
> >
> > The primary purpose of buying a new computer was to reduce the long CGAL
> > rendering (F6) times of some of my larger models (WW2 Spitfire Cockpit
> > Instruments) on my 2012 I7 Macbook.  Some can take 40+ minutes.
> >
> > A lot of this could possibly be down to the way that I use OpenScad and not
> > understanding any of the tuning options.
> >
> > The M1 will F6 render faster than the i7 at around 175% so good news there.
> >
> > However the big problem that I have is that trying to change the viewpoint
> > in preview mode on my more complex models has dropped from around 4 or 5fps
> > to around 2 seconds per frame making it totally unusable.
> >
> > Any thoughts or suggestions ?
> > <http://forum.openscad.org/file/t3083/Screenshot_2021-01-09_at_10.png>
> >
> >
> >
> > --
> > Sent from: http://forum.openscad.org/
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


--
This email has been checked for viruses by AVG.
https://www.avg.com


_______________________________________________
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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: OpenCSG slowness

tp3
On 13.01.21 12:59, nop head wrote:
> Yesterday I was looking at a VBO branch, by I think, thehans,
> but the artefacts had timed out and today the branch seems to
> have gone. Is that likely to speed up preview by an order of
> magnitude that I need?

Latest updates are in:
https://github.com/openscad/openscad/pull/1935

Last build:
https://6490-1049088-gh.circle-artifacts.com/0/64-bit/OpenSCAD-2020.12.23.ci6490-x86-64_PR1935.zip

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: OpenCSG slowness

nophead
Thanks. It doesn't seem any different to OpenSCAD 2021.01.01.ci6570 playing with them alongside each other.  Both somewhere between one and two seconds per frame I think.

On Wed, 13 Jan 2021 at 12:08, Torsten Paul <[hidden email]> wrote:
On 13.01.21 12:59, nop head wrote:
> Yesterday I was looking at a VBO branch, by I think, thehans,
> but the artefacts had timed out and today the branch seems to
> have gone. Is that likely to speed up preview by an order of
> magnitude that I need?

Latest updates are in:
https://github.com/openscad/openscad/pull/1935

Last build:
https://6490-1049088-gh.circle-artifacts.com/0/64-bit/OpenSCAD-2020.12.23.ci6490-x86-64_PR1935.zip

ciao,
  Torsten.

_______________________________________________
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
rew
Reply | Threaded
Open this post in threaded view
|

Re: OpenCSG slowness

rew
In reply to this post by nophead
On Wed, Jan 13, 2021 at 11:59:44AM +0000, nop head wrote:
> Who does it take 2 seconds for a reasonably modern laptop to draw 5000
> polyhedra?

This usually happens when an O(N) algorithm is used by a programmer
when he expects it to be "quick enough to be considered O(1)".

If you're not familiar with big-o-notation look it up at:
 https://en.wikipedia.org/wiki/Big_O_notation

Of course this often happens at a library interface: if you write the
loop yourself you're likely to realize your mistake.

I observed this in "e2fsck". It opened a "simple database" to map
inodes to something. Now when you have a SHITLOAD of inodes, you
notice.... My big filesystems, extrapolated would have taken over a
month to fsck.

Turns out that the "simple database" designers meant it to be simple:
Not too many entries in a table. But, well designed: if you want many
that's possible too. Preferably you declare the expected number of
entries at creation time, but if not it will cope, albeit not
efficiently. Well e2fsck did not declare the expected number of
entries at creation time, so a low number like 139 was assumed. The
algorithm used is then O(N/139). For low N that (below 139) that's
O(1) as intended. But for large N like any reasonable number of inodes
that's O(N). For number-of-inodes below "a shitload", the problem is
manageable.

Anyway: "Expected finishing time: a month" is enough to debug, find,
and fix the problem. Then a restart of the still-running fsck results
in a fsck time of a couple of hours.

fsck expected iterating over all the inodes to be an O(N) operation:
repeating an O(1) operation (lookup that inode) N times is O(N). When
the underlying lookup becomes O(N), the whole loop becomes O(N^2)
which was unnecessary.

If you have a Linux system, my patch is included in there somewhere.

In the case at hand (openscad)... Someone with the right skillset
should look at it one day. And NOT stop at the library boundary:
"openCSG is just slow" but look into the actual problem.

You're saying that N=5000 is too slow. And you're saying that it
should be doable in O(N). Well with about 5G instructions available a
second, 1M instructions per object sounds like too much (improbable)
(*). Something in there is O(N^2) where it doesn't need to be. (like
in fsck described above).

        Roger.


(*) You can double check by halving the number of objects and measure
if you observe 1s redraw time (hint for O(N)), 0.5s (hint for N^2).


--
** [hidden email] ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

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

Re: OpenCSG slowness

nophead
I wonder if there could be an optimisation when all the CGS terms are + then simply draw them with OpenGL and not use OpenCSG at all. 

On Wed, 13 Jan 2021 at 12:58, Rogier Wolff <[hidden email]> wrote:
On Wed, Jan 13, 2021 at 11:59:44AM +0000, nop head wrote:
> Who does it take 2 seconds for a reasonably modern laptop to draw 5000
> polyhedra?

This usually happens when an O(N) algorithm is used by a programmer
when he expects it to be "quick enough to be considered O(1)".

If you're not familiar with big-o-notation look it up at:
 https://en.wikipedia.org/wiki/Big_O_notation

Of course this often happens at a library interface: if you write the
loop yourself you're likely to realize your mistake.

I observed this in "e2fsck". It opened a "simple database" to map
inodes to something. Now when you have a SHITLOAD of inodes, you
notice.... My big filesystems, extrapolated would have taken over a
month to fsck.

Turns out that the "simple database" designers meant it to be simple:
Not too many entries in a table. But, well designed: if you want many
that's possible too. Preferably you declare the expected number of
entries at creation time, but if not it will cope, albeit not
efficiently. Well e2fsck did not declare the expected number of
entries at creation time, so a low number like 139 was assumed. The
algorithm used is then O(N/139). For low N that (below 139) that's
O(1) as intended. But for large N like any reasonable number of inodes
that's O(N). For number-of-inodes below "a shitload", the problem is
manageable.

Anyway: "Expected finishing time: a month" is enough to debug, find,
and fix the problem. Then a restart of the still-running fsck results
in a fsck time of a couple of hours.

fsck expected iterating over all the inodes to be an O(N) operation:
repeating an O(1) operation (lookup that inode) N times is O(N). When
the underlying lookup becomes O(N), the whole loop becomes O(N^2)
which was unnecessary.

If you have a Linux system, my patch is included in there somewhere.

In the case at hand (openscad)... Someone with the right skillset
should look at it one day. And NOT stop at the library boundary:
"openCSG is just slow" but look into the actual problem.

You're saying that N=5000 is too slow. And you're saying that it
should be doable in O(N). Well with about 5G instructions available a
second, 1M instructions per object sounds like too much (improbable)
(*). Something in there is O(N^2) where it doesn't need to be. (like
in fsck described above).

        Roger.


(*) You can double check by halving the number of objects and measure
if you observe 1s redraw time (hint for O(N)), 0.5s (hint for N^2).


--
** [hidden email] ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

_______________________________________________
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: OpenCSG slowness

jon_bondy
In reply to this post by nophead

Would it make sense for the UI to display the time it takes to perform the current screen display?

On 1/13/2021 7:57 AM, nop head wrote:
Thanks. It doesn't seem any different to OpenSCAD 2021.01.01.ci6570 playing with them alongside each other.  Both somewhere between one and two seconds per frame I think.


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

Re: OpenCSG slowness

nophead
Yes that would be nice, perhaps in the status bar?

On Wed, 13 Jan 2021 at 13:05, jon <[hidden email]> wrote:

Would it make sense for the UI to display the time it takes to perform the current screen display?

On 1/13/2021 7:57 AM, nop head wrote:
Thanks. It doesn't seem any different to OpenSCAD 2021.01.01.ci6570 playing with them alongside each other.  Both somewhere between one and two seconds per frame I think.


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

Re: OpenCSG slowness

rew
In reply to this post by nophead
On Wed, Jan 13, 2021 at 01:02:27PM +0000, nop head wrote:
> I wonder if there could be an optimisation when all the CGS terms are +
> then simply draw them with OpenGL and not use OpenCSG at all.

That's too simple. In your very simple case, that would help you and
only you.  But then adding a single non- + item, would cause a
fallback to the "other algorithm", and suddenly invoke other code and
also be slow. This is dangerous: You'll not realize that you're
not testing the other path.

For example when allocating a dynamic array:

init:
  array = malloc (100);
  space = 100;
  curitems = 0;

use: add an item:
  if (curitems == space) {
    space = space * 2;
    array = realloc (array, space);
  }
  array[curitems++] = newitem;

This is "nice", but now for "easy" test cases, you'll be adding all
items into the first 100 items allocated in the init routine. You'll
forget to test the realloc code!

Now if you initialize:
  array = NULL
  space = 0;
  curitems = 0;

and use:
  if (curitems == space) {
    space = 1+ space * 2;
    array = realloc (array, space);
  }
  array[curitems++] = newitem;

you'll test the "expand" code on every test. The "don't do the
complicated stuff in simple cases" programming trick is something to
be avoided when possible.

        Roger.

--
** [hidden email] ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

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

Re: OpenCSG slowness

nophead
>   In your very simple case, that would help you and only you.  But then adding a single non- + item, would cause a fallback to the "other algorithm"

I think it would also help at least one other user of my library that also uses it to design big machines with lots of parts. 

I normally render all differences to avoid artefacts with negative objects z-fighting and to get faster drawing. It would be easy to notice the slow down and if the CGS dump used meaningful names easy to find the unrendered difference and fix it.

I don't know any other way to make large models draw at a reasonable speed. As can be seen from caggius' example it is easy to make OpeCSG crawl with just a small assembly like his. By structuring my library to avoid 3D difference as much as possible and render any that are necessary, I manage to keep a balance between the preview taking too long and the frame rate being too slow. Does anybody else make large assemblies with OpenSCAD without using NopSCADlib or the techniques I describe?



On Wed, 13 Jan 2021 at 13:15, Rogier Wolff <[hidden email]> wrote:
On Wed, Jan 13, 2021 at 01:02:27PM +0000, nop head wrote:
> I wonder if there could be an optimisation when all the CGS terms are +
> then simply draw them with OpenGL and not use OpenCSG at all.

That's too simple. In your very simple case, that would help you and
only you.  But then adding a single non- + item, would cause a
fallback to the "other algorithm", and suddenly invoke other code and
also be slow. This is dangerous: You'll not realize that you're
not testing the other path.

For example when allocating a dynamic array:

init:
  array = malloc (100);
  space = 100;
  curitems = 0;

use: add an item:
  if (curitems == space) {
    space = space * 2;
    array = realloc (array, space);
  }
  array[curitems++] = newitem;

This is "nice", but now for "easy" test cases, you'll be adding all
items into the first 100 items allocated in the init routine. You'll
forget to test the realloc code!

Now if you initialize:
  array = NULL
  space = 0;
  curitems = 0;

and use:
  if (curitems == space) {
    space = 1+ space * 2;
    array = realloc (array, space);
  }
  array[curitems++] = newitem;

you'll test the "expand" code on every test. The "don't do the
complicated stuff in simple cases" programming trick is something to
be avoided when possible.

        Roger.

--
** [hidden email] ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

_______________________________________________
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: OpenCSG slowness

thehans
In reply to this post by nophead

On Wed, Jan 13, 2021 at 6:58 AM nop head <[hidden email]> wrote:
Thanks. It doesn't seem any different to OpenSCAD 2021.01.01.ci6570 playing with them alongside each other.  Both somewhere between one and two seconds per frame I think.

Did you enable the experimental feature in preferences?

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

Re: OpenCSG slowness

nophead
No, I didn't realise it was a feature. I ticked all four features to do with rendering and now it is very responsive. Definitely an order of magnitude faster, at least, perhaps two. Thanks a lot for the work.

It would be good to have a measure in the status bar to see the actual frame rate to evaluate the difference.

On Wed, 13 Jan 2021 at 19:02, Hans L <[hidden email]> wrote:

On Wed, Jan 13, 2021 at 6:58 AM nop head <[hidden email]> wrote:
Thanks. It doesn't seem any different to OpenSCAD 2021.01.01.ci6570 playing with them alongside each other.  Both somewhere between one and two seconds per frame I think.

Did you enable the experimental feature in preferences?
_______________________________________________
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: OpenCSG slowness

nophead
It is an unbelievably different experience, even with smaller subassemblies that used to draw at a reasonable speed, they are now virtually real time. I don't think I have seen anything draw this fast in OpenSCAD before.

On Wed, 13 Jan 2021 at 19:24, nop head <[hidden email]> wrote:
No, I didn't realise it was a feature. I ticked all four features to do with rendering and now it is very responsive. Definitely an order of magnitude faster, at least, perhaps two. Thanks a lot for the work.

It would be good to have a measure in the status bar to see the actual frame rate to evaluate the difference.

On Wed, 13 Jan 2021 at 19:02, Hans L <[hidden email]> wrote:

On Wed, Jan 13, 2021 at 6:58 AM nop head <[hidden email]> wrote:
Thanks. It doesn't seem any different to OpenSCAD 2021.01.01.ci6570 playing with them alongside each other.  Both somewhere between one and two seconds per frame I think.

Did you enable the experimental feature in preferences?
_______________________________________________
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: OpenCSG slowness

thehans
In reply to this post by nophead


On Wed, Jan 13, 2021 at 1:25 PM nop head <[hidden email]> wrote:
No, I didn't realise it was a feature. I ticked all four features to do with rendering and now it is very responsive. Definitely an order of magnitude faster, at least, perhaps two. Thanks a lot for the work.

No problem.  But most of the VBO work was done by @obliviand on github (not sure if they frequent the forums / mailing list).  I did contribute a few changes, mostly fixing conflicts after large changes to master, but those have already been incorporated back into obliviand's repo which Torsten linked to.
 
It would be good to have a measure in the status bar to see the actual frame rate to evaluate the difference.

I agree, maybe even ms per frame, rolling average of last 5-10 or so?
 

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

Re: OpenCSG slowness

nophead
Does it vary between frames enough to warrant an average? It is basically drawing all the same stuff with a slightly different viewpoint. If it would flicker then then perhaps a simple ave += (sample - ave) / k would suffice.

On Wed, 13 Jan 2021 at 19:52, Hans L <[hidden email]> wrote:


On Wed, Jan 13, 2021 at 1:25 PM nop head <[hidden email]> wrote:
No, I didn't realise it was a feature. I ticked all four features to do with rendering and now it is very responsive. Definitely an order of magnitude faster, at least, perhaps two. Thanks a lot for the work.

No problem.  But most of the VBO work was done by @obliviand on github (not sure if they frequent the forums / mailing list).  I did contribute a few changes, mostly fixing conflicts after large changes to master, but those have already been incorporated back into obliviand's repo which Torsten linked to.
 
It would be good to have a measure in the status bar to see the actual frame rate to evaluate the difference.

I agree, maybe even ms per frame, rolling average of last 5-10 or so?
 
_______________________________________________
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: OpenCSG slowness

OpenSCAD mailing list-2
In reply to this post by tp3
Any chance someone has the time to build or has already built this for MacOS
and could ship me the app....seems my development system has developed an
obstinate streak and won't even come up properly.

I have noticed some marked slowdowns in my scad lately and just curious if
it is related....reviewing code for other sources of slowness now, but any
improvement to scad rendering is worth a shot.

TIA





--
Sent from: http://forum.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: OpenCSG slowness

caggius
Ditto I would love to try this out on M1 Mac.
thanks
Caggius


> On 13 Jan 2021, at 23:07, macdarren via Discuss <[hidden email]> wrote:
>
> Any chance someone has the time to build or has already built this for MacOS
> and could ship me the app....seems my development system has developed an
> obstinate streak and won't even come up properly.
>
> I have noticed some marked slowdowns in my scad lately and just curious if
> it is related....reviewing code for other sources of slowness now, but any
> improvement to scad rendering is worth a shot.
>
> TIA
>
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> 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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: OpenCSG slowness

tp3
This will merge to master as soon as there's a bit of time to
spare. With that done, the changes will automatically show up
max. 2 days later in the snapshot builds on the official
download page.

MacOS build times are limited on most of the free CI platforms
so we can't just build every change unfortunately.

Github seems to have quite generous usage limits even for MacOS,
so there's a chance we can extend the automatic builds there.
With Travis pretty much going down soon for Open Source usage
we'll have to see how that impacts other platforms as people
migrate their projects.

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: OpenCSG slowness

nophead
When I preview all of my library it still draws at a good framerate but a lot of it is missing.

image.png

It should look like this:

image.png

I don't see any pattern in what is missing and the normalised tree size is the same 8823 elements. There are a lot more cached CGAL polyhedra. I think this version is based on an old master and may have some bugs that have been fixed.

Or is there a limit to the number of elements it can draw with vbos?

On Thu, 14 Jan 2021 at 10:05, Torsten Paul <[hidden email]> wrote:
This will merge to master as soon as there's a bit of time to
spare. With that done, the changes will automatically show up
max. 2 days later in the snapshot builds on the official
download page.

MacOS build times are limited on most of the free CI platforms
so we can't just build every change unfortunately.

Github seems to have quite generous usage limits even for MacOS,
so there's a chance we can extend the automatic builds there.
With Travis pretty much going down soon for Open Source usage
we'll have to see how that impacts other platforms as people
migrate their projects.

ciao,
  Torsten.


_______________________________________________
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: OpenCSG slowness

nophead
Turning off the vbo features gets the missing objects back but turning them on again still draws everything, so not sure what is going on.



On Thu, 14 Jan 2021 at 12:38, nop head <[hidden email]> wrote:
When I preview all of my library it still draws at a good framerate but a lot of it is missing.

image.png

It should look like this:

image.png

I don't see any pattern in what is missing and the normalised tree size is the same 8823 elements. There are a lot more cached CGAL polyhedra. I think this version is based on an old master and may have some bugs that have been fixed.

Or is there a limit to the number of elements it can draw with vbos?

On Thu, 14 Jan 2021 at 10:05, Torsten Paul <[hidden email]> wrote:
This will merge to master as soon as there's a bit of time to
spare. With that done, the changes will automatically show up
max. 2 days later in the snapshot builds on the official
download page.

MacOS build times are limited on most of the free CI platforms
so we can't just build every change unfortunately.

Github seems to have quite generous usage limits even for MacOS,
so there's a chance we can extend the automatic builds there.
With Travis pretty much going down soon for Open Source usage
we'll have to see how that impacts other platforms as people
migrate their projects.

ciao,
  Torsten.


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