Pleeeease can we do away with Imperial under the hood!

I’m newly astounded at how Sketchup implements its units in imperial. I used to think it was simply annoying that the default setting was imperial, and relieved to have the metric templates option. Now that I’m diving into dynamic components, coding and hopefully one day becoming a developer, I am absolutely flabbergasted that internally Sketchup is using inches regardless of what the template setting is. ‘Backward’ is the only clean word that comes to mind.

I’ve got a long, long road of learning ahead of me. I’m an architect whose been using Sketchup for many years and constantly espousing it’s benefits to the Autodesk crowd. However regardless of chosen software, and as in every other industry, I can see I need to expand my skillset in order to deliver my services in very new ways. Having a ridiculous little imperial thorn embedded deep in the software really isn’t helpful, or acceptable. I suspect that once I start to get somewhere with my endeavours, I’ll be looking for new software. This makes me quite sad, because I do love Sketchup.

Please can we have a version that completely does away with this US-centric legacy? For sure, have templates and include imperial, but surely under the hood it should all be unit-less base-10, and therefore speak metric natively.

Ps. Wikipedia asserts that the US construction industry is one of the last bastions of imperial, the majority of other design and manufacturing in the US is metric behind the scenes. Time to modernise Sketchup too.


metric is so “inhuman”, we know about a foot and feet, got some myself

I figure we should go back to…
4 digits = 1 palm
3 palms = 1 span
2 spans = 1 cubic
4 cubics is about the height of a person

measures that reflect the human condition…who needs all these m&m’s :grinning:


The Imperial, as defined today, is, too, metric under the hood. An inch is a derivative unit defined as 25.4 millimeters, so it all goes back to the same lightwaves that define the meter. The “normal” inch or foot doesn’t exist by itself either as a physical object or as a reference to some other natural constants than the meter.


Hmmmm… 4,3,and 2, all convenient divisors of a 12 based system. :yum:


Are you really going to give up on SketchUp just because you don’t like the unit? I hate to think what you’d do when you have a difficult problem. I’m not a fan of imperial either but there probably should be one internal unit and it’s inches.

Converting between units is trivial in Ruby. There’s even methods provided to make it easier. In Dynamic Components using anything other than inches is messy, but not impossible.

It can’t be unit-less and metric!

1 Like

Actually, under the hood it is all binary! True base-10 representations require either special hardware (not standard in any PC or Mac that I know of) or software emulation, which is slow compared to the native binary.

No, I won’t really give up on Sketchup that easily. Thanks for calling me out on that.

I’m just shocked that the underlying software engineering assumes decimal inches, a very odd concept. Why does it need to assume a unit at all prior to appending a denomination for the human. I would have thought that all the internal calculations would just be done with a unit-less number. Why bludgeon a fractional measuring system into a decimal (decimal inches) and then re-decimasie it into a true decimal (metric) that has then probably lost a digit of precision along the way? All whilst not really needing a unit in the first place. It seems a very sloppy thing to do. Is this why no matter how careful i be whilst modelling, I eventually end up with an ~approximate dimension in a complex model with many nestings?

It seems like whoever decomposed the original algorithms, forgot about the idea of unit conversion and then sloppily implemented a conversion to metric later, ie. absent mindedly assuming inches are native, then we convert for metric. Rather than, a float being native, prior to display we convert it to the chosen unit, inches, mm, rods, cubits, whatever. Surely this avoids constantly doing the math twice if using metric, ie. most of the world’s users.

This is what exposed the horror to me: if I create a model of a cube in a metric template, 1000mm per side, and export it as an .obj, I get a cube with sides 39.370078 (= 1000 / 25.4)? The annoying thing about this is that an.obj doesn’t even have a unit (just a comment of intended units, and the Sketchup exporter still comments it as meters!). I’m guessing the solution is to model within an inches template and ignore the unit in order to get non-blugdeoned exports.

Yes, dynamic component complications is exactly what I’m worried about. I think I don’t yet understand the scaling of groups (they seem to have a private scale vs. a public scale? or at least that’s how it seems when having nested DCs). Should I be drafting all my DCs in an inches template whist ignoring the unit, and then when using them in a metric template, scale the outermost parent by 25.4 to get mm?


