Avatar Bugs & Feature Requests

In order to get correct eye behavior with VRC's native face tracking, eye look angles sometimes need to be way more extreme than normal. Anyone who uses the avatar without face tracking will have crazy eyeballs. It would be great if we could define different angles specifically for face tracking. For example, to replicate jerry's FT template with default eye muscles, they need to look 60 degrees up, 50 degrees down, and ~57 degrees left and right. This looks perfect with face tracking on but horrible with face tracking off. (Quest pro tends to output 0-0.7 for eye direction instead of 0-1. If it used the full range, the angles would instead be 42 degrees up, 35 degrees down, and 40 degrees left and right. This is still too extreme for most avatars without FT.)

A popular use case for expressions on avatars is to do things like toggling objects on and off, adjusting blend shapes, and more. Setting up cases like these in an SDK project from scratch requires a fair amount of knowledge of how Unity and its animator system works, which isn’t always intuitive to users that are brand new to creating avatars. To help make it easier to set up common use cases like this, we’re working towards introducing a new component called the Action Driver. The fundamental idea of it is to let avatar creators bind parameters on their avatar directly to one or more “actions” that they want to trigger, which includes common tasks like turning game objects on and off. *Read more in our Developer Update .

Some people don’t have time to make all those hundreds of blendshapes for the Unified expressions, or already have an avatar that only uses ARKit Blendshapes. Please add support for ARKit Blendshapes in the built-in face tracking. That way, more people can switch to built-in and have higher quality face tracking that uses up less parameter space.

SDK 3.10.6で作成したフェイストラッキング対応アバターについて、Build & Testでテストビルドを行い、VRChat上で使用した際に不具合が発生します。 この問題はテストビルドしたアバターでのみ発生し、同一のアバター設定でアップロードしたアバターでは再現しません。 具体的な現象の説明 テストビルドしたアバターでSelfie Expressionを実行すると、口周りのフェイストラッキングだけが正常に動作せず、音声によるリップシンクでの口の動きのみしか確認出来ません。 同じアバターをBuild & Publishで正式にアップロードし、VRChat上でそのアバターを使用した状態でSelfie Expressionを実行した場合は、口周りを含めてフェイストラッキングが正常に動作します。 目など、口以外のフェイストラッキングはどちらでも正常に動作しています。 再現条件 1.SDK 3.10.6を使用してフェイストラッキング対応アバターを作成する。 Build & Testでアバターをテストビルドする。 3.VRChat上でテストビルドしたアバターを使用する。 4.Selfie Expressionを実行する。 5.発声せず口を動かし、口が動かない事を確認する。 フェイストラッキングのシェイプキーの割り当てに関する設定では部分的に欠けこそあるものの、おおよその動きを出来る程度の口の動きを割り当てた上でこの現象を確認しています。 Face Trackingに関する設定が選択可能な項目(LipSync,Eye Gaze Mode,Eyelid Type)は全てFace Trackingを使う物にしており、Face TrackingのUse All Tracking Keysのチェックボックスも有効にしています。アップロードしたアバターでは動作する事で示しているように各KeyのMutiplierが極端に低かったり0だったりする事もありません。 なお、デバッグ画面のFace Trackingの画面ではJawOpenなどの値が口の開閉に応じて正常に変化することを確認しており、フェイストラッキング用のパラメーター自体は不具合状況下でも動いてはいるようです。 Description I have encountered an issue with a face tracking-enabled avatar created using SDK 3.10.6. This issue only occurs with avatars built using Build & Test. It cannot be reproduced with the uploaded version of the same avatar using identical settings. Details When I activate Selfie Expression while using the test-built avatar, only mouth-related facial tracking fails to work correctly. The only mouth movement I can observe is from voice-based lip-sync. However, when I upload the same avatar using Build & Publish and activate Selfie Expression while using the uploaded avatar in VRChat, facial tracking works correctly, including mouth tracking. Other facial tracking features, such as eye tracking, work correctly in both cases. Steps to Reproduce 1.Create a face tracking-enabled avatar using SDK 3.10.6. Build the avatar using Build & Test. 3.Use the test-built avatar in VRChat. 4.Activate Selfie Expression. 5.Move your mouth without making any sounds and observe that the avatar's mouth does not move. Additional Information Although some of the facial tracking blendshape assignments are not yet implemented, I have assigned enough mouth-related blendshapes to reproduce most of the mouth movements. I confirmed this issue with that configuration. All available settings related to Face Tracking (LipSync, Eye Gaze Mode, and Eyelid Type) are configured to use Face Tracking. The "Use All Tracking Keys" checkbox is also enabled. As demonstrated by the fact that the uploaded avatar works correctly, none of the multipliers for the individual keys are set to extremely low values or zero. Additionally, on the Face Tracking debug screen, I have confirmed that values such as JawOpen change correctly in response to mouth movements. This indicates that the facial tracking parameters themselves appear to be functioning even when the issue occurs.

