Open Beta

repro steps: While in VR w/ FBT, open menu and hit the Calibrate button Notice that avatar is invisible/unloaded while in calibration state. Avatar returns when calibration is completed. I tested with many different avatars and they all exhibit this behavior when calibrating. My best guess is that this is likely a side effect of the nameplate height fix in this update as that seems to be one of the only avatar specific changes this update and it states that an avatar will remain hidden until initialized and tracking.

Eye tracking works locally on an avatar that was uploaded with that latest SDK [3.10.6-Beta.3] However remote users that are also on the beta cannot see the eye tracking. My eyes are fixed in place for remote users. However, they can see my mouth moving and eyebrows moving just fine. The eye gaze mode is set to "Both"

When wearing an avatar that uses the new FT system, other players that are on the beta will see you sunk partially in the floor. The eyeline does not line up between wearer and observer. Players on live do not see the avatar sunk down. The local wearer does not see the avatar sunk down. How far the avatar is sunk down seems to depend on the avatar's height, some are only a very subtle amount. Get an avatar that works works fine on live and beta Go to the avatar descriptor and press the Enable button in the Face Tracking section. Upload and wear the avatar, have someone on beta 1934 view you. They will see you sunk in the ground Same avatar with FT button enabled/disabled, respectively: Repro: avtr_a03379b5-9c41-4c1f-a785-b352a79d5733 Non-Repro: avtr_bfa6d206-620d-4650-a885-a851364ca8c7

Currently there is no way to view any information about the new SDK face tracking system while in motion. Please add a page to the Debug UI for the new face tracking system. Ideally it would contain: Every Tracking Key name and their value. Every Viseme Key name and their value. The Voice parameter and its value. Every Parameter Behavior and their resulting value (doesn't need to include the entire expression, just output Key/Parameter name and value). Eye rotation values. List of the modes set on the descriptor (Lipsync Mode, Eye Gaze Mode, Eyelid Type, FT Enabled, Viseme Dampen, Use All Tracking Keys). List of all Blendshape Set names and their current weight. Tracking/Animated states from the Avatar Debug for Eyes/Eyelids and Mouth. Ideally also display the current tracking source (ie: OSC, Selfie Expression, or Emulated).

With Unity’s default array fields, you can drag objects onto the array’s header to add them as new elements. However, Face Tracking Meshes array field on VRCAvatarDescriptor does not support dropping Skinned Mesh Renderers to add Face Tracking Meshes. It's a small UX issue, but users familiar with Unity expect this to work, so it's surprising when it doesn't.

Contact Receivers that send their transform matrix to a renderer, do not work locally in-game. They work correctly for remote players viewing your avatar, and they work in-engine. In-game, for the local player, the contact receiver is sending the position with your avatar in a Tpose, at the world origin. The contacts themselves are in the correct position according to the overlay, but the matrix they send to the renderer is wrong.

New portal loading screen doesn't respect the UI/Menu volume setting when muted.

This would be very useful, as currently receivers become "saturated" once a sender is overlapping with the receiver's center-point. Either local or global scale would be acceptable. Similar is already available for velocity (_SenderVelocityMagnitude), so this is just a feature gap.

If two senders have both saturated a receiver (proximity 1.0), the closest one center-to-center should "win" for Advanced Proximity / Material Contact Parameters. Currently, the result is non-deterministic. Previously, this order didn't matter, as the result was always 1.0. However, now that additional information comes from the "nearest" sender, the selected winner is more important.

This information is already being exposed to materials in _VRChatContact_Transforms. Currently, receiving this information in the controller requires using multiple sets of active contacts, plus a bunch of additional blendtree math.