0.9.8 crashes on too small stls

[AxTheB]

Importing STL with less than 1mm across fails with: Can't call method "regions" on an undefined value at /home/ax/src/Slic3r/lib/Slic3r/Print/Object.pm line 541.

which makes problems, as some designers use 1 in stl as meters not milimeters

Test object: scale([0.2,0.2,0.2]) cylinder(r=1, h=1);

[mesheldrake]

Here's the model described above: http://sheldrake.net/bag/tiny_tiny_pentagon_prism.stl

The error or crash should be avoided, but then there's the question of whether to support models with less than ideal choices for dimensions. It's a quirk if a designer is targeting the mm scale, but publishing in meter units. Or maybe these designers are actually designing meter-scale things. Either way, the user of those published designs needs to scale to dimensions appropriate for the target printed model size.

@alexrj - maybe there should be a warming for too-small (and too-large?) models, advising users to scale their model before bringing it into Slic3r.

[AxTheB]

Of course, support them. I got stls from many people to print, and many of them are in meters. It would be fine if I could print them without scaling in another program. Remember, there is scale button in slicer

[kefir-]

If someone works on pushing the limits for smaller and more detailed prints, it would be a shame if they at some point hit an arbitrary limit in the software saying "no, that's too small".

[mesheldrake]

@kefir - You're right that would be a shame. But here we're dealing with a model that's less than a cubic mm. And limit-pushers will just use mm as a stand-in for nm, or parsecs, and write a post-processing script.

@AxTheB - Maybe that's a reasonable use case - designers, or students, or CAD novices work up a design for a small object, using meters for units, and then they take that to someone else who is responsible for running the 3d printer. I would send them away for the poor choice of units, but you're a nice accommodating guy, and you'll accept a file in meters.

Slic3r, and the whole RepRap realm, take the mm scale for granted, so sometimes things tend to get hard-coded based on mm. G code is in mm (or inches!). All the GUI dimensions are mm. The key printer part dimensions are in mm. So it's not obvious to me that Slic3r should support mm-scale models expressed in meters. But it's worth considering. @alexrj can make the call on this.

[amaurer3210]

@mesheldrake likewise the problem exists for the millions of us who live where inches are in common use. Its one thing to ask a student to simply "use mm", but converting large extant assemblies to mm is often not feasible.

In prior versions it was a simple task to scale inch models by 2540% in Slic3r.

Regardless of your philosophical position on the matter, at present the behavior is inscrutable; at the very least some output explaining the failure to load the model seems in order.

[mesheldrake]

@amaurer3210 You're right about present behavior. There's a crash if the thing is too small and has a skirt. Without a skirt it's just too small to see, and may get simplified to a single line, which won't recover the proper shape when scaled up.

That's why I proposed some changes to @alexrj int the 929-too-small-models branch.

I am of the millions of us who grew up in inch increments, and think natively in imperial units. My reservation here isn't about inch vs mm but choice of scale of units. If the dimensions of a 2 inch part are given in yards, that's already inconvenient, and the mm-meter scale difference shifts that decimal point another place to the left. This can start to degrade the precision of certain calculations when you have a fixed number of significant digits centered, in a sense, on an inch or mm scale assumption.

[alranel]

@mesheldrake, I merged your branch but I only grabbed the changes to Plater.pm. Now it's possible to import small files and scale them until they match the required size. I think that warnings about too small files (and too large files) should be handled in GUI and not included in the slicing part.

Thanks to everybody for feedback and discussion.