It’s actually criticizing VRChat for not putting in the bare minimum of thought into a feature, including the value add vs. dev time, plus not making the feature accessible for those with disabilities/allowing users to tailor their experience.
But go off queen.
If this is under consideration, please please please consider letting those transforms drive shader properties (even just locally this would be huge). Components that take Transform values and output them to Custom Shader properties/Animator parameters? | Voters | VRChat
On the topic of booping. My opinion is similar to a lot of other feedback here. It just seems like really odd feature to use dev time on, as it serves almost no purpose (its like DM’s, but with no message. Just direct nothing lol).
I would like a way to turn it off globally as I can immediately see it getting super annoying, it also seems like something that would absolutely startle me from the demos. If it was just a little heart or particle effect that popped up on the menu this would be a different story. DND is not a suitable limiter for this imo. I don’t want to have to constantly be in DND. For people with wide friends lists (ie: event hosts), this could quickly become a nightmare. I also don’t want to have to be that person who, when I make a new friend, I have to tell them not to use the boop function on me. I would like a way as a player to control my experience without having to block or unfriend people who just don’t know my preferences, its not their responsibility to remember them.
Boops feels like a good april fools joke. Like a social media network that is only used to send “Yo”
We’re planning to convert constraints automatically on existing avatars, to help improve performance as much as possible. That said, there is an overhead cost for converting Unity constraints on avatars into VRC constraints when VRChat is already running, so avatars that use VRC constraints directly would get the best performance.
We’re aware of the execution order issues between constraints and avatar dynamics - we’re still looking for solutions to this, since changing the execution order in its current state would break some avatars that use constraints in a specific way.
This isn’t included in performance rankings since each constraint only modifies a single transform. Any children of that transform will naturally move with it.
Constraint groups are mainly a suggestion to not have very deeply nested constraint chains. As mentioned, we aren’t ready to talk about the specific performance limits yet, but benchmarking has been done internally and I can say that the impact is comparable to physbones versus dynamic bones.
Anything that triggers a full avatar reload would also reset the constraints on it.
Thats pretty sad.
All these years, it was hard to make objects that sustainably bound to the world AND guaranteed to be seen correctly by others.
Synchronization of constraints is desired 
Will the new constraints be available to the creators of the worlds?
I feel that the solution for the physbones would be to add something like an “anchor” component for immobile settings that could negate rotation values from the anchor source, applying physics to things later in the hierarchy like in Magica Cloth 2’s Inertia settings for Bone Physics. As for the contacts I feel that would probably be a bit more difficult to achieve, especially when by default Contacts aren’t synced unless you do some workarounds to have it sync to remote users. Hopefully it’ll be figured out wish y’all the best with the development on VRC Constraints. As a bonus could y’all make some icons for the scripts?
Ship the merch to Brazil, c’mon 
Sorry, missed this one earlier - our focus for now is matching Unity’s constraint components, but further features like this may be considered in the future.
VRC constraints will only be part of the avatars SDK for now.
Thanks! I’ve passed on the comment about icons.
VRC Constraints … great addition
the Boop system … Why??? it only adds more unnecessary network load meaning more costs on VRC side which will be pushed to us the user
How about instead add distance based LOD systems where others turn into the imposter if they are far away.
In-game support for Webcam based tracking would also be nice (for those that can’t afford FBT tracking devices) to look into as external solutions required reduces performance drastically on low/mid range systems.
The network overhead is very low, after all there is no need for constant updates.
Also the LOD has been changing to a diamond shape for a long time now, and becoming an “ugly” impersonator doesn’t seem to be much of an improvement to me.
Also this specific tracking software has nothing to do with the game itself, it’s a matter of interaction between the outside and steamVR.
This is way beyond what VRchat is supposed to do, you can’t realize the complexity of steamVR.
I am really curious as to what gives you that impression. Performance overhead sending some tracking numbers to vrchat seems minimal to me.
So, this has been asked many times now on X without response. I’m hoping to get an answer here. What will happen to all the currently already uploaded avatars that exceed these limits? Will the owner still be able to use them and they’ll be visible locally to them, but hidden from others? Will they just disappear from your account? PLEASE, some clarification on this. Everyone is all hype about this optimization, but there ARE legitimate uses for massive avatars in private worlds for use in photography/cinema/performance scenarios. I get that these avatars cause issues for others in public settings, but just like over optimized worlds, sometimes quality and detail or functionality have priority over framerate.
This feature can be great without an option to turn off ONLY, IF YOU’LL MAKE A messaging system and the emojis will be at the DM. (On the menu) Just like Steam has it with the cool effects you can buy for points.
Seeing the feature the way you want to implement is irrelevant.
If I had to guess they’ll just show up as a robot.
I would also like some clarification on this as well. As much as I want to have better performance overall, I also understand why some folks have such avatars in other than public instances as mentioned.
boop to you
The core part of this question was answered in the previous developer update, you can see it at Developer Update - 14 March 2024 - #149 by euan. On it failing checks it will still be visible in your avatar list however you will be unable to switch to it and will not be visible to others. Currently the plan is to have local test avatars not be restricted by the limits to allow for quick iterative testing.
If you have example avatars for the use cases you list please do pass them along, as currently we have no example avatars in which would go over the reduced limits and could not be optimised to below the limits
Whilst the feature does some rather novel, boops are something that I can see becoming abused easily. Any automated systems in place to prevent abuse will most likely only result in a slow stream of constant boops instead of a massive on pour of them. “Simply unfriending them” is not a solution as they may be someone you do not want to unfriend.
Please consider allowing at MINIMUM the ability to specifically disable receiving these. These kinds of things are incredibly distracting/disruptive to me and I know I am not the only one.
The only true way to prevent abuse/disruption is thorough user control of social/general notifications. Granular user control for notifications is only a good thing, regardless the development cost.
