Whether you’re importing art into the engine from another software package, or adding functionality from within the editor, a solid grasp of how scale and measurement is calculated is a fundamental part of working with Unity. Alongside an understanding of its world coordinate system (which dictates how these units are interpreted to place objects in your scene) this information defines how distance, mass, velocity, and more are calculated. As you can imagine – this can affect every facet of your game.
The size of a unit of scale in Unity is arbitrary, and developers are free to work within whatever measurement system they are most comfortable. However, by default the engine expects you to use meters for distance/length and kilograms for mass. Diverting from this may have unexpected results.
A practical understanding of unit scale in Unity is more than just knowing how big an asset is going to be when you import it into the engine (although this is really important), your choice of unit scale also affects how animation is interpreted, effects within the audio engine, physics calculation, and more.
Before we get too deep into that, let’s define some terms.
What is a ‘Unity Unit’?
The term ‘Unity Unit’ describes the arbitrary values used by the engine to measure a range of things including distance, time, and velocity. Since these values are set entirely within the engine and may not reflect any outside measurement system, it’s important that they have its own definition.
There is a lot of contradictory advice regarding the default unit of scale in Unity. I believe this confusion comes in part from a lack of the language to describe the size of a unit of measurement within the engine, so I hope this helps the conversation.
Side note: ‘Unity Unit’ is not a ubiquitous term. I have found it very useful to describe these arbitrary values, but you may have another word for them. For the purposes of this article I will sometimes refer to Unity Units in shorthand as ‘uy’. Unfortunately Unreal Engine’s ‘Unreal Unit’ has the market cornered on ‘uu’. They beat us to the punch on this one.
Default Unity Units
One of the primary culprits of the confusion I see on Unity Answers is an apparent disagreement over what Unity expects its unit size to be. Some users will confidently say that “Unity works in meters, so 1 unit is 1 meter”, and others will counter with “The size of your units of measurement are entirely arbitrary, just pick whatever works best and go.”
Both of these opinions are correct. As Unity forum user AngryPenguin once wisely stated; “A Unit is a meter if you treat it like a meter.” (the emphasis is mine)
As accurate as that statement is, and although Unity can support any number as its default unit distance/length size (maybe not incredibly huge or small numbers, but you get my point), out of the box it expects meters.
Unity Technologies had to pick a default value so they could calibrate their systems to work for the greatest number of projects. Here is a table of what they came up with for the default unit settings across different types of measurement.
|Type of measurement||Default Unity Unit size|
|Speed/Velocity||Meters per second|
The following table can be used as a reference for the default size of various Unity objects and settings. Although these values are all in Unity Units, remember that by default the engine also treats them as in meters.
Changing the unit of measurement
There are many good reasons to want to work in a custom unit of scale. Sometimes centimeters is the better choice as it makes it easier for level designers to place objects with precision. Likewise, if your project involves working in spaces the size of a planet, then something much larger might be more appropriate!
The bad news is there isn’t a simple setting that tells the engine to compensate for a change in measurement unit and off you go. The good news is that Unity gives you a lot of control over changing individual project settings, and it’s just a matter of knowing which ones you need to update and where they are.
Finding your scale factor
If you’re dead set on using a custom unit of scale, the first thing you need to calculate is your scale factor. This is the value you’ll use to modify the relevant project settings to make sure systems like physics simulation remain accurate and realistic.
For reference, here are some quick conversions between common units of distance measurement that may help you find the scale factor you need.
Note: Multiplying or dividing almost any value or setting by 9461000000000000000 is generally not a good idea. You probably don’t want to work in lightyears.
Updating your project settings
Now you have your scale factor you’ll need to jump into your project settings and update a few values as the engine is still assuming you’re working in meters.
Disclaimer: The values listed below are the settings that I have confirmed to need updating when you change your unit of scale. Unity is a complex machine, however, and there are likely others I have missed. Just be aware that changing your unit of scale can cause unexpected behaviour, and you may need to tweak things as you go.
That said, here are (some of) the settings you’ll need to update:
Inside the physics section of your project settings you’ll need to multiply the following values by your scale factor if you want to retain accurate physics simulations in your new scale.
Breaking these settings down in more detail is unfortunately out of scope for this article, but for more information on what each of them does check out the Unity physics documentation.
In audio, the doppler effect is the change in a sound’s frequency when it is moving towards or away from the listener at speed. Unity’s sound engine reproduces this effect, but its setting is calibrated for meters. If you don’t multiply this setting by your scale factor, you may notice it occurs when you don’t expect as Unity thinks your objects are moving faster or slower than they actually are.
You can find this setting inside the audio section of your project settings.
Camera clipping planes
Each of your cameras has a near and a far clipping plane. These define the bounds within which your cameras see the world. Multiply these values by your scale factor.
You’ll need to do this for each camera you have in your scene.
That’s it! Thanks for reading this far. I hope I’ve adequately explained how unit scale works in Unity and I’ve helped you make an informed decision as to what you’ll choose to do for your own projects.
At the end of the day, all that matters is that you use a unit size that works for your project. Changing mid-production is relatively straight forward, but not trivial, so if you’re just starting out give this decision some forethought. My advice would be to stick to meters if you can at all help it.
Before I sign off, here are a few final tips and tricks that I have found useful:
- If you need a cheap measuring tool, creating a line or a cube from the hierarchy create menu is a quick and easy way to discover the distance between objects, as you know they will come in at a unit size of 1.
- The scale information in the inspector under ‘transform’ is relative to the object you have selected. It has nothing to do with your unit of measurement. I noticed a few people on the forums getting confused between the two.
If your object has a scale of 2 in the inspector all that means is that, relative to its original size, your object is now twice as big.
- If you’re working in VR, I highly recommend you stick to the default unit of 1uy = 1m.
The consequences of confusing and/or incorrect scale are far more severe in virtual reality, where mismatches in the dimensions of your world can cause motion sickness and dizziness in your players. Moreover, when looking at your game world in VR it’s far easier to notice when/where the scale is incorrect. Depth perception makes the discrepancies obvious.
- Finally, if you’re having issues importing your meshes into Unity at the correct scale (which is a whole other article!), you should double check its scale factor in the import settings under the ‘Model’ tab. I hope you find the solution to your problem there!
I am a technical artist from Adelaide, Australia. I created techarthub to share my knowledge and love for this industry. I hope you feel it too!