Avatar Bugs & Feature Requests

When a PhysBone component has a root with multiple children and is set to Multi Child Type = Ignore, the root bone is counted is a physbone affected bone. This makes it more difficult to split a skirt, hair setup, or similar dynamic system into multiple sections for collision optimization, because the common root transform is effectively duplicated in the count. Having an extra physbone component seems cheap in comparison to collision checks that could be saved. ## Expected Behavior If a transform is not affected by a physbone it should not be counted as a transform affected by a physbone. ## Minimal Reproduction Use the simplest possible hierarchy: * BoneParent * BoneChild1 * BoneChild2 Setup: * Add one PhysBone component to BoneParent with BoneChild1 as ignored. * Add a second PhysBone component to BoneParent with BoneChild2 as ignored. * Set multiChildType to Ignore on both components ## Expected Result PhysBones Affected Transforms should be 2 ## Actual Result PhysBones Affected Transforms is reported as 4 There are not even 4 bones to transform in this setup. ## Why This Matters Splitting large dynamic systems into multiple PhysBones can reduce collision complexity. However, the current counting method discourages this optimization because shared transforms are effectively penalized multiple times (and you get one more physbone component on top of that). ## Suggested Improvement If the root of a PhysBone has multiple children and multiChildType is set to Ignore , the root transform itself should not be counted as a PhysBone affected transform. In that configuration, the root is acting only as an organizer transform and is not part of the active simulated chain. This would: * Produce the expected result in minimal hierarchies * Avoid double-counting shared parent transforms * Better match how creators expect Ignore mode to behave ## Minimum viable fix psedocode this.affectedTransforms -= this.root.childCount > 1 && this.multiChildType == Enum:Ignore

Animated Scaling for bone with Physbone applied will Jitter and never stop moving when hit with a collider. A Prox Contact receiver is used to Scale bone size 0 - 1 Physbone are applied normally Separate both parts work. Together Physbones scale but rotation is jittering and won't go in rest state On SDK 3.10.1 and 3.10.2 broken

Interpolating float parameters locally could smooth out stuff like face tracking, which suffers from the current low update rate. Right now people use perf-costly animators to interpolate their face tracking manually.

