Does Cura Engine development go in a wrong direction?

[Ricky 5]

The post here shares my thoughts on Cura after reading source code of Cura engine 15.04 vs 3.31.

 

Recently, I want to improve Cura sub par path planning. Thus, I read and understand Cura engine source code.

 

My conclusion is the following: the latest developemnt of Cura engine is going in a wrong direction. 

 

Compared to 15.04, latest Cura exposes tons of settings and frequently add/remove/patch/re-patch special hacking tweak here and there. That alone will make slicer getting worse.

 

In philosophy, there is so called Occam's razor. The idea is simple: Among all solution, the one with fewest assumption is always the best.

 

This idea applies to slicing as well. Let say slicing engine is a model that we want to fit a desirable physical printed model from an STL model input file -->

 

Physical Printed Model = Slicing_Engine (STL model)

 

Differen version of Cura engine is different slicing model. To fit majority of physical printed model well, the best model should not use tons of parameter.

 

In econometrics, it is called model misspecification due to creating a over complex model with many parameters to fit a specific set of data points. In general, the fitting works well only in a small subset of sample data. It doesn't fit well for the majority.

 

If you find that latest Cura 3.31 doesn't work well in your model compared to 15.04, it is highly possible that someone placed his/her hack somewhere in the settings which messed your slicing up.

 

My observation is based on Occam's razor, my daily job experiences and also my reading of source code. It might be biased. So welcome to chime in and share your thoughts.

[yellowshark 153]

Interesting post! I do not have the benefit of your background or experiences but I am a long gone software developer, ranging from assembler to Cobol. Yes old stuff but the fundamentals of software development broadly remain the same, just the tools and audiences change.

The more complex one makes a subject, whether necessarily or unnecessarily, the more difficult it becomes to deliver clean code. Probably more importantly the more difficult it becomes to modify and deliver clean changed code. A generalisation would be that new functions work but bugs are introduced to existing code that was clean – it is just too complex to understand all ramifications of change and beyond one’s financial/operational capabilities to test everything that has not changed ( or so your thought!).

At the moment I am stuck on Cura 2.7 (which for me works fine) whilst I await a clean version of 3.n. Does 2.7 produce better models than 15.04? For the most part, for me, probably not. But, as you say, there are more options which give you more control and if nothing else should help one overcome problems more easily.

So is Cura now more complex than it needs to be? (Anyone from Ultimaker is welcome to shoot me down in flames for any wrong assumptions here).

There are some fundamentals.

The decision to create the new software (was it Pink Flamingo back then?) would have been driven by a variety of influences. There was a new printer in the labs to support, importantly with dual extruders. There was a new extruder system and coded reels of filament to support. Probably the architecture of the old Cura software did not lend itself to what Ultimaker wanted to do and the decision to throw away the old software was taken.

Maybe, above all of this, Ultimaker saw that the market needed to change. It was populated mainly by techies and difficult, without help and that level of technical capability, to produce decent quality results quickly without some considerable experience – the learning curve was quite steep.

 

Ultimaker wanted to move the market to a more plug ‘n play level; just compare laptops now to pre Windows or even early Windows PCs. I cannot remember the last time I reloaded the Windows O/S whereas with W95 it was every 6 months at least.

Just consider how much functionality they have added to try and make this goal achievable if you have an Ultimaker 3.

So yes the subject is more complex and no doubt so is the code, although hopefully better architected. I for one would not criticise them for this; indeed I applaud them for embarking on such a change. Just think of the increase in productivity if your engineers each had their own printer and with a few key depressions could produce their own prototype there and then, not having to rely on people like ourselves.

And whilst there are now all these additional settings to keep the techies happy, their challenge going forward will be to gradually automate everything, remove all those techie settings, so we are all just making a few key depressions!

[Ricky 5]

@yellowshark