True. Where I’ve said ‘under the hood’ assume I’m talking ‘within the code’

True. And that is my point. The unit designation should come right at the very end, ie. display for the human. Within the code, surely they’re all just floats. Why assume decimal-inches?

I don’t think any precision is lost by this. Converting between base to and base 10 should lose as much precision and multiplying/dividing by 2,54 if I’m not mistaken.

However I have to say I was also chocked that SU used this obsolete units under the hood. As a plugin developer I don’t think much about it though. I normally think of a length as a distance in space, not as a number with some unit. In some situations, e.g. when you work with areas or volumes, you need to think about it though.

I haven’t used the .obj format but it saddens me ity is broken. If the exported file states it is in meters all length s should also have been converted to meters on export.

DC is a bit of a mess. I’ve never bothered to figure it out.

I don’t think it’s likely SU will separate number from unit internally because of how much would need to change. For plugin developers a native volume and area class could perhaps help but I don’t know.


As an 20+ years naturalized biped living in the States, take a chill pill. Architecture and construction are all about imperial here, so entrenched for generations permeating everything, from construction materials, to interior design and furniture.

Nominal lumber, sheets reflects that: 2x4, 4x8, etc. Framing a house has imperial written all over: spacing of studs and trusses, expected room dimensions, floor heights, windows, etc. Building codes just the same. Appliances and furniture are designed to enter a house thru 3-0 door, required by code. Proportions and ratios in design are based on this. It’s everywhere and it’s not the decision of one person to keep traditions alive. It’s the simple way of thinking over here.

As an outsider, just learn it and get over it. Standards are great, but is it worth flattening the world in every way!


Everything you say applies to a handful of counties only. The world is bigger than that.


There are other countries besides Liberia, Myanmar and the USA.

Besides, the imperial measurement system as we know it today is not historical but dates to the year 1959. In old times, every locality had its own set of weights and measures that might have similar names but differed a lot in practice. After the French revolution France invented the meter and its use started to spread. It was the first ever widely accepted standard of measurement, based first on a part of the circumference of the Earth but nowadays on lightwaves. Other localities kept on using their local varieties of the foot etc. until 1959, when the then imperial-using countries agreed upon a standard yard that fixed the inch at exactly 25.4 millimeters.


I was taught ‘both’ growing up in Australia during ‘metrification’…

this schooling came in handy when I moved to the UK more than 30yrs ago…

I have used both almost daily since and tend to think in both…

I love that SU can cope with my typing 50,6" for a rectangle in my mm template…

The issue isn’t the ‘internal’ unit, but how some of the dialogs and extensions are badly implemented to not handle the Users set units…

the only relevant statistic would be the number of daily unique activations of SU using metric templates…

what different countries ‘use’ is a moot point…



Here in Canada we switched over from imperial measure to metric back in 1970’s. The process took about 10 years.

The construction industry is influenced greatly by availability of materials AKA the trade between USA and Canada. So we still have 2X4’s and 4X8 sheets etc. I tend to switch between both systems and also I think in both. If I’m working on a house layout then I use imperial fractional inches. However when I want to do cabinets or stairs then I switch over to mm.

I agree with John, internal units aren’t as important as how plugins seamlessly (or not) deal with them.

I believe software like Sketchup that originally grew up in USA store data in imperial measure. So it isn’t surprising that under the hood that Sketchup uses decimal inches. So when I want to display a length value in the ruby console I use a variation of the following: puts “Length: #{len.to_l}”. Although I do work in mm - any calculation contains the native value in inches. The .to_l translates the display thus honoring the users Units.

My own plugins can use inches or mm. However in my CutMaster CNC database (C++) units are store in decimal mm. You can flip a switch to display in inches - but - since the majority of cabinet hardware uses the 32 mm standard I chose mm as my internal units. I even have a setting so you can do the majority of your work in inches but do configuration of hardware (drilling and grooving) in mm.

I spent a fair amount of time with Dynamic Components but settled on Ruby since it does not have all the constraints and limitations of DC. However I did code dictionary attributes for doors and drawers so you can use the Dynamic Components interact tool. That is all that I chose to incorporate from DC into my plugins.


