Me too. I prefer the increments in 1m as well. UE is also in cm so maybe that is where these units came from? With testing and imports things work fine as to scaling but yeah, keeping track of everything *0.01 is a pain.
Is accuracy any better when in cm? Not at all. Meters has the exact same accuracy when comparing small ranges because decimals are only ever good to 7 decimals. It is a float and unitless. We give it a unit…in this case cm. So let’s do some math! 
This here is exactly why we should be in 1m increments. Real examples. Real math! Love math.
Space scene (or large world). Let’s say the playable area is 10,000m x 10,000m and we want something larger for some simulation and spacing…so we multiply x1000 units. This should end up with 10,000,000m x 10,000,000m. Floats are only good for 7 decimal places reliably before having to delve into the mantissa so our reliable math for 1m increments is now 10,000,000.0001 (4 decimals). So this works when it is in meters. In cm we are now limited to 10,000,000.01 (2 decimals) but we NEED at least 3 decimals for math to work well…so 100,000.0001m (4 decimals). Note below that Flax has a limitation of 1,000,000.001cm. You can see we simply lost a lot of area because of cm units.
Note: this is a great method to make very large environments then everything is scaled in this environment by the same multiplier. As long as we have 3 decimals to work with the math works fine.
For any game we have to solve what the maximum engine units are (all 3 have the same physics limits). If you are not doing this then you are not solving your limits. So here are 3 game engines that I have worked with and the limits of the engine. Some reliable testing was done to get these as well. Notice the much smaller usable space in UE4 (I converted UE4 to meters in the project settings…new-ish setting). UE5 can go much larger with its cell based tech but each cell has these limits. Flax aligns perfectly with UE4 prior to the meters option in UE4. Notice the strange math. In any code there must be a function that does this conversion so we don’t have to remember to do it every time. Vector…LERP…Slopes…all sorts of math issues.
Flax Note:
- 64bit enabled does not work for PhysX (please correct me on this if wrong).
- the map/scene size limit in Flax is not limited like UE and only limited by PhysX so that is what is shown below. Flax has the same maximum dimensions as Unity in the end. In some testing 3 decimal math is still working and movement is still smooth.
So let’s say we need to move our object(s) in the engine. How mast can they move smoothly? Where does the engine break down based upon a 25ms maximum CPU frame?
Maximum Engine Design Speeds
500.0mps In Planetary Influence (remember meshes have to render in)
500.0mps Actual Movement
8.33m per frame
50,000.0mps In Space (notice the large space scene x1000 muliplier…0.001 scaler)
50.0 mps In Space (Actual Movement) <= this is post LERP math to actually do movement
0.83m per frame <= Notice how close this is to 1m per frame. Visually movement is lurching.
1800.00km/h
1117.80mi/h
Some interesting equals as well as UE4/Flax PhysX sub stepping (semi-fixed time stepping).
343.0 Speed of Sound (mps)
1.46 Mach
1640.0ft per sec
60.0fps (Hz, Frames Per Second)
120.0Physics Design Maximum (Hz)
0.008333Max Substep Delta Time (Physics Design)
12Max Substeps
45.0Smoothed Framerate Minimum
90.0Smoothed Framerate Maximum
1234.80km/h
766.81mi/h
Unity (m based)
500.0mps
8.3m per frame
10.0m per frame Maximum
10,000m Map Max
100Km2 Map Max
Unreal Units (cm based)
50000.0uups
833.3uu per frame
8.3m per frame
1000.0uu per frame Maximum
10.0m per frame Maximum
500,000uu Map Max
25Km2 Map Max
UE5 can go larger if necessary
Flax Units (cm based)
50000.0cmps
833.3cm per frame
8.3m per frame
1000.0cm per frame Maximum
10.0m per frame Maximum
10,000,000cm Map Max
100Km2 Map Max
10,000,000cm Map Max (Physics)
100Km2 Map Max (Physics)
I love math. 
Cheers
O