Thanks for sharing your thoughts. I totally agree with your points: more feature you add in the code, more bugs you introduce. No matter how good the QA (if any) is or how smart the programmer is, this is a inconvenient truth.

 

I understood Ultimaker's strategy to split UI from engine. Let UI takes care of the complex setting for user. Hopefully in future some intelligence can tweak the optimal settings based on user's STL input model, compared to a simple rule-based driven setting check now we have.

 

But in reality engine itself gets overly complicated. When we patched something because of an X STL input model from you, it may break Y and Z STL input model from others. I did saw a couple unit test for QA purpose. But I didn't see any integration test which perform end to end or do a physical print test. Maybe it didn't release in Github or it may be difficult to benchmark this.

 

I didn't complain anything or anyone here. Cura is free and good stuff. I mean I can afford $150 for Simplify 3D. But there is no fun at all to poke around what is under the hood. 

 

In any case, I just want this open source project getting better and go towards a right direction. No intention to offend anyone.

Edited May 24, 2018 by Ricky

[yamaha26 0]

Hi!

 

Im using Cura 14.07 and i tried the new cura 3.3.1. I use the same settings and the Print time with the 3.3.1 is bigger.

E.g. If the print time with cura 3.3.1 1 hour with 14.07 is about 38min. Some times the 14.07 is 2x time faster.

[Ricky 5]

Latest version Cura didn't optimize GCode generation that much. It generate tons of redundant M Code. 

 

In most of the print, I noticed that it generate sub par tool path and use variable print speed for different types of section (inset and infill).

 

For sure, I can notice thate G code files size is bigger and print time is longer compared tot the legacy one. I have never seen any print quality improvement compared to old version. 

 

Early optimization is the root of all evil.

 

See my version benchmark test: https://www.thingiverse.com/thing:2890860

Edited May 25, 2018 by Ricky

[nallath 1,120]