When the following conditions are met, a PB placed under an object with a Constraint setting will not follow the Constraint’s movement, regardless of whether it is Local or Remote. (Contacts follow correctly without any issues.) An animation within the Animator manipulates the Transform of the object that has the Constraint setting. (This applies even if it's in an isolated state.) The Constraint applied to the object is in an enabled state. Once the Constraint is disabled and the animation is able to move the object, the PB starts following to the correct position. (The avatar where this bug was discovered has a somewhat complex setup, so there may be other contributing factors.) The avatar ID where the issue occurs is as follows: avtr_d45ac5bc-cb20-4bce-8c03-bf45e81f0dec SDK: 3.8.0 BuildVersion: 1628 --------------------------------------------------------------------------------------------------------------------- [JP] [特定条件下でPBはConstraint設定されたObjectの動きに追従しません。] 以下の条件を満たすとき、Constraint設定されたObjectの配下に設定されたPBがLocal/Remote問わずConstraintの動きに追従しません。 (Contactは問題なく追従します。) ①Animatorの中にConstraint設定したObjectのTransformを操作するAnimationが含まれている。 (孤立したStateでも同様) ②Objectに設定されたConstraintが有効状態になっている。 Constraintが無効になりAnimationで動かせるようになると、PBは正しい位置へ追従するようになります。 (バグを発見したアバターは少々複雑な作りをしているため、他にも原因があるかもしれません。)

In build 1101 and 1102, it seems that VRC Avatar Parameter Driver may not work correctly for a few frames after avatar loading. I made a small Animator Controller to reproduce this problem. https://drive.google.com/file/d/1ufhdX02DcTPvbLcXMyLK2Of2P1FlwbRU/view?usp=sharing This Animator Controller contains two layers: Layer0: This layer writes 1 to the local parameter Local . Layer1: This layer counts the number of frames it took for the parameter Local to be changed. I think that Layer1 should stop at state 0 because modified values will be observable immediately, but actually it stops at state 2. This behavior is different from older builds.

Follow up to previous post - issue now 100% determined. Scaling a bone in y axis (along bone length) that is a bone for a physbone root transform will cause physbone Jitter. This was introduced with the update that made boops public. Avatar was previously fine. Tested on multiple bones (ears, whiskers, hair, tongue) on a fresh upload default Awtter avatar, as well as another avatars ears - issue was repeatable in both avatars. It appears to be only the Y axis. I have not tried negative scaling values. physbone parameters not at fault. Impossible to get natural motion and eliminate jitter. Jitter frequency is high in VR, and less noticeable in desktop mode. See attached video of issue replicated on all root transform bones on Awtter.

With the recent-ish change that makes particle lights correctly count towards your total light count, I noticed a possible discrepancy with the total count. Steps to recreate: Add a Particle System to the avatar In the Particle System, scroll down to Lights Create a Point Light in the scene but outside the avatar Create a prefab of the Point Light Insert the Point Light prefab into the Light slot inside the Particle System Limit Maximum Lights to 1. Upload to VRChat Observe avatar details of avatar. Lights will be listed as 2/1 Example of an avatar that only has 1 Max Particle Light on the entire avatar but is listed as 2/1 lights in the avatar details https://vrchat.com/home/avatar/avtr_7c80a2a5-3473-421f-86ce-fdda8fa8eb3f Expected behavior: Lights should be listed as 1/1. Though I expect the 2/1 is likely due to the server-side(?) performance check adding both the light in the light prefab itself (Even though that prefab itself is not included in the hierarchy on the main avatar and is only used on the particle system) and the maximum lights in the particle system. I understand that this is a relatively niche usecase as most people would likely just use a a regular light, but having this singular light be part of a particle effect allows for some neat control of the light through manipulation of the particle. i.e. I use it as a way to add noise to the the size and intensity of the light which would be more complicated to implement using a normal light. Also, is it possible to update the performance stat calculation of SDK Test avatars to match the new behavior? It's still using the old behavior that only counts the prefab and not the particle light count itself. I need to upload the avatar to see the correct stats.

I've been noticing and increasing number of issues with physbones over the past couple of months. 1. Immobile used to work with Gravity, but now bones with gravity always shake violently while the avatar is moving quickly, completely ignoring immobile. Example: avtr_ba3daad5-0c64-4fb4-8593-38265acd9ad3 avatar uses that to determine the up vector for the cat, walking around causes the cat to jump around, it never used to in older versions. 2. Physbones resting on or inside colliders vibrate, sometimes even to the point where they seem to struggle to stay inside inside-out colliders. This used to be stable with no vibration. In minor cases this can sometimes be mitigated with "physbones as spheres", but it never used to be necessary. Example: avtr_04a9d322-e228-4934-93b1-6e20b62cfded The boxing gloves on this avatar are long physbones with squish that are held back by inside-out colliders, they now vibrate violently at all times, they used to stay calmly in place.

Remove the 10mb limit for quest avatars. Add an option for the user to select whether they want to download an avatar larger than 10mb or not. Easy solution.

When the player moves at high speed (locomotion) over about 2m/s physbones will flail around wildly. This would be acceptable except for that it also happens even if they have their Immobile set to 1. It doesn't make any difference if it is set to "All Motion" or "World". This negatively affects avatars such as avtr_ba3daad5-0c64-4fb4-8593-38265acd9ad3 which use physbones to measure the up direction. When walking briskly the angle of the measurement physbones will flail around wildly causing undesired animations. I feel like this wasn't originally an issue with physbones, and it started happening relatively recently, but I don't have any hard evidence to back that up.