Does Cura Engine development go in a wrong direction?

[kmanstudios 1,120]

3 minutes ago, nallath said:

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.

Yeppers, but, sadly I am stuck because my main programs I use are Windows only (3DS MAX) or I do not own the Linux version (Adobe Master Suite).

3 minutes ago, Ricky said:

@kmanstudios

Well, you misunderstood us all.  

Ummmm, no I did not. I am advocating a watchful eye and still keeping flexibility or you will have a monster like what @nallath said. Making things too simple is never an option and quite frankly, trying to make things so simple anybody can use it, while noble, can make things worse for the people who can work it. I have not been printing for more than 18 months. A noob still in many ways. But, when I invest real money into something like this, I am going to make sure I can maximize it, not whine that it is not simple enough.

 

So, do I think Occam's razor is the way to go? Not of this. Occam's Razor is for the actual guts. The straightest, shortest line to solve an issue prevents less issues on the side.

 

Do I think every little thing needs to be made available? No, that is why I appreciate @ghostkeeper's attempt to restrain some things.

 

Are there flaws to fix, yes, but simplification is not one of them. Simplification needs to be in the guts. 2 + 2 needs to be used as an algorithm and not 1 + 1 +1 +1 *1 *2 /2. That is where Occam's Razor works.

[kmanstudios 1,120]

12 minutes ago, Ricky said:

we should not expose the exact number of layer height like 0.1234 mm.

This deserves a separate reply: Uhhhh, no. Again, the user must adapt to a way of thought. Those numbers allow for a user to learn the relationships of detail, but also allow for the user to customize the relationship.

 

Limiting choices on such a gross level would only start to ensure that everybody's prints start to look alike. And, that is happening in the 3D industry as the renderers have become more 'push-button and not really as open as possible. Persets are good forstarting points, but should not make things detrimental. Otherwise you would not have things like the hairy Einstein or Lion or Drooloops or my own little tweak of gumdrop printing, which is only possible by doing goofy things like playing with numbers in a specific way.

[ianpaschal 7]

As an open source project, Cura is always open to feedback.

 

That being said, after letting it sink in, this feels more like concern trolling than constructive feedback.

 

If anyone is so concerned that the development is "going in the wrong direction" (the horror!), there's two very simple steps to take:

1. Participate in code review. See something that looks hacky or overly complicated? Say something.

2. Begin a refactor. We can all hum and drum about razors and philosophy but it doesn't really mean anything if there's not code behind it.

I'm leaving off 3. Switch development model. There are pros and cons to any model we bring up here, and they will all work provided that the above two things are done. If the code review isn't done correctly, it doesn't matter if stuff gets merged through a dev branch first, and if the review is done correctly, it shouldn't matter. With any statement ever, I'm sure someone can disagree but it doesn't really make a difference.

The beauty of open source is that anyone who is concerned with the process can make a measurable improvement to it by simply participating. To any who do, Cura team thanks you!

[kmanstudios 1,120]

5 minutes ago, ianpaschal said:

I'm sure someone can disagree but it doesn't really make a difference.

No I don't!!  ?

[ahoeben 1,948]

2 hours ago, Ricky said:

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.

 

Again, that is pretty much what Recommendrd mode does.

[Ricky 5]

@ahoeben

You missed the whole picture. I'm talking about the intelligent deduce all the settings based on limited number of human understandable configuration. No slicer has ever done that. Recommended modes in Cura is a naive version (or put in political incorrect way -- a joke)

 

As a consumer, when you plug a power adapter to electric grid, you really don't need to understand the whole complicated process how the electricity deliver to your home. If you want to know the nitty-gritty, just Wikipedia it. You will be amazed how engineer hide that superb well for ordinary people.

 

@ianpaschal

I'm fine your implying me trolling. That's how the liberals in US did to violate other's freedom of speech.

 

You think code review is a panacea? No, it didn't solve the problem, either. My suggestion to split stable and experimental branch is to set up a clear firewall between new features that impact everyone (category 1) and new features that only impact some specific brand of 3D printer (category 2).

 

For example, a new feature that change how to determine the starting point of path belong to category 1. Such feature needs to be carefully reviewed (as you proposed) and an extended long period of testing by all users. Note that it should not be just UM brand 3D printer's user. My contribution to Cura open source project doesn't mean you can offend my own interest. Otherwise, in the long run you just exclude others to join this open source project. In the end, Cura just turned into another MySQL. I will just fork it to work on 15.04 branch.

 

For a new feature like adding new support for two extruders 3D printer, it is category 2. You can merge it to stable branch as early as possible. 

 

