ctbeke

1) Look at the code, it's very much adaptive (as in it looks at the mesh wall angles to determine layer height). in case of a sphere, this would be a continuous decrease indeed. you can prevent this by choosing a larger step size. 2) 3D printing is not milling, so I don't see how that milling technique would result in a 'perfectly smooth surface' in case of 3D printing. 3) It's in the experimental section because it's, well, experimental. We push out features as early as possible to get feedback rather than stay in our own world. 4) It's Free an Open Source Software, so feel free to contribute.

Well, the slicing would work fine and it would produce printable G-code, but the print quality wouldn't be what users expect from it. We always try to keep print quality high when building features.

Thanks for reporting! We're aware of the limitations of adaptive layers (hence it's experimental status). As it's kind of designed to only work with 1 model at a time (otherwise the layers would be weird for the other models), I'm not sure if we'll make it work with multiple models. Of course there should be some UI feedback if that's the case. We'll discuss this internally and see how to improve the feature.

I'm sure all of those things will happen at some point in the future. They're quite difficult to implement in such a way that we can guarantee print quality (that's the whole reason the base profile is used as center of the layer range and the offset goes in both directions, see my linked post above for more details). Doing different behavior for overhangs vs top surfaces should be doable though. Note: I'm not working on Cura at the moment but on another project, so I guess someone else in the Cura team will pick this up when it becomes a priority, or when I find some spare time to work on it.

Actually the threshold works differently, here's a whole post/thread about it: https://community.ultimaker.com/topic/21192-cura-32-beta-adaptive-layers/?do=findComment&comment=197896

The most important one is extrusion speed, which affects the amount of material extruded per distance. The amount needs to lower when using a lower layer height (e.g. ~50% when using 100mu instead of 200mu). We we can't change extrusion speed to quickly as that would result in poor print quality due to changing nozzle pressures. That's why the max. difference per step parameter is there (to tweak these changes). The print speed itself also changes when the engine detects the material volume is lower than a certain amount, but I'm not familiar with all these details of the engine.

Can't reproduce on my Mac either (MacBook Pro 13'', latest OS version).

The reason for that is that changing layer height affects flow rate, thus line width, extrusion speed/volume, and so on. To limit the amount of change from all the other parameters, we use the profile as the middle of the variation instead of one of the edges. This gives far better print results.

Didn't know that trick, great it works now!

Then Cura has detected that your graphics card or drivers are not compatible with the minimum required OpenGL version (4.1?). You can still slice and use adaptive layers, you just can't preview the layers in Cura.

It's the last checkbox in the "viewport behaviour" section. Disable it and then restart.

You're still in compatibility mode. Please go to preferences -> general and switch to normal layer view mode (if your PC can handle that). Then the drop down for new color schemes becomes available (after restart).

You mean you're not in compatibility mode anymore but can't see the different color schemes that are available? It should look like the attached screenshot.

Compatibility mode doesn't allow other colors schemes. To see one of the 3 other schemes you have to switch to the normal layer view (if that's possible on your pc).

The first few installs always give these virus scanner issues because it's not in their databases yet. After a few hours it usually is not a problem anymore (as is now?). Quirks of being an early adopter I guess

It is not exposed by default, you have to explicitly enable it in preferences, where it is listed as experimental.

@timmeh thanks for putting effort into this! Some thoughts that cross my mind: 1) We have never tested it at Ultimaker, so can't say anything about if it works or not. 2) There are breaking changes in Cura 3.2 and 3.3 for the plugin API, so this plugin needs to be updated in order to support those versions in the near future. 3) There is now a 'container provider' plugin type available (see local container provider in Uranium for an example) which can be used to insert new containers for the Dremel printer. That would omit the manual copy/paste steps for the printer/material/quality profiles. You could also submit the profiles as part of the main repository (not sure if that's useful as it needs this plugin to work with a Dremel?). If you have more questions you can always email us at plugins@ultimaker.com.

Should be a direct line to @Msuurmond? 3.2 release is gonna be very soon!

@ahoeben we can put the plugin in the browser any time, just give us a ping

My experience with prime lines on other printers is quite successful, maybe it'll work well on UM3 as well?

The initial layer height is always fixed because it's needed for proper bed adhesion. It also stays 1 step size above 0 to prevent empty layers. Since the default layer height here is 0.1 and the max. offset is 0.15 (totalling to 0.25), the initial layer heigh of 0.27 is still a little bit taller, so it appears in the spectrum. But the actual yellow part of the model will be 0.25 (except the first layer ofc). So indeed it's intended.

Just confirming here that OctoPrint will be available as downloadable plugin from the browser in the 3.2 stable release and onward.

@gr5 That's right! Indeed it tries a layer height with that formula. If it doesn't satisfy the threshold it'll try the next 'allowed' layer height (1 step size smaller). Also in our case, steepest means the one closest to a horizontal surface. The naming might be a bit weird, but it's 'steep' in the context of the algorithm. Indeed we could differentiate between overhangs and top surfaces to improve results, that's not too hard to detect. I did see some results though where an overhang with adaptive layer height actually made a print possible (https://github.com/Ultimaker/Cura/issues/2877#issuecomment-348109846). Food for thought!

All manuals suck I think the software itself should be the manual. It's good to know that this feature is not straightforward to use, I'll let the UI designer of Cura Connect know.

Finished the custom command sending PR and added an internal ticket. It'll be in 3.3 hopefully. It doesn't show printer responses yet though, but maybe someone else will add that as 2nd step.