Simply speaking; The Cura Engine must do these things. The idea that there is a simple model that fits everything is false. The solution space is vast. Not only are we talking about differences between materials (PLA, ABS, CPE, PVA), inter material variation (Blue PLA vs metalic PLA), Machine variation (Which is it's own fied; Accelerations are different, has bowden tube, different behaviors, you name it), model variation, etc. The notion of oxxams razor is a nice one, but fairly naive. Compare this problem with making an autonomous car. If you're only writing software for a single instance thereof, you don't need a lot of exposed settings. All cars you make it for will have the same type of sensors, the same engine and the same interface. We made it really difficult for ourselves by not doing that. We made a bit of software that should work for *all* instances. So we need to have those settings (eg; Sensors are different, speeds are different, even interfaces are different). We could make it simpler. It would be doable for us, but the price would be destroying the possibility to use it for other machines.

 

So there isn't just "one" model. There is perhaps one model that can "Get most models working for PLA on an Ultimaker". Those parameters won't work at all for a machine that has a direct drive or when printing with ABS.

Also note; Only the frontend was redesigned. The engine is one continued process to get to this state.

As for optimisations; Yes, we mostly focus on stuff that helps ultimaker. Makes sense as they pay me. We're already doing a lot of work that helps others, so we kind of have to draw the line somewhere.

As for overfitting on models; We don't. We fully understand what overfitting is and why it's bad. I also disagree with the idea that there are so much hacks in the engine. Is that code the best maintained code out there? No. There are architectural mistakes we made there. But i don't believe that there is a simpler model that will have the same results.

The creation of models with different speeds is intentional. I've also seen vast improvements of g-code since the legacy version especially when using dual extrusion (and of course; When using ultimakers, because we provide the right settings).

Now, I do believe that profiles can be smarter. Changing a setting is an action; It makes property X of a print better and property Y worse. But with 500 ish settings, that is a lot of knowhow to have in the head of a user (and thus is unreasonable). But users perform actions because they have an intent.   If we can somehow capture intent and transform them into actions we can get what we want.

[Ricky 5]

I totally agree that your support for Cura should base on promoting the sales of Ultimaker brand 3D printer. The point is well taken. I'm not against it at all. Because everyone has to pay their bills. Smart software developer deserve a better pay.

 

In fact, by supporting Cura can it also promote the sales of your 3D printer in the long run. It is a very smart business strategy compared to some Chinese 3D printer company, who just build a cheaper and better 3D printer. They have no clues how to keep their advantage in the long run. The 3D printer I owned didn't upgrade their firmware according to slicer thus it may not see the tweak or benefit in the latest slicing engine. 

 

However, there is one and only one model (not talking about STL model, I refer to slicing algorithm) in theory. If it is not, your model is wrong and go find another one.

 

Majority of new settings might be a must-have. But some like the one impact tool path generation needs to be carefully reviewed. Those settings related to tool path severely impacts print time and print quality regardless of your printing material or the brand of 3D printer. Like the z-seam setting in Cura engine 3.31, I disliked this. After reading how it works, I think it should be deduced intelligently instead of exposing it. That's a nitty-grity. 

 

Regarding to the intelligent profile, formalizing human intent into machine understandable format is always a hard subject in computer science. It is like automating software requirement in software engineering. Unless we have a true AI (not talking about pattern recognition like artificial vision, voice recognition and etc), we will never have that day coming soon. For now, what we can achieve is to reduce the number of settings that exposed to the UI as many as possible. Transform those technical settings into novice understandable terminology. That alone can make a night and day difference in term of usability. It will for sure promote the sales of Ultimaker 3D printer as well.

 

My suggestion is that put more focus on UI and make very very conservative change in Cura engine. I have my suggestion in Github regarding to the branching management (https://github.com/Ultimaker/CuraEngine/pull/722#issuecomment-392003445)

Edited May 25, 2018 by Ricky

[kmanstudios 1,120]

1 hour ago, nallath said:

We're already doing a lot of work that helps others, so we kind of have to draw the line somewhere.

You would think this would be appreciated by the community at large, but it seems that users of other machines kinda forget that most of those other machines either do not OEM their own version (Few do) or provide really solid machine settings for their brands. There seems to be some strange onus placed on UM to do it all for everybody.....

 

As for the optimal model stuff, well, I will relate a story of a piece of software written with that philosophy in mind and just how yucky it was.

It was called "Busy Ray". They called it that because they felt that people were busy and the software should be as Occamish as possible. Start it and walk away. Their sales pitch was "There is only ONE correct solution to lighting and rendering!!" Which was ridiculous on its own as, if that was truly the case, Photographers would not exist as a profession. I mean, how much more simple can it be when Nature itself is providing the lighting for you?

 

The renders we3re horrible, devoid of the personal touches that made a good render of a scene. It was devoid of character and many times, just wrong because it could not keep up with all the parts of a variety of scenes. And, when I say wrong, I mean things like light direction being off and areas of 'bounced light (Ambient lighting)' was as bright and more prevalent than direct lighting......which is just not possible.

 

 

It was so bad that you cannot even find it on a search anymore....well, I cannot find it and I used to use it as a golden example of not expecting software to solve problems.

 

Consistency is needed along with focus on robustness, and not always new features.

 

But, they also do start off with a bit of the Occam approach by the way it starts out with only the most prevalent settings exposed. It is up to the user to expose any other settings than that. And, then you get wonks like me that just unhide all the settings before knowing what you are doing. Why? To try and figure relationships and just experiment.

 

If I am going to cook in the 3D printing kitchen, I want to cook with ALL the ingredients and tools, not just a few boxed mixes that someone else decided was 'best.' This allows ME to adjust the settings for MY goals and not be limited. What works for an engineer does not really work for my strange organic fractal thingies I put out. And the surfaces I can get away with certainly would not work for them.

[nallath 1,120]

52 minutes ago, Ricky said:

Majority of new settings might be a must-have. But some like the one impact tool path generation needs to be carefully reviewed. Those settings related to tool path severely impacts print time and print quality regardless of your printing material or the brand of 3D printer. Like the z-seam setting in Cura engine 3.31, I disliked this. After reading how it works, I think it should be deduced intelligently instead of exposing it. That's a nitty-grity. 

Ah, I think we're at the meat of the discussion here. We try (and because we can't do it yet, often fail) to provide with settings that should make the model work. But as our algorithms are far from perfect, it could well be that it might be wrong. This is why we at least give people the option to tweak it. In the long run, this shouldn't be required.

We try to do as little with the engine for exactly these reasons, but it just doesn't always pan out that way. The setting changes that we had to do between 15.04 and 2.3 are probably the most impactfully change (together with the multi-threading) and they were / are must have features.

As for the cooking analogy; I'd like to see it like as "We give you some pointers, but if you want to put chocolate paste on pickles, be my guest."
 

[ahoeben 1,948]

> For now, what we can achieve is to reduce the number of settings that exposed to the UI as many as possible

 

That is what Recommended mode does.

 

Even Custom mode, by default, only exposes a very small subset of the available settings. The idea is that the interface can grow with the experience of the user. Unfortunately, some people seem to be intent to advice even novices to just make every setting visible, which leads to a very suboptimal learning curve.

 

I am not saying the settings UI is perfect (far from it), but thought was given to this.

[kmanstudios 1,120]

3 minutes ago, nallath said:

In the long run, this shouldn't be required.

I hope it is always available though....Back in the Analog days, when I worked at a TV station, we would do all sorts of strange things to our production pipeline for special effects like static, jumping video and such just by wiggling wires while putting clean A-Roll  and B-Roll tape out to the final recording station. Much like this below

6 minutes ago, nallath said:

"We give you some pointers, but if you want to put chocolate paste on pickles, be my guest."

Sometimes it tasted good, sometimes, not so much.

[nallath 1,120]

1 minute ago, kmanstudios said:

I hope it is always available though....Back in the Analog days, when I worked at a TV station, we would do all sorts of strange things to our production pipeline for special effects like static, jumping video and such just by wiggling wires while putting clean A-Roll  and B-Roll tape out to the final recording station. Much like this below

Sometimes it tasted good, sometimes, not so much.

Yeah. We will keep this available. I'd like to think that this is why engineers like our product. If you want to, you can "open the hood" so to speak, in order to mess with the internals. This is why we only give errors for settings that we *know* are impossible or will break the hardware. Really improbable values will just net you a warning.

[Brulti 177]

As a non-engineer, I do also hope that there will always be a way to access the full range of settings, because I want to learn and tweaking settings is a way to learn, plus, sometimes, on that one special model, you do need to tweak a setting that would otherwise never have touched.

 

And I don't believe in the 'one-size-fits-all' approach of the Occam's Razor. This can work only in a civilization of clones.

[kmanstudios 1,120]

12 minutes ago, nallath said:

Yeah. We will keep this available. I'd like to think that this is why engineers like our product.

Suh-weet! And, yeah, it is fun to dabble like that....you can get some really neat stuff when you are not just making tchotchkes and engineered parts. A lot of expressiveness available.

[burtoogle 513]

When I was working on the bridging (which is still WIP), it occurred to me that I could probably come up with some code that worked for my specific examples that I test in a particular environment (PLA, 0.4mm nozzle, delta printer, etc.). When it was working OK for me, that would be OK for everyone else, too? I don't think so. The point being, as already explored above, there's so much variation in materials/printers/models/requirements (prettiness, strength, etc.) that there is absolutely no way that one size fits all. What works for me, is unlikely to work for others. So we need the ability to tweak and tune. That's why there's such a daft number of experimental bridging settings. It's complicated because we don't yet know what will work best. Once the tweaking and tuning has been done to our collective satisfaction the good combinations of settings can be embodied in "standard" profiles which can then be used with a degree of confidence by people who don't care about the detail. It may turn out that some of the settings are actually redundant and some of the implementation simply doesn't need to be there. In which case, we can chop out the bits that are not required. Cura is complicated because although FDM 3d printing is a theoretically straightforward task, it's made  extremely complicated by the limitations and physical properties of real machines and materials.

[nallath 1,120]

4 minutes ago, Brulti said:

As a non-engineer, I do also hope that there will always be a way to access the full range of settings, because I want to learn and tweaking settings is a way to learn, plus, sometimes, on that one special model, you do need to tweak a setting that would otherwise never have touched.

 

And I don't believe in the 'one-size-fits-all' approach of the Occam's Razor. This can work only in a civilization of clones.

I have a clone (identical twin) and even he does different stuff ? 

[kmanstudios 1,120]

26 minutes ago, smartavionics said:

Cura is complicated because although FDM 3d printing is a theoretically straightforward task, it's made  extremely complicated by the limitations and physical properties of real machines and materials.

Environment can complicate things even within one's own home. I have to be very careful when the humidity changes outside as it will affect things inside and sometimes, settings do not work as well at one time as they do in another. I have to see the differences and know what is not working.

[Ricky 5]

@smartavionics

Your example is exactly my concern on the improvement (or hack/tweak) I mentioned.

 

We need a better way to manage it and expose it to end user. If we don't get it right, we are in the wrong way. 

 

I made a discussion thread in Github. Welcome to chime in. https://github.com/Ultimaker/CuraEngine/issues/784

 

[ghostkeeper 105]

41 minutes ago, Brulti said:

As a non-engineer, I do also hope that there will always be a way to access the full range of settings, because I want to learn and tweaking settings is a way to learn, plus, sometimes, on that one special model, you do need to tweak a setting that would otherwise never have touched.

 

And I don't believe in the 'one-size-fits-all' approach of the Occam's Razor. This can work only in a civilization of clones.

 

55 minutes ago, nallath said:

Yeah. We will keep this available. I'd like to think that this is why engineers like our product. If you want to, you can "open the hood" so to speak, in order to mess with the internals. This is why we only give errors for settings that we *know* are impossible or will break the hardware. Really improbable values will just net you a warning.

Actually, for some of the settings, I'm sort of putting my foot in the door and try to steer it such that it doesn't become a setting. Because some of these settings are just so complex to use for the user that they will hardly ever be used at all. Or there is just one option that is in every case better than its alternatives (but takes 0.05s longer to compute in the engine or something).

[Ricky 5]

@ghostkeeper

I totally agree with you. Even for a sane engineer/hacker like me, I don't want to spend my time to figure it out what the setting is or even read the code to figure it out why.

 

No matter how smart you are, sometimes you have to admit you have a limited time and energy to get your print better. For majority of user, they just don't care why and take it as the limitation of their 3D printer.

[kmanstudios 1,120]

12 minutes ago, ghostkeeper said:

 

Actually, for some of the settings, I'm sort of putting my foot in the door and try to steer it such that it doesn't become a setting. Because some of these settings are just so complex to use for the user that they will hardly ever be used at all. Or there is just one option that is in every case better than its alternatives (but takes 0.05s longer to compute in the engine or something).

I do not think anybody is arguing for having everything available. But there is a difference between reductionism and flexibility. A watchful eye on this is always welcome. But you cannot reduce it to just minimalism for the sake of ease.

10 minutes ago, Ricky said:

@ghostkeeper

I totally agree with you. Even for a sane engineer/hacker like me, I don't want to spend my time to figure it out what the setting is or even read the code to figure it out why.

 

No matter how smart you are, sometimes you have to admit you have a limited time and energy to get your print better. For majority of user, they just don't care why and take it as the limitation of their 3D printer.

That is why the basic default is so limited.....to just get it out without muddling things.

15 minutes ago, Ricky said:

@smartavionics

Your example is exactly my concern on the improvement (or hack/tweak) I mentioned.

I am not sure I understand this as it is already being managed. Recognizing that something in a feature that has been optimized and tested on one system must be available on all systems, but hardcoding all of that would be nightmarish. Some onus has to be on the user.

 

Honestly, I miss the days of computing when you had absolute control over your system with minimal input from the OS makers. Now, in the attempt to make things as simple as possible, we have bloated OS's, crap so deep it is not easy to get rid of the things you would never want if you are in an industry. I would love to turn a boatload of things off and just have enough OS to run my programs without worrying about Suzie homemaker not being able to easily file her brownie recipes because she cannot be bothered to learn the difference between a right click and a left click.

 

And, now? We have it so dumbed down that users cannot decide when to upgrade anymore, no matter what it breaks or jobs it interrupts.

 

Balance is needed, not one view or the other.

[nallath 1,120]

21 minutes ago, kmanstudios said:

Honestly, I miss the days of computing when you had absolute control over your system with minimal input from the OS makers. Now, in the attempt to make things as simple as possible, we have bloated OS's, crap so deep it is not easy to get rid of the things you would never want if you are in an industry. I would love to turn a boatload of things off and just have enough OS to run my programs without worrying about Suzie homemaker not being able to easily file her brownie recipes because she cannot be bothered to learn the difference between a right click and a left click.

The stuff that an OS does is so complex and big that there is no single person that understands what every bit of it is actually doing. So there *is* no turning back to that time. That being said; Linux does get you a long way with regards being able to tune / adapt features.

[Ricky 5]

@kmanstudios

Well, you misunderstood us all. 

 

My points of view is from a non-techie user. Please allow me to give you an example. To improve usability of slicer, we should not expose the exact number of layer height like 0.1234 mm. But instead, we should just say fine, normal or draft in the option. From there we deduce rest of settings like how to do a trade off between print speed and print quality.

 

If UI can achieve this for slicing engine, that can beat all the slicer out there.

 

If you are truly a hacker/engineer who want to take control, just read the code. But I can imagine nobody just nobody in the world want to do that for improving one single print.

[Brulti 177]

1 hour ago, nallath said:

I have a clone (identical twin) and even he does different stuff ? 

 

Oh noes, my opinion has been completely disproved! ?

 

19 minutes ago, kmanstudios said:

Some onus has to be on the user.

 

Honestly, I miss the days of computing when you had absolute control over your system with minimal input from the OS makers. Now, in the attempt to make things as simple as possible, we have bloated OS's, crap so deep it is not easy to get rid of the things you would never want if you are in an industry. I would love to turn a boatload of things off and just have enough OS to run my programs without worrying about Suzie homemaker not being able to easily file her brownie recipes because she cannot be bothered to learn the difference between a right click and a left click.

 

And, now? We have it so dumbed down that users cannot decide when to upgrade anymore, no matter what it breaks or jobs it interrupts.

 

Balance is needed, not one view or the other.

 

Why can I only like this once? ?

[Brulti 177]

8 minutes ago, Ricky said:

@kmanstudios

Well, you misunderstood us all. 

 

My points of view is from a non-techie user. Please allow me to give you an example. To improve usability of slicer, we should not expose the exact number of layer height like 0.1234 mm. But instead, we should just say fine, normal or draft in the option. From there we deduce rest of settings like how to do a trade off between print speed and print quality.

 

If UI can achieve this for slicing engine, that can beat all the slicer out there.

 

If you are truly a hacker/engineer who want to take control, just read the code. But I can imagine nobody just nobody in the world want to do that for improving one single print.

 

So, for you, there's only two ways: non-techie can choose between option A and option B, hacker/engineer need to learn to read the code? That's scary in many ways. And completely disconnected from reality.

Edited May 25, 2018 by Brulti