Fixed (1.20.77.9)(Desktop Mode)Joints switching to parent link(none)

[RandomVAMUser]

So i am having this issue since 1.20.77.2 but wasn't fully aware of it at first.
Although there are some reports about desktop mode, but not sure if related to this issue so i decided to report it anyway.
(also not sure if related to Input.mousePosition>Input.GetAxis change, since that semi-broke prestigitis_DesktopClothGrab plugin)

Bug:
Kinda hard to explain but, during scene edits i noticed hand joint was getting changed to parent link (none) from "on" state for some reason.
At first i was sure something was wrong with my vam client or plugin...
but after some testing today on 2nd fresh 1.20.77.8 client with default.json scene i managed to repoduce it constantly
with most joints i tested/moved around (hands, elbows, chest)
Although still not 100% sure what is actual trigger for this to happen,
is it mouse (mouseGrab) drag/rotation then gizmo (selectionHandles) drag/rotation or de-selecting and selecting joint duging drag,
but eventually after moving joint around it will switch to parent link (none).

How to reproduce:
use desktop mode
load MeshedVR\default.json scene /it can also be new empty scene and new person atom
switch edit mode > toggle targets "T"
select right hand joint
start moving hand around with gizmo or mouse grab rhand joint (through gizmo, or while deselected joint...not sure what trigger is)
eventually after some moving around hand should switch to parent link (none)
optional: add link to something (example: person > hip) but don't actually link it, so you can see when link to atom line disapears and it switches to parent (none)

so far i managed to switch almost from any state (on, comply, off, parent (with link), hold, lock) to parent (none)
except from physics link, for some reason from physics link it sets it to physics (none) instead of parent (none) but it still clears link atom.

EDIT: After more testing
sadly it's not only joint related....it appears to be any node
I just managed to switch AudioSource, InvisibleLight and Cube to parent (none)

But it appears to be only in center of node/gizmo where selectionhandles and mousegrab links are (ontop/behind) and not outside.
After zooming inside cube node i wasn't able to switch state when draging outside
only once i started clicking/draging in center i was able to switch from on (invisiblelight) to parent (none) state.
Tryed to avoid gizmo xyz position/rotation, mainly focused on entire node dragging to force switching state.

 

[meshedvr]

When the mouse or VR controllers "grab" a node, they temporarily change the state to Parent Link and link them to the mouse/controller. When released, they should change back to original state. Somehow this is not happening in some cases. I'll see if I can replicate.

 

[meshedvr]

Unfortunately I can't seem to replicate this in 1.20.77.8. There was some minor changes in 1.20.77.6 related to grab to allow a node in lock state to preserve lock-level spring/damper force while being grabbed, but I just reviewed code and I can't see any reason the mouse release doesn't return the node to it's previous state every time.

 

[RandomVAMUser]

Unfortunately I can't seem to replicate this in 1.20.77.8. There was some minor changes in 1.20.77.6 related to grab to allow a node in lock state to preserve lock-level spring/damper force while being grabbed, but I just reviewed code and I can't see any reason the mouse release doesn't return the node to it's previous state every time.

Don't think it has anything to do with physics settings of frametime.
(Tested windowed, fullscreen, 60fps cap/144hz vsync/uncapped/various physics settings, result is always the same.

Here are 2 quick example videos
sorry if quality is low (used builtin radeon recording), switched to hevc codec on second video.
also don't mind quick mouse movements (i needed to force it, usually it happens on slow edits)

example1: empty scene with random atom node edits
2021.02.20-16.32_clip_1_clip_1 .mp4

example2: default scene with person joint edits
2021.02.20-19.27 .mp4

 

[meshedvr]

I was able to see from the 1st video that it happened when using the selection handles. And it appeared that when it happened the node did not actually move and was not attached properly to the selection handles. When released it caused it to go to the parent link to none state. That is helpful info, and I'll try to replicate.

 

[meshedvr]

Oh I see you locked it 1st which is why it was not moving. I was thinking that was part of the issue. Does it only happen when the node is locked?

 

[meshedvr]

I was able to replicate. Now I have to get it to replicate in Unity Editor so I can debug what is going on.

 

[RandomVAMUser]

I was able to replicate. Now I have to get it to replicate in Unity Editor so I can debug what is going on.

That's great news, started to think something was wrong with my mouse drivers/OS inputs.

Oh I see you locked it 1st which is why it was not moving. I was thinking that was part of the issue. Does it only happen when the node is locked?

I only locked it for "ease of showcase" in video

so far i come to conclusion that:
-locking or unlocking xyz position/rotation has no effect
-using any state (on, off, comply, parent, physics, hold, lock) still switches to "parent" (none) or "physics" (none)
-no need to add any "link to atom" (added for better showcase), still switches
-using atom/node with collision and physics or without them (example:VariableTrigger) makes no difference
-something changed between v1.20.1.5 and v1.20.77.2 (thats causing this issue)
in relation to inside of gizmo selection (where "selectionhandles" and "mousegrab" overlap)
grabing node outside gizmo where only "mousegrab" is, it always returns to previous state on release (from parent/physics)

 

[meshedvr]

I have this fixed in upcoming patch.