Report a Bug
Please check out the following rules and use the provided template when posting a bug report! Off-topic posts will be deleted.
Avatar arms often can't move while in chair or ingame menu
Version: 848 This is locally a very old bug, but it became a problem with Networked IK update: before Networked IK, the issue would only appear to the local player... Anything that locks my player capsule (chairs, ingame menu) will restrict arm movement and move my arms to the side if a given arm moves too far from the player capsule. I understand this arm locking behavior is useful to prevent issues when a controller loses tracking. I am requesting that arms move to the side when too far from the head, rather than too far from the player capsule. As an example, this is infuriatingly frustrating as a fullbody user where I might be "seated" but offset from the center of the chair, lying down or otherwise trying to reach over to give a head pat, and my arms fold down to my side, preventing such non-verbal social interaction from taking place. As a related bug, I do not like that menus/chairs lock my avatar chest orientation (especially in full body), and it causes the avatar to behave in creepy ways if I turn around while seated or with my ingame menu open (head goes backwards, arms swing around the wrong way). Expected behavior would be to allow twist of the avatar chest (at least in full body mode) I believe these two cannys may be related:
[845] Avatars with an Active Blendshape causes a significant loss of performance
VRChat 2019.3.1p2, build number 845 (Pretty sure i first noticed this issue early this year) Specs Windows 10 Enterprise i7 4790k 4.4ghz Asrock z97 pro4 GTX 980 ti 1286mhz ddr3 2600mhz Tested with Oculus Rift&Desktop (Tested with lipsync&blink) 1.More polys on the skinned mesh containing the active blendshape comes at a very significant cost 2.Normals and Tangents contribute to the performance loss which is derived from polys hence more polys=bad (they both contribute a significant cost) 3.even if you have zero normals and tangents it will still affect performance just at less of a cost 4.the difference between 10k and 20k polys is quite significant (perhaps the issue is linked to that) 5.Separating meshes for blendshapes to reduce polycount for active blendshapes helps significantly 6.Mirrors and cameras recalculate it 7.the quantity of shapekeys and vertex groups seem to make a negligible difference "if any" 8.Performance loss isn't local tldr. ActiveBlendShape+ManyPolys=bad Steps for reproduction: 1.have a 60k poly skinned mesh with an active blendshape (doesn't have to be 60k but higher the more obvious the loss) 2.disable any active blendshapes and you should see a gain (Blink will always be active if your mesh is named "Body" and has shapekeys) // more Mirrors will give you an easy to see result theoretically or from what i've read about blendshapes it shouldn't be creating much of an impact if any Ultimately this loss could be "working as intended" but i doubt it // Image with the correct formatting for the post
Load More