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 oz.at.michael@gmail.com wrote:

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 nop.head@gmail.com wrote:

On 13.01.21 12:59, nop head wrote:

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.

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 Torsten.Paul@gmx.de wrote:

On Wed, Jan 13, 2021 at 11:59:44AM +0000, nop head wrote:

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

--
** R.E.Wolff@BitWizard.nl ** 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.

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 R.E.Wolff@bitwizard.nl 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:

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

On Wed, 13 Jan 2021 at 13:05, jon jon@jonbondy.com wrote:

On Wed, Jan 13, 2021 at 01:02:27PM +0000, nop head wrote:

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. 

--
** R.E.Wolff@BitWizard.nl ** 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.

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 R.E.Wolff@bitwizard.nl wrote: