Re-Think Transform Component Implementation

Summary

The current implementation of the Transform component is quite bloated and not as fast as a component used this often should be. A brief attempt at simplifying it was made, but yielded no results. Re-approach the topic by rethinking how a Transform component should be done if there wasn’t one already.

Analysis

• Implement lots of unit tests for Transform before beginning any implementation.
• Is deriveAngle used anywhere? Remove it otherwise.
• Can transformation change events be removed?
  • Their main purpose is ensuring safe interaction between RigidBody and Transform so they always remain synced up.
  • With the implementation of deterministic component update order, this can potentially be solved differently.
• Can velocity values be removed?
  • It was established during #576 that a distinction between moving to X and teleporting to X is required, so the answer is generally “no”.
  • However, an alternative implementation using last / current values would be viable, if that was preferable for some reason.
• Can the tempVel accumulation values be removed?
  • Depends on the exact outcome of velocity value removal or adjustment, but potentially yes.
  • Their main purpose was to ensure stable velocity values over the current frame as different objects adjust Transform position in any order.
  • With the implementation of deterministic component update order, this might no longer be necessary.
• Can absolute values be removed?
  • They’re derivative and can always be calculated from relative values plus object hierarchy.
  • This would save object size / memory, but would require calculating them on access.
  • If it’s fast enough, it might still be worth it. If it isn’t, keep them.
• Is it possible to make Transform no longer implement ICmpUpdatable?
  • Probably not, as long as there are velocity values to be maintained.
• If not, is there any way to adopt an array-of-structs approach internally without public API changing in any way?
• With an updated, simplified Transform implementation, make sure to fix parent rotation velocity behavior and reactivate their tests.

[ilexp]

Progress

• Started working on this is the feature/3.0/refactor-transform branch.
• Removed DeriveAngle without replacement, as it was a 0.1% feature that can be easily added with a custom Component.
• Removed EventTransformChanged without replacement for the same reason. Rewrote RigidBody update-from-Transform code to work without relying on the now removed event.
• Removed change flags, as they were no longer necessary.
• Attempted to simplify velocity calculations to operate in world space only, but reverted because derived velocities wouldn’t work that way.
• Attempted to move velocity calculations into a separate VelocityTracker component, but reverted for complexity reasons.

Immediate ToDo

• Consider simplifying velocity calculations into using a “last pos” / “current pos” form, and velocity information into world space only.
  • Movement doesn’t update last values, generating velocity.
  • Teleportation updates last values, resetting velocity to zero.
  • This will lose pre-teleport velocity information, but is that really an issue?
  • If it is, teleport updates could still update last values to match, so velocity is retained.
• Investigate whether ICmpUpdatable can be removed from Transform.
• Investigate removing absolute values from Transform.
• Consider renaming all “RelativeXY” style properties and methods with “LocalXY”.

[Barsonax]

Some work has been done to make the transformation methods (like GetLocalPoint) faster in #595. Notably sin and cos values are now calculated when the rotation changes in order to prevent recalculating these everytime you had to transform a point. There might be a bit more to gain but the end result is these methods now execute in less than 10ns at the cost of having to calculate these when changing the rotation. I think this will help alot in keeping the performance high when if remove the absolute values.

A observation I made while rewriting the transformation methods is that writting the calculation out instead of combining separate methods for each operation (like translation, rotation and scaling) can make a difference. This is a micro-optimization and it will lead to duplicated code but there might be cases where this is worth it. Do not always count on the compiler optimizing/inlining the calculations as it seems to be a bit conservative in this regard. I seen this making a difference of ~2x in alot of cases and it happens both in the legacyJIT and RyuJIT.