Bug Reports

One bug report per post. Off-topic posts will be closed. Only submit bug reports for builds currently marked as "public". For isolated issues or customer support visit help.vrchat.com.
[1914] Steady Cam recorded/streamed POV output feels less smooth since 2026.2.3, increasing motion sickness for 2D viewers
Since the 2026.2.3 Stable update, I have noticed that the Steady Cam POV output produces a different smoothing feel compared to pre-2026.2.3 builds. I primarily use Steady Cam as an external POV camera feed for recording/streaming VRChat events, especially clubs and other event spaces. Enabling it does not significantly change my own in-headset experience, but it changes the camera output that viewers see when watching a recording or stream. This is where the issue becomes noticeable. With the new Build, the recorded POV feed feels less smoothed and more aggressive than before: quick left/right head turns feel snappier on screen; the apparent rotation speed during quick turns seems higher; small high-frequency head movement/hitter is more visible in the footage; subtle bounces are less filtered and can look uncomfortable to watch; when UI is enabled (mic/face mirror), the UI may snap immediately / not follow the same smoothed motion as before Before 2026.2.3: quick head rotations felt more damped on screen; small head jitter was filtered more effectively; the overall POV feed felt more comfortable for viewers watching a 2D stream/recording Expected behavior: For the same input and settings, Steady Cam’s external camera output should provide similar smoothing/damping behavior as pre-2026.2.3 builds, or at least an option to restore that feel. Small high-frequency movements should be filtered more consistently, and quick head turns should not produce large unfiltered velocity spikes in the recorded/streamed feed. Actual behavior: The external POV output feels less smoothed and more responsive than before. Quick turns are snappier, subtle movement is more visible, and viewers watching a 2D stream/recording are more likely to experience motion sickness compared to pre-2026.2.3 builds. Reproduction Steps: use VRC 2026.3.2p2 Stable [1903] or open-beta [1914] in VR Enable Steady Cam Record your POV output Make quick left/right head rotations make small high-frequceny head bounces/jitters Compare the recorded/streamed footage against pre-2026.2.3 output in the attached video Video link (unlisted): https://www.youtube.com/watch?v=__qZLlO4Ohw The video shows a few comparisons between the current build and pre-2026.2.3 output. It contains on-screen text explaining each comparison, you may need to pause to read it properly. These are not perfect one-to-one recordings because I cannot record new footage for a build that is no longer publicly available, but they should illustrate the difference. Note: This is not mainly about my personal in-headset comfort. It affects the quality/comfort of the external POV camera feed used for recording and streaming. I understand Steady Cam components may have been rewritten, so this seems like a regression in perceived stability/comfort for 2D viewers watching the output. Second Note: My recordings and testing were done on the current Beta build [1914], however because the 2026.2.3 release came out in June, it should affect both open-beta and public branch. Steadycam rewrite quote: https://discord.com/channels/189511567539306508/449386885299830794/1516252086222983279 (pi on vrc discord in open-beta-discussion) tldr: The new Steady Cam implementation [1914] is more likely to cause motion sickness for 2D viewers during snappy head movements, compared to pre-2026.2.3 builds.
1
·
tracked
Avatar culling does not unload PhysBones — performance scales with total loaded avatars, not visible ones
Avatar culling hides avatars but does not unload their PhysBones. This means your CPU is simulating PhysBones for every avatar that has loaded near you, not just the ones you can see. In a populated world this adds up fast. You can confirm this with the PhysBones debug overlay — enable it while culling is active and you can still see PhysBones moving on hidden avatars. Repro: Join a populated world, no avatar limit set Hand Menu → Settings → Culling → Show Nearest X Avatars → set to 0 Radial Menu → Options → Avatar → Avatar Overlay → PhysBones → enable PhysBones are still active on hidden avatars. The debug view has a range cutoff but performance confirms they're running beyond that Hand Menu → Safety → switch to any safety preset to force avatars to fully reload PhysBones are now gone, performance improves Set your avatar limit back to what you want — performance is better, but degrades over time as new avatars load in and their PhysBones never unload Tested on: i9-12900K, RX 7900 XTX, 32GB RAM — public world, 30-40 players. in the instance pictured i went from 100 - 150fps by hiding physbones Dynamic Bones had limiter settings. PhysBones removed them, which wasn't a big deal at launch, but avatars use a lot more PhysBones now than they did back then. The fix needed: PhysBones should unload when an avatar is culled. A user-facing PhysBone simulation limit would also go a long way. Also noticed in this session many many users with physbones active for hidden meshes if some wizard can make these disable when the meshes referenced to the bones hide would also be a great optimization
2
·
tracked
Load More