Introduce a Way to Adjust the Duality Coordinate System and Internal Unit Conversion Rates for Advanced Users

[ilexp]

Summary

Duality currently uses a world space unit scale that has been chosen to match pixels at 1:1 camera zoom. While nice for some games, this screws up a significant number of physics conversion rates and is a somewhat arbitrary choice for most other games. Investigate whether it makes sense to switch all of Duality over to a MKS (meter-kilogram-second) scale.

Analysis

This issue is to be investigated and discussed. Whether or not it should be implemented still needs to be figured out. Feedback appreciated, please join the discussion in the comments.

What that means

• It will change the base units for length, time and mass to be based on meters, seconds and kilograms.
• Physics conversion rates would flatline to 1.0f for all units.
• Audio conversion rates would flatline to 1.0f for all units.
• Implementing this will break all serialized and hardcoded values from the old coordinate system.
• Rendering and audio would be adjusted to operate on scaled spatial units.
• Changing the spatial scaling factor afterwards will not be a breaking change and could be adjusted on a per-game, per-scene or even per-camera basis.

Things to take note of

• To mimic the current relation between physics and rendering scale, the scaling factor should default to 100, meaning that one unit (meter) is going to be scaled up to span 100 pixels at 1:1 zoom.
• It will be a downgrade for games or gamedevs who prefer a pixel based coordinate system, while being an upgrade for those working with physics a lot.
• It will make the scale of units more intuitive. Examples:
  • Before: 1.6666 pixels / frame
  • Before: 2.7777 decigram * pixels / frame²
  • After: 1 unit / second
  • After: 1 kg * units / second²
• The scaling factor could be adjusted as seen fit by the game.
  • For example, a 32x32 tile based RPG could specify that one tile is 1m², defining the rendering scale as 32 and essentially using a world space coordinate system where one unit equals one tile.
  • Setting a scaling factor of one would make it a pixel-based coordinate system like before, but that's not to be recommended, since physics will be less accurate while only gaining a bit of editor convenience in exchange.
  • The default scaling factor should be useful / good enough that changing it could be considered advanced.

What needs to be done

• Adjust all sample project Scenes and Prefabs.
  • Object positions, Transform.Pos
  • Gravity
  • RigidBody mass overrides
  • RigidBody Joint properties
  • Any property value relating to velocity, force, impulse or similar.
  • Would probably be easiest to write a script that does the grunt work automatically.
• Adjust all sample project code.
  • Hardcoded physics-related values.
  • Also distances, offsets, positions.
• Adjust physics settings.
  • Velocity threshold.
• Adjust core code
  • Absolute anchors for min-max audio ranges.
• Adjust Camera and SoundListener code to use a scaling factor.
  • Find a good place to store the default of that scaling factor, as it needs to be used by the Camera View, as well as all other runtime-generated Cameras and SoundListeners.
  • A global default might be a good start.
• Figure out how to auto-create a SpriteRenderer, and similar situations.
  • The SpriteRenderers rect will be set automatically, but the right size will no longer be the image size in pixels, but a world space size that, given the scaling factor, would be rendering as the image size.
  • That kind of conversion might show up more often. Would be good if there was a somewhat common place to ask for the "current" (whatever that means) scaling factor.
  • Also, what happens when creating a sprite prefab in a project with scaling factor A and re-using it in a project with scaling factor B? Its rect will be off. Is there a way around this? Is it likely to be a real-world problem?

How to proceed

• Discuss the pros and cons of this potential change.
• Figure out pitfalls and how to solve them.
• If actually deemed a likely enough improvement, branch off of the develop-v3.0 branch to implement a prototype.

[ilexp]

Feedback so far raises some valid points against this change:

• The current pixel based coordinate system is quite intuitive when starting.
• Not everyone does a lot of physics. In fact, most projects probably don't deal with physics units that much.
• It would make porting content from v2.x to v3.0 next to impossible. While a bit of work already, this would make it non-viable.
• The new system makes it more likely for people to adjust the default scaling factor, making it harder to share code and content.

Leaving this open for now, but this change increasingly seems like a bad idea, or at least one to be very very careful with.

[ilexp]

Thought about this a bit more and I think a better way to go about this is a route similar to what @SirePi mentioned a chat discussion: Rather than switching over from one default to the next, keep the old default and gradually provide the means to allow advanced users to adjust the global coordinate system for their project. Approaching it this way, 99% of users will likely keep the default and enjoy all the benefits of having that shared default, while the 1% who really do build a game that could benefit heavily from a custom coordinate system can achieve this in their projects self-contained universe.

This would essentially involve two things:

• Make base unit conversion rates in PhysicsUnit and AudioUnit editable in some way.
• Introducing a spatial scaling factor for rendering and audio representation of the simulated world.
• The way smaller subset of the above points that are still required when keeping all the defaults as-is, and that mainly boils down to applying the new scaling factors at various previously unscaled points in code.

Renaming the issue accordingly. Even though it will no longer be breaking for content when approached this way, it will likely require public API changes and thus still be a breaking change on a binary level, although a greatly smaller one.

[ilexp]

Moving this to the Future milestone, as it doesn't seem to be crucial or urgent.