The AngularJointDrive's InitialTarget feature seems to be broken when the container is rotated before being instantiated

[ShinStalk]

Environment

• Code version: Controllables package v1.12.1
• Platform version: Tested on Unity 2020.3.2f1 and 2020.3.0f1
• All packages used:
  "io.extendreality.tilia.camerarigs.spatialsimulator.unity": "1.4.1",
  "io.extendreality.tilia.camerarigs.trackedalias.unity": "1.6.0",
  "io.extendreality.tilia.interactions.controllables.unity": "1.12.1",
  "io.extendreality.tilia.interactions.interactables.unity": "1.17.0",
  "io.extendreality.tilia.mutators.collisionignorer.unity": "1.2.0",

Steps to reproduce

1. Create an new unity scene set up with tracked alias and a spatial simulator with grab support.
2. Create an interactable door, following the door creation tutorial.
3. Modify the AngularDriveFacade properties of the door as follow :
   
   It should get the door to be shut (y angle to 0) at start.
4. Create a prefab from that door and remove it from the scene hierarchy.
5. Duplicate the door prefab and name the second prefab "DoorRotated". Then modify the root gameobject y rotation (not the angular facade driver gameobject). Set it to 10 or any positive value for example.
   
6. Create a script that will instantiate a prefab (that will be referenced in a public field on that script) in the scene at start and put it on an empty gameobject in the scene.

using UnityEngine;

public class TestSpawner : MonoBehaviour {
    public GameObject objectToSpawn;
    void Start() => Instantiate(objectToSpawn);
}

7. Make the script instantiate the door with no rotation first. Observe that the door is properly closed.
8. Make the script instantiate the door with a rotation on the y axis. Observe that the door will spawn opened.

Expected behavior

With both prefabs being the same but the root gameobject y axis rotation, the door should spawn with the same initial target value. The only thing changing should be the overal rotation of the container of the door parts (frame + door).

Current behavior

Now, with no rotation set is properly closed, while the door with the root gameobject slightly rotated on the y axis is opened at start.

Gif illustration :

[thestonefox]

I think this is an instantiation issue, perhaps a race condition where when the door is created by script, the order of initialisation is different in unity causing the rotation logic to not occur.

[thestonefox]

One workaround for now is set your y rotation to 0

and then in your script do:

Instantiate(objectToSpawn).transform.localRotation = Quaternion.Euler(Vector3.up * 10f);

This will apply the rotation required after the instantiation. I know it's not an ideal work around, but may help during the further investigation required for this issue.

[ShinStalk]

I think this is an instantiation issue, perhaps a race condition where when the door is created by script, the order of initialisation is different in unity causing the rotation logic to not occur.

I want to add an observation if it helps :
The door opens in the direction of the rotation. Let's say your limits are [-120,120], if you put 10°in the y axis, the door will open at 120°, but if you put -10°, the door will open towards the other direction, so it'll go to -120°.
So I didn't investigate deeply into the code but it might be that somehow the parent rotation transfers a velocity to the rigidbody and gets the door to open towards this direction.

Thank you for the workaround :)

[thestonefox]

I think this is an instantiation issue, perhaps a race condition where when the door is created by script, the order of initialisation is different in unity causing the rotation logic to not occur.

I want to add an observation if it helps :
The door opens in the direction of the rotation. Let's say your limits are [-120,120], if you put 10°in the y axis, the door will open at 120°, but if you put -10°, the door will open towards the other direction, so it'll go to -120°.
So I didn't investigate deeply into the code but it might be that somehow the parent rotation transfers a velocity to the rigidbody and gets the door to open towards this direction.

Thank you for the workaround :)

I don't think it's a velocity transfer issue. I think it's a race condition where the "move to initial position" isn't being triggered by the time the object is finished instantiated.

[ShinStalk]

I think this is an instantiation issue, perhaps a race condition where when the door is created by script, the order of initialisation is different in unity causing the rotation logic to not occur.

I want to add an observation if it helps :
The door opens in the direction of the rotation. Let's say your limits are [-120,120], if you put 10°in the y axis, the door will open at 120°, but if you put -10°, the door will open towards the other direction, so it'll go to -120°.
So I didn't investigate deeply into the code but it might be that somehow the parent rotation transfers a velocity to the rigidbody and gets the door to open towards this direction.
Thank you for the workaround :)

I don't think it's a velocity transfer issue. I think it's a race condition where the "move to initial position" isn't being triggered by the time the object is finished instantiated.

Ok I just shared a thought in case it'd help. The correlation between the rotation and the direction the door opens is still leaving me perplexed tho.