不明

With the new Native FT update, windows build 1937, I've been having an issue where remote clients see my avatar's eyes with set random offsets. Locally, everything is 100% perfect all the time. Only remotes have this offset issue. After tracking the issue down, I've found that if I disable Eye Look completely in the VRC Avatar Descriptor, the offset no longer happens on remotes. (See included VRC Desc picture for broken version) It appears if you drive your own eye look bone rotations in your own animator while Eye Look setting is enabled (even with Eye-gaze field set to Face Tracking ), an offset is applied to remotes when your avatar is loaded in. Possibly an additional problem that I have 'none' set as my eye bones (defaulting to use Unity-Avatar's set Eye Bones when none?) If I had to guess, when the remote loads in your avatar, the stimulated Eye-Gaze functionality is on by default applying bone rotations and/or Eye Look param value changes. Then, the avatar is initializes with its networked params. Which freezes the simulated Eye-Gaze baking that offset into the remote user's avatar. This offset may be baked into the bone rotations, or the Native FT Eye Look parameter itself. If this issue is an intended conflicting behavior, perhaps a warning help-box in the VRC Avi Desc and an additional note in the documentation, would really help. Reproducible by: Use an avatar that uses bone rotations for its eye tracking. (you can use my linked avatar) Enable Eye Look with Face Tracking Eye-Gaze setting enabled. Drive your eye rotations via Native FT Eye Look params. Join a world with another remote user. Have the remote user observe the potential offset in the positions of the eyes. Included video: Note how when I switch avatars, the Remote eyes are completely different than the local. Including the ears rotations as they are also driven by Native FT Eye Look params. This public avatar uploaded with Eye Look enabled demonstrates this issue well. (yeah its creepy xD Just a stripped down version of my avatar): https://vrchat.com/home/avatar/avtr_b1e1f772-1b05-4556-965c-1ddeb5a8a0fc

In many scenarios, we could reduce the number of contacts required for systems by a factor of 8x or more if receivers exposed more information about the current collision. This is very necessary to avoid the undocumented vrchat "hard nearby contact limit." This additional information could be exposed as parameter suffixes, just like _Stretch on physbones. Specifically, these parameters would be very, VERY useful, and allow for an ENORMOUS reduction in contacts: * X, Y, Z offset of the nearest collision in world units but LOCAL rotation (for example, z should be "forward" of the contact) * Whether the nearest collision is self or others (or world?) * Velocity of the proximity (change in collision proximity since last contact update / time delta, this is very difficult to calculate in animator since contacts do not always update every frame) * Velocity of the sender (change in sender position since last contact update / time delta) * Matching tags of the nearest collision. This could possibly be exposed as multiple bools <receiverparam>_Tag_<tagname> = 0,1

SDK 3.10.6 A child PhysBone is still being affected by its parent PhysBone, even when the parent PhysBone component is disabled and the parent is configured to ignore the child. The child's physics behavior does not work as expected.

On worlds, it has a counter for how many people both visit and favorite it, and as an avatar creator myself, I would LOVE this same counter for public avatars just to see first hand how many people wear or fav my avatars.

Same issue when preloading the big worlds, when player/others have changed the avatar before preload is finish, game will keep loading the world anyway, and then avatars. It's understandable avatars with accessories being loads the last, but the local avatar(not cached?) is another thing, it should load first no matter what(which usually not issue unless player use accessories), otherwise in bigger lobby(or slow internet) it will surely cause issues(and more since there will be more accessories in the future) since you will have no idea how yourself looks like when people came and greets/talk to you. The percentage bar also mislead since it will show the loading progress for whole instance(until everyone joined before you finished unless culled) instead of the actual progress to your own avatar loading.(build 1854)