I was living in Canada at the time that they began the long process of phasing out imperial. As stressful as I thought it would ultimately be, I made the transition without hangup or hardship.
I’ve been living in Michigan (no laughing please) since '99 and have no issue switching between imperial and metric as needed.

I’m sure that if or when the United States makes the same transition to metric, so will the great majority of products that are produced in this country…wishing for anything else is a waste of your time and stress level.

For some reason (no laughing please) Michigan was where many migrating Finns settled to in the 1800s and early 1900s.

1 Like

I’m sure they appreciated the balmy weather :sunglasses:

The point of this post was to talk about a framework that is units-agnostic. I’m not suggesting taking away anybodies preferred measuring system. The unit that one uses to annotate a drawing for other humans is still completely open. Many of you are talking about your “real-world” existential experiences. This is not about that, its about the machinations of internal code.

I assume the reason Sketchup has an internally denominated unit is so that no matter where an imported model comes from, it lands in a new model at the correct relative size. For example Warehouse downloads. This seems a little unusual in the 3d world, a bit hand-holdy, but it does make sense.

My point is, surely the choice of unit should be for the user to decide, and declared in the .skp file header, not deep down in the software code that generates the model in the first place. This way, all the files can still play together and land correctly scaled. If you use multiple unit types (poor Canadians) then this will work just fine. Or, if you use a single unit only, it will also work just fine, whatever the unit. In fact, the end user notices no difference from the current workflow whatsoever. It just means that when writing code that manipulates a dataset, there’s no need to constantly check and translate from system A to system B. I guess you could say I’m suggesting the user interface would do any unit translation needed.

Now, Sketchup is presented as a clean, moddable, unencumbered tool for making things. A digital green field. Sketchup is awesome. Through its intentional lack of tools, it encourages expanding the functionality of the software. Tools to make better tools. Sketchup would not be what it is today without the warehouse models and add-on developers. Sketchup however, forces expert users and developers to constantly keep tabs on working with inches regardless of their location in the world. This is not freedom, equality, and liberty for all.

Being a complete noob, the thing that I’m considering learning over the next 10 years, is akin to sending a probe to Mars. I don’t want my probe to crash because of a single bad unit declaration (yes this really happened, look it up, Mars Climate Orbiter). Because I have the luxury of not being invested, I can look around for the most convincing, confidence inspiring environment. This might seem overly picky, glass jawed perhaps, but from what I’m taught in Computing Methodology CS106A (Thankyou Mehran Sahami & Stanford’s free online lecture series), the best time to make for clean algorithms, is right at the start. My impression thus far from tinkering, and from those who have engaged here with the real issue and are clearly years ahead of me and perhaps more invested, is that Dynamic Components are easily compromised outside of inches. The next step deeper would be Ruby, and I’d still need to convert. Next would be the C API to maniputlate .skp’s outside of Sketchup, oh now I’ve got a bigger mountain to climb AND it’s all still in inches. One dimension is easy enough, its the areas and volumes and all the permutations of interactions that I’m more wary of. One or two components should be doable, but I’m contemplating much more complex models than that.

All this leads me to thinking I should invest my time outside of Sketchup. Since Sketchup is not Unit-agnostic, the better foundation for my project is Sketchup-agnostic. Therefore, I’m still free to use Sketchup to execute the process of turning a 3d model into a set of black and white contract documents that sometimes millions of dollars are riding on. Its great for presentations, page layout, and quick explorations of ideas. However, this internal inches issue, my gut seems to have decided now, is enough to send me to develop externally, where whatever variables I declare can be just another floating point number. The units can be decided at the end use. The brains of my problem will be safe from the unnecessary complications of Sketchup’s Imperial lords.

This no doubt makes my challenge much broader, and that’s probably a good thing.

1 Like

I’ll even add a third dimension to the discussion. I’m designing a house and would like to work in inches under for any dimension under 8’.

I’m bilingual and actually prefer metric for precision but when you trying to center a 32" appliance in a 7’ 8 3/4" counter top I end up doing some number scratching off to the side and then try to remember it all as I type it into the drawing.

I’d really like for a simple keystroke combination to set the dimension units and so forth.

It’s not about what’s “best” or who is “right” it’s about GETTING THE DRAWING DONE without losing our humanity.