On 25.11.20 21:01, crunchysteve wrote:

There is no python in the normal application installation.
It's only used at build time, e.g. to run the test suite.

It might run via Rosetta 2, that will have to be seen when
someone can actually try this. So if you get the M1 Air,
it would be interesting to hear if and how it works.

That kind of help would go a long way. Right now I don't
have contact to someone who both has an Apple machine to
build on and also the time to help. I can barely run
pre-built binaries on the old 2009 MacBook Pro machine
I have sitting here.

ciao,
Torsten.

I'm still fighting with building openScad for aarch64 on Linux (mainly
because of AppImage). I don't know how this will go on the M1 (which also
is aarch64 if I'm not mistaken).
I know the whole ecosystem is different.

On Wed, Nov 25, 2020, 21:21 crunchysteve bandmassa@gmail.com wrote:

On 25.11.20 21:25, Verachten Bruno wrote:

Why, what's the issue? There's a not fully up-to-date aarch64
AppImage built for RaspberryPI 64-bit and it builds fine on
Ubuntu 20.10 and Debian. So aarch64 in itself should not be
a problem

The question is probably more regarding the tools provided
(basically XCode at version >= 12.2 as far as I have read)
and the time needed to build.

ciao,
Torsten.

I'm having problems with cgal (installed but not found). Later on, I
also have problems with AppImage (no official aarch64 release), which
depends on LinuxDeploy (no official aarch64 release), which depends on
CMake (no official aarch64 release).

Interesting. Would you please share a link, so that I can have a look
at how it is built? I would love to have code from master branch
compile regularly for aarch64.

Thanks a lot,

Bruno Verachten

On Wed, Nov 25, 2020 at 3:16 PM Torsten Paul Torsten.Paul@gmx.de wrote:

I'm in the same boat.  My MBP is mid-2010.  It runs fine, but it's
stuck in time.  I will likely have to retire it in the next couple of
years.

I do not buy new Apple hardware.  It's too expensive for me.

-ethan

On 26.11.20 09:28, Verachten Bruno wrote:

I've built based on a Debian Docker image, so that worked
with the normal cgal package.

Base Image:
https://github.com/openscad/docker-openscad/tree/master/appimage/appimage-arm64v8-base

OpenSCAD Build:
https://github.com/openscad/docker-openscad/tree/master/appimage/appimage-arm64v8-openscad

That is the one built via Docker linked above. Link is on the
normal download page / snapshot section:

https://www.openscad.org/downloads.html#snapshots

ciao,
Torsten.

OK, I'm having a love/hate relationship with my M1 Macbook Air right now.
There are quirks to Big Sur (MacOS 11) that are frustrating me, mostly a new
gesture that is too subtle and nuanced for good design (force touch) but
I'll get over it ;-)

The good news is, immediately after replacing Safari with Chrome as my
default browser, I downloaded the latest stable build of OpenSCAD and ran
it.

First, I was told that, to run it, I needed to download and install
Rosetta2, Apple's Intel emulator for the M1 Macs. This happened live and
VERY quickly. Next, I double-clicked OpenSCAD and got the usual "first run"
security protocol, "The App OpenSCAD cannot be verified..." (can't remember
the exact wording, but it's the usual thing with non Developer Connection
meber apps) This involves clicking Cancel, going to Apple/System
preferences.../Security and Privacy, where it will say, "OpenSCAD could not
be verified" and give you the option to run it anyway or delete it, run it
anyway, it will again confirm that you really do want to run it again and
then will run happily ever after. (Unless you delete and reinstall.)

This is my first experience of the M1's processor speed and all those cores!
OpenSCAD's current build is running under Intel emulation. Total emulation.
The model I tested is a moderately complex (probably inefficient) bicycle
pannier mounting system, and it generated a render, ready for export in
about 2/3 the time it takes on my old i5 2013 Air and in easily less than a
10th of the time my 2010 Macbook Pro takes. It saves that render to an STL
in what I can only call instantly! All under Intel emulation on Apple
Silicon M1

So, the Mac version will get by for now, and will give our community 2 years
to get 100% M1 native. Meanwhile, the roadmap is to build a "Universal
Binary" using X-Code. I have played around with trying to learn Swift and
Objective C on Mac OS and never really had the patience to get beyond a 10
step tute on "How to write your own Mac App." But in all that, I know that
Mac OS does support C, C++ and Python in the command line developer tools
when X-Code is installed, so Mac builds should be easy for somebody who
knows how to do this, or for me if somebody can steer me through the
process. I do work well from "recipes."

promises I'll be any good. However, what I can do is run nightly builds and
give feedback.

I also iterate again that Developer connection membership is worth it to
remove the "Cannot be verified" first run hurdle.

So, Mac OS build status: Runs under Big Sur on Apple Silicon under Rosetta
emulation, straight from download.

Two screenshots uploaded...
OpenSCADPreview.png
http://forum.openscad.org/file/t3026/OpenSCADPreview.png
OpenScadRender.png http://forum.openscad.org/file/t3026/OpenScadRender.png

Make things, travel and tell stories.

Sent from: http://forum.openscad.org/

Try wrapping it in render(). It will take time to make the first frame but
be fast to draw after that.

If you post the code I could probably make it faster as it doesn't look
like it should take 2s per frame. I get that sort of frame rate on my
laptop with this model but it has about 2000 parts.

[image: image.png]

On Sat, 9 Jan 2021 at 10:21, caggius caggius@gmail.com wrote:

On 09.01.21 11:20, caggius wrote:

In addition to the other suggestions, you can register
this new feature:
https://github.com/openscad/openscad/pull/1935

Once it's merged, which may happen in the next couple of
days, try out the snapshot version (and enable the new
display features in Preferences).

ciao,
Torsten.

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.

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

oops...I keep forgetting I'm using S/W rendering on my VM.

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

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: