Thanks everyone for the replies. I realize now that STL's don't have units, and it is the slicer program for my 3D printer that is interpreting them as mm. I will consider just scaling my entire object to metric as some have suggested. Thanks again. Kevin T On Mon, May 20, 2019 at 9:38 AM A. Craig West <acraigwest@gmail.com> wrote: > I find that it's less of an issue than you might expect. At least in my > use case for imperial units, cut lumber and fasteners mostly, the > dimensions are nominal and not actually that close. A 2x2 board, for > example, is about 1.5 inches by 1.5 inches, with a fairly high variability. > Once you account for that, it's just as easy to just use the metric > dimensions > > On Mon, 20 May 2019, 09:14 William Adams, <will.adams@frycomm.com> wrote: > >> I was trying to work through this a while back --- wanted to provide a >> unit setting in the customizer and it was rather problematic. >> >> On 19.05.2019 18:33, Kevin Toppenberg wrote: >> > function inch(i) = 25.4*i; >> > cube([inch(1), inch(1), inch(1)]); >> >> That would probably be better than what I achieved, but the problem was >> that in addition to dimensions of the project itself, tooling needed to be >> scaled as well. >> >> I'm currently leaving OpenSCAD to the default of millimeters and working >> on a front-end for it which will handle units more gracefully. >> >> William >> >> >> On Sun, May 19, 2019 at 9:17 PM MichaelAtOz <oz.at.michael@gmail.com> >> wrote: >> >>> leebc wrote >>> > I have been finding, however, that 1 unit in the game world, is >>> > aproximately 1 meter, so I change my scale factor to >>> inch_to_mm=2.54/100; >>> > this was very helpful, and I'm glad I chose to scale everything. >>> >>> That may be setting you up or trouble. >>> >>> You 24"/609.6mm top is the stored as 0.6096, and smaller details, say >>> screw >>> hole for draw handle 1/8"/3.175mm is stored as 0.003175. >>> OpenSCAD gets a bit flaky down in such small number scales, with floating >>> point conversion losing accuracy. >>> >>> >>> >>> ----- >>> Admin - email* me if you need anything, or if I've done something >>> stupid... >>> >>> * click on my MichaelAtOz label, there is a link to email me. >>> >>> Unless specifically shown otherwise above, my contribution is in the >>> Public Domain; to the extent possible under law, I have waived all >>> copyright and related or neighbouring rights to this work. Obviously >>> inclusion of works of previous authors is not included in the above. >>> >>> The TPP is no simple “trade agreement.” Fight it! >>> http://www.ourfairdeal.org/ time is running out! >>> -- >>> Sent from: http://forum.openscad.org/ >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

On Sun, 19 May 2019 12:33:43 -0400 Kevin Toppenberg <kdtop3@gmail.com> wrote: > I know that OpenScad doesn't formally have units. But if I make an object: > > cube([10,10,10]); > > and export it to STL and print it on a 3D printer, it comes out 10x10x10 mm. That depends entirely on your slicer and printer. Most let you change the unit to anything you want (within reason). Alan

> OpenSCAD gets a bit flaky down in such small number scales, with floating > point conversion losing accuracy. > Double precision (64-bit) floating point has 53 bits (about 16 decimal digits) in the significand, and loses accuracy when adding a small number to a large number (or subtracting). However, this loss of accuracy is essentially independent of the absolute size of the number, at least until you get down to 10^-292 or so. So, unless you're doing astronomy or microscopy, multiplying or dividing all numbers by 25.4 won't have any noticeable effect on accuracy. Frank

The problem is STL uses floats, so when converting from double distinct points can merge and create degenerate triangles and self intersections. Also OpenSCAD snaps to a grid coarser than floats and the same problems happen there. On Mon, 20 May 2019 at 19:44, Frank van der Hulst <drifter.frank@gmail.com> wrote: > > OpenSCAD gets a bit flaky down in such small number scales, with floating >> point conversion losing accuracy. >> > > Double precision (64-bit) floating point has 53 bits (about 16 decimal > digits) in the significand, and loses accuracy when adding a small number > to a large number (or subtracting). However, this loss of accuracy is > essentially independent of the absolute size of the number, at least until > you get down to 10^-292 or so. So, unless you're doing astronomy or > microscopy, multiplying or dividing all numbers by 25.4 won't have any > noticeable effect on accuracy. > > Frank > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >