Feature Request: Disable automatic toolpath computation

A
aroth Getting started Level: 9 Points: 93
Posts: 62

Posted by
A
aroth

Posted Aug 3, 2014 - 10:50 AM  

Cura generally seems to work quite well, however I'm finding the way it automatically starts recomputing the toolpath as soon as any option is changed to be extremely annoying. For small/simple parts it's not too bad, but trying to rotate, scale, and configure a print of a complex object is a complete nightmare. You change one option, wait several seconds (or more) while it churns trying to compute a new toolpath, change a second option and wait again while it throws out the work it was trying to do and starts over, rinse and repeat. And sometimes just going into a settings dialog will trigger a recompute, even if you cancel out of it/don't actually change any options.

Surely it would be possible to add an option to disable this automatic computation, so that Cura only tries to create a toolpath when I tell it to (or at least, after 'X' seconds have passed with no further changes being made)? I think that sort of change would make the software much more usable.

21 replies
 2313
Sort 
Blizz Feel free to ask me Level: 32 Points: 901
Posts: 678
Location: Belgium Printers: Ultimaker 2
Posted by
Blizz

Posted Aug 3, 2014 - 11:19 AM

I've asked for http://umforum.ultimaker.com/...resh-of-render-time/ a while back.

The best solution that came out is to do all your settings with an empty buildplate, which I now do (if I remember)

D
dirkels 3D printing enthusiast Level: 16 Points: 234
Posts: 114
Posted by
D
dirkels

Posted Aug 3, 2014 - 11:57 PM

You don't need to wait until the whole toolpath is generated again, just ignore the toolpath generation and make any changes as if it was not there. The toolpath generator is a separate background process that is running on the lowest priority which should not hinder anything else you do in Cura. For that reason you have to make a very strong case before the lead developer of Cura would even consider implementing you feature request.

D
dgsharp 3D printing enthusiast Level: 12 Points: 147
Posts: 47
Posted by
D
dgsharp

Posted Aug 4, 2014 - 3:00 AM

Dirkels, one that frequently bugs me is that if I have a model that takes a long time to slice, and then I decide to switch the settings for Support Type or Platform Adhesion, I am forced to wait until the slicing is done before Cura will allow me to change settings. If I try and change these settings before it's done slicing, the dropdown combo box will not stay visible long enough for me to do anything. That gets pretty old. I often have to resort to something like scaling the object down to be very tiny (so it slices quickly), changing the settings, and then scaling back up.

-Dave

A
aroth Getting started Level: 9 Points: 93
Posts: 62
Posted by
A
aroth

Posted Aug 4, 2014 - 3:28 AM

Quote by Dirkels

The toolpath generator is a separate background process that is running on the lowest priority which should not hinder anything else you do in Cura.

That's true for some of the process, but not all of it. There's definitely something that happens when settings get changed that either uses or blocks the main/UI thread, resulting in an unresponsive application. Whether that's toolpath generation or something else, it would be useful to have an option to defer the costly operation until after all changes have been made.

The issue is more noticeable on slower machines (my laptop struggles a lot more than my desktop), and is particularly pronounced on the scaling inputs. So perhaps it's related to the rendering of the part in the preview view, although scaling the graphical model should be quite efficient assuming that it's done on the GPU. But load a moderately complex model and try changing one of the scaling options when the toolpath is just starting generation, and see how long it takes before your keystroke is even recognized. This takes a few seconds on my desktop (hex-core i7 @ 4GHz, 24GB RAM), and up to a couple minutes on the laptop (quad-core Q6600 @ stock settings, 4GB RAM). And it's sufficiently reproducible that the lead developer should easily be able to experience it for himself.

Though I see Cura is actually open-source. If I get some free time I'll poke around and see if I can come up with a patch/pull request.

Daid Team Ultimaker Points: 6182
Posts: 4667
Posted by
Daid

Posted Aug 4, 2014 - 7:36 AM

Quote by aroth

Though I see Cura is actually open-source. If I get some free time I'll poke around and see if I can come up with a patch/pull request.

Good luck. I have a pretty good idea what is blocking the GUI, and fixing it won't be easy.

(Disabling re-calculation does not remove the effect you are having, hench the reaction to these requests)

3dcase I know my way around here Level: 30 Points: 784
Posts: 502
Location: tilburg, Netherlands Printers: Ultimaker Original, Ultimaker 3, Ultimaker 3 Extended
Posted by
3dcase

Posted Aug 4, 2014 - 8:52 AM

+1 vote for a start slicing button...

for now I load the (multiple) parts, move them quickly from the buildplatform and when they are grey start turning and twitching.

Dim3nsioneer Knows the BOM by heart Level: 74 Points: 5019
Posts: 3293
Location: Zurich, Switzerland Printers: Ultimaker 2, Ultimaker Original, Ultimaker 2 Go, Ultimaker 2+, Ultimaker 2 Extended+, Ultimaker 3
Posted by
Dim3nsioneer

