Add linear and angular offset to collision component

[LeXXik]

Fixes #698

Adds an ability to set local linear and angular offsets for a collision mesh.

https://user-images.githubusercontent.com/5677782/144762092-4faf8195-bfd8-41b5-b41e-e73b41f980d9.mp4

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

[willeastcott]

Great! Thanks for this @LeXXik. Some comments:

1. Why has package-lock.json changed in this PR?
2. _updateDynamic and _getEntityTransform are very sensitive to performance changes. I'm wondering if it would be useful to have a boolean on the collision component isOffset which can be used as a if statement test in those two functions. This would allow the fast path to run for what I suspect will be the majority of cases. You could update isOffset on every set of linearOffset and angularOffset.

[LeXXik]

1. No clue why it was included into the commit, I thought it would be ignored. Had to check before pushing. Will restore the original version.
2. Good points. Will incorporate.

[yaustar]

Is there a need to recreate the physics shape? Can the offsets be applied to an existing shape when changed?

[LeXXik]

Hey, sorry, didn't have a chance to get to back to this.

@willeastcott So, in my system I don't use the isOffset flag, since the overhead is negligible. Every bit matters though :) I agree with your suggestion.

@yaustar With the current way rigidbody and component system is organized it is not possible. Any sort of transforms, like moving a body is a responsibility of a rigidbody, which defines the body physical properties like mass and friction, as well as its transform in the physics world. Collision component should only be responsible for the physical shape of the body and the intersections check during phases. In my system the offset is handled by the rigidbody component. This also makes it easier to simply move the body, rather than generating a new shape.

In order for the shape to be moved, collision component would need to instruct rigidbody component to do so. Firstly, I didn't want to make collision component be aware of rigidbody component (even though rigidbody is aware of collision in some places). I could move the offset to the rigidbody, as I did in my system. However the engine has a special method of creating triggers, where the rigidbody component of the trigger is not exposed in the Editor. If I move the offset to the rigidbody component, I would also have to add duplicate field to collision component, so the trigger volume could also be offset.

Nevertheless, I think it is acceptable to generate a new shape here, since it only happens, when the user changes the offset values in the Editor.

[LeXXik]

How does this variant look? I've added a private proeprty _angularOffset to the collision component, to store the quaternion. The data block would keep Vec3 containing the eulers, that could be exposed to Editor.

[yaustar]

@willeastcott ?

[mvaligursky]

This has unit tests failing at the moment.

[LeXXik]

Hmm, I would hold off with merging this. Currently following PRs missing:

• Refactor collision component system to ES6 class to match other systems.
• Add new tests to cover the default functionality and the added offsets one.

[LeXXik]

This depends on #4144. Once merged, I will update this one.

[LeXXik]

Closing in favor #4865