Adopting meters as the standard distance unit

[EdyJ]

Issue description:

(This is a follow-up from this suggestion thread on Discord)

As a physics developer, I've noticed a major issue in the Flax design – the inconsistency in distance units. Using centimeters makes using the engine for physics development quite challenging.

I strongly recommend that Flax Engine adopts meters as the distance unit in a major update, perhaps in Flax 2.0. This change would significantly simplify physics development and reduce the likelihood of encountering inconsistencies, confusion, and unnecessary difficulties. It would also give Flax an advantage over other engines that use centimeters. Now is a good time to make this transition; the earlier, the better.

I can't think of a proper justification for using centimeters as the distance unit in modern game engines. The argument that "Unreal (or any other engine/tool) uses centimeters" is not valid. Unreal's design comes from 1995. Importing 3D models from tools that use centimeters is as easy as specifying the scale in the importer. It's not about precision either; 32-bit floating-point precision remains at 6-7 significant digits regardless of where you place the decimal point.

In physics development, full consistency is crucial. Without it, developing good physics simulations becomes unnecessarily difficult. Many critical magnitudes involve distances and must be fully coherent, including torque, velocity, spring rates, damper rates, and inertia. Working with units in meters is way more intuitive, particularly when dealing with larger-scale environments or objects, and with real-world magnitudes.

Examples of significant inconsistencies when dealing with Flax and distances:

• Torques in WheeledVehicle are specified in Newtons per meter, not Newtons per centimeter.
• I couldn't figure out the torque unit in angular joints (i.e., HingeJointDrive).
• In Flax 1.6, the tooltips for the wheel radius and width in a WheeledVehicle stated that the units were in meters, while the values in the editor were clearly in centimeters.
• Flax 1.7 removed all tooltips mentioning any distance or mass units.
• The API documentation for WheeledVehicle specifies meters as the distance units, which adds to the confusion.
• PhysX docs provide defaults and references assuming meters as the distance unit.
• Flax documentation mostly avoids mentioning any unit or providing any reference (example). Is the spring rate in SpringParameters Newton/cm or Newton/meter? What units is BreakTorque in joints?

Addressing these inconsistencies and adopting meters as the standard distance unit would greatly enhance the overall usability and consistency of the Flax Engine not only for physics development, but also in many other areas (graphics, shaders, audio, etc).

Steps to reproduce:

N/A

Minimal reproduction project:

N/A

Flax version:

All (currently 1.7.2)

[nothingTVatYT]

If the fear is that this would be a breaking change, would a configuration option be feasible? Something along the lines of what Blender does with the unit settings? It would be nice to even adopt the presentation of values i.e. in cm/meters/etc. If you ever used Blender for models to 3d printing you'll probably love this option. Flax could benefit from that too especially when parameters important to physics have a meaningful unit and display it as such. All that is needed IMO is an extension to the input control so that it knows the value is not just any float (or whatever) but a value in SI units and dependable on project settings.

[mtszkarbowiak]

I'm going to throw some more pro-meter arguments here:

1. Switching to m from cm enables larger game scenes without the need for resource-heavy double-precision calculations, ideal for games with bigger environments and vehicles. (Example scenario: tank game to be ported on mobile)
2. It is significantly easier to transfer Unity games. In my subjective opinion, there would be more cases of willing to port Unity game to Flax, not Unreal to Flax. Therefor keeping the same scale is beneficial.
3. Meters are more practical for prototyping assets, particularly those of human-scale dimensions, enhancing development speed and design efficiency.

[EdyJ]

If the fear is that this would be a breaking change, would a configuration option be feasible? Something along the lines of what Blender does with the unit settings?

I also use Blender, but I believe that implementing a configuration option in this case wouldn't be a good solution. It would complicate development even further, requiring every piece of code, setting, and asset to be aware of the units it's working with. This could lead to significant fragmentation in the Flax ecosystem, with assets and modules either designed for specific units or having to accommodate both. Additionally, it may introduce significant challenges with documentation, the future store, and more.

A breaking change is necessary for this, but I believe it will bring substantial benefits in the mid-term and future of Flax. The sooner it happens, the better. For instance, if it's introduced in Flax 2.0, it will provide clarity for everyone that anything related to version 1.x will require at least a review to be compatible with 2.0 and future versions. While it's a one-time situation, the long-term advantages make it a worthwhile consideration.

[EdyJ]

Another advantage of adopting meters is that the documentation wouldn't require modification. Currently, it avoids specifying units. If it's clarified that the units in Flax are SI, everything would remain correct as is. Only special cases, such as using angles in degrees or angular velocity in rpm, would need to indicate the units.

[GasimoCodes]

3rd party libraries, rendering and physics formulas often expect meters to be the base unit. Converting the units real-time or rewriting things by hand to just work with flax sounds like uneccessarily alot of work. I am trying to find a justification for CMs but I cant think of any (besides (maybe) some additional precision for objects reeaally close to the camera?)

[mafiesto4]

I'm sure we could add proper editor support for physical units so users can configure those in Editor Options. Adjusting some values for realistic physical simulation or lighting effects is problematic right now. Full engine refactoring of units might be a challenge. But I would not cross that one from the list yet as it's possible if that might required. Firstly, let's improve the Editor UI to handle different units. Thanks for your feedback.

[EdyJ]

I've just learned that force unit is not Newton, but centiNewton, 1/100 N (!?). Torque unit is centiNewtonMeter, 1/10000 Nm (!!??) (source: https://discord.com/channels/437989205315158016/790657150674141265/1202246371449778238).

The unit inconsistency is so significant that, unfortunately, I've had to rule out Flax from any development plans. Developing serious physics-based projects in Flax is a no-go unless there's a significant course change in this area.

[GonziHere]

It's beautiful, when it's done. You can prototype your vehicle with 1.2T weight, 50km/h speed, you can set your light to 1000 lumens and 5500 kelvins, your camera to fullframe 5.6f, etc. I personally find the lack of this in say Godot incredibly bad (everything is just numbers there). I was even more amazed that Unigine (more b2b oriented engine) says It is not recommended to use real values of mass, density, gravity, etc. IMHO, it's incredibly useful, when you aren't aiming for a pure game (think Mario and his jump trajectory, etc). The second that you start to work with a real life stuff, you need consistency, you need to mention units everywhere (it's not acceleration, it's acceleration[meters per second]) and you need the ability to use the real numbers as a base, to match the look and feel of a gopro camera, for example. It also helps with the stuff that you cannot see IRL (at least I cannot test how long it takes for an oil tanker to stop). To drive the point home, I've spent some time in Unreal with a physics driven quadcopter. The end result was believable, because there was a real mass, real weight transfer, real aerodynamics, etc. It ultimately led to a fun vehicle physics, simply by using the numbers in the realm of possibilities. The only pain points with it were units, where I've actually had to test each and every one of them to see what I actually have to input where. It was incredibly frustrating, especially knowing that the correct PhysX was behind it and that it was just UE being opinionated.