Flax engine unit choice centimeter - IMO, painful to work with


I’m a newcomer and have been playing around with Flax for few days.
IMHO, the choice to use centimeter as the base unit make it more difficult to work with.

Every actor you move on the scene have very fast growing transform values.

I’m not sure, maybe I’m too used to work with meter as base value, but nowadays, game worlds tend to get bigger and bigger.

The cons:

  • Visually, harder to read, check for the developer.
  • Values need larger fields or smaller fonts to be displayed on the editor UI

Please, let me know what you think.

Note: don’t get me wrong, I like the engine :slight_smile:


+1 for meter unit, just my personal preference also

1 Like

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! :smiley:

This here is exactly why we should be in 1m increments. Real examples. Real math! Love math. :smiley:

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.

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

Unity (m based)
8.3m per frame
10.0m per frame Maximum
10,000m Map Max
100Km2 Map Max

Unreal Units (cm based)
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)
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. :rofl:

1 Like

Just to align this thread with Discord and Github

Summary: Quite a lot of support for it and options are being considered.


Adding my two cents here that I would greatly prefer meters over centimeters.

Is there any benefit at all to using centimeters? Why was that unit chosen?

It’s a relict of the past. We’re considering migrating to meters for Flax 2 - it’s going to be breaking change so we cannot do it now. Meanwhile, we’re adding some tools to the editor properties panel to make entering physical units easier.


I also put my vote for using meters as unit. It always annoyed me the default unit in Unreal is cm, while in Unity it just feels natural as they use meters. Moving to meters would add another star to Flax IMO.

I am currently researching what framework to use for a very large open world game, and while Flax has the ability to use doubles for positions, this is a bit cumbersome as in my case I need to mix the regular pipeline with my own ported pre-existing pipeline for more advanced effects such as real time path tracing. And if using floats / cm units directly, I run out of precision at the end of my world.

It is manageable with cm, but it creates some overhead that it would be nice to avoid. Especially since the Physics engine is tuned to cm, and we cannot simply scale down the world either. On the other end, I cannot think of any practical case where I would need super high sub cm precision. Sacrificing a long reach for super high sub cm precision seems like the wrong priority.

If the unit is meters that works perfectly in my case at least. Also, I think using meters this would help the transition for existing Unity developers and even help them use code from the Unity Asset Store with much less porting headache.

I know it would break some things, but making the transition this early might be the least painful point to do it, as I predict Flax could become very popular while ATM it is not being used in many big projects AFAIK.