We made it, the New Cura

[nallath 1,120]

I am eating my own dog food I print all my stuff with the new Cura. To be honest, i didn't do this for 15.06 when it first came out, which is bad.

I don't see the forum as a good place for (functional) development talks. Most of that stuff is done on github, but that isn't that good for that. We're moving towards Jira.

I'd love to get help from anyone. We're already noticing a steady increase in external developers (and others) helping out with Cura. What could I do to convince you to not give up on this?

[KevinMakes 22]

@KevinMakes Given the fact that on this machine do not play games

 

Mine doesn't play games either. It is my office workstation. Not my man-cave battle station.

[SkyKorp 6]

Sometimes you can solve things in ways the user would never think about...

Just like the nest thermostat you can log the user's interactions and make good guesses on how to leverage the computer resources based on facet count, model size, toolpath settings. If my model is large and complex, and I type an extra zero for layer height, I will wait and crash no doubt.

You could keep auto slicing on as you wish, but change the hooks to the UI so cura never disrupts the user's visual focus. Keep it a background process. Then , when a click the button, it is so fast because it is already queued and ready.

It reminds me of a time I optimized a startup routine such that the the company brand and logo flashed so instantly, that marketing had a fit saying I killed the built in commercial at bootup time. I fought it and lost, and it kills me to this day to see this device slow bootup when I know just a counter inside I replaced it with. Haha.

A feature isn't a feature unless there is value. Otherwise it is technical debt.

 

 

Remember that feedback is like an iceberg,... what you see here on the forums is only the tip.

 

The same is also said of audio design in games. If someone finds it good they don't notice it, but if they find it bad, all hell breaks loose. I've used cura back in the day where the auto slicing wasn't an option yet (you had to press the slice button every time), which was fairly annoying. I think the current problem with the auto slicing is that the message pops up and pops down again, which is quite distracting.

For all the developers shouting that they want this feature, I've yet to see a pull request. We're considering adding an energy saving mode which disables auto slicing, but due to the feature freeze we're in at the moment, it won't be added until the 16.01 release.

I don't think this has anything to do with bravery so i don't quite understand what that has anything to do with this discussion.

 

Edited September 19, 2015 by Guest

[nallath 1,120]

The slicing is a background process. For the most part that is. Python is inherently single threaded (or well; it has multiple threads, but only one of them is active at any given moment). The slicing itself is a stand alone process.

So the sending of the data is the only task that could block the GUI from reacting. We have some ideas how to fix that in the future, by not re-sending the model every time something is changed, but simply sending changed rotation / scale / position together with settings. This would save pumping over a ton of data every time. Such a change would also allow for faster slicing, as we don't have to re-calculate everything every single time.

[peggyb 169]

just to be curious: is it that complicated to make a tick box to pause the slicing?

Is it 'impossible/very difficult' to do, or is there any other resistance...?

like I said before: I love the autoslicing.......but not always... This is not a competition for yes or no, sometimes you want it sometimes you don't.... I want both!

[Labern 774]

just to be curious: is it that complicated to make a tick box to pause the slicing?

Is it 'impossible/very difficult' to do, or is there any other resistance...?

like I said before: I love the autoslicing.......but not always... This is not a competition for yes or no, sometimes you want it sometimes you don't....  I want both!

 

This still comes to Gr5"s point, If they put this in place then the people with issues will use the pause function rather then reporting the issues.

[nallath 1,120]

It wouldn't be very hard to add it. I do see some issues with workflow, as you would only start to slice when the user performs a certain action (button? When save is clicked? Switch to layerview?)

[cloakfiend 995]

Ok Im a bit pissed off now and am getting more and more tempted to throw in swear words which would emphasise the amount of annoyance at the constant avoidance of explaining why exactly the auto slicing wont help and will cause trouble for dumb idiot people (who really shouldnt even be using the printer in the first place in my opinion!) who will press it and forget to turn it on and whine about it or whatever lame reasons you want to give, like developers not getting feedback and all that crap that i don't care about. What irritates me even more is you telling me disabling autoslicing will not help. I simply dont believe you as what you are saying doesnt even make sense?

Why would disabling a service from running still cause it to run?

Why do i need to wait 3 minutes between entering values in each box in cura with or without autoslicing enabled?

Surely disabling the autoslicing will disable the thinking/waiting. if not why not?

What on earth would it be thinking about if not the slicing when im changing values?

If its so easy to implement then just do it and see what happens, you can always pull it in the next release?

Development is the only reason youve given for not implementing the autoslicing. period. and that doesnt help me or anyone else with large complex poly models one bit. you are effectively not caring about people who are pushing the limits of your software. you are limiting the software.

Bye. I wont post here anymore.

Edited September 21, 2015 by SandervG
mind the capitals :)

