adding better multi core support for slicing

[markus-reinisch 0]

Today I saw cura is only using one CPU for slicing.

I got a 12 core Mac Pro and this is slower than my macbook pro when I slice objects.

Maybe you can add multicore support?

 

[Daid 306]

Are you a software engineer?

 

[markus-reinisch 0]

no I'am not.

But I'am slicing a lot of 3D objects and it would be a great improvement, when it is faster. Or with a good computer you can slice realtime.

is the slicing process using CPU power or does it work with OpenGL?

 

[Daid 306]

I am a software engineer.

And saying "add multicore support", is like saying, just add more fuel and wheels to your car, then it will go faster.

 

[markus-reinisch 0]

I'am a car engineer. And without fuel you can't go faster But I know what you mean.

 

[anon4321 16]

Daid might be a little gruff but as a developer I can understand. He is working on a lot of things and probably a lot of "uncool" mundane stuff. In commercial settings, you work on broken things first and new features that marketing wants to sell then sorely needed features then cools stuff (which you never get to).

Here is some more info: http://umforum.ultimaker.com/index.php?/topic/6183-why-cura-so-slow/

 

[aroth 1]

And without fuel you can't go faster

 

Multithreading doesn't actually make the 'car' any faster. The top speed is still the same (or in some cases, reduced due to the TDP of the processor which can cause throttling when all cores are at 100% load). What multithreading does is let you be in more than one place at the same time.

If you think of it as driving in a race, being able to be in multiple places at once may or may not help, depending upon the rules of the race. Maybe all you have to do is pass over every part of the track exactly once and not in any particular order, in which case multithreading will let you complete the race in far less time.

But maybe the rules say that each part of the track must be touched in sequence, and starting mile 5 before completing miles 1-4 results in a disqualification. Now multithreading won't help you, because even if you can be in 12 places at once, the rules prevent any of the extra 11 places from being ahead of where you'd be when using only 1 place at a time.

And I think slicing falls more into the second case than the first. The problem is that what you do in one layer depends at least somewhat upon what you do in the layer that came before it. So you can't (easily) start 'Layer 2' without waiting for 'Layer 1' to be done, and you can't say 'Processor 1 will do layers 1-10, Processor 2 will do layers 11-20, ...' and then expect to get a usable result. At least not unless Processor 2 waits for Processor 1's result before it gets started. In which case the multithreaded version would perform worse than a single-threaded version, because now there's added overhead for synchronization and inter-process communication.

 

[john-seaton 0]

Daid, I am a Software Engineer and I am surprised that Cura does not support multiple CPUs. There is a reason why people like me are surprised that Cura doesn't support multiple cores/CPUs and that is because with today's technology multiple CPUs/cores are a standard and software developed today should be developed to support this. It's not a matter of it not being possible to do so why not?

 

[codemaven 0]

John,

Most of slicing is an inherintly linear task. Some small parts can be broken out... but for the most part you can really only process one polygon / line segment at a time because each segment is dependant on the last... You need to do one layer before you can do the next one because you need to determine overhangs, etc. Not all tasks lend themselves to multi-threading... If Step A requires Step B to be complete before it can begin then by multithreading it you are just locking resources and introducing overhead.

I've looked at slicing algorithms. There are some places where it can be threaded... but the benefits would probably be small compared to the complexity... And the majority of the tasks involved simply cannot be done in parallel because of circular dependancies. It's like trying to construct a sky-scraper by using a crane to lift beams up to the top and letting them go... unless you build the base first they're not going to stay where you put them....

Cheers,

Troy.

 

[john-seaton 0]

Of course that won't work but you can build sections of the sky scraper and then put the sections together. Kinda like farming out the work to different companies to build different sections so that those sections are being built in parallel and then you put each section together in order.

I know linear stuff is a harder problem to solve but it can be done. I know this because I've done it myself. (not trying to brag just saying it is possible)

[eldrick 65]

If you have a Mac multi-tasking fetish, use Slic3r or Kisslicer (both of which take longer to slice a piece than Cura takes).

 

[john-seaton 0]

What about when you have multiple models on the build plate you slice them in separate CPUs/cores? Does it do this already? If not maybe that would be a good start.

 

[Dim3nsioneer 557]

http://umforum.ultimaker.com/index.php?/topic/7170-cura-multi-threading-what-is-and-whats-next/

 

[john-seaton 0]

Wish I could help make it happen but I'm a .net guy so probably not going to be much help here.

 

[codemaven 0]

There are bits that can be multithreaded... But multithreading is not the solution to every problem. It can seriously reduce performance in many cases. Some tasks are inherently threadable and others are not.

You could slice different models on the build plate in parallel... The easiset way to do this is just to spawn a new instance of the slicer engine thread... But within the slicer it's a poor focus of effort in my opinion. Better to work on making the process more efficient than just throwing around threads at it and hoping that it will go faster. You will run into contention without serious tuning and simple problems. Because you need to identify top surface skins vs infill you cannot slice it in chunks, you need to slice it either top-down or bottom-up, layer-by-layer.

As pointed out, there are other slicers out there that claim to be multithreded... to the degree that they actually are? not sure... but they are slower than Cura is already.

I work as a software developer on stock market trading applications for one of the world's largest banks. The sofware I deal with is highly threaded and highly distributed across many cores and servers because we have to process hundreds to thousands of trades per second. I can tell you from experience that threading is not always the answer to every problem.

Cheers,

Troy.

 

[john-seaton 0]

I know multithreading can't solve every problem and isn't always the best answer but that's not what we're talking about here. Cura doesn't take advantage of multithreading where it can (besides the seperation of the UI and the engine which goes without saying) and that is my only complaint. No offense intended but I don't think it is a poor focus.

I too am a software developer so I'm not just speaking out of my butt here.

 

[john-seaton 0]

Look, I'm not just some Joe Shmoe throwing around the multithreading keyword without understanding what it is I'm asking. I understand that multithreading with linear tasks is a challenging problem to solve but I also am of the opinion that we as developers should make every effort to make good use of the hardware available to us.

IMO Performance is Key and as developers we shouldn't settle for just good enough. Suporting multiple CPUs/cores should be a foundation of every application and the best places to implement it and avoid it should be considered early on in the design. Some of the responses on here just make it seem like multithreading is either an after thought or just disregarded all together.

Ok, I'll get off my soap box now and finish with this. I would like to see supporting multiple CPUs/cores implemented in the future where it makes sense and provides an enhancement to the user experience.

 

[anon4321 16]

Do you develop software for a living? If you do in any commercial setting, you will know that often due to time and money, good enough is all you get to do....

Very often, it is difficult to add multithreading to existing code without refactoring it first. From the point of view of management, this is wasted time and money because it isn't adding features. If you say because it will make it faster, the response will be is it too slow to be usable now? If you honestly answer no, you won't be given the time to do what management sees as adding no value.

Daid is reportedly working on something he calls Pink Unicorn which sounds like a complete rewrite of at least the Cura UI. I don't know if the slicer is being rewritten. There is a git branch named PinkUnicorn but I don't know if that is just changes to the interface to the new UI or if more of the core processing is being rewritten.

He has recently been pulled to work on something else that I think isn't even software related.

So people aren't dismissing multithreading arbitrarily. It's just the practical reality of commercial development that you don't always get to do what you want.

Are you aware that the slicer is open source? If you want to tackle multithreading, the source is here:

https://github.com/Ultimaker/CuraEngine

 

[john-seaton 0]

Yes I do software development for a living for a global corporation and yes that is the story of my life where I work.

I was not aware of it being open source but I'm guessing it wasn't written in .net and probably c++ so I wouldn't be able to offer much assistance there.

[Daid 306]

As for speeding up Cura, people might notice that the latest Beta is up to 40% faster on large objects, due to some optimizations in the infill code.

http://software.ultimaker.com/Cura_closed_beta/

 

[codemaven 0]

Cura is already the fastest slicer out there. Compared to the older generation it's really quite impressive. I wrote a slicer myself a while back... It was around the time that Daid first started on the slicing engine for Cura (before he was hired by UM). My slicer was written in Java and was of comperable speed to Cura. I did have a threaded pipeline in it, but only in a couple of spots. Some areas that I had hoped to multthread turned out to not be possible - for example, I wanted to read the file in triangle by triangle and pass each triangle to the slicer immediatly running in another thread. But I discovered that .stl files are not cleanly ordered... Triangles are all over the place in the files and not neatly in order. To get around this I would have needed a much, much more compllicated and memory intensive way of building the BSP tree. Whereas by loading the file in first and then building the tree from it I got a much more ordered and optimized tree that was hundreds of times faster to walk.

Some day I would like to get back to my slicer... I got it working in a basic sense, but it's far from complete. My priority is on other projects at the moment.

Cheers,

Troy.

 

[Daid 306]

It was around the time that Daid first started on the slicing engine for Cura (before he was hired by UM).

 

I think this mixes a few things up. I started on the CuraEngine while I was already working for UM. Before that, I did work on my own Java version, which never really worked.

Also, no idea why you would want to build an BSP tree... Cura builds a connected mesh, and uses a hash-map of the vertex positions to speed this up: https://github.com/Ultimaker/CuraEngine/blob/PinkUnicorn/src/mesh.cpp#L14

 

[nallath 1,120]

Because a BSP tree drastically reduces the cost of intersecting lines with lines, which is pretty much the basis of the slicing.

But same as with multi-threading, it could quite well be that making the bsp tree costs more then it actually saves.

 

[codemaven 0]

The BSP tree allows for very fast intersection testing. By testing the BSP tree against a plane I get back a sub list of all crossing points on that plane - i.e. the verticies / line segments of all of the triangles that intersect that plane and where they meet.

This was my insperation: http://evanw.github.io/csg.js/

I originally started by building an implementation of something similar to OpenSCAD in Java... and while playing with that I realized that the same code for building 3d meshes by intersection of two BSP trees could also be used to return 2d 'slices' of a model very quickly.

Also, my calculated BSP information returns back which parts of the plane are inside the model (hence need infill) or outside of the model.

The result comes back as a 2D BSP tree which is incredibly fast to walk. I can then use another 2D inersection operation on the generated BSP tree with another pre-generated BSP tree which I've done ahead of time that contains just crosshatched lines, the result of that is a list of line segments only on the solid (interior) parts of the model - which is the infill. It's a matter of walking the tree and generating the G-Code from that.

Cheers,

Troy.

Cheers,

Troy.

 

[Daid 306]

Problems with that are:

A: Models are not manifold, causing your inside/outside BSP tree to fail.

B: It takes more time to calculate your BSP tree then you are actually using it. (Especially on a high poly model, this can be expensive)

Instead of slicing planes with the model. I slice the triangles with a list of planes (which have a fixed distance). This is pretty quick, and only has the disadvantage it uses quite a lot of memory.

https://github.com/Ultimaker/CuraEngine/blob/PinkUnicorn/src/slicer.cpp#L321

Which gives 2D lines on every slice plane, for each triangle.