Posted Aug 4, 2014 - 9:24 AM

Quote by 3dcase

+1 vote for a start slicing button...

for now I load the (multiple) parts, move them quickly from the buildplatform and when they are grey start turning and twitching.

Neat trick! :-P

D
dirkels 3D printing enthusiast Level: 16 Points: 234
Posts: 114
Posted by
D
dirkels

Posted Aug 4, 2014 - 9:57 PM

If I understand Daid right the problems many seem to have (I'm either to slow or only work with simple objects) in the GUI don't go away if you stop recalculated tool path every time you change a setting.

A
aroth Getting started Level: 9 Points: 93
Posts: 62
Posted by
A
aroth

Posted Aug 5, 2014 - 2:42 AM

After some quick initial investigations, I've found:

  1. It's trivially easy to disable automatic toolpath computation and provide a menu item that triggers it manually.
  2. Doing so improves the experience when entering print settings (speed, thickness, layer height, etc.), but does not help when rotating/scaling the model (which is the bigger issue, really).
  3. Trying to access the 'Layers' view when no layers have been generated and no layers are currently being generated will hang the app forever (so actually disabling toolpath computation in a user-friendly way is marginally less trivial).
  4. The issues when manipulating the model object appear to be related to the PrintableObject.processMatrix() method.
I agree that 'fixing' the method itself would not be easy. Or it might be, for someone who does a lot of graphics programming, but I'm not that guy. In any case, deferring calls to processMatrix() seems like it may help. Not a proper fix, but the UX can't tell the difference.

Developer question: Is the PrintableObject class used as a data-source for non-trivial things, or does it exist solely for the purposes of display?

Daid Team Ultimaker Points: 6182
Posts: 4667
Posted by
Daid

Posted Aug 5, 2014 - 8:57 AM

deferring the processMatrix can cause hell in other areas, which depend on up-to-date model information to be available. But, yes, that's one of the main causes of slowdown.

As for the delaying of slicing performance, I do not notice any performance difference. But it might be interesting to test to see if it's the starting of the slicing, or the receiving of data that is causing the slowdown.

Daid Team Ultimaker Points: 6182
Posts: 4667
Posted by
Daid

Posted Aug 5, 2014 - 11:05 AM

Wait, let me explain a few more things that could be messing things up here.

Another fine example of my shitty code. If you have multiple objects on the printer bed, and you print those "all at once", the GUI code (does this on a thread, but the PIL could be messing with you here) will calculate the final 3D model before sending this to the engine. With multiple complex models, this could potentially take quite a load on your CPU. Especially as it's also doing all the transformations then and essentially storing the model twice in memory. Recalculating positions so the final position of the object matches with what you want.

The plugins are run in the same Python instance as the GUI, so plugins will block the GUI (Due to the PIL once again) plugins can be a real slowdown if you have a lot of them enabled.

The Engine communicates a lot of polygon data back, the GUI is storing this. This is used to speed up rendering of the toolpaths, but storing this data could potentially be causing slowdowns.

When in toolpath view, GCode is parsed, result is stored, and then read again to be transformed into the shown toolpaths. This isn't as efficient as it can be. Totally rewrote this code for the PinkUnicorn.

So...

3dcase I know my way around here Level: 30 Points: 784
Posts: 502
Location: tilburg, Netherlands Printers: Ultimaker Original, Ultimaker 3, Ultimaker 3 Extended
Posted by
3dcase

Posted Aug 5, 2014 - 2:59 PM

Hi,

I have read above posts, a little technical, but get the idea ( I guess ).

I might not be the average Cura user, but I took some pictures from the workflow that suits me best.

WP 001075

I have an idea about the files I load, so choose the profile already.

Hit he load button

WP 001078

As soon as the models appear, move them away from the buildplatform in 1 sec before cura starts calculating.

WP 001080

Most parts I have to rotate and move. Prints a lot faster keeping the Bowden as straight as possible.

WP 001081

When the stones are in position, pull them fast in the right position on the buildplate.

No hesitations otherwise you have to wait until cura is done with the one yellow part.

On this computer there seems to be a delay off aprox. 1 sec before cura starts calculating.

WP 001082

When parts are yellow, hit layer view, go do something else for 2 minutes. check layers and save the gcode.

WP 001083

Hit normal view ( don't forget it!!) and load a new platform ( 400 stones to go ) Almost done

And In my free time, still having fun printing at home .

But I do like a START slicing button!!!! :-|

3dcase I know my way around here Level: 30 Points: 784
Posts: 502
Location: tilburg, Netherlands Printers: Ultimaker Original, Ultimaker 3, Ultimaker 3 Extended
Posted by
3dcase

Posted Aug 5, 2014 - 3:06 PM

Quote by Daid

Wait, let me explain a few more things that could be messing things up here.

. Totally rewrote this code for the PinkUnicorn.

So...

P.S.

Psst Daid where do I sign in to volunteer for a beta version off the PinkUnicorn????

Daid Team Ultimaker Points: 6182
Posts: 4667
Posted by
Daid

Posted Aug 5, 2014 - 4:31 PM

Quote by 3dcase

and load a new platform ( 400 stones to go )

That sounds more like a job for.... scripting.

Blizz Feel free to ask me Level: 32 Points: 901
Posts: 678
Location: Belgium Printers: Ultimaker 2
Posted by
Blizz

Posted Aug 5, 2014 - 4:46 PM

3dcase: Unrelated, but wth are you printing?

3dcase I know my way around here Level: 30 Points: 784
Posts: 502
Location: tilburg, Netherlands Printers: Ultimaker Original, Ultimaker 3, Ultimaker 3 Extended
Posted by
3dcase

Posted Aug 5, 2014 - 5:38 PM

Quote by Blizz

3dcase: Unrelated, but wth are you printing?

www.projectegg.org

http://umforum.ultimaker.com/...ject-egg/#entry31972

Blizz Feel free to ask me Level: 32 Points: 901
Posts: 678
Location: Belgium Printers: Ultimaker 2
Posted by
Blizz

Posted Aug 5, 2014 - 7:19 PM

Cool!

A
aroth Getting started Level: 9 Points: 93
Posts: 62
Posted by
A
aroth

Posted Aug 6, 2014 - 3:16 AM

First, here's a patch for anyone who wants to try out the 'manual slice' version (go to 'File -> Preferences' and uncheck the 'Automatic slicing' option, and then slicing will only start when you hit 'Ctrl+T'): http://pastebin.com/GX1A4igz

Quote by Daid

deferring the processMatrix can cause hell in other areas, which depend on up-to-date model information to be available. But, yes, that's one of the main causes of slowdown.

If deferring the call causes issues, what about short-circuiting the costly part when possible? I'm assuming the costly part is where it iterates through each mesh to find the largest bounding circle that exists (if that's what it's doing?).

Based upon what little I understand from my cursory examination, it seems like the method is being used to compute bounding geometries, sizes, and offsets. In theory that means instead of performing the exhaustive search through each mesh every time a change is made, the new values could be worked out mathematically based upon 1) the previous values and 2) the nature of the change. For simple changes, at least.

