Not A Bug linkTo data is not saving to scene when [CameraRig] is the target Atom

[AlienAxeMan]

If I link an object to a tracker by setting "Link to Atom" to "[CameraRig]" and then "Link To" to "Tracker1", when I save the scene it won't include that as it does with other link data. So, when I load the scene later, the link is cleared.

I've experimented quite a bit and it seems that if I simply add the following to the object's "storables" section of the JSON for the scene, it will load and link as expected:
"linkTo" : "[CameraRig]:Tracker1"

For more context, here's a sample of the JSON as it saves now (without the link to tracker data):

{ "id" : "ISTube", "on" : "true", "type" : "ISTube", "storables" : [ { "id" : "control", "position" : { "x" : "-0.03480911", "y" : "0.822526", "z" : "-0.9369402" }, "rotation" : { "x" : "-2.224455E-07", "y" : "-1.144586E-16", "z" : "5.896271E-08" } } ] }

Here's an example of where I've manually edited the JSON to re-inject the link to the tracker:

{ "id" : "ISTube", "on" : "true", "type" : "ISTube", "storables" : [ { "id" : "control", "positionState" : "PhysicsLink", "rotationState" : "PhysicsLink", "position" : { "x" : "-0.002687752", "y" : "0.8019442", "z" : "-1" }, "rotation" : { "x" : "-2.224455E-07", "y" : "-1.304775E-13", "z" : "5.89627E-08" }, "linkTo" : "[CameraRig]:Tracker1" } ] }

Additionally, and perhaps unrelated, this "linkTo" does not appear to be exposed such that it can be set from a button action, etc. This lack of functionality makes it so there's no viable workaround currently, as there's no way (that I know of) to re-set that linkage from a button action, logic brick, or even C#.

 

[Origin69]

I've come up against this issue. I asked Ky1001 to make a change to their Headlightlink plugin to use the camera rig tacker so items linked with the plugin now persists after loading. I'm not that versed in coding, but the plugin itself has built in position offset and rotation functionality, so it can be used as a trigger target in timeline or through UI buttons to do some really useful things in VR.

Plugins - HeadLightLink

The license notation of my content is basically "CC BY-NC", but you can use it for paid content. However, please refrain from distributing it together with paid content. If the license notation seems to be wrong, it would be helpful if you could...

hub.virtamate.com

 

[AlienAxeMan]

I've come up against this issue. I asked Ky1001 to make a change to their Headlightlink plugin to use the camera rig tacker so items linked with the plugin now persists after loading. I'm not that versed in coding, but the plugin itself has built in position offset and rotation functionality, so it can be used as a trigger target in timeline or through UI buttons to do some really useful things in VR.

Plugins - HeadLightLink

The license notation of my content is basically "CC BY-NC", but you can use it for paid content. However, please refrain from distributing it together with paid content. If the license notation seems to be wrong, it would be helpful if you could...

hub.virtamate.com

Thanks for the information. I may be able to use that for some workarounds. I'm really hoping they'll fix the actual bug, though, as I'd like to use physics links in some cases rather than parent type fixed links. It also looks like it should be a super simple fix.


Edit: After exploring that plugin and poking around at some related code, I at least came upon a way for a plugin to set the "Link To Atom" and "Link To" values, which I really wanted to know how to do anyway, and should provide a decent workaround for me for this bug.

Here's a sample C# snippet for anyone looking to assign the "Link To" values via a plugin (basically you just find the Rigidbody you want to link it to, and pass that to the control's SelectLinkToRigidbody function. This example links the person's "pelvisControl" to the "[CameraRig]:Tracker2":

Rigidbody tracker_rigid_body = SuperController.singleton.RigidbodyNameToRigidbody("[CameraRig]:Tracker2"); FreeControllerV3 pelvis_control = person_atom.GetStorableByID("pelvisControl") as FreeControllerV3; pelvis_control.SelectLinkToRigidbody(tracker_rigid_body);

 

[meshedvr]

Unfortunately I don't consider this a bug as this is really just an issue with how CameraRig nodes cannot be saved and restored so links to them would not restore correctly. The reason is these nodes are controlled in real-time by the various VR devices. So the decision was to not save links to CameraRig nodes.

There is only 1 specific way you can save a scene while head is possessing something and that will properly restore on scene load.

 

[AlienAxeMan]

Unfortunately I don't consider this a bug as this is really just an issue with how CameraRig nodes cannot be saved and restored so links to them would not restore correctly. The reason is these nodes are controlled in real-time by the various VR devices. So the decision was to not save links to CameraRig nodes.

There is only 1 specific way you can save a scene while head is possessing something and that will properly restore on scene load.

I get that, but in many cases it would still restore it "well enough". My hand edited JSON experiments showcase that.

