Number one has been a problem ever since binary floating-point was applied to storing decimal numbers … the workaround has historically been to pick a threshold value. I first ran into this problem in 1972 and, most recently, with SketchUp. Like you, I have posited a number of reasons why 0.001" was chosen instead of some other number, but I don’t know the answer for sure. Somewhere back along week one or so of developing SketchUp 0, this decision was made. Maybe it’s passed through so many hands that no one really knows the answer to this question anymore. 
I have a vague recollection of reading that the intrinsic Alchemy openGL settings has fixed upper and lower limits…
if one goes down so does the other and conversely…
when combined with the need to cater for the fractional notation desired by American Architects, the base unit was set to 1" and the lower limit was set within ‘construction’ norms for house building…
I also recall reading that Metric was ‘later’ shoe horned in primarily for the Japanese market…
john
I think you guys have hit on all the right points already in this discussion— SketchUp is like all CAD systems in that it handles floating point numbers with fixed precision. Practically speaking, SketchUp carries 16 significant digits— 12 in front of the decimal place, 4 after.
Internally, SketchUp uses ‘inches’ as its dimensional unit. Without taking on position on the metric vs. imperial system, technically this is really only a semantic difference. But the net result is that SketchUp can reliably represent dimensions in a range from thousands of an inch to thousands of miles. SketchUp was designed to support folks making things as small as furniture and as large as cities.
MCAD tools like Solidworks handle smaller objects better, but struggle with larger ones. GIS tools from ESRI handle even larger objects than cities (like ‘the world’), but struggle even more at small scales. Microchip CAD systems (like those from MentorGraphics) are capable of modeling at angstrom scales, but would struggle to model a toothbrush. All these systems suffer from the same basic problem, though all have set their precision thresholds in different places to accommodate the particular needs of their users. Pure DCC tools (like Maya or Blender) just dispense with named units entirely, operating essentially in a unitless cartesian space.
The floating point number representation is only part of the story, but it is enough to explain why you see merging/face closing problems with points smaller than .001" Essentially, SketchUp can’t tell the difference between points closer together than the lower precision threshold, and so you get unpredictable results due to rounding errors.
Since more people are making small parts in SketchUp today, primarily due to the growth in interest in 3D printing, they tend to hit the lower threshold more often than the upper threshold. Scaling the manually object while you’re modeling serves to move you away from the lower precision threshold and into the happier middle ground between extremes.
john
.
8 Likes
cheers john
john
Inside a scaled down component SketchUp seems to cope with dimensions smaller than 0.001" (< 0.00254mm) as long as there is a “normal” instance much larger than the one scaled down.
One can work inside one or the other. I’m not sure how this works out when exporting to *.stl for printing.
There doesn’t seem to be any problem with STLs. I created a scaled down 0.00001" x 0.00002" x 0.00003" component copy of a nominal 1" x 2" x 3" box. While it no longer displayed properly, I was able to select it and export it as an STL file:
solid test21
facet normal -1.0 0.0 0.0
outer loop
vertex 0.0 1.9999999999999995e-05 9.999999999999997e-06
vertex 0.0 0.0 0.0
vertex 0.0 0.0 9.999999999999997e-06
endloop
endfacet
facet normal -1.0 0.0 0.0
outer loop
vertex 0.0 0.0 0.0
vertex 0.0 1.9999999999999995e-05 9.999999999999997e-06
vertex 0.0 1.9999999999999995e-05 0.0
endloop
endfacet
facet normal 0.0 -1.0 0.0
outer loop
vertex 2.9999999999999987e-05 0.0 9.999999999999997e-06
vertex 0.0 0.0 0.0
vertex 2.9999999999999987e-05 0.0 0.0
endloop
endfacet
facet normal 0.0 -1.0 0.0
outer loop
vertex 0.0 0.0 0.0
vertex 2.9999999999999987e-05 0.0 9.999999999999997e-06
vertex 0.0 0.0 9.999999999999997e-06
endloop
endfacet
facet normal 1.0 0.0 0.0
outer loop
vertex 2.9999999999999987e-05 1.9999999999999995e-05 0.0
vertex 2.9999999999999987e-05 0.0 9.999999999999997e-06
vertex 2.9999999999999987e-05 0.0 0.0
endloop
endfacet
facet normal 1.0 0.0 0.0
outer loop
vertex 2.9999999999999987e-05 0.0 9.999999999999997e-06
vertex 2.9999999999999987e-05 1.9999999999999995e-05 0.0
vertex 2.9999999999999987e-05 1.9999999999999995e-05 9.999999999999997e-06
endloop
endfacet
facet normal 0.0 0.0 -1.0
outer loop
vertex 2.9999999999999987e-05 1.9999999999999995e-05 0.0
vertex 0.0 0.0 0.0
vertex 0.0 1.9999999999999995e-05 0.0
endloop
endfacet
facet normal 0.0 0.0 -1.0
outer loop
vertex 0.0 0.0 0.0
vertex 2.9999999999999987e-05 1.9999999999999995e-05 0.0
vertex 2.9999999999999987e-05 0.0 0.0
endloop
endfacet
facet normal 0.0 1.0 0.0
outer loop
vertex 0.0 1.9999999999999995e-05 9.999999999999997e-06
vertex 2.9999999999999987e-05 1.9999999999999995e-05 0.0
vertex 0.0 1.9999999999999995e-05 0.0
endloop
endfacet
facet normal 0.0 1.0 0.0
outer loop
vertex 2.9999999999999987e-05 1.9999999999999995e-05 0.0
vertex 0.0 1.9999999999999995e-05 9.999999999999997e-06
vertex 2.9999999999999987e-05 1.9999999999999995e-05 9.999999999999997e-06
endloop
endfacet
facet normal 0.0 0.0 1.0
outer loop
vertex 2.9999999999999987e-05 0.0 9.999999999999997e-06
vertex 0.0 1.9999999999999995e-05 9.999999999999997e-06
vertex 0.0 0.0 9.999999999999997e-06
endloop
endfacet
facet normal 0.0 0.0 1.0
outer loop
vertex 0.0 1.9999999999999995e-05 9.999999999999997e-06
vertex 2.9999999999999987e-05 0.0 9.999999999999997e-06
vertex 2.9999999999999987e-05 1.9999999999999995e-05 9.999999999999997e-06
endloop
endfacet
endsolid test21
The numbers get exported like they should.
1 Like
I consulted with David, our resident Computational Geometry expert and long-time member of SketchUp’s development team. He gave me the following answer:
Double precision numbers can accurately store ~16 decimal digits. To be safe, lets assume 15 digits. I.e. 999,999,999,999,999.
Since SketchUp requires accuracy to 1/1000”, SketchUp’s maximum dynamic range is +/-999,999,999,999.999 – say 1 trillion inches or 83,333,333,333 ft or 15,782,827.7 miles or ~½ the distance from the Earth to Mars, etc…
So in SketchUp you could…
Model the Sun.
Model the Earth.
Model the Moon.
Model the Earth and the Moon together.
but you could not…
Model the Sun and (Mercury or Venus or Earth…) together.
Model the solar system.
Model the milky way.
or model things smaller than 1/1000 inch.
Anything much larger than 15 million miles or smaller than 1/1000” WON’T WORK!
After reading this I have to play with the upper limit I think 
1 Like
The working size range of SU is badly skewed toward the gargantuan–worse than I had thought. Models of star-system proportions just don’t come along very often, whereas models of, say, fist-sized objects fail all the time. Even if these smaller models do not approach the lower size limit imposed by two points merging at a distance of .001", they still fail all the time because they have faces smaller than about 1mm in any dimension (that’s the number I’ve most often heard used for missing faces, some forty times larger than the point-failure size).
In practical terms, it’s hard to model typical mechanical engineering-sized objects because they have small faces below the size limit. This means that a huge number of manufactured objects simply can’t be modeled successfully in SU without using impromptu scaling or some other kludged workaround.
Since SU has such a wide dynamic range, why not just transpose the limits down (or the dimensional values up) by an order of magnitude or two, enabling it to model all reasonable subject matter at full size?
-Gully
3 Likes
There is also the practical upper limit imposed by OpenGL - clipping creeps in when your model reaches the size of a city block or two, and beyond that things look increasingly weird. It would be interesting to read an expert comment about what the actual limits are in this respect. Archicad and Revit documentation sets their practical upper limit at about 35 kilometers from the origin, if I remember right (the first uses OpenGL, the second DirectX).
Anssi
This explains a lot— Thank you.
Sometimes a Push/Pulled object has faces a few millionths of a unit out of plane, and when the original face is altered, SU doesn’t remake that face. (perhaps I have that backwards: after altering, does SU distort that plane?) Anyhow, if SU doesn’t work down below .001 of a unit, why does it judge planar to the millionth?
I heartily agree with Gully. A few orders of magnitude would still let us model the Earth, but also allow for common objects.
The tough thing to appreciate about precision in CAD systems is that computers deal only in discrete mathematical operations. Floating point numbers are only precise to a fixed number of decimal places, which is somewhat counterintuitive.
We could have built SketchUp to hide the internal units, or to treat them as purely abstract except at display time in the UI. That way you wouldn’t be troubled by the idea of "scaling up, scaling down’ that you have to do today to accommodate finer precision that thousandth of an inch. We didn’t do that for reasons that felt pretty reasonable at the time, especially given our vision for a product targeted at objects from furniture scale to city scale. That worked pretty well until folks started using SketchUp to scale large models (like cities) down to 3D printable scales.
In software, it is always possible to change things in the future, but this is one that is so ingrained into the basic object/interaction model for SketchUp that we wouldn’t do it quickly or casually.
john
.
1 Like