[peggyb 169]

relax, people are trying to help here... nallath is thinking with us...

workflow:

autoslice will be on by default, as it is a nice feature.

If you don't want it, you are probably already working with layer view because settings are being changed. If you want to make a lot of changes, slicing is paused/disabled. If you want to see the changes in layer view, enable slicing again, repeat if needed. When satisfied, save.

[nallath 1,120]

If you can't (or won't) believe things that I have to say about how the software works, then why ask in the first place (or use the software, as you seem to think that I know nothing about it ).

Disabling the auto slicing won't disable the waiting. It will improve it slightly, but not to the extend that you need. This is what I've been telling all along and is also the reason why i'd rather not remove the function (See previous comments about it being a band aid, not a 'real' solution).

I have tried disabling it. It didn't have any noticeable change for very large models. What it's thinking about you ask? What about it simply chokes because it has to show 10 frigging million polygons. Which as you guessed correctly isn't the main usage of the software. 99% of the people don't do this and despite that I want to help everyone (I'm even here in the weekends) there just isn't enough time to do everything. Optimising it for higher polygons is something we want to do, but it doesn't have the highest priority (fixing other crashes and adding stuff like manual support does).

We used to have the not auto slicing issue, but it caused a lot of issues with people who forgot to slice and ended up saving the old version of the file.

Edited September 19, 2015 by Guest

[cloakfiend 995]

Ok ive calmed down a bit but yet again you have not given a valid reason why with auto slicing off changing a value from say 10.0 to 26.5 in the scale dialogue would still result in waiting between pressing delete four times (with a three minute wait between each press of the delete key) and a further wait of four time typing in the new 2 wait, 6 wait, . Wait, 5 wait?

Why would it calculate anything until you tell i t too? That has not been rationally answered. You are telling me that you will not be able to change any setting without waiting each time i press a key? Really. Polygon count is irrelevant as you are not scaling UNTIL you press enter.

[xisle 34]

Scaling is one thing Cura <=15.04.2 didn't handle nicely IMO. The new Cura does not have the same eternal delay as @cloakfiend describes.

[nallath 1,120]

The typing has no effect, as it actually waits a a bit until it starts sending. So no calculation is done what so ever directly on a value change.

It's just the entire GUI that's slow as f*ck at millions and millions of pollys. We're well aware of this, but its just not a simple thing to fix.

[cloakfiend 995]

OK, maybe i overeacted some what and in my own world of stress completely forgot that were probably not talking the same versions, lol. I'm using an older version, 15.02.01. as I found the new one took even longer to load my files and even refused some, but as my version is no longer supported, i cant actually complain seeing as i was just complaining about the 'eternal delay' which no longer seems to be a problem, in the new one. So my bad! i have a bad temper, sorry.

[SkyKorp 6]

I work with very complex models. I use STL files and I push the limits and use millions of facets. My parts come out great this way, but it comes at a cost using auto-slice because cura is getting choked with numbers. This is why I feel that there can be other symptoms overlooked.

I am on the side of Nallath in wanting the elegant solution. I think we will all suffer a terrible user experience outcome, when maybe we are around the corner in the best possible elegant solution.

For example, I also use Simplify3d and they do not have auto slice. I surprised myself how irritated I got having to click the generate code button. It's like those automatic sinks, once you experience auto, you want them all to be that way.

Edited September 20, 2015 by Guest

[ivan-lipunov 15]

After the comment about the limitations of multithreading in Python some time I googled this question and found here some interesting option: https://docs.python.org/2/library/multiprocessing.html

This method has its limitations in terms of platform dependence, but the execution speed is obviously higher than when using GIL. @nallath, you have not considered the possibility of changes in this way?

[yellowshark 153]

Hi Cloakfiend, possibly germane, possibly not. A while back I was working with a scan of a plaster cast of a foot (so a reasonable size of model) - which we then take Into Solidworks and create an orthotic insole. The model had about 750,000 faces. I found that most of our software including Solidworks (£5,000 not free like Cura) struggled with this (not sure about Meshmixer as memory fades). "Struggled" means took ages, took so long I killed it, actually failed or would not seem to load the model(could just be taking ages).

I decimated the model to 80-100,000 faces and all was OK. On the computer screen I could not detect any negative impact on resolution of the surfaces. I have no idea what type of models you work with but I wonder if a similar approach could be a route forward for you? I.E. in the real world does one actually need millions of faces. A bit like photography where ultimately it does not matter how much resolution the camera sensor has, you end up being constrained by your printing hardware or display screen resolution.

[cloakfiend 995]

I fully understand the uneccesary polygon argument, but if i am printing something very large sliced in to pieces with fine curves and gradients, then i NEED the high poly count otherwise it just means more sanding to get rid of them. I admit you can in some situations reduce the count, but no always. In terms of programs throwing around millions and millions of polygons while still being responsive, well zbrush is the ONLY one i know of. Maya, max and all the big players also choke on the numbers and they dont isolate the area you work on and keep the entire structure in memory and have to purge and refresh each time, which is dumb in my opinion, and the sole reason why zbrush can play with 10 million polys and not even notice. Its only when you takle that model into a 3D app you find out how heavy it is in the real 3d world.

and @skykorp 'I surprised myself how irritated I got having to click the generate code button.' ...that seems irrelevant, and could be solved very easily with simply having the slice included in the export, so when you export your model to you card it starts slicing on export hence saving you from ever having to actually click any slice button. If you wanted to know before then you could just click on it, to generate code to see how much filament you would use, etc..... These things are not difficult to figure out. Im my opinion, if it makes me wait, then auto ANYTHING is stupid if you want fine adjustments. Its for people who either don't have the time to get things right, or for idiots, or for devs, or for convenience. By all means let impatient kids and the rest of the world have their auto settings if clicking one button really gets that irritating, but it would make sense for others to have the option to not have it if it hinders their workflow one iota. The sensible thing to do, would be as was already mentioned above, enter all the values you want then hit slice.

But seeing as i'm not using the latest cura these are merely my suggestions which make perfect sense in my head and my workflow. If you had the chance to skip standing in a queue and move to the front, would you?

Edited September 20, 2015 by Guest

[Titus 170]

I've been reading this for a while now, and in my head it summarizes to this

Argument: We want a disable autoslice, since it is slowing down everything.

@Nallath 's reply :I've tried it, it's not the slicing that slows everything down, looking into what is(or just to much polygons)

Reply: But we want disabled autoslicing anyway, since it is slowing down everything.

Can you link me to one of the models you experience problems with? I want to play around to experience it myself.

Edited September 20, 2015 by Guest

[SkyKorp 6]

@Titus raises a good point. Is there a software model you are following and is there a part library?

Many moons ago I ran a QA division at a major CAD company and we created a room of computers that represented every OS and computer our software would run on. We developed our own non graphical interface and a part library of customer models and automated 24x7 running loading models and use-cases and trails. We developed tolerances for execution and wait time, and we sent alarms and text messages when code failed or crashed on of these computers. It meant we could stay ahead of quality and never have to step backward. It meant I could sleep at night.

That was the old days and today we have continuous integration and unit testing.

 

I've been reading this for a while now, and in my head it summarizes to this

Argument: We want a disable autoslice, since it is slowing down everything.

@Nallath 's reply :I've tried it, it's not the slicing that slows everything down, looking into what is(or just to much polygons)

Reply: But we want disabled autoslicing anyway, since it is slowing down everything.

Can you link me to one of the models you experience problems with? I want to play around to experience it myself.

 

[petergruenbeck 0]

Nice job on the Cura software. I'm new to 3-d printing and solids modeling in general being a software guy by trade. I found all the hidden tweaks an am experimenting with them - good stuff. I have a few suggestions for improvements if I can post them here or is there a better place for bugs and such?

1) Duplicating parts and moving them leads to ever increasing mouse/object offset errors. Its like the mouse thinks its at the edge, but the part is in the middle.