As an example, imagine a scene where there's a button to take temporary control of a character's pelvis, by way of temporarily setting the position and orientation to "physics link", then back to the previous setting ("On", "Off", "Comply", etc.). So, at a certain point in the scene's action, you take over control of some object(s) for while, do your thing, then relinquish control for the next animation, scene, etc. This is pretty simple to set up if the linkage would save/load with the scene, but prohibitively complex to support otherwise via a lot of extra UI, code, and in editor management.

I utilize a lot of linkages, even injecting them into scenes I download from the hub. Most often I use 2 trackers, with a female head and/or pelvis linked to a tracker and a male pelvis and/or toy linked to another tracker. That's four sets of two-selection linkages, or 8 fiddley actions required every time I load such a scene, which is quite time consuming and cumbersome, especially while in VR, often needing redoing multiple times for complex multi-scene setups, as you have to fix all that after every scene load. If the linkage information saved, my setup would simply allow for some speech or button controlled actions to toggle on/off the various tracker physical linkages.

Now, as I've recently discovered, I can work around this by using a plugin that basically saves and loads this linkage information and reapplies it as needed, where each action not only sets the position and rotation to "physics link" but also sets the link to atoms and receivers. That's technically viable for me, but not a great solution and doesn't really work at all for many other cases.

My main point is that in my opinion, saving and loading the CameraRig linkage information would be overall a win, even if the position and rotation may not be as expected when loading while parent/physics linked to the rig. Loading the linkage information at least is much better than nothing, even if it's not a completely accurate solution in all cases. There certainly may be other factors I'm unaware of that tip the scales the other way, though.

 

[VAMSOY]

If I link an object to a tracker by setting "Link to Atom" to "[CameraRig]" and then "Link To" to "Tracker1", when I save the scene it won't include that as it does with other link data. So, when I load the scene later, the link is cleared.

I've experimented quite a bit and it seems that if I simply add the following to the object's "storables" section of the JSON for the scene, it will load and link as expected:
"linkTo" : "[CameraRig]:Tracker1"

For more context, here's a sample of the JSON as it saves now (without the link to tracker data):

{ "id" : "ISTube", "on" : "true", "type" : "ISTube", "storables" : [ { "id" : "control", "position" : { "x" : "-0.03480911", "y" : "0.822526", "z" : "-0.9369402" }, "rotation" : { "x" : "-2.224455E-07", "y" : "-1.144586E-16", "z" : "5.896271E-08" } } ] }

Here's an example of where I've manually edited the JSON to re-inject the link to the tracker:

{ "id" : "ISTube", "on" : "true", "type" : "ISTube", "storables" : [ { "id" : "control", "positionState" : "PhysicsLink", "rotationState" : "PhysicsLink", "position" : { "x" : "-0.002687752", "y" : "0.8019442", "z" : "-1" }, "rotation" : { "x" : "-2.224455E-07", "y" : "-1.304775E-13", "z" : "5.89627E-08" }, "linkTo" : "[CameraRig]:Tracker1" } ] }

Additionally, and perhaps unrelated, this "linkTo" does not appear to be exposed such that it can be set from a button action, etc. This lack of functionality makes it so there's no viable workaround currently, as there's no way (that I know of) to re-set that linkage from a button action, logic brick, or even C#.

Thank you!!! This has been bugging me for so long. Your manual workaround works!!

 

[VAMSOY]

I get that, but in many cases it would still restore it "well enough". My hand edited JSON experiments showcase that.

As an example, imagine a scene where there's a button to take temporary control of a character's pelvis, by way of temporarily setting the position and orientation to "physics link", then back to the previous setting ("On", "Off", "Comply", etc.). So, at a certain point in the scene's action, you take over control of some object(s) for while, do your thing, then relinquish control for the next animation, scene, etc. This is pretty simple to set up if the linkage would save/load with the scene, but prohibitively complex to support otherwise via a lot of extra UI, code, and in editor management.

I utilize a lot of linkages, even injecting them into scenes I download from the hub. Most often I use 2 trackers, with a female head and/or pelvis linked to a tracker and a male pelvis and/or toy linked to another tracker. That's four sets of two-selection linkages, or 8 fiddley actions required every time I load such a scene, which is quite time consuming and cumbersome, especially while in VR, often needing redoing multiple times for complex multi-scene setups, as you have to fix all that after every scene load. If the linkage information saved, my setup would simply allow for some speech or button controlled actions to toggle on/off the various tracker physical linkages.

Now, as I've recently discovered, I can work around this by using a plugin that basically saves and loads this linkage information and reapplies it as needed, where each action not only sets the position and rotation to "physics link" but also sets the link to atoms and receivers. That's technically viable for me, but not a great solution and doesn't really work at all for many other cases.

My main point is that in my opinion, saving and loading the CameraRig linkage information would be overall a win, even if the position and rotation may not be as expected when loading while parent/physics linked to the rig. Loading the linkage information at least is much better than nothing, even if it's not a completely accurate solution in all cases. There certainly may be other factors I'm unaware of that tip the scales the other way, though.

I ended up using the HeadLight plugin as well, that's the only reliable workaround for my scene right now.

Thanks for this post!