Slicing report

[alranel]

There are a few situations where Slic3r produces a correct result but still it doesn't match the user's expectations. While it is true that the user needs to check their configuration to adjust the result to the desired goal, this apparent unpredictability (I'm citing an user's words) produces bad user experience and is wrongly seen as buggy behavior.

While lack of bugs doesn't allow to blame Slic3r, I still think some effort is needed to restore some DWIM. User errors are still worth to consider from a software designer's point of view.

Some examples:

• Slic3r warns user about non-manifold models, but still many users ignore that warning and click "OK". Then they see some repeated layers (the usual repair strategy) and think Slic3r is buggy.
• When a model contains thin walls (thinner than twice the extrusion width) Slic3r has to collapse them to a single trace. This often produce dimensional errors (for example, a 1.37mm wall doesn't allow two 0.8mm traces, but still there's no way a 0.5mm nozzle can make a single trace that thick). Users think this is a bug, while they would just need to adjust the extrusion width setting.
• In some cases, thin features are actually completely removed. Think of a 1mm round column, which is impossible to print with a 0.8mm extrusion width. User thinks Slic3r just forgot about that part.

I think the warning for the first problem could be turned into a dialog asking "Continue?" with Yes and No buttons, so that the user is more aware of what's written there.

A general fix could be a (short) textual slicing report where Slic3r notes some warnings about the slicing job.

[nophead]

for example, a 1.37mm wall doesn't allow two 0.8mm traces, but still there's no way a 0.5mm nozzle can make a single trace that thick

Bad example because a 0.5mm nozzle can make two 0.685 traces as long as the layer height is not too small.

On 15 May 2013 18:19, Alessandro Ranellucci notifications@github.comwrote:

There are a few situations where Slic3r produces a correct result but still it doesn't match the user's expectations. While it is true that the user needs to check its configuration to adjust the result to his desired goal, this apparent unpredictability (I'm citing an user's words) produces bad user experience and is wrongly seen as buggy behavior.

While lack of bugs doesn't allow to blame Slic3r, I still think some effort is needed to restore some DWIM. User errors are still worth to consider from a software designer's point of view.

Some examples:

-

Slic3r warns user about non-manifold models, but still many users ignore that warning and click "OK". Then they see some repeated layers (the usual repair strategy) and think Slic3r is buggy.

When a model contains thin walls (thinner than twice the extrusion width) Slic3r has to collapse them to a single trace. This often produce dimensional errors (for example, a 1.37mm wall doesn't allow two 0.8mm traces, but still there's no way a 0.5mm nozzle can make a single trace that thick). Users think this is a bug.

In some cases, thin features are actually completely removed. Think of a 1mm round column, which is impossible to print with a 0.8mm extrusion width. User thinks Slic3r just forgot about that part.

I think the warning for the first problem could be turned into a dialog asking "Continue?" with Yes and No buttons, so that the user is more aware of what's written there.

A general fix for both could be a (short) textual slicing report where Slic3r notes some warnings about the slicing job.

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1173 .

[alranel]

Example is correct because changing extrusion width requires action from user... which is my point.

[simonkuehling]

first off all a quick question for my own understanding: Would it be possible for slic3r to dynamically adjust extrusion width for thin features (less than 2x configured width) to keep dimensional accuracy of those walls down to the minimal extrusion width for the current layer-height/nozzle-dia ratio? I mean, could this be done somehow algorithmically?

Now to the main topic: I think the proposed way of handling these misinterpretations of error correction is exactly the way to go. It is really desirable to have software that does its job without complaining (being able to cope with defective models and such) - but at the same time it is extremely important to keep reporting about intentional deviation from (user-)expected results. If the user is aware of defects in the model and intentionally selects "continue anyway! (i'll try my best)" - and finally gets a report on where those repairs kicked in BEFORE printing, one is able to inspect the gcode and decide if it is still usable or not.

Regarding gcode inspection: A visual inspection of the generated tool paths directly integrated into the slicing software is still a highly interesting feature in my opinion - especially now that more and more of the printers get stand-alone capabilities (e.g. printing from SD or RasPi) without fully fledged graphical host software for this task. You usually want to check the slicing result directly after slicing anyway - to determine if the chosen parameters work well for the object or if further adjustments are necessary (like infill density or orientation and such...). a 3D preview option would be cool - but a pure 2D layer inspection (like pronterface&co) is already highly usable and informative.

