Break signal for 3Dsurface

[GeneFC]

As I mentioned earlier, when I was playing with Freman's "endless loop" model I saw full 100% utilization (4 cores) for most of the time.

This was using the precompiled FreeCAD available on the releases page. It may be a packaging thing.

OS: Windows 7 SP 1 (6.1)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.21937 (Git)
Build type: Release
Branch: master
Hash: 0de5a290113800dc5779a76d7e216bd882e0ed1e
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

Gene

[GeneFC]

I mean howcome Slic3r can just eat through a huge complex model at 0.2mm layer height basically instantly ?

what if we ditch G2 interpolation and just use linear piecewise ? would that speed it up ?

I think slicing is 2D.

Lots of repetitions for layers, but still just 2D.

Just from looking at the code I would guess that the G-code generation is only a tiny part of the time consumed. The majority of the time is figuring out what to cut.

Gene

[etrombly]

As I mentioned earlier, when I was playing with Freman's "endless loop" model I saw full 100% utilization (4 cores) for most of the time.

This was using the precompiled FreeCAD available on the releases page. It may be a packaging thing.

OS: Windows 7 SP 1 (6.1)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.21937 (Git)
Build type: Release
Branch: master
Hash: 0de5a290113800dc5779a76d7e216bd882e0ed1e
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

Gene

That's weird, maybe a different program was running at the same time? The endless loop was in a single threaded python portion of the code that doesn't call out to anything else.

[GeneFC]

No, it was definitely FreeCAD. Memory usage sky-rocketed as well, up to about 30 GB, so perhaps something else was going on. This went on for 30 minutes or more, until I finally killed it. Of course there could have been a very small portion of the code that was locked up, using multiple threads to do nothing.

Gene

[<Charlie_root>]

I'm also wondering ... maybe this is completley absurd, but is there a possibility of speeding it up frther by doing some of the parralel processing on the GPU ?

[freman]

I raised this a while ago. IIRC it was reckoned to be too hardware specific to invest time into developing it.

[freman]

There are a few things that can still be done to speed it up. There are some steps that can be done in parallel, but I just did a quick check with mnesarco's threading module, and due to pythons GIL it doesn't actually speed anything up. Those sections would need to be ported to C++ (which would be a big task, it's a large chunk of the current python code).

Originally the meshing was done using brepmesh, it's currently done using part.tessellate. I can do some tests because it seems like tessellate is a little slower. I had added a much faster method, but it didn't create an accurate enough result. Maybe we can still use that for a preview pass, before generating the final operation.

That preview idea is very good. I often do half a dozen recomputations of a 3Dsurface path before getting all the params the way I want. I also have to turn off auto-recompution when editing params in the tree view. A faster, less accurate preview mode would be a great help.

Opencamlib is the slowest part. It's supposed to support multi threading, but I've noticed 3D surface seems to just be pegging 1 core most of the time. Maybe there are some improvements that can be made upstream. It might not be something that could be made parallel easily though.

edit: just looked around with opencamlib, the docker build I'm using doesn't turn on openmp (multithreading) support. I have a feeling this is true for most people. I turned it on and recompiled, but need to test more if it makes a difference.

What needs to be done to enable openmp on OCL build? I want to make sure I'm doing that.

[etrombly]

When you compile opencamlib change it to something like "cmake -D BUILD_PY_LIB=ON -D BUILD_CXX_LIB=OFF -D USE_PY_3=ON USE_OPENMP=ON". If you're on windows and using the cmake gui just search for openmp. I just opened an issue for the docker container I'm using here https://gitlab.com/daviddaish/freecad_d ... /issues/15 to turn it on by default.

[freman]

Yes, I find that option ON in my CmakeCache.txt
Thanks for the confirmation.

That may just make the library re-entrant so mulitple threads can be called at once rather than creating multiple threads internally.