SI units in Game engines

[vpochapuis]

Hello~
I am sorry if this doesn't belong here, i didn't know where to ask for it. Please let me know if i should remove and where i should ask instead if it was not appropriate.

I extensively use uom for some private projects, it saved me a lot of mistakes and made things clearer (apart from some error messages related to the generic essence of those structs) and I was wondering the place of using typed SI Units in Game engines.
Yesterday i was tinkering with the physic engine bevy xpdb and wondered if there could be a way so that we could have typed units for parameters (Length, Force, ...).
I also saw this issue #11577 (comment) in bevy that mentioned using real units instead of abstract ones, in this example for Lumen (or other).
Having typed dimension units in my opinion makes it clear without documentation about what the value is suppose to be (instead of a simple number).
Does this kind of approach make sense and would it be feasible?

[Aeropolian]

bevy_xpbd is a third-party crate and issues or discussion should happen there for it's components and design.

That said...

I personally feel that using multiple units provides more benefit when built into an editor than being in the code itself, in the context of a game engine. Especially given the duplication of components and systems to support every unit and the pain of unifying those data sources at runtime. Otherwise, the different units end up remaining completely external to the engine causing duplicate components, systems, and events to handle each unit type. Thus, I suspect adding multiple units to bevy would end up as a re-export of uom or some other similar library with minimal direct integration into the engine.

Going beyond one unit per concept adds unnecessary complexity to the engine and would need to be a separate abstraction on top of the engine; since, all units would need to be converted to the same one to simplify the calculations within the engine to reduce the risk of errors for one unit but not another. I would recommend using the uom library by converting any results into the base unit of the engine rather than expecting the engine to handle any unit you throw at it. This prevents unnecessary duplications of functionality in the engine while providing all the benefits you may experience from more explicit unit handling.

TLDR; adding multiple units per concept would add unnecessary complexity to the engine and, generally, better outside of the engine

[vpochapuis]

Hello!
Thank you for answering me.
Indeed supporting multiple units (mm,cm,m for a Length for example) is added complexity and in such case re-exporting uom would be an easier way.
However my question was more targeted towards using typed units (or quantity/dimensions i am never sure of the exact term to use here) for, following the light example, Candella. So that when setting luminosity intensity the Bevy interface requests a bevy:: quantity::Candella (which could be an internal type Candella(f64) or a kind of uom re-export of uom::si:: quantities::LuminousIntensity<f64>). The goal being preventing the user of setting a f64 value thinking its another kind of quantity type, as well as having a kind of self documenting parameter type.
I hope the idea i am trying to convey is understandable.
If i missunderstood something in your answer please let me know!
Thanks again

[rlidwka]

Please check out this issue (radians vs degrees): #11132

I only needed dimension units once (to distinguish rpm vs rad/s) in my previous projects, so I don't think it's necessary to have in bevy, but still worth keeping in mind if more use-cases emerge.

[vpochapuis]

Interesting!
I will take a look~
Thank you!