[alranel]

@simonkuehling, to answer your first question I can say: yes, it's possible. And @mesheldrake has been doing some precious work for it, but it's not ready yet and we really don't know how long will it take.

Also, thank you for your thoughts about graphical preview. I keep asking myself what a good strategy would be for that. I think 3D would be nice for input files, with some tools like rotate/scale/mirror/cut. But 2D is still the best option for inspecting G-code. Doing that inside Slic3r also means that we can access lots of information that is lost in the G-code. For example we could overlay a solid color showing the original object slice. Do you have any idea about this? Also, what kind of interactivity would be nice at that stage? (i.e. change bridge directions etc.) I'm trying hard to separate "cool" features from useful features. I really want to make useful things. :)

[simonkuehling]

@alexrj, that's exciting - nice to know that you already have this on the radar.

I generally agree that 3D is the best choice for preview purposes ("plating"/scaling/etc) since it is the most intuitive way to work with 3D models - and quite some information gets lost in 2D view (like arranging an object with thin body/base that increases dramatically in diameter to the top - in 2D projection view it is hard to determine if there is space left to add smaller objects around the base that do not touch the big one) Also, i had similar thoughts on available data that gets lost in the final gcode file - in slic3r you can still use parameters like extrusion width to visualize a realistic outline of the extrusions and not just the general paths (=center lines). As an experienced user i am quite happy with 2D gcode inspection - and suggest to always also offer a per-layer 2D view. A great use of 3D visualisation though (again, possibly including a variety of additional information from the slicing process - like extrusion width for realistic volumetric representation) could be that users can more easily compare the 3D source model to the volumteric gcode representation to identify regions that lost detail for instance (clipped thin features or fine textures on the surface that are not well represented by the selected layer height). Another great use is for development purposes of course - filing comprehensive bug reports without the need for other visualization tools (repetier host...yagv...). Holes in the printed surface due to missing extra perimeters are one case that isn't easily traceable in 2D layer view - or evaluating if (internal) break-away support is accessible through existent holes of the model.

[simonkuehling]

