Feature Requests

IMU based tracking systems track in different ways than traditional ways such as Vive/Tundra where calibration is required since those trackers can be put anywhere and calibrated positions from previous sessions does not remain consistent. IMU based tracking, ill be referring to Slimevr as a im a Slimevr user, has a function where all trackers are set to one position that it expects the user to be in before tracking works, for slime this can be an I or T pose, which conveniently is what Vrchat wants as well. because of this there's no reason at all to ever recalibrate after the first time. Id just like to ask for this QOL feature after laying down twice, after crashing and calibrating twice. "Save FBT calibration" across sessions toggle please and thank you!

Its reconfiguration was unnecessary, and now every time I use it my muscle memory is all wrong. Why was it changed?! Nothing was added, they just moved things around in a way that screws with you!

Currently, sanitization is applied to bios, world descriptions, and even notes, but I believe this is unnecessary. Because of this sanitization: URLs no longer work without manual correction. Since there’s no option to open URLs directly anyway, there’s no need to intentionally invalidate them. Emojis and symbols such as arrows are removed, and even words like “mishit” become “mipoop.” This prevents clear and expressive descriptions, and I don’t think it meaningfully prevents guideline or ToS violations. Line breaks are also lost in places other than bios. Is there really a reason to disallow line breaks in world descriptions or notes? You might think this affects web security, but technically, it’s clear that a more appropriate approach than sanitization should be used. ---------------- Ja: 現在、bio、ワールド説明、noteにまでサニタイズが行われていますが、これは不要だと思います。 このサニタイズのせいで： URL が手動で修正しないと機能しなくなります。 URLを直接開くオプションがそもそもないため、わざわざ無効にする必要はありません。 絵文字や矢印などの記号が削除され、「mishit」が「mipoop」になることもあります。 これでは分かりやすい説明が妨げられ、ガイドラインや利用規約違反を防ぐ効果もほとんどないと思います。 改行もbio以外では失われます。 ワールド説明やnoteで改行を禁止する理由があるでしょうか？ Webサイトなどの脆弱性を懸念しているのかもしれませんが、技術的にはサニタイズ以外のより適切な方法を取るべきです。

Hello! I’m currently working on developing toe tracking support for the SlimeVR software. There are many SlimeVR compatible solutions emerging and available today, and hardware I am currently testing which are pushing just how small full body trackers can get which is allowing this development to be possible. As of present, I’ve been trying to see what I can push through the VRChat expression parameter system, but there have been many limitations when used with avatar systems such as full face tracking, or other third party avatar systems. The 256 bit limit fills quickly when more than a few things need accurate float parameter handling. Memory optimizers, and other systems cause the tracking over expression parameters to simply function poorly. In an ideal scenario we would want to be able to drive the toes with raw quaternions via OSC, or an equivalent tracking system. 5 toe quaternions per foot, for a total of 10 quaternions. This would allow pitch control of individual toes, and splay on the yaw axis. Another option would be two floats per toe via OSC, controlling pitch and yaw on local rotation. This would be half the data of syncing quaternions, and since toes don’t have a different roll rotation than the foot they are part of, the foot tracker would provide roll. I also think native toe control may allow for more passive avatar compatibility. If toes have been set up accordingly in Unity armature settings, they should ideally already be compatible with toe tracking. As of present, I have been able to make a tech demo that is limited to only pitch rotation on two divided halves of a foot's toes, and it requires making custom blend tree animations for either a curled, neutral, or tip toed state. It took considerable effort to optimize the parameters to have access to 4 total floats of syncable data among other avatar options such as face tracking, and there’s more nuance I would want to capture without having to compromise on other avatar features. Toe support currently requires building an avatar that is compatible with the expression parameters we’re testing with, which may not be very accessible to most people currently. Another thing that might be fun with the addition of native toe support, but potentially out of scope, is allowing toes to grab objects similar to hands (fully curled toes, grabbing). The thought of people handing somebody an object or shooting a weapon with their feet is the kind of silly thing that people would probably find amusing. Current tracking demonstration working with the present limitations we would like to move beyond. https://youtu.be/7L01RTmJWdE

We don't need more avatar slots, we need more world slots. Especially for those of us who like to explore.

Please make the FUNCTION buttons easier to press. Sit/Stand and Respawn buttons are now too small. In three-point tracking VR, Sit/Stand buttons are used frequently. Respawn is the same across all platforms. But on the latest QM, they have been changed to a small rectangle pane. It's become significantly harder to press. related canny: https://feedback.vrchat.com/open-beta/p/1744-improve-qm-launchpad-ui

## Problem Coordinating identical camera angles between multiple users is slow and imprecise. Creators, photographers, streamers, and event staff currently align by hand or exchange coordinates, which breaks framing and continuity. ## Proposal Provide a command to place my camera at the exact position, rotation, and FOV of another user’s active camera. ## Suggested UX User Quick Menu → Select User → Camera → Match Camera -Position Options: - Include rotation ✔︎/✖︎ - Include FOV ✔︎/✖︎ - One-time snap or follow mode (continuous sync until toggled off) Rules and Permissions Target must have an active, shareable camera. Consent toggle on the target side: “Allow others to match my camera.” Respect privacy/visibility settings and world permissions. World creators can disable this feature per world. ## Why This Matters Faster multi-camera setup for events and shoots. Consistent framing across users for recordings and streams. Reduces coordination overhead and misaligned shots.

If there are buttons or chairs next to you while calibrating full body, you will trigger them. Please disable them, so we dont hop onto chairs or activate things unintentionally.

Thank you for your continued work on the development and maintenance of VRChat. Currently, VRCStringDownloader, VRCImageDownloader, and VideoPlayer all enforce a 5-second delay between requests. I assume this restriction exists primarily as a security measure — to prevent worlds from transmitting data externally without user consent — and I fully understand the reasoning behind that design. However, this restriction currently applies globally across all domains, and that behavior is causing significant usability issues in practice. For example, if an asset in a world includes components that use these downloaders, they all share the same cooldown timer. As a result, even content that should load immediately upon joining the world may be delayed for several seconds — or even minutes — depending on how many downloader requests are queued. In extreme cases, if just one asset tries to load 30 images at once, the 5-second global cooldown means those requests could take up to two and a half minutes to complete. This delay cannot be avoided by world creators, since the restriction applies globally and affects all content equally. To resolve this, I suggest keeping the 5-second restriction but applying it only per domain. If requests are sent to different domains, there should be no need to throttle them, since doing so would not increase the risk of data exfiltration. This change would maintain the intended security benefits while greatly improving usability and load performance. I would greatly appreciate your consideration of this improvement.

Can VRChat save the state of your trackers position in order to not need to calibrate should the game crash? This can also be useful even if someone puts on trackers the same way as they have in the past, worst case scenario they can still re-calibrate.