Blender Unit Scale - Compatibility issue!

Other Development Topics User Feedback
#1

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.

3 Likes
#2

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?

1 Like
#3
  1. Blender should be compatible with 3D modeling software/environment, but not necessarily with any kind of other standards.
  2. 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.
1 Like
#4

Exactly. The SI base unit of distance is the metre, not the centimetre. That’s the scientific standard.

1 Like
#5

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.

1 Like
#6

So, forget all the physically-based simulation, modelling and rendering stuff?

#7

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!

#8

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.

  1. 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).
    grafik

  2. In 3D view the grid does not zoom to smaller details, though. Zooming out works fine but zooming in stops pretty much at meters.

    grafik
    grafik1009×659 19.2 KB

    This leaves the user with two options:
    a) Change the world unit scale which scales the grid but seriously messes up the object size:
    grafik
    grafik1015×569 75.1 KB

    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.
    grafik
    grafik965×883 120 KB

But what happens then is that the Orthos suddenly show a multiplier value:
grafik
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.

2 Likes
#9

  1. 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.

  2. 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!!!.

1 Like
#10

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.

#11

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.

#12

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

#13

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.

4 Likes
#14

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.

#16

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.

#17

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…

#18

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

1 Like
#19

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:
grafik

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.

#20

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.

#21

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?