For instance, scaling and translation seem like they should have very predictable effects upon the previously computed result. It's fundamentally the same, but multiplied by some factor (scaling) or shifted by some offset (translation). I'd say the same about rotation as well except it seems that somewhere along the way there's some accounting made for gravity/the build platform, such that a rotation can also trigger a translation along the vertical axis.

Perhaps you could even precompute the result once, and then supply data to the external world by applying whatever the current transformation matrix happens to be to the precomputed result(s), in an on-demand kind of way? If so it seems like that would be very fast, once the initial computation was completed.

Though as noted, graphics (and in particular, 3d-graphics) is not my area of expertise, so perhaps I'm completely wrong.

Quote by Daid

When in toolpath view, GCode is parsed, result is stored, and then read again to be transformed into the shown toolpaths. This isn't as efficient as it can be. Totally rewrote this code for the PinkUnicorn.

So...problem already fixed for the next release?

Edit: And one possible explanation for why the toolpath computation may cause issues for some people even though it's done on a background thread is paging. If the thread is allocating memory so that it can run its computations and the OS is forced to start paging things to disk, that can easily cause performance degradation in other threads (and processes, even). And then if the main thread keeps trying to bring the paged information back in...the two threads throttle each other and things grind to a near-halt.

Paging might also explain why my desktop seems significantly less impacted than my laptop; it has 6x the amount of RAM installed and is very unlikely to ever need to page anything out.

Daid Team Ultimaker Points: 6182
Posts: 4667
Posted by
Daid

Posted Aug 6, 2014 - 8:47 AM

If paging is happening, then you're pretty much screwed anyhow. But I don't think Cura uses shitloads of memory, and any recent laptop should come with at-least 2GB of memory these days.

As for re-using, there are some many cases that can happen, and there is quite some geometrical magic going on at that point. Lots of it is done with numpy, which makes it even trickery (but loads faster)

A
aroth Getting started Level: 9 Points: 93
Posts: 62
Posted by
A
aroth

Posted Aug 7, 2014 - 2:52 AM

Here's a patch that also moves the graphics/'processMatrix()' updates onto the manually triggered computation: http://pastebin.com/L6kKaRe4

Caveat Emptor

I haven't had time to test this thoroughly, but it seems to work as expected (I can rotate, scale, and configure my print parameters with zero delay, hit 'Ctrl+T', and then get a successful slice) and with only minor side-effects (if I scale an object outside of the build volume, it won't always turn gray until I hit 'Ctrl+T', etc.).

Daid Team Ultimaker Points: 6182
Posts: 4667
Posted by
Daid

Posted Aug 7, 2014 - 10:24 AM

You might run into problems with one-at-a-time printing. As well as strange things when you try to place multiple objects on the bed (allowing intersections after rotating objects)

21 replies
 2313
Sort 
Support