nallath

Slicing is multi threaded these days. This means that it will use more resources if there are any. If you don't want Cura to use that much resources, disable auto slicing. If more people feel this way, we could also add a force single threaded option, but that would significantly increase slicing time (~ 2x as slow)

You don't. This is why i was not so sure we should have this feature. But all the other slicers had it and at some point we also had to participate. Because if we don't, people keep using the lack of a "realistic" rendering as an argument why Cura is falling behind. If you want a perfectly right layerview, it's going to take a loong time to build. You would need to take a whole lot of physics, material flow, deformation, etc into account.

That should be pretty accurate. The totally unofficial list; - Number of fixes regarding settings not updating - Added some missing profiles - Fixed material costs not always being saved correctly - Build volume calculation fixes - Project loading bugfixes The total list is 52 issues.

If the nozzle is thicker, it might be that it needs to extrude less in the second pass. The layer view, even though it looks realistic, is not a realistic representation of what it will do when printed.

Sniff. You hid the kitten post it :(

Yes. There were some issues with this, which have been fixed. Not sure if all the problems are gone of course.

Well, Cura already died for your sins; You don't have an active quality profile (as visible from not having a name in the profile dropdown) which means something already went horribly wrong.

We're going to need more information to help you. Could you share a project file?

I meant "automatic" nesting - just mark the parts, click "nesting" and they arrange at the smallest possible area - like similar functions in 2D milling/cutting... maybe something based on @chrisSalzburg 's orientation plugin...? Ooh. Like that. Yeah, that's something that we have on the backlog.

Cura can't slice this properly as it's a completely broken model.

https://github.com/nallath/BarbarianPlugin

Group the objects. Intersections in the group are ignored.

This is a "problem" with how we calculate the shapes. In order to simplify this caluclation, we use convex hulls. Don't expect this to change anytime soon.

As far as I know, binary STL can only have a single solid.

Ugh :( That stupid thing again. It's one of those issues that rears it's ugly head every so often, but has proven to be a nightmare to find (and therefore fix).

Which is odd, because binary stl is probably the simplest format out there. The only thing you can mess up is the header length, but that means it's a exporter issue.

The materials team isn't quite done with the profiles, so they aren't there yet. Another thing is that both extruders must have the same quality, as quality defines the layer height (which must be the same). So if one extruder only supports draft, the other is also limited to draft (or draft like) quality. Because I nagged for the bottom layer pattern I noticed that quite a few models print a lot better (less warp) if you put bottom layer to Concentric. I've already added a feature to 2.6 to invert the zoom direction. I think the zoom in mouse direction has a good shot at being in 2.6, as a lot of people ask for it (and i don't think it's going to be that hard to build).

The PPA is not officially supported by us. The appimage that we distribute should work fine. I've sent a mail to the guy that made the PPA so he can have a look at it

Huh. Odd. Do you have an example of one of those models?

It did help that the original wording even implied that connecting a network cable or your own thumb drive to the UM3 would void warranty

Yep. Even works when running it from source. I use the plugin a lot myself, so it's almost guaranteed to work

Sniff. You did got a bit ahead of what I wanted to build. I think a "Don't automatically connet to USB" preference would be better for this case.

The engine sends us 2D data for the layerview. We use geometry shaders to convert those into geometries. In order to do that, we need a pretty high opengl version.

The tl;dr is: "Yes it's possible, but would slow down your computer and cost a lot of resources to build".

Yep; "Top/Bottom pattern" for all top/bottom layers and "Bottom Pattern Initial Layer" for just the first layer. I nagged the guy building the engine for quite some time for the second option