A simple form of a list comprehension for loop without floating point
increments would be:

[ let(N=round(s)  for( i=[0:N], ang = 360*i/N) ...]

which is equivalent to:

[ let(N=round(s)  for( i=[0:N] let( ang = 360*i/N) ...]

A third form is available with snapshot OpenSCAD versions - the C-like for
form:

[ let(N=round(s)  for(i=0, ang=0; i <= round(s) ; i=i+1,  ang = 360*i/N)
...]

Lastly, what about the center point? I know it isn't strictly needed when

You are right. My simplification of your code for the vertex computation
applies only for your original model.

On 01.12.18 02:22, klusacek wrote:

Interesting. Two points I am going to comment on:

• a few comments about the patch
• the observation that render can be faster then preview

Looking at the patch file, I am confused why it has a makefile.

In my understanding, the makefile is automatically generated using qmake.

Also note that you can ignore the object folder. Those are also generated.

objects/comment_lexer.hxx is - if my memory serves me right - by GNU bison.

I think the patch could be a lot smaller when only patching the files
that needed patching.

On a side note: Why not use git?

We are on github:

    https://github.com/openscad/openscad

and the .gitignore file

    https://github.com/openscad/openscad/blob/master/.gitignore

is pretty good at preventing adding or diffing autogenerate files.

Using git would also allow you to open a pull request, so that we can
look into it if we want to adopt this patch into the official build..

I would be interested in seeing if there are any issues with our
regression tests.

When you open a pull request, those are run automatically for our major
platforms.

/For models with complicated CSG structure, the preview rendering
can easily last longer than the CGAL rendering./

/It often overloads the graphics card, leaving user interface
unresponsive for several minutes./

/I use external editor, using auto reload and preview function./

/Unfortunately, auto reload always turns rendering into F5 mode
everytime I save the file in editor, which //
//lock up the user interface for several minutes in case of complex
models. /

Very very interesting. We could add an "Automatic Load and Render"
option or something like it.

The complicated thing about that would be, that leaving the wrong one on
for the wrong model would waste time.

For the case where render is faster then preview, something like

    assert($preview ? false : true, "Render is faster then preview -
please press F6");
    cube(); //just a silly example

would help.

With kind regards,

Michael Frey

Yes I don't like the fact auto reload doesn't remember you have done F6. I
think it should remember the mode and do an automatic F6. I.e. you make
changes and the preview changes. Then you press F6 and get the CGAL render.
Then you make more changes it should update the CGAL view, not flip back to
preview.

If F5 is too slow I add a render() call to my code to force the CGAL
render, even when F5 is pressed.

On Sat, 1 Dec 2018 at 13:24, Michael Frey michael.frey@gmx.ch wrote:

As for the makefile -- when I used qmake to generate it, it included
QtMultimedia lib (or something like that) in the list of libraries against
which it should link. I lack this one on my system and it was not needed by
openscad anyway, but I have to delete it from the generated Makefile (as I
didn't figure out where did it come from) to get rid of compilation error. I
just then forgot to delete the Makefile before making the patch. So, please,
ignore it.

As for the git: Unfortunately, my schedule is quite tight, so I only posted
the patch. Already posting an info to the mailing list was quite
intimidating and time consuming (I had to create an account, play a captcha
for a considerable time (are these still effective today when deepnets
already matched human performance?) and then ask the administrator for the
right to post). I guess that pushing this to the mainline would take more
time than I currently have. Also, I doubt if this patch would be generally
appreciated by all, as it introduces a built-in shape that could possibly
intersect itself.

I just needed to draw that shape so I did it and made it public. Feel free
to use it, or make it git pushable (in which case I would remove the `caps’
parameter as it could be possibly computed from the others).

I'm quite happy with the 'sticky preview' I just have. It is starting in F6
mode and then remembers whatever mode I was using, when it comes to reload.

The reason to start in F6 is that in the beginning, when the model is simple
(think of several cubes), F6 does not hurt that much anyway. Moreover it can
be always interrupted, which cannot be said about F5 mode which effectively
hangs up the machine for several tens of minutes, in case of larger models
(100k+ facets, deep CSG structure). So from my point of view F6 is less
harmful, because only the openscad is working and I can use the computer for
other things, wheres F5 cannot be interrupted and can overload the graphics
card, which in Linux causes that the X server temporarily stops redrawing
the user interface and I cannot do anything. At the same time CPU is idle.
With AMD drivers it even caused the video card driver restarts (several
times a second) so I changed the card to nVidia and used their binary blob
drivers. These are better, but still I have to wait about 20 minutes or
more, which is simply unacceptable.

So I'm generally fine with F6, the only thing that bugs me is that it lacks
colors and that the model disappears from the screen on reload long before
it is computed. It would be much better if it stayed there all the time so
that I could look at the old version (and be able to rotate it), while the
new one is being rendered (maybe the old one might be in grey color to avoid
confusion).

This approach does not solve anything because if the model would be
complicated, I would have to wait for 20 minutes before openscad realizes
I've pressed F6. And I would have to be very cautious in doing so in order
it would not want to redraw the screen again (such as if I moved the
openscad window before it finished rendering) --- in that case it would cost
another 20 minutes.

My feeling is that this is caused by two things. First -- it seems to me
(correct me if I'm wrong) that the CSG tree is converted to a disjunctive
normal form (formula like this a&!b&c | a&b&!c | ..., where a,b,c are
primitive objects, & is intersection, | is union, ! is negation). This by
itself can cause exponential blow up.

The second suspicion is that all the generated triangles are sent to the
graphics in a single display list. The card then tries to process this beast
and does not react to much simple requests from the X-server until it
finishes the rendering.

With kind regards,

David Klusacek

On Sat, Dec 01, 2018 at 06:00:47PM +0000, nop head wrote:

The idea about the "preview" is that it's fast. It's a preview.

The idea about the F6 "render" is that it's probably slow.

These things don't always hold. When your model is simple, even the F6
render is fast. When your model is quite complex (or simple, but has
an intersect-with-the-XY-plane), even F5/preview will be slow.

But WHEN those rules hold, THEN it is often preferable to quickly show
the preview, than to spend ages doing the render.

It depends a bit on if, for your application, the preview is good
enough or not. In my workflow, the "render" is only done once, just
before I export-to-STL.

If you end up needing to go to the render and not the preview because
of some issue, then maybe indeed you'd want your suggested behaviour.

I use a separate editor and the "automatic reload and preview"
feature. Each time I hit "save" I would like the screen to update
quickly to show what I've changed. Even when I have just exported say
a sub-assembly to STL. So I would object to automatically keeping the
"render mode".

As the intersect=true is very slow even in preview mode, I would find
a feature that allows me to enable the intersect only when doing the
cgal render. That would, in my case, make the rendering "as expected":
I'd get a "thin" 3D object rendered quickly(*)  and I have to wait for the
cgal render that allows export.

Roger.

(*) I'm not doing a complex intersection with a complex object. My
original object is a simple thin extrusion of the 2D object that I now
have as the destination. All planes of the object intersect the XY
plane at right angles, or don't intersect at all because they are
parallel. (and those last ones all lie in precisely two planes, Z=-2
and Z=+2).

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands. KVK: 27239233    **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Yes, but it is not always fast. There are occasions when it is not only slow
--- it literally hangs up the machine for many minutes, which is outrageous.

I would of course like to use it that way. But my models tend to be so
complex that F5 in the end lasts longer than F6, and when it finishes it
displays all those z-buffer artifacts that it is of little use anyway. And,
more importantly, anytime I try to move the model with a mouse, I have to
wait for a new frame all that long time again. On the other hand, after
rendering it with F6 once, it can then be moved and rotated fluently.

That's not what I've suggested. I suggest that the render mode should stick
to what you were using the last time. If you were in F5 mode, auto reload
would display it in F5 again. It should start in F6 because F5 is not
interruptible and may hang the machine up. So if you wanted your model shown
using F5 from the beginning you would just click on that red x icon to stop
F6 rendering and then press F5. An inconvenience, I know, but that's nothing
when compared to having to wait 20 minutes before it allows me to pres F6,
having whole machine unusable all that time.

My models tend to be larger. I'm also not a fan of optimizing then number of
boolean operations so that it would render quickly. Nice execise, I admint
but I want to specify the shape as quickly as possible, have it
parametrized, and easily modifiable to have it printed as quickly as
possible.

By the way --- I suppose the main use of openscad is in 3D printing on
RepRap style printers, isn't it? Why then the `Export to STL’-function is
hidden in a submenu, even not having a keyboard shortcut? This is the last
step and most if not all previous steps have their hot keys. So perhaps this
one would deserve it too.

Regards,

-- DK

It isn't normal for F5 to take longer than F6 to do booleans. Normally it
is many orders of magnitude faster. Either there is something unusual about
your model or your graphics card is very slow.

Just wrap it it in render() if you always want it to use CGAL. Then F5 and
F6 will do the same except F5 is not uninterruptible.

On Mon, 3 Dec 2018 at 21:12, Florian Kirsch florian.kirsch@gmx.net wrote:

Yes, but I doubt you can do anything once the program starts sending all the
triangles to the video card. The computer hangs because the GPU does not
accept any requests from the X server during that time. I tried that on
windows too, there only the openscad window stops responding and draws
nothing in F5 mode. Whereas X-server hangs but after very long time it
really displays the model.

I didn't study the sources so closely but I suspect that the reason for this
behaviour might be that all the triangles are sent to the card in a single GL
call.

David