Feature Requests

talking with a friend, when I rejoin the world, I can hear him and he can hear me. after a while, I can't hear him and he can't hear me. microphone icon and microphone bar in the audio setting is active. video player in the world is hearable. repro ratio 4 times per 6 times. it was good when I'm PCVR. not good when I'm desktop mode.

i was opening on and checking hows online and seeing this

Y'know.. Instead of deleting what we spend time putting thought into and writing out. "You went x amount of characters over the invisible limit that we refuse to show you" Is not helpful... Like at all.

Currently, the triangle part of VRChat’s Avatar Performance Rank is misleading on PC because it creates a hard cliff that does not match real-world performance behavior. a genuinely heavy avatar can still rank Excellent, and a well-optimized avatar can still end up as Very Poor. The triangle thresholds on PC also make the system feel unfair. On PC, the official limits are 32,000 triangles for Excellent and 70,000 triangles for Good, and the triangle cap is still 70,000 for Medium and Poor. Anything above 70,000 immediately becomes Very Poor because that rank is unbounded. That means 70,001 triangles is treated the same as massively unoptimized avatars, which is discouraging and makes creators stop caring once they cross that single line. On PC and PCVR, triangles are not automatically the primary performance problem. They can matter, especially for skinned meshes and when combined with other expensive features, but VRChat’s own optimization guidance puts strong emphasis on reducing draw calls and CPU overhead by limiting skinned meshes and material slots. Each additional material slot is effectively another draw call and consumes more processor time, and material slots also drive submesh creation which adds draw calls. Texture memory and shader cost can also be major FPS killers, and these factors are explicitly not represented by the rank’s static triangle number. I also tested this in a controlled scenario: a very high-poly avatar (about 2,000,000 triangles, 1 material, 1 skinned mesh) versus a low-poly avatar (about 7,500 triangles, 1 material, 1 skinned mesh) in the VRChat Home world. The FPS difference was relatively small (about 350 FPS vs 375 FPS). This supports the point that, when materials and meshes are kept simple, triangles alone are often not the bottleneck. It does not mean triangles never matter, but it shows why a single harsh cutoff is not a good signal for PC performance. The triangle ranking needs a refactor on PC to remove the 70,000 cliff and provide more meaningful tiers. My suggested triangle tiers would be: 40,000 triangles = Excellent 70,000 triangles = Good 85,000 triangles = Medium 90,000 triangles = Poor 98,000 triangles = Very Poor Why this approach: it keeps optimization incentives alive. With the current system, one extra triangle past 70,000 immediately labels an avatar as Very Poor, so people stop caring. A gradual scale would better reflect reality and encourage creators to keep improving instead of giving up at 70,001. Finally, it is important to remember that rank alone cannot predict FPS. Because the rank does not consider shader complexity, texture resolution, pixel lights, or animator behavior, an avatar that ranks Excellent can still run worse than a higher-ranked avatar if it uses heavy shaders or excessive VRAM. Below is an example profiler graph comparing 110k, 70k, and 45k triangle models. In this test, they show the same end result in terms of performance. Even when I place 80 instances into the scene, the difference between 80×110k triangles and 80×45k triangles is only about 4%. Another test shows that a 30.000 Triangle Avatar with Unoptimized Materials can consume more GPU and CPU Usage compared to a Very Poor Avatar that has Optimized Materials but 70.001 Triangles. Thus; Is missleading.

A feature where it will appear as if you have no bio or pronouns or status or different ones entirely, until we've been friends for atleast 10 minutes (or if its a private instance like invite(+) or friends(+). This would be in "Edit Profile" and would help avoid transphobic or homophobic people or just bad actors in general. This already exists for groups and if vrchat actually decides to do this it would be GREAT! an option for this to be hidden if ive blocked someone or the other way around or both would be less extreme and nice.

As a way of reducing the amount of particle systems on an avatar, it would be nice that there is a Behavior script for the Animation Controller that allows for the complete control over a particle system. Animation Clips have a good amount of control over particle systems but lack specific functions such as duration or even complete modules like the Texture Sheet Animation module. By adding a behavior script to the animation controller, we can potentially reduce an avatar that is using multiple particle systems for specific animations, such as the Maya avatar using them for anime like emotions, to around 1 to 3 particle systems.

Currently VRChat does not support native runtime lightmap swapping. Creators must rely on workarounds such as duplicated geometry sets with toggles baked separately, or shader PropertyBlock overrides that depend on internal shader property names. These approaches increase build size, complicate workflows, and can be fragile. This limitation blocks common world features such as day and night cycles and multi scenario lighting setups. Exposing Unity’s lightmap API to Udon would enable a clean and supported solution. Requested API exposure in Udon Core requirements LightmapSettings.lightmaps read and write access Ability to assign an array of LightmapData at runtime LightmapData access Support for lightmapColor Support for lightmapDir for directional lightmaps Support for shadowMask for shadowmask workflows Renderer mapping Write access to Renderer.lightmapIndex Write access to Renderer.lightmapScaleOffset These are necessary to correctly remap renderers when lightmap atlases and packing differ between bakes. Strongly recommended additions LightmapSettings.lightmapsMode So creators can use non directional or directional bakes reliably Light probes access or swapping support LightmapSettings.lightProbes and or equivalent support This is important for dynamic objects and avatars that rely on probes Reflection probe refresh or reassignment hooks A supported way to refresh probes or reassign custom reflections after a swap to keep reflections consistent between scenarios Why this matters With these APIs, creators could bake multiple lighting scenarios such as day, night, indoor, event themes and swap them at runtime without realtime lights and realtime shadows. This reduces performance cost, avoids inflated builds from duplicate geometry, and removes reliance on unsupported shader internals. Suggested minimal acceptance criteria A sample UdonSharp script can assign a new LightmapData array, then update affected renderers lightmapIndex and lightmapScaleOffset, and the scene displays correct baked lighting for both directional and shadowmask modes.

Allow Group admins to configure the group so certain roles can ONLY host Age Verified instances. I have a group that I allow people to freely host instances using but I don't want them hosting non-age verified instances.

I am writing to request the implementation of a feature that would allow users to mute invite and request notifications from specific individuals, as a solution to the serious issue of "invite/request spam" that is currently affecting the VRChat community. ●Current Problems 1.Widespread Spam Behavior ・Certain users are repeatedly sending excessive invites and requests to the same person, engaging in spam-like behavior ・This has evolved into a form of stalking, combining activity monitoring with spam attacks 2.Disproportionate Impact on Female Users ・Female users are particularly targeted by this harassment, suffering psychological distress from persistent invite attacks ・Some users have quit VRChat entirely due to this issue 3.Limitations of Existing Features ・Unfriending or blocking users can disrupt community event management and participation ・Event organizers and community leaders often cannot fully block problematic users without affecting their community responsibilities ●Requested Feature Per-user settings to individually mute/unmute invite and request notifications Ability to block notifications from specific users while maintaining the friend relationship Flexible settings that can be adjusted as needed This feature is essential for protecting users' psychological safety while maintaining healthy community relationships. We strongly hope you will consider implementing this improvement.

When you pull up your own groups you can edit them right like hide, show to friends only, an then public but the thing is you cant tell what category each are in untill you go into the group to check. What the idea that i had was that when you pull up your own groups to what only see it pops into the categorys their put in, an shows if the group is hidden, public, or shows to friends only. Like how in the manage acounts, with the mute user, block, an mute chat box. Idk, it this was just an easy idea that i had when editing my groups. Also sorry for my bad grammar, hope u know what im trying to say :p