2) Saving STL file does not preserve edits such as scaling and rotation or duplication. You just save the same thing you loaded.

3) Cura does not know the name of the STL that was loaded. Usually this is in the app window title bar and would be the default when saving to a gcode.

4) New: Have the ability to save the settings file (Ultimaker+2.cfg) with the gcode so you know what parameters you used to set up a file or manage jobs and settings as a set

5) Add more comments to the gcode to document the settings used - makes the gcode more standalone for version control.

6) Add the ability to save some text user comments/descriptions with the generated part in the gcode file, or make use of the file system custom properties for metadata. Currently using the folder/filename to store part metadata.

[nallath 1,120]

Add bugs to github. Forum is rather hard to keep track (and add every bug in a separate issue!)

Edited September 21, 2015 by Guest

[karine7dm 0]

This thread is too good.

[Dim3nsioneer 557]

This thread is too good.

 

I wish they same would go for the new Cura. Let's see what 2016 brings...

Edited December 28, 2015 by Guest

[apgodshall 0]

 

Okay tried it out....despite the settings being Ultimaker Original and No Heated Bed, if you go to use this, the Ultimaker Original sits at "Heating bed".

Umm, you guys test this stuff, right?  

 

We did test, quite a bit. But... well, all our originals where upgraded to + or heated bed upgrade status. So that was missed.

There is a workaround, you can enable the heated bed setting and set that to 0, that will work around this problem till we have a fix out.

 

Well, some time has passed. Is it safe for a newbie with an ultimaker original to try it yet?