@alexrj - editing bridge direction definitely adds to the "useful" side (and from the enthusiast's perspective it is also abolutely COOL ;-) 3D printing really shines when it comes to shapes and geometry that don't care about squareness or the like - so determining the best bridging angle sometimes isn't detectable automatically where only the user knows the final use of the printed object. Nonetheless this is also more of a "pro" feature that depends on quite some experience and a solid understanding of the gcode-generation concept to put to good use.

[cakeller98]

Yup - visualization of the model, the gcode, and often even more important would be the non-printable features/regions! that will be huge in getting rid of the the cries for help - because it will allow people to see what's going wrong in a visual way, rather than trying to decipher cryptic and often overly vague/general dialogs - sorry non-manifold near point what? .... uh... there's 100,000 polygons and I didn't make them they're just rendered out and that point is supposed to mena something to me? no... but a picture would.

another thing I really think will help is a single-layer preview... in other words - show me what a setting does on a manageable small, single layer, in real time... allow me to disable it if it's a really complex part and slows things down. but really - when learning if you have a visual cue how something works - you don't have to ASK.

sure some settings won't really show/update anything in the preview, and I dont' have a great idea for that (all of them seem too complicated) but real time visualization of gcode generation will help immensely. (don't get too caught up on 100% final GCODE just the idea that if I change this setting, I should see what?)

:)

[smartroad]

If you had a 2D (or even 3D) preview, it would be useful for it to mark where the errors have been found. At the moment you get a cryptic "Warning: the input file contains a hole near edge X Y Z - X Y Z.....". Having it highlighted on a preview would be much easier to locate.

Maybe even change the warning to something like:

Ooops! There appears to be a problem with your file. I can try to repair it for you automatically (however I can only guess so check the result!) or click the advanced button for more information to fix it yourself.

Then give the options Advanced, Fix for me, Cancel - where Advanced could show the more cryptic information.

[jfpion]

for the previsualisation a great faeture could be to mix the 3D view ( as repetier) with a 3 view projection cut XYZ plan (with movable cutting plane. on the 3 view cuts it woud be great to be able to zoom to see the actual layer to be able to see the probable effet of the layer width and hight on the overhang for exemple.

for the thin wall may be an option saying "minimum perimeters" could be useful setting the minimum size of a thin wall indépendantly of the STL (leaving the user to deal with the geometrical deviation he ask for). anyway keeping 1 continuous track is the minimum, for now the thin wall sometime look like eated by moth...

it could be useful too to be informed befor slicing of the width of the layer before runing the slicing to be able to make improvement before to save time

thank you

[ghost]

I'd actually like something as simple as a warning that says "Your current slic3r settings allow for a minimum wall thickness of XXX mm. Your model has at least one wall that needs to be YYY mm thick. Would you like to continue the print, knowing that the wall thickness will be wrong, or abort, to let you redesign your part?"

If you've got a 3D model viewer, then the next step would be to highlight the model with green for regions where tolerances will be well-met, orange with tolerances that are off by 0.1mm or so, and red for anything more.

[traverseda]

Then they see some repeated layers (the usual repair strategy)

I'd guessed that this was the usual repair strategy, but only from running my head up against it repeatedly. Simply explicitly mentioning "you may see some repeated layers or other artifacts" would be a great help in figuring out what's actually wrong. The particular phrasing initially lead me to believe it was sort of an all or nothing the print worked or you're going to see spaghetti. That's obviously not a sane expectation, but more explicitly saying what slic3r is going to do would be nice.

[cakeller98]

The information is too complicated to try and explain with words what's not working. give us pictures.... if there's a layer that didn't slice properly, fine give a message, AND a picture of the layer... if you have info on the location, put a big red circle in that location around the error.

This idea of trying to come up with phrasing that makes sense on something like this - where the user rarely fully understands the details of what was being sliced in the first place - is ridiculous.

If it's a warning about continuing, fine, then ask the user if they want an report about the error at "X Y Z" after slicing is completed. Then when slicing completes, show a 2d image of the layers in question with the circle in the region of the error. A picture is worth way way more than 1000 words when it's referencing a concept that is hard enough to understand when you can see it, but without the picture...sheesh.

Just think about how much more clear it is for a user if they were to look a picture of a slice that has a circle around a non-manifold vertex that they could zoom in to... and the errors resultant in that slice. It would go a long way to helping them understand what's wrong and how to fix it.

and if there's an overlap or something that could be fixed manually... maybe just for that slice, maybe then the user could edit that slice. it's not an uncommon practice in software. e.g. Pro/E's stl export every once in a while used to fail on a particular type of surface, and it would allow you to go in and add points that were difficult for the automated process to do without over-meshing the entire STL...it worked well 90% of that <0.01% of the time that an STL output would fail.

Any processor that deals with 3D objects really needs a 3D viewer... period.

And the best interface for the user will have good robust automated fixes for common errors, and when those fail, a good set of manual tools to fix errors.

I can't tell you how annoying it is to have to re-slice 1/2 a dozen times because slic3r decided to leave out the infill on a single layer because the open area just happened to be an exact error producing width... changing the perimeter width by 0.005mm and the object sliced fine. but reslicing something that takes a minute or 2, more than once... SUCKS. But imagine if that hole could be outlined in a 2D view, and in-filled manually! now that'd be rockin' and it's something that commercial software does.

Obviously all of that would be a lot of work - but @alexrj has always been about doing it "right" not hacking together things that just work ok for now. So hopefully this thread gets filtered down to a goal that is perhaps lofty, but also has baby steps to get there, that include things like others have suggested, but in a way that leads us toward the ultimate goal.

thanks :)

[whosawhatsis]

Another useful feature for 3d STL/gcode and 2d gcode views would be color-coding to indicate overhang angles. This is something I haven't seen anyone implement, but it shouldn't be particularly difficult, especially when done in the slicer. If the model turned red where there were overhangs exceeding 45 degrees (or some user-defined threshold), it would be easy to look for large red areas that will need support, or decide to leave support off if they are all small and scattered.

It would also be really cool to color the whole model with overhang angles. For example, flat top surfaces might be blue, vertical walls green, bridges red, and everything in between shaded accordingly. For STLs, this would be based on the orientation of each facet (could probably be implemented with a little hacking on a basic shader), and for gcode, it would compare to the previous layer, taking layer height into account.

[alranel]

Thank you everybody for writing your ideas here. All of your points of view are very interesting.

[traverseda]

@whosawhatsis Actually, blender added that in their new 3D printing extensions. it's under mesh analysis. http://wiki.blender.org/index.php/Doc:2.6/Manual/Modeling/Meshes , along with a bunch of other useful visualizations.

[alranel]

The overhang threshold is actually f(extrusion width, layer height). And I think it depends on nozzle diameter too (doing some experiments for that). Slic3r allows to use different values for all of these three things in two adjacent layers. My new support material implementation (new-support2 branch) takes this variability into account. But this means there's no single overhang angle for a whole model, and an accurate visualization must first slice the object...

[whosawhatsis]

...which is why I mentioned that this type of rendering is best done in the slicer, rather than in a modeling program or a separate gcode visualizer. Full slicing should not be necessary to get this information, and the visualizer's code would have access to the slicing settings and could run a subset of the slicing code to get the information needed for analyzing overhangs.

Yes, nozzle size is obviously a factor. Consider if a thread is offset 2/3 of a thread width from the previous layer, if the thread width is the same as the nozzle diameter and the layer height is small by comparison, it should stick (at least for a few layers), but if the thread width is 1/3 of the nozzle diameter, the extrusion will miss the previous one entirely. An extreme example, but they are usually best for illustrating points. BTW, I wrote an openscad script to visualize various layer artifacts with various layer heights and thread widths (mostly things like wobble and inconsistencies in layer height/extrusion characteristics due to mechanical issues, but I also added visualization of overhangs), https://github.com/whosawhatsis/layer-illustration.

[alranel]

One more case is Infill only where needed. People might select it and forget they have it on, then complain because they see missing infill.

[JoshMcCullough]

I think making the "manifold" message more clear such as "listen, we're going to have to add extra layers...if you continue..." etc. would help, just make it clear - "manifold" may mean nothing to a lot of users.

And in general, a slicing report would be great with a list of warnings such as "while slicing layer X, a thin wall found which is too small to ... the end result will be a thin wall that is Ymm instead of Zmm thick" or similar. And then perhaps give an explanation of how to fix this issue (change extrusion width, get a smaller nozzle, etc.).

The more information you can concisely present to the user, the better Slic3r is protected against false bugs (which I've been guilty of reporting, myself).

[o-jasper]

About displaying. It would be good for slicers and printer-managers all round if development of these can somehow be shared? It would also allow for the potential for the interface to be somewhat similar between them. Cura has a good visualization, it has color coding of overhang. (But it is in python)

Of course there is the question of the default viewing method, surely having a few options is better. For instance if you have a 3d gcode view, you look at an angle, probably a button to look from straight up ortho is good.

grep 'G1 ' something.gcode | tr X ' ' | tr Y ' ' | tr Z ' ' | grep 'G1 ' | tr X ' ' | tr Y ' ' | tr Z ' ' | gnuplot -p -e "splot '-' using 2:3:0 with dots .. That kind of user, maybe he wants the positions stdout or something. (Or maybe feed the positions and have gcode from that) I am not sure if that falls into this tool though, just thought i'd mention it.

About user mistakes/forgettings. Basically i think what would be good is to add a 'start print' tab that contains all changes over the current default settings, plus warnings, and at the end you go there.(If something is wrong in particular the tab could go red too?)

It could also be done a little differently, i mean the above is essentially a difference between the default and the changed settings. So it might be useful to have it display them as sequence. For instance with a vertical bar indicating it is a new 'level'. For instance the first one would say the ~/.slic3r.cfg, then --loaded settings in their order, and finally gui-set values.

[ryanbnl]

Would it be possible to visually display the difference between the expected and actual model, with a toggle so they can easily be compared? I'm thinking of something along the lines of the travel model shown in Rep. Host. Then warn the user that their model can't be printed perfectly on their hardware, and that they can see the 'fixed' model and compare it to the design.......