0
$\begingroup$

I want to import STL files which I know to be in mm, but blender displays it in meters. I know that I can change the units in properties->scene, but this converts the the units (1m->1000mm), so it's no good.

There is a scale option when I import and I can rescale post import, but I am relectant to do this, since I don't want to multiply and divide large factors on stl files, as this tends to degrade precision from rounding errors.

I actually just want to change unit symbol with no change in the underlying numbers.

$\endgroup$
4
$\begingroup$

Choose unit scale that you like:

enter image description here

0.001 if you need to scale meters to millimeters.

$\endgroup$
6
  • $\begingroup$ This works. Thanks. But are you sure that this doesn't necessarily multiply and then divide by 1000. I'm going to 3D print some pretty big objects, so if even a small number of verticies are shifted slightly by floating precision errors it can cause various errors downsrteam. $\endgroup$ – DrDress Dec 1 '20 at 21:16
  • $\begingroup$ You should not worry about multiplying and dividing by even 100 or 1000 because if you do that for all the values in the file that are 32bit floats you will only change the exponent part of their representations saved in memory, not the actual number. This does not change precision. Google "32bit float" to see how they are stored. Also slicing, tool path generation and 3d printing as a physical process ruins precision way more than 32 bit floats ever get the chance. You definitely do not need to worry about that in this context. $\endgroup$ – Martynas Žiemys Dec 2 '20 at 7:39
  • $\begingroup$ Good point about floats. I thought that base 10 operations don't play nice with binary data. But the exponent part is of cause base 10. You are not correct about slicing though. If you try to slice a part where several faces meet in a single vertex, it is not a trivial matter to sort out which segment belongs to which polygon and floating error do contribute. And if you part has +100k facets, this become quite likely. Same goes if you want to run the part though other spatially dependent computation like simulation. $\endgroup$ – DrDress Dec 2 '20 at 8:16
  • $\begingroup$ You are talking about inaccuracies in the printing process, not the model. 32bits is adequate for very precise data in this context. You get around 7 digits of precision so if you are working with dimensions around 1 meter, you should still get meaningful precision of a few hundreds of nanometers(might need to scale the units for that). That is insanely small. 3d printing is a few orders of magnitude less accurate than that. Keeping in mind the way the floating point numbers are stored, I see no point in worrying about binary precision errors in this process too much. It's all good. $\endgroup$ – Martynas Žiemys Dec 2 '20 at 11:35
  • $\begingroup$ I know we are not supposed to discus in here, but I'm not talking about the printing process, since floating errors are typically below nm in size and play no part. I'm talking about about the algorithms used to convert 3D stl to voxels. If you have millions of verticies you can run into floating prescision errors. This can result in mistaking hols from parts or mismatching the slice point when constructing the 2D polygons and several others pitfalls. This is a real issue that we spend a lot of time on. $\endgroup$ – DrDress Dec 2 '20 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.