I simply draw a temporary edge and use midpoint snap. I can’t remember when I last manually calculated any numbers for drawing itself in SketchUp.
@ChrisG I know it’s more conventional for modelers and file format to declare the unit in the file header but I think it’s too late to refactor SketchUp for this. Even as as a plugin developer from a part of the word where inches are solely used to measure screen sizes I don’t have much problem with SketchUp’s internal inches. The only time you really have to think of it is when you square a length or add lengths and floats. In most cases you don’t have to think of how lengths are expressed internally; the Length class nicely formats output and accepts input in various units.
Dynamic Components is a quite old and very unconventionally designed extension. It modifies SketchUp’s API’s Ruby classes which is a huge no-no and would not be accepted into the Extension Warehouse if submitted today. It also handles units very oddly for being a Sketchup plugin. Instead of relying on built in API methods to parse user input into Length objects, store those Lengths internally, and use built in API methods to format output to the user, it treats input as raw numbers and has 2 hardcoded units users can chose between. Typically extensions handles units just as SketchuUp’s native tools does and do not in any way expose the internal units to the user.
I would advise you to skip Dynamic Components and jump directly to Ruby if you don’t want to develop for SketchUp and not pick up any bad habits.
Looks like you are probably headed on over to FreeCAD. They decided (being mostly non-US developers,) to go with an internal unit of mm. To each his own. They are also “brainstorming” adding a Unit Manager that would allow moving back and forth between different unit systems (and creating historical / custom units definitions.) Ie, part of a project in standard SI, and a sub-part in say, some local ancient Chinese unit system.
One of the most frustrating file specification that I ever had the pleasure to work with was ESRI Shape Files. It was truly unit agnostic although we in the industry called it Unknown units. The problem was users could store pretty much any spatial data they wanted to in the file. Essentially spatial data could be transformed from one GIS projection to another and then stored that way. Unfortunately every time the data was transformed error factors were introduced. Additionally - some data - once transformed could not be transformed back.
We ended up storing all of our data in lat lon WGS 84. This provided the most data flexibility with the least amount of error. The main reason ESRI gave for unit less data storage goes back to the early days of computing. If data could be stored already projected then additional data transforms were not necessary and GIS systems would benefit from the increased overall speed. However in this day and age the transforms are virtually instant.
In my experience all data has some sort of unit whether specified or not. For example North American manufactured vehicles follow the SAE (society of Automotive Engineers) and yes - sometimes the units of measure are imperial (J1708 - J1587). And sometimes they are metric (J1939 etc.)
Personally I don’t have issues with having a known internal units for data. I would have issues if the warehouse had millions of files with unknown units.
calculating internally with the smallest unit available does surely make sense for avoiding rounding errors of floats required for e.g. geometrical dimensions in a fraction of an inch, e.g.:
• internal Unit ‘Millimeter’ : 1 mm = 1 unit
• internal Unit ‘Inch’ : 1 mm = 0.0393700787401575 unit
But with a kernel historically grown in inches every transformation to another unit would be surely lots of effort and pretty error-prone.
Thanks, I’ll check out FreeCAD. I’m not above admitting that yes, if sketchup were working in mm internally I wouldn’t have a problem at all. Being at the beginning of my learning curve comes with a lot of freedom. Currently the most attractive option seems to be learn C# and Unity - such a wealth of support material, and the sky is the limit for project complexity. I’ll still use SU for bashing out basic blocks and exporting them as .obj from an inches template (and changing the file header comment from inches to mm).
I agree. I feel that once the model gets complex, there might be 10 or so layers of nesting. Thats alot of converting back and forth, and being an architect, I really hate it when i see the ~prefix on a measurement, let alone debugging to find out where I’ve messed up the units : )
I would bet there would not be even so much as an imperial spanner set at Tesla. It’s all about looking forward rather than back.
You must be a surveyor. Yes, I remember trying to get GIS files to play nicely with ACAD back in the day. Thats the extreme example - measuring very large distances with super accurate data. I certainly wouldn’t want to be doing that in inches : )
You have a fair amount of control regarding if and when SketchUp displays approximated (“~”) dimension values. This has nothing whatsoever to do with the units used internally to hold coordinate values (speaking as a 35-year professional software developer who has written plenty of graphics and geometry-processing code).
Firstly, you have control of the coordinate values (positions, lengths, etc.) that are encoded into the model, to about a millionth of an inch or a hundred-thousandths of a millimeter. For example, you can enter a line length or circle radius numerically - I do this frequently when creating my models. You can disable length snapping. You sometimes need to be very careful in accepting SketchUp’s inference snap-points when say, an end-point is very close to where you actually want to be.
Secondly, you can control the display tolerance shown by SketchUp (via the Model Info window), down to six decimal places (of either mm or inches); I normally use four decimal places of inches.
I’ve also been developing software since the early 80’s - including a GIS rendering engine etc. Now I write software for the cabinet making industry.
This sketchup form works with the users model units without any extra work on my part. Here I’ve turned off units (to reduce clutter) and set my units to mm with 1 decimal point.
In this example I merely set the model’s units to fractional inches and included the units display. Since there are no tildes ~ in front of the various parameters the values are being displayed accurately.
I also provide a number of language translation files which various users have graciously sent me. This one is French.
Again I don’t have to do anything special to handle the different input values.
Actually I am not a surveyor. I am a professional software developer. I worked in the transportation industry for several decades and wrote GIS rendering software in C/C++ as well as M2M cellular and satellite communications. This is also the time period when I worked with ECM devices on Semi Trucks.
There are situations where working down to the inch or cm level in GIS is absolutely required such as when digging from both sides through the Alps and expecting to meet in the middle.
I feel compelled to ask: is this really an important issue for SketchUp users and extension writers or just an opportunity to critique the USA for failing to join the rest of the world? Not saying that criticism isn’t merited, but maybe it is irrelevant here?
It seems to me that a SketchUp user shouldn’t care what internal units are employed so long as everything visible is in the system chosen in Model Info. And a SketchUp Ruby coder must always make use of the methods and classes in the Ruby API to convert user inputs to internal units and format outputs in user units (as the SketchUp GUI itself does). So, anywhere the internal units leak out should be regarded as a bug (and yes, I consider the DC implementation to be riddled with bugs!).
No matter what units are used internally, there are going to be values that can’t be represented exactly. How many places do you need to represent 1/3m exactly (as you will get if you divide a 1m edge into 3 equal parts)? A change of internal units isn’t going to prevent the awkward ‘~’ from happening now and then.
In my own extensions I have had considerably more difficulty with handling the different local conventions for representation of the decimal point (‘,’ vs ‘.’) and “grouping” in multi-place decimal numbers (1,000 vs 1000 vs 1 000).
I think a much more significant issue is how the dynamic range of SketchUp seems arbitrarily limited. At the small end, we have no way to customize the small edges tolerance, and must constantly worry about whether an operation will cause vertices to merge. At the large end, we run into issues at sizes considerably smaller than might be expected, and smaller than other apps handle readily. The useful range seems to suggest that despite being 64-bit, SketchUp internally uses 32-bit floats to represent coordinates. Is this perhaps an issue with passing values back and forth to OpenGL?
I hate it when I see it but love how clearly it tells me something is wrong. I’d much rather see the ~ mark and know something is wrong than seeing rounded values that appears to be fine, or have to model in several additional decimals just to constantly confirm the last few are zeros.
Agreed, especially concerning the large-end of the scale. How do people cope with SketchUp’s clipping when modeling a town, or even a large building? My work involves objects on the order of a few meters, but when scaled up 100X (for the Dave Method) and zooming in very close, clipping sometimes occurs.
Coming from unitless and scaleless AutoCAD model space, SketchUp’s fixed-scale modeling was one of the things that surprised me most. I still scratch my head every time I have to scale up a component x1000 to get the small facets right, and then scale it back down to the size I need. Isn’t it the same geometry? (The answer: not in SketchUp!)
But as US-based cabinetmaker who has to build cabinets in inches with hardware in millimeters for rooms that architects draw in feet/inches, there’s one thing I love about it: being able to enter any measurement in any unit I want and have SketchUp do the conversion automatically. I can draw a 30" wide cabinet with 5mm shelf holes spaced 32mm apart centered on a 17’ 5 1/2" wall and never touch my calculator.
Coming from SketchUp I was really confused by somewhat unitless Rhino when I changed model units and the program also asked me if I wanted to scale the model. “No, I want it to retain the same physical size”. But you have to press Yes and “scale” the model for it to keep the physical size…
It is kind of surprising that SU is using any kind of real world units of measure in its engine. Until they are presented in the user interface, all that matters are the relative sizes and distances of objects in 2d and 3d space. Units of real world measure should be the last thing applied. Does anyone know of this anachronism has anything to do with those ‘tiny object’ problems that require upscaling to rectify?
