I can explain what was changed and hopefully that will give some context. I made some changes In order to make "local" movement/rotation work on the new Move tab shown here:
What did I change?
When an atom is re-parented to another atom and after scene or preset load the following function is called to zero out the reParentObject transform, but this preserves the (world) positions and (world) rotations of the controls and objects that usually sit below this transform.
C#:
protected void ZeroReParentObjectTransform() {
if (reParentObject != null && !doNotZeroReParentObject) {
List<Vector3> savePosition = new List<Vector3>();
List<Quaternion> saveRotation = new List<Quaternion>();
foreach (Transform child in reParentObject) {
savePosition.Add(child.position);
saveRotation.Add(child.rotation);
}
reParentObject.localPosition = Vector3.zero;
reParentObject.localRotation = Quaternion.identity;
int ind = 0;
foreach (Transform child in reParentObject) {
child.position = savePosition[ind];
child.rotation = saveRotation[ind];
ind++;
}
}
}
Before this change, the reParent transform could have a non-zero offset from the object it was getting re-parented into. Now it zeroes these out and moves the children so they stay in same world position/rotation, but fixes the parent relative position/rotation. That allows the Parent Atom Relative movement system to work.
Based on AcidBubbles reply
Timeline animates relative to the root joint (the default Transform parent of the FreeControllerV3 gameobject)
, Timeline must be storing the positions of the control and object that sit under reParent transform relative to the reParent transform. Here is how every atom is normally set up in the hierarchy:
If Timeline is storing location of the control Transform relative to reParentObject, than yes that could be broken here. I tested quite a few scenes with Timeline and all worked fine for me. But reParentObject is normally zero-ed out relative to the atom transform, so I can see in most cases it would be fine. What can happen, however, is if the atom is re-parented to another atom, moved around and animated in parent state, or if that atom is parented back to original and animated, the reParentObject could then be greatly offset from the original zeroed transform and the position/rotation that Timeline is storing is incorrect relative to the (real) parent. It would be relative to the odd location of reParentObject. This is what has changed. I did not realize Timeline was animating relative to the reParentObject. What I *think* needs to happen to fix Timeline is for it to animate relative to what reParentObject is parented to instead. Staring in 1.22 reParentObject is always going to get zeroed out relative to what it is parented to. This allow control and object to have "true" local coordinates.
I'm not sure how to fix this on my side without backing out my change to allow parent atom relative (local) movement to work properly.
Note that new animations made using Timeline will work fine. It is only existing ones that were depending on a non-zeroed reParentObject transform that will be broken.
Also note any new Timeline animations made since the 1.22 release could break back the other way if I back the change out since reParentObject might no longer be zeroed.