When you do code review, classify them into two categories and then merge accordingly.  That is my proposal in https://github.com/Ultimaker/CuraEngine/issues/784

 

Edited May 25, 2018 by Ricky

[kmanstudios 1,120]

1 hour ago, Ricky said:

@ahoeben

You missed the whole picture.

You keep saying that when p[eople are demonstrating that what you have suggested actually exists in one form or another. It may not be the form you specifically want, but it is a form of your stated desire.

 

Disagreement also does not imply 'missing the point.' That can be construed a bit insulting as if these individuals, myself included, cannot 'get the point.'

 

This is why  it is difficult to take this seriously beyond this point.

[Ricky 5]

I apologized for my rudeness. I'm not a native English speaker. I was not educated the way like kids in US did use the political correct term or way to express the idea. 

 

I felt frustrated sometimes when my point didn't get fully understood even though you don't have to agree with mine. The discussion about intelligent deducing settings is exactly good example. Cura recommended mode indeed is a simplify version of my ideas. But there is no intelligence built-in at all except some rule-based check on settings. My rudimentary thinking is that it should analyze the STL model file by slicer and make that intelligent decision for normal users based on the feed back from slicer. For example, when slicing layers (not reach to path planning yet), if you find that the object is a spiral one, UI setting should use spirals print path automatically without human intervention.

 

No slicers has been there yet. That's why FDM based printing is still not as easy as printing paper.

 

 Thanks for pointing it out @kmanstudios. My comment is harsh but no means to insulation or trolling.

 

 

Edited May 25, 2018 by Ricky

[kmanstudios 1,120]

19 minutes ago, Ricky said:

That's why FDM based printing is still not as easy as printing paper.

That is like saying Apples are harder to peel than oranges. They are not the same.

 

I am sure that someone will put out a 'no thought at all' slicer. But the default, viewable settings with Cura is to produce that experience pretty much, while still leaving flexibility. Oddly, the people who start out with just those settings eventually get frustrated and start to unhide things when they find out that there is no easy way to slice all models. Having come from a modeling background, I can say that I would not want all my models sliced the same way.

[ahoeben 1,948]

I am probably missing some big picture, but

 

On 5/24/2018 at 10:46 AM, Ricky said:

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.

 

44 minutes ago, Ricky said:

My rudimentary thinking is that it should analyze the STL model file by slicer and make that intelligent decision for normal users based on the feed back from slicer.

 

How is software making intelligent decisions not making assumptions?

[Ricky 5]

@kmanstudios 

I'm totally with you that slicing engine needs to be flexible enough. For people like you, you can still override the setting and input them directly to slicing engine. But my point is that UI should hide the complexity and make a optimal settings based on STL model so that majority people don't need to tweak hundred of settings to get a good print. That's also the idea behind Cura split Engine and UI. 

 

To make FDM printing accessible to ordinary people, slicing engine is a technical barrier not the high price. Chinese manufacture has pushed the price down to the level everyone can afford in US.

 

In fact, Ultimaker company want to promote the sales of their hardware. Making slicing engine ease of use is also in line of their interest as well. But making your brand FDM printer works great is  **NEVER** their goal.

 

Thus, I made my proposal to change the development model and its course so that everyone even those who don't pay for Ultimaker can still enjoy the fun of 3D printing. That sounds very altruism but that's my plan.

 

I personally forked 15.04 branch on my repo https://github.com/rickyzhang82/CuraEngine/tree/dev-15.04.6 and started to make it better. My recent goal is to optimize path planning with ATSP solver.

 

@ahoeben

You mistook the assumption from the information provided from slicer. When slicer do slicing, ie cutting the triangle mesh from plane and connect all line segment into closed polygons, it knows the geometry of your STL model better than anyone. Such information in fact feed back to UI through a socket. But fo now it just visualize in UI. There is no and no whatsoever analysis to make a better setting decision for users. That is not assumption at all.

 

 

Edited May 25, 2018 by Ricky

[kmanstudios 1,120]

4 minutes ago, Ricky said:

But making your brand FDM printer works great is  **NEVER** their goal.

Why should it be? Again, this gets back to a point I made earlier. They make it open source, Why do the other printer manufacturers as a whole do not do so? They could provide profiles, they can OEM it. This is a false equivalency.

 

This would be something to take up with S3D, of which their only product is a slicer. If UM were to really be 'not making it best for YOUR printer', then it would not be open source at all and only geared to their line of printers. Quite frankly, that would make Team UM's job much easier. UM's job is not to make it for everybody right out of the starting gate. They have generously decided to keep it open source and not hog really cool stuff.

 

[Ricky 5]

@kmanstudios

Well, that's how they did in reality -- improving slicing and generating GCode optimal to their 3D printer firmware. That's I feel disgust it the most.

 

Do you recall in the couple threads or the UM's people reply from Github. They did do 3 round of QA test before release Cura. But that test must be done in their brand of printer. 

 

So please advise me why anyone should contribute to Cura if Cura is not in line of their own interest. We didn't get paid by UM.

 

I'm a American. I'm a rebel and  love the quote 'We the people'. So if they don't accept my plan. I will do it by myself in my own way on my own repo. It is GPL after all.

Edited May 25, 2018 by Ricky

[ianpaschal 7]

@Ricky Maybe I shouldn't have used the term "concern trolling" if people are not familiar with it but I'm not calling you a troll really. I'm refering to the general nature of online threads that are a big discussion about "how bad things are." They accomplish nothing.

My statements stand; if you're concerned about the quality of CuraEngine; do something about it. Participate. Start a refactor in the name of Occam. I guarantee you we'll jump on that. That's why it's an open source project.

Also, stop bringing up liberals. That has no place in this conversation and at least from my end only makes it hard to take you seriously. Politics out.

[kmanstudios 1,120]

9 minutes ago, Ricky said:

So please advise me why anyone should contribute to Cura if Cura is not in line of their own interest. We didn't get paid by UM.

To make the printing world a better place. To reverse the question, why should UM do anything at all for any other printer company that is their direct competition? That is the competition's job.

 

10 minutes ago, Ricky said:

I will do it by myself in my own way on my own repo. It is GPL after all.

So, you rail that they do not do it and blame them for not doing everything for everybody, but you are willing to use their hard work to build upon? Wow....we are done.....

[Ricky 5]

Please put yourself in my shoes.

 

In my spare time, I contribute my brain power to some other open source projects which I'm interested in. You can check my Github account. Pull request history didn't lie. By contributing back, everyone get benefits. 

 

But those projects I worked on are not endorsed or back by any profit driven hardware company like UM, whose sole interest is to promote their hardware sales. If anyone tries to undermine others' interest to take other's hard work for free, I don't think it is ethical thing to start with. 

 

My point is that such open source model is not a win-win situation to UM and any outside contributors. If they completely overlook the interest of others, they should make the slicing software closed source. Once they start to take in other's PR, they should have some decent human conscious (if they have).

 

If you check Cura engine license in Github, it is under AGPL. If you are familiar with licensing, AGPL is more restrictive than GPL. If you distribute slicing engine as online service, you must open source under AGPL. GPL doesn't need to. So you must know that UM's legal team must have protect their IP well.

 

That being said. I'm not against anything what UM does. It is a smart business strategy.

 

I just want that they can steer back to right course.

 

Just my 2 cents. Not my whining. 

Edited May 25, 2018 by Ricky

[Ricky 5]

@ianpaschal

I already proposed a development model in Github to resolve my concern. But it was rejected by @ghostkeeper

 

I did read two blogs he linked. But the counter argument in the 2nd blog is weak and naive. One of the argument point even said master branch is not a default development branch. Thus, branching is not a good idea. Such logic is silly.

To your 'Politics out'. Sorry. No more politics. 

[ianpaschal 7]

9 hours ago, Ricky said:

But those projects I worked on are not endorsed or back by any profit driven hardware company like UM, whose sole interest is to promote their hardware sales. If anyone tries to undermine others' interest to take other's hard work for free, I don't think it is ethical thing to start with. 

 

That's why Cura is free, though. Everyone can use it, for free, with any printer they want.

 

9 hours ago, Ricky said:

My point is that such open source model is not a win-win situation to UM and any outside contributors. If they completely overlook the interest of others, they should make the slicing software closed source. Once they start to take in other's PR, they should have some decent human conscious (if they have).

 

OK, you might feel that way, but I don't think most people do. This is also a whole other issue than the day-to-day development workflow. It sounds like you have a problem with a for-profit enterprise backing an open-source project which is totally unrelated to CuraEngine development specifics. No one would disagree with you that such a company should have a conscience, but I think UM actually has a pretty great reputation in that regard. Largely because of, again, things like making our slicer open source and working with competitors' hardware.

 

9 hours ago, Ricky said:

@ianpaschal

I already proposed a development model in Github to resolve my concern. But it was rejected by @ghostkeeper

 

 

That's true, and to be honest, I'm a fan of the development model you mentioned. But the point is that Git workflows don't magically change code quality. If starting a new project we might consider a different model. Some of the private internal UM repositories do use this model. But applying it to CuraEngine doesn't make the code better by default. Merging into a dev branch and then merging into master makes no difference if the review process was not good, nor will it address the fact that you have the idea that the whole architecture of the code is wrong.

Again, if you are concerned, there's two things you can do: Read and review pull requests to point out code which you feel is overly complicated, and secondly, start a refactor to simplify it. These actions are not at all dependent on the branching model used.

And if you feel that you don't want to contribute your time to the project in these ways (participating, contributing) because it doesn't fit your philosophy, that's fine too. But then to spend lots of time complaining why it doesn't suit you absolutely is "concern trolling."

[Ricky 5]

@ianpaschal

Fair enough. I will work on the improvement on my way.

[Dim3nsioneer 557]

This is a pretty interesting discussion with good arguments in favor or against certain ways and strategies in the Cura (engine) development.

 

Being no software engineer myself I also contributed to Cura with code a long time ago. This was at the time of what we call today legacy Cura. In the meantime the code of both Cura and the engine have become more complex in order to match more people's needs. A code contribution to Cura is from my point of view only possible today if you are a software engineer or at least a very enthusiastic coding hobbyist with the professional knowledge of modern coding (standards). This is good in terms of the quality of the code. However, it limits the access for "normal" people. Their only way to contribute is by making suggestions. So I think your argument, @ianpaschal, that Cura is open source and everybody can contribute is correct in theory but sees serious limitation in the real world. Therefore, I would appreciate if making suggestions would also be regarded by the dev team as a serious and valuable way of contributing to Cura.

 

As @ahoeben pointed out multiple times, Cura has a recommended settings mode where the user just has to set very few things to get a generally good slicing result. There will always be examples where you have to change settings in order to get e.g. an optimal print quality. So the separation into the two modes "recommended" and "details" is exactly how things should be done imo. If a professional customer has troubles finding the right parameters for his e.g. special print geometry, there is a network of Ultimaker sales partners and resellers part of which offers such additional services. It would need some kind of AI in Cura to recognize all those special cases and provide the right parameters for every single print.

 

It was mentioned before one should separate the discussion into Ultimaker printers vs. third party printers. I fully agree. Cura should always focus on Ultimaker printers but stay open to other printers as long as possible (disclaimer: there is no sign on the horizon this might not be the case in foreseeable future). However, that focus also brings some responsibilities with it such as the obligation to fix bugs which affect Ultimaker users strongly and implement features in such a way that they follow the principle of a hassle-free print preparation. The latter could be followed even more consequently (for instance Cura could auto-select PVA as support material if present/loaded; I find it e.g. more likely a user wants to print with PVA (which is usually in extruder 2) than with the main build material).

 

To summarize, I don't think that the Cura (engine) development goes into a wrong direction but the path seems a bit unclear to me. I would appreciate if the Cura team could publish some general strategy where to go with the development. This would allow other people to adjust their contributions - suggestions and code - to those guide lines.

[ianpaschal 7]

6 hours ago, Dim3nsioneer said:

A code contribution to Cura is from my point of view only possible today if you are a software engineer or at least a very enthusiastic coding hobbyist with the professional knowledge of modern coding (standards). This is good in terms of the quality of the code. However, it limits the access for "normal" people. Their only way to contribute is by making suggestions. So I think your argument, @ianpaschal, that Cura is open source and everybody can contribute is correct in theory but sees serious limitation in the real world. Therefore, I would appreciate if making suggestions would also be regarded by the dev team as a serious and valuable way of contributing to Cura.

 

This is true, but I also don't see it as a problem. You yourself say it's good in terms of quality of the code. Also of course it's a limitation in the real world. That's the case with everything. There's social causes I'd like to help lawyers fight for but criticizing their process is not that and without a legal background the best I can do is cheer from the sidelines. I'd also really love to cook alongside a world class chef but I am not much help. That's life, and that's ok.

 

There are still non-coding ways to contribute though. I brought up the other two because everyone is listing their "I know a thing or two about code" credentials, to which the obvious response is: participate then. I really like what you finished with though...

 

To summarize, I don't think that the Cura (engine) development goes into a wrong direction but the path seems a bit unclear to me. I would appreciate if the Cura team could publish some general strategy where to go with the development. This would allow other people to adjust their contributions - suggestions and code - to those guide lines.

This is a case where it is really helpful to know what users want. This is why I say of course Cura is always open to feedback. Granted it's up to our product owner to chart a course for the software, but I know he wants to know what people want.

But the discussion of features and purpose is of course a separate issue to the actual nitty gritty of development process which is what I was under the impression Ricky initially felt was not going well.