Feature Requests

Physbones is really cool. In particular it has a performant set of tools that allow for avatar-avatar interaction. Please port the Physbones code so we can use it in Worlds too! It would make making many Worlds things far easier, like buttons and levers.

Articulation Body component should be added to the whitelist. The Articulation Body component is new in Unity 2020.1. https://docs.unity3d.com/ja/2022.3/Manual/class-ArticulationBody.html This component is suitable for creating articulated arms, etc., and allows for more precise and stable movement than the traditional RigidBody/Joint connection. With this component, flexibility of mechanical movements such as robotic arms, which previously could be performed only by baking with animation or by somehow connecting RigidBodies, will be greatly increased. Especially, RigidBodies were undesirable in terms of both functionality and performance, as their movements became very unstable when many RigidBodies were connected together. Although gimmicks such as sub-arms are popular in avatar gimmicks, they are currently confined to following the arm with Constraint or playing back baked animations, but with the implementation of Articulation Body, more complex movements are expected to become possible. In addition, more accurate simulation of joints may enable manufacturing and other companies to demonstrate their products and manufacturing processes on VRChat. https://blog.unity.com/ja/industry/use-articulation-bodies-to-easily-prototype-industrial-designs-with-realistic-motion-and Translated with DeepL.com (free version) ------------------------------------------ Articulation Body コンポーネントをホワイトリストに追加してください。 Unity 2020.1から新たにArticulation Body コンポーネントが追加されました。 https://docs.unity3d.com/ja/2022.3/Manual/class-ArticulationBody.html これは多関節のアームなどを作るのに適したコンポーネントで、従来のRigidBodyとJointの連結よりもより正確で安定した動きを実現できます。 これが実装されることで、従来アニメーションでベイクするか、RigidBodyをどうにか連結して実現するしかなかったロボットアームなどの機械的な動きの自由度が遥かに上昇します。 特にRigidBodyは多数連結すると動作が非常に不安定になるため、機能的にもパフォーマンス的にも好ましくありませんでした。 アバターギミックでも、サブアームなどのギミックは人気ですが、Constraintで腕に追従させるかベイクしたアニメーションを再生するくらいが現状では関の山ですが、Articulation Bodyが実装されることで、より複雑な動きが可能になることが予想されます。 また、より正確なジョイントのシミュレーションによって、製造業などの企業が自社製品や製造過程などのデモをVRChat上で行うことも可能になるかもしれません。 https://blog.unity.com/ja/industry/use-articulation-bodies-to-easily-prototype-industrial-designs-with-realistic-motion-and

VRCStation needs an alternative for many reasons. Here are some: Too many issues with the introduction of every new feature. Too many undocumented behaviors which seem to change from (client) update to update. Full of difficult-to-reproduce, obscure bugs that are much too time-consuming to debug for more casual creators. Excessively sensitive to implementation and usage factors to the point of total absurdity (Try putting an Udon behavior on the same object as a Station and writing to another Udon behavior's variable.) Changes behavior based on the number of people in a world. (I've seen this several times and it breaks the game.) It doesn't even know which player is sitting in it. Solutions to some Station issues are already in the SDK but not implemented apparently such as the animator fix for full body tracking which exists in the Avatar SDK but is missing in the World SDK. In practice, UDON Solutions and workarounds to VRCStation issues can work less effectively over time, demanding constant maintenance and causing worlds to stop working entirely. PROPOSAL: Because numerous existing worlds currently make (hard fought) use of VRCStation's quirks for actual features, you can't simply get rid of it, as this would break a huge number of very cool worlds. Instead of re-engineering the existing VRCStation (nobody wants that!), Create a brand new VRCStation alternative and creators may choose between the two (an extremely worthwhile choice to present compared to the alternative of not fixing anything). This new VRCStation2 should have the following: The Player must never be misplaced or "thrown" because of playspace origin or other factors separate from and totally irrelevant to the transform of their head. Players must always be positioned where they are expected to be at all costs even if it hits the frames a little to correct it (because the UDON acrobatics we have to do to make this happen without this assurance are going to hit frames harder anyway. Nothing is being saved by doing this quickly but incorrectly. I cannot stress enough how important this is.) The Station must have a public variable or method by which to get the VRCPlayerApi object of the player seated. The Station must be movable by any mechanism by which a GameObject can be moved (Animation, RigidBody, updating the value of the transform position/rotation), with no exceptions or conditions. Usage of this must be as simple as possible with no hidden/undocumented behaviors. The Station must not immobilize the arms of a player by default. In practice, players are expected to be able to interact with things with their arms when seated so it would never make sense for this to happen without the world dev explicitly specifying it. The Station must have a facility for player exit by calling a method on it/sending an event. This is imperative for ergonomics and feature-rich worlds. The Station must have the ability to NOT restrict FBT movement, as this is widely used by many players and there are entire forms of emergent gameplay and experiences which depend on this. There is currently a community workaround for this, don't break it. Stations should be able to sync their positions relative to their host GameObject. If a player is adjusting their seat, their position should be synced because without it, players don't know where each others heads are and this interferes with social interaction. It is unreasonable to require a world dev to have to crack into Networking in order to sync the position of seats because Networking is among the most difficult parts of UDON and most world creators will just skip it if this syncing isn't included in the component (and you can't really blame them, some people just want to casually make a room with a couch or something and don't have time to learn Networking). Stations should orient the player to match the Up direction of the Station's local transform, and NOT the Up direction of the world. The current implementation which orients to world's up creates a huge amount of nauseating misalignments where players end up sideways in a seat because it's on a vehicle, if the vehicle isn't completely flat, and in-practice it is absurd to ask players to only enter a vehicle when it's on flat ground. This might be a lot of things, and in general with some exceptions, it matches the functionality of VRCStation, but the key is that the new one needs to prioritize expected behaviors and cannot have the entropic "decay" in reliability exhibited by the current one. I have spent many hours trying to drag VRCStation into doing exactly what it's supposed to do, entirely because I needed to get events from it or any myriad of other various ways it can find a reason not to work right. This component's vagaries have even evaded the skills of friends that are far better at this kind of thing than I am. This component is a disaster and it's only getting worse with time. Surely, I can't be the only one who is at the end of their patience and resources in dealing with VRCStation. So please, for the sake of future world development and the health of the platform, please consider creating an alternative to the existing VRCStation component. Thank you.

We need a South America localized server!! Playing VRC with 160ms+, it's horrible! You cant make choreography, create content (people look like dumb, or cut you while talking). And this would be a HUGE improvement for the South America at all. And if you can locate the prices since vrchat plus price is NOT located to our currency, which is R$50 (10$). It would be interesting if the price was R$25 (5$), same as discord prices like $9.99 to $4.99 in BRL would be R$51 to R$25 , this did a lot of people pay for it. So We REALLY need this changes!

VRChat is working on a new and improved version of the VRChat home world. It's bigger, prettier, cozier, and more modern. Like the previous home world, it will also be updated regularly for various events and celebrations.

Pretty simple, just reimplement a feature previously accessible by reading avatar osc config files but expose the same data in the JSON data returned by OSCQuery

The title is self explanatory

There is already a request for user-based chatbox override and integration into the safety system, both I think are very useful, but I think another option would be useful (yes I know, more options wheee) is a toggle to make the chatbox visibility respect the earmuff distance (the red line specifically). This would allow users to limit the visible chatboxes to only the users around them that they are talking to, and save them the trouble of hunting through crowds of people's selection capsules or though the social menu just to disable the voice (or in future override the chatbox) of a specific user who's doing the annoying chatbox spam stuff. it's a logical progression of the chatbox being (currently) tied to mute as they both are "user speech" mechanisms, no?

In newer versions of Unity they have developed a new package that is integrated into the engine called Animation Rigging, which adds new types of constraints and gives a lot more control in regards to creating animations and better deformation correction tools. It utilizes the Unity Jobs system so it's multi threading compatible so it could also potentially work on Quest too. Overall it would be a net benefit for avatar and world creators since this is a part of the package manager as of Unity 2020. Here's a look at the plugin here: https://docs.unity3d.com/Packages/com.unity.animation.rigging@1.3/manual/index.html Edit 1: This is not supposed to replace Final IK, it's supposed to be something to add to the current way most of us do our constraints and hopefully could also help in regards to avatar optimization Edit 2: What makes this different from regular constraints is that it adds multithreading support and adds new types of constraints that would be beneficial for things like twist bones or dampening effects. Instead of supporting the add on it may be better to implement it directly into the SDK to reduce the amount of confusion for world and avatar creators. And if implemented correctly, this can reduce the CPU overhead the current constraint system has on avatars and even as I mentioned it could mean constraint support for Quest.

I posted this on the feature request board o the vrc discord and I got some DMs saying that it’s a good idea, thought I would post it here. Basically my feature request is to add a way to see if you have mutual friends with someone, have it be a random person or some of your friends.