I would like to stress the attention of developers and community that Blender is still using meters as the base unit scale. Other software like Unreal Engine 4/5, Unity, Allegorithmic Painter/Designer, 3ds Max, Maya use centimeters as the base unit scale. So why not to change default units in Blender to meet other software units?
Unless you set 0.01 Unit Scale in Blender you always get a 10000% scale (100 times bigger) of the models exported from the Blender. But with 0.01 Unit Scale some weird things happen in Blender interface like for example an Origin Transfer gizmo gets so tiny that at first you donât see it at all.
Each year Blender gets closer to giants in 3d modeling industry. Please start fixing such a basic things to allow artists to interchange their assets between software without need to know secrets of Blender. It should just work from the box.
The SI unit is the metre, not the meter or centimeter or even the centimetre. How can you have an American spelling for a unit that Americans donât use?
Blender should be compatible with 3D modeling software/environment, but not necessarily with any kind of other standards.
SI stands for Système international (dâunitĂŠs) (French) and is the modern form of the METRIC SYSTEM (includes metres, centimetres and other units). It does not stand for the meters (metres), but rather comprises all metric system units including length units which start with metres as the BASE unit and then it goes with centimetres and millimetres.
Blender is a 3D modeling application, not an application to learn SI or laws of physics where SI is used extensively. No need to apply SI to where it is not belong.
Calculation of simulation algorithms have just to be adjusted by 100. Thatâs it. Invisible change to users but you can interchange Blenderâs FBX with other soft without issues right from the box.
3ds Max also has ability to choose the base internal unit scale - System Units - and whatever you choose it will not influence simulation procedures.
Moreover, Blender versions 2.7x automatically changed Unit Scale when you choose something other than Metres accordingly! But now 2.8x and 2.9x donât even do that automatically!
I donât see the dfault Unit itself as the problem, per se. Itâs more the inconsistency in which the units are displayed and exported. For example - say, you are working with a smaller object size like centimeters. In this example the Default Cube⢠is 1cm x 1cm x 1cm.
In Orthograpfic view everything is fine. The grid scales up and down from large values to very fine ones and displays the current grid size correctly (we could argue that 10cm could be called decimeter but thatâs marginal for now).
In 3D view the grid does not zoom to smaller details, though. Zooming out works fine but zooming in stops pretty much at meters.
And there really is no easy or understandable way to have the grid scale into smaller values with Unit size settings. Either the size is all over the place or the grid is huge.
b) set the grid to 0.01 scale.
But what happens then is that the Orthos suddenly show a multiplier value:
Not helpful at all. Not to mention that the 3D perspective view simply never shows any values for current grid size.
Now the even bigger problem is what unit to set up in the export settings because now you have several values that push and pull on the object and scene size. On top of that a multiplier value for exporting the object into your desired exchange format. So itâs unit value, unit scale and/or percieved grid scale plus export multiplier.
And the solution is actually (at least logically) not that complicated:
Give the 3D grid the ability so also have some close up zoom subdividion buffer. When zooming out it works rather flawless. That way the user doesnât need to use weird grid scaling that messes with unit displays.
Show the current grid scale in the 3D viewport just like in the orthographic view.
Thatâs it. That way the user wouldnât need to fiddle with gridscale or unit scale. Set the units to either scale unit and work with it. This also take a lot of guesswork out of the export because you only have one multiplier value to take care of mentally. The one from the exporter to the target app/engine.
Unless you export your model as FBX file and import it, say, in 3ds Max or Maya, you will not notice the issue. Blender will show your models correctly in every aspect. As I say the issue appears when you want to interchange your models with Unity/UE/Max/Maya and others.
Blenderâs Unit Scale is the amount of units that the base unit scale (meters, canât be changed in settings - PROBLEM!!!) is multiplied. If Unit Scale is set to 1 (applicable to 2.8x and 2.9x) then if you choose centimeters in Length units your 1 centimeter will be equal to 1 meter. Actually, whatever Length units you will choose it will be equal to 1 meter unless you change Unit Scale accordingly. You will not notice that in Blender, but after exporting to other software youâll get a mess if you donât change Unit Scale value - your objects will appear scaled 100 times!!!.
That is a problem of every application and most exchange formats, though. You will get 10x scale issues (usually ranging from 100x to 0.01x in 10 increments) as exchange problems in most 3D apps. That includes CAD programs. Itâs the reason Unity has an importer file scale multiplier - to get FBX to be able to import at 1/1/1 scale from any other application. Not only Blender.
If the work units inside Blender are consistent and easy to set up you only need to figure out the correct ratio to your target apps and create a preset for that. And that multiplier should be the only thing the user has to figure out and remember or save. That one needs to be consistent. in order to be consistent it needs to be solid and without any weird multiplication issues inside Blender. And from my experience of working with CAD files and smaller world scale values these problems mostly come from having to fiddle with either Unit- or Gridscale. And thatâs just unnecessary, I think, as itâs mostly a display issue of the gridsize.
I absolutely agree that this value needs to be applied depending on the units and measures you set in the world settings. Yet ultimately only the export scale multiplier should be the factor to remember. Not which scale multiplications inside Blender have been set.
Transform Scale in Export Window doesnât work the same way as Unit Scale does. For sure it would solve the issue but it you set Unit Scale in Blender to 1 and Scale of 0.01 in Export Window the scale of object will be 1 but the size will be 100 time smaller than in Blender. If you leave Transform Scale in Export Window to 1 and Unit Scale in Blender to 1 too then youâll get you model imported to another software with a scale of 100.
The only working solution to import to another software a model from the Blender with a scale of 1 and of the correct size would be to use Unit Scale of 0.01.
Sorry But I canât really understand the problem
you can simply set the in the scene setting legth as centimeters
save the file and set it as the new defaut one so you dont have to keep changing the settings everytime you create open blender
I just tried exporting two default cube to godot of different sizes and everything seemed fine to me
Thank You
The problem is that when you choose centimeters or whatever length you need the actual measurment units are meters. You can not notice that in Godot or Unreal Engine for unknown reason, I may assume they set a scale of 1 for whatever mech you import to it. However, if you try to import Blender FBX with a Unit Scale of 1 to whatever mesh edit software like Autodesk Maya, 3ds Max etc. youâll see that actual scale of the mesh is 100 (times), i.e. 10000%. Youâll have to apply this scale then to work appropriately or you may have some issues using it with a scale other than 1. However, youâll not get into this issue if using Unit Scale 0.01 in Blender.
This is why Iâve got doubt using meshes created with Unit Scale other than 0.01 in game engines. There is a big chance such meshes still have a scale of 100 which is not appropriate.
The problem is that you donât understand that 1 m = 100 cm = 1000 mm. And âLengthâ parameter just a visual representation of units.
You can choose Unit Scale whatever you like or need for your job. I also work with Nuke, often getting models from Maya and 3DMax, sometimes do models for UE â no problem, at all. Nuke and Blender use 1 meter as default. For Maya and 3DMax you can also use 1 meter scale as default or you can adjust Blender Unit Scale to match pipeline.
Blender has much bigger issues with simulations, caches and other things that actually affect production.
In favor of centimetre as the default basic unit. In my opinion, not only for compatibility, but also for simulations, which improve computation (integer computations are faster and more accurate than floating point computations). In the world of the human eye, the cm unit is moderate, and results in more integers and fewer decimals than metre. When doing simulations, we often encounter situations where we need to scale up ten or a hundred times to get good result, and then scale down. This situation is because that the mesh is too close (in essence, the number after the decimal point is too long). If the interface does not use cm as the default basic unit, at least the background needs to use cm as the calculation unit( or it is already cm? I dont know), which can speed up the calculation and improve the accuracy. Users also donât need to scale up and scale down frequently when doing simulation.
Agree with that. Yes, it is possible to set scale of 0.01 while exporting to FBX, but why to? The two most used software on the market if used with metric system use centimeters. UE4 & UE5 also use centimeters. So there are a couple of reasons to switch to CM as default basic unit and at least myself I see none to stay with meters any furtherâŚ
blenderâs 1 unit = 1m, UEâs 1 unit = 1cm, they are hard coded, thatâs how they work. But blenderâs true problem is itâs fbx exporter sucks, it doesnât actually change the file units system of exported fbx, it always write fbx as âcentimeterâ. When you âimportâ in UE you can see that info in the âFile Unitsâ section of import dialog, even you set blender unit scale and export scale both to 1, it will always be a âcentimeterâ fbx and amazingly UE still somehow can convert(scale up 100 times) the mesh to centimeter unit. Letâs say you export that 2m default cube with both 1 scale factor, the dialog shows itâs in centimeter but you still can get a 200*200*200 cube mesh in UE.
BUT here comes the fun part, if you use the âimport into sceneâ way, you will get a 100 times scaled big actor and a 2cm*2cm*2cm static mesh!! It means UE read the fbx unitlessly as 2*2*2 and multiply them with the âFile Unitsâ factor witch is centimeter means = 100. This can mess up many things.
Iâm not sure if itâs an UE side issue but I enable USD plugin and âimport into sceneâ from usd file, everything just works fine
I never really understand this discussion. Yes, maybe Blenderâs internal Measurements are hardcoded but isnât that the case with every major 3D software? The exporter has problems, yes. Mostly due to Autodeskâs proprietary FBX license terms. But for export to any other game engine or 3D software this is the screw you adjust:
Scale and Apply transform (as long as thereâs only geometry - rigs break) to whatever the target space and axis is.
The one real problem I always found with Blenderâs internal scaling is that it breaks during modeling in very small scales. When working with toy-scale models in the cm or mm range and trying to stay true to Blenderâs scale model thereâs nearly no chance of using cloth. Also merging and projection occasionally also breaks in small scales. And the world grid also canât adjust automatically. It always has to be set to 0.01 in order to not be ginormous.
But as far as export to any game engine in FBX goes - adjust the scale on the exporter.
You know, it is really not unresolvable problem but it is issue as long as other industry standard software use cm as the basic unit. Because many other software also take in consideration that Maya and 3ds Max use cm as basic unit. Also many people who start learning 3D or try to switch to Blender from other modeling software may experience issues related to Blenderâs basic units set to meter while not having enough experience to resolve their issues. Because with 3ds Max and Maya in this respect âit just worksâ. So I believe Blender developers should consider switching to cm from m just because it is a kind of standard in industry. Blender just should be compatible with them by default.
I donât think centimeters is really the standard. While Unreal uses cm, Unity*, and Godot both use meters.
* OP mentioned that Unity uses cm as its base unit which is incorrect, however I remember that there at least used to be issues with rotation when exporting/importing to Unity, and maybe scale too, if so maybe its importer expects cm?
