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.
This leaves the user with two options:
a) Change the world unit scale which scales the grid but seriously messes up the object size:
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.