Avatar Bugs & Feature Requests

Current behavior: When a self global collider is in contact with a Physbone where Self Collision is allowed, disabling Self Collision will still allow the global collider to collide until it is no longer in contact with the physbones. Expected behavior: The self global colliders should not collide with the Physbones when disabling Self Collision. Current behavior: When a self global collider is in contact with a Physbone where Self Collision is not allowed, enabling Self Collision won't allow the global collider to collide until it is no longer in contact with the physbones. Expected behavior: The self global colliders should collide with the Physbones when enabling Self Collision. Here's the avatar ID for testing: avtr_d34c9e59-4083-4433-bfa4-02a337132cd0

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.

While working on animations scaling with the new avatar scaling parameters I noticed a issue. the VelocityX and VelocityZ were being clamped between -4.17 and 4.17 even though the avatar is moving much faster. https://www.youtube.com/watch?v=C_kmAlCxHOM

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

opening the esc menu to close action menu pretends to close it and reopens on moving

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.

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.