Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Adopting SI units for all ThreeJS physical quantities? #6259
I would suggest that ThreeJS officially adopt SI units for its physical variables including distance, time, mass, light intensity, etc.
Right now ThreeJS is trying to be unit agnostic. While I can understand the motivation, it makes it harder to combine assets together in a ThreeJS scene -- artists need to come up with their own standards. Also many materials only look proper if you adjust their properties correctly relative to the scale of the object -- normal and bump maps in particular.
Also if you pick a non-standard unit, it can be hard to integrate physics properly. If you make 1 ThreeJS distance unit = 1km. You can not use SI units for mass specification in you are using ammo.js -- you need to also adjust those to match your unit scaling.
Unreal Engine 4: 1 Unreal Unit = 1 CM.
My recommendation is to recommend standard SI units for all quantities:
I think using standard SI units makes everything work together nicely. And it will lead to further maturation of the ThreeJS content pipeline, and increased interchangability.
what code changes would be required, in order for 1 to become 1 meter? what would prevent anyone from creating a lizard model with -100 ... +100 (now meters) bounding box? so far, the only useful SI unit in programming is a second. mostly in the form of ms, in setTimeout-s, Date.now()-s, etc.
I don't think this requires any code changes. You just put "We recommend you use models with a scale of 1 unit = 1 meter" in the documentation, and set all default values (like the camera clipping planes) assuming the scene is a couple of meters large.
As long as you can freely change camera parameters, don't have absolute thresholds inside the engine (like not rendering meshes with a radius of less than 1e-4 units), and have control over all assets in your application, there's nothing that prevents you from using feet instead of meters. Having a recommended unit system just makes it easier to exchange assets between three.js applications, or convert assets from another engine to three.js.
If you want to integrate a physics library, the unit becomes more important. The stability of the simulation might depend on the scale of numbers (due to the numerics), and there's usually many thresholds (for example, to detect stationary objects).
Example formulation from the Bullet engine wiki: By default, Bullet assumes units to be in meters and time in seconds. Moving objects are assumed to be in the range of 0.05 units, about the size of a pebble, to 10, the size of a truck. The simulation steps in fraction of seconds (1/60 sec or 60 hertz), and gravity in meters per square second (9.8 m/s^2). The page also goes on explaining that for some scenarios, centimeters, kilometers or even light years might be the more appropriate unit.