Cura vs "Smooth Variable Layer Height"

[gmeardi 0]

Just read an article where the new "Smooth Variable Layer Height feature" for Slic3r Prusa Edition improves surface quality while maintaining print speed.

Effectively it's not a bad idea at all... and the hadware is unaffected: only a slicer software upgrade is required.

Any idea about Cura plans?

Here's the related article: link

[Kin 3]

I've heard but not seen that stratasys software can do something like this (their high end suite.)

I don't see a lot of value over "infill thickness" (e.g, .1mm perimeters with .3mm infill.) But it is something neat enough that it would be cool if cura matched.

Sometimes I wish slic3r and cura were one software package, they both have a ton of strengths and end up doing a lot of redundant work. besides the general reasons for why they are not one project, I also have no conception of why they probably physically can't be merged [presumably they have different architectures and code bases.]

[nallath 1,120]

I also have no conception of why they probably physically can't be merged [presumably they have different architectures and code bases.]

 

And a different language to top it all off. Merging them isn't going to happen.

As for the variable layer height, it's something that is pretty high on our feature list, but due to some dragons in our architecture it will require more work than is should / would have. This is the main reason why we don't have it already.

[ahoeben 1,948]

NB: "merging" is a fairly specific term in programming, where changes from one repository of code are copied into another repository.

https://en.wikipedia.org/wiki/Merge_(version_control)

Since slic3r and cura don't share a common base, this type of merging does not apply in this context.

[DaHai8 74]

This is also known as 'VariSlice' from Autodesk. Nice to see a slicer with a version of that, but a bit disappointed that it must be set manually and not automatically detected and generated by the slicer.

[neotko 1,417]

I would love a combination of this, with a manual custom selection. Like, for example the slicer shows X colored areas that could need this, then the user selects or removes that areas. I would like this because printing lower layer height for a technical part, sometimes the look of an area doesn't matter but the area with a thread (for example) could need this allowing a faster print but with precision where the users wants it.

[Kin 3]

For the record I am absolutely aware there is no way to "merge" the two programs. I hope i didn't distress anyone by throwing around words like that with more specific meaning than I intended . [Distressed insofar as someone feels distressed when they hear someone talking about things so far off-base]

I absolutely only meant it in the sense of a dream world concept in which all the things I like about slic3r existed in cura, and cura handled the random nifty super-tweakable settings of slic3r. I also meant it in the sense that I conceptually admire slic3r (it was my first quality slicing experience and got my first amazing prints with it), but I see cura/ultimaker as a wonderful platform overall that I prefer to use (it feels less disjointed than slic3r.) So I just am recognizing that there are some awesome developers contributing to both slic3r and cura, and my eyes bug out at the thought of what could be done if one of the projects had *all* of the developers, haha.

[Labern 774]

It's a bit disappointing hearing that its hard to implement something like Varislice as I thought the whole point of the new plugin style CURA was to make it easy to add in features like these.

By that's just my programming ignorance.

I'm just glad it's on the developer's radar. Because this would be a epic feature for CURA.

[nallath 1,120]

It's a bit disappointing hearing that its hard to implement something like Varislice as I thought the whole point of the new plugin style CURA was to make it easy to add in features like these.

 

The issue here is that the frontend of Cura has an amazing plugin structure. The engine doesn't.

[tomnagel 126]

I really like UI side of the slic3r Prusa edition. Seems rather intuitive, well thought out.

You see what you are doing in the vertical bar, but also in the 3D view, where the section that you are modifying is highlighted. The combination is great.

[ahoeben 1,948]

So I just am recognizing that there are some awesome developers contributing to both slic3r and cura, and my eyes bug out at the thought of what could be done if one of the projects had *all* of the developers, haha.

 

No, we need the diversity. Healthy competition promotes better software, and is ultimately better for the end user. Being the single "best" at something promotes complacency. Simplify 3d is sometimes seen as an example of this; it *was* clearly the best slicer option a year or so ago. (ducks for cover for the ensuing fanboy war)

[nallath 1,120]

So I just am recognizing that there are some awesome developers contributing to both slic3r and cura, and my eyes bug out at the thought of what could be done if one of the projects had *all* of the developers, haha.

No, we need the diversity. Healthy competition promotes better software, and is ultimately better for the end user. Being the single "best" at something promotes complacency. Simplify 3d is sometimes seen as an example of this; it *was* clearly the best slicer option a year or so ago. (ducks for cover for the ensuing fanboy war)

We look at quite a few other slicers & 3D printers to see what they did well / bad. So having some competition is a good thing, even though it does mean that certain things get re-implemented.

In some cases it's even good that something gets re-implemented, because you can occasionally find a much better way of doing the same thing. Improving on something that's already there tends to suffer from moving towards a local maximum.

[eldrick 65]

I just tried the variable layer height with Slic3r Prusa on a smooth knob with a spherical domed top, and it works beautifully to keep the layer edges evenly visually spaced.

Watching while it printed, it reduced the layer height by .01mm each layer as it approached the top, then on the last few layers, it used even thinner layers.

A bit of a PIA to set the area where you want it applied, and you are shooting in the dark, as the Layer view does not visualize the reduced-height layers, but it does a nice job..

[yellowshark 153]

I visited the Prusa website but could not find a download, anyone have a url?

[DaHai8 74]

Caveat Emptor - its beta:

https://github.com/prusa3d/Slic3r/releases

[yellowshark 153]

Thank you8)

[DaHai8 74]

I played around with the Smooth Variable Layer Height (SVLH) feature. While it may seem off-topic on the Cura forum, I'd like to state some of my impressions of it here for the Cura developers - so they can do it better:

First, its a decent first cut. It does what it says it will do with little effort on by the user (or the app )

But, in my opinion (and I might have missed something), it falls way short in a 'good' implementation:

There is no analysis by the app on what parts would benefit from "SVLH", nor any suggestions by the app on what an appropriate layer height would be for any given section.

There is no feedback on what you are 'smoothing' the layer height by. It's just a curve to the side with no numbers to tell you the new layer heights.

Smoothing is done across the entire X/Y plane. If you object has 'towers' (or you have two objects), one curved and one straight, the smoothing is done on both, regardless.

I'll shut up now.

[tomnagel 126]

Shutting up not necessary. I think this is good input!

[Dim3nsioneer 557]

I feel that a lot of Ultimaker users have that wish that Cura can slice with different layer heights at different heights. However, quite often people ask for an even more sofisticated feature which automatically recognizes the optimum layer height throughout the print. So for the developers here: That is probably going to be the step after the basic feature... But I could imagine it is not so difficult to implement - it could work in a similar way as the overhang angle recognition.

btw: about two years ago I was very close to implement the different-layer-height-feature into Curaengine myself. I found at that time it would not be the hell of a work to do just on the engine level. But the whole communication with the GUI would have to be altered dramatically. But I don't know what the situation with today's code is.

[yellowshark 153]

I for one would welcome a similar implementation to that provided by S3D. Just allowing me to set layer ranges providing the ability to change layer height is all I really need - ideally plus changing those parameters one might like to change to support the increase/decrease to the volume of filament flowing through. Nothing automatic, just let me take the responsibility.

It is really the only thing that still makes me want to change to S3D - I would really benefit from it - although out of principle the lack of a demo version still prevents doing this!!! Not forgetting of course the outstanding Cura support provided by this Forum

[Labern 774]

It needs to have some sort of auto mode with the direction UM is heading.

I would like bridge detection where it increases the layer thickness on the first layer while bridging.

And Varislice.

Also the ability to manually increase the layer thickness in a set range.

[gmeardi 0]

It's great that... as I'm absolutely a newbie on 3DP (my very first UM3x is just less than one month old)... this topic has been considered interesting :-)))

And it's nice to read that "as for the variable layer height, it's something that is pretty high on our feature list, but due to some dragons in our architecture it will require more work than is should / would have".

Effectively I think that such a feature would give benefits in:

- faster detailed prints (using thicker layers only on simple surfaces)

- more robust prints (if I'm not wrong... just learning...).

Hope you'll kill the dragon in a reasonable time, Nallath! TKS!