Jump to content

Recommended Posts

Posted · adding better multi core support for slicing

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?

 

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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/

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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?

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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)

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

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

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

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

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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/

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Posted · adding better multi core support for slicing

    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.

     

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • UltiMaker Cura 5.9 stable released!
        Here comes Cura 5.9 and in this stable release we have lots of material and printer profiles for UltiMaker printers, including the newly released Sketch Sprint. Additionally, scarf seams have been introduced alongside even more print settings and improvements.  Check out the rest of this article to find out the details on all of that and more
          • Like
        • 5 replies
      • Introducing the UltiMaker Factor 4
        We are happy to announce the next evolution in the UltiMaker 3D printer lineup: the UltiMaker Factor 4 industrial-grade 3D printer, designed to take manufacturing to new levels of efficiency and reliability. Factor 4 is an end-to-end 3D printing solution for light industrial applications
          • Heart
          • Thanks
          • Like
        • 4 replies
    ×
    ×
    • Create New...