Avatar Bugs & Feature Requests

Currently, avatar performance ranks tell creators whether an avatar is expensive, but provide very little feedback about the practical consequence of that performance rank. If other users hide Poor/Very Poor avatars, or otherwise do not download the full avatar, the avatar author generally has no way of knowing. From their perspective, their avatar works and looks correct. This removes an important incentive to optimize. If we somehow had access to aggregate avatar visibility statistics to the avatar's statistics/performance information. For example: Last 7 days Full avatar downloads: 8,412 Impostor downloads: 3,105 Estimated visibility: 73% Where an approximate visibility metric could initially be calculated as: Full avatar downloads / (Full avatar downloads + impostor downloads) If VRChat already tracks cache comparisons or avatar/impostor selection separately from actual CDN transfers, those would be preferable to literal downloads. The objective is to measure how often the full avatar is selected compared with its impostor, while using aggregate data VRChat already collects or can collect cheaply. This creates a direct incentive to optimize. Instead of performance optimization only changing an SDK rating from Very Poor to Poor or Medium, creators can see that optimization resulted in more people actually seeing their avatar. Performance optimization currently benefits everybody except, visibly, the person doing the optimization. Users whose clients struggle can hide expensive avatars, use safety settings, or rely on impostors. The avatar wearer may never know this happened. Aggregate visibility statistics would close that feedback loop without identifying individual users or exposing anybody's personal safety settings. These statistics should be aggregate only. The avatar author should not be able to determine which users downloaded the full avatar, received an impostor, manually hid them, or otherwise chose not to render them.

Thinking outside the box here. Everyone focuses on these extremely arbitrary feeling ranks, and I think it's the wrong way to think about the problem. Computers are not equal, so the ranks cannot have equal meaning across them. In other words, what is Very Poor to the state of the art computer is vastly different than what is Very Poor to a wireless headset, or a laptop. Why not let the host computer decide for itself based on actual realtime metrics, letting the user configure and apply rules based on that? Provide sane defaults, like other video games give you quality presets "Low, Medium, High, Ultra". Just spit balling here (and some of these exist in similar ways already) but what if I had settings like: How many avatars make an instance light, cozy How many avatars make an instance busy, poppin How many avatars make an instance overloaded, omg-furality-club-world Frame rate impact of an avatar (show the cost to draw it somewhere?) Frame budget buckets for CPU time (draw calls?) Frame budget buckets for GPU memory Report about excessive shader compilation time/frame hitches. These ranks can adjust based on how populated a world is to maximize performance. I'm in a world with 3 other people, they can be in absolutely gargantuan avatars. But when the instance starts to fill up, the game has to cut back a little, those ranks reevaluate, and I might see some avatars fall back. [Frame budget] = [Current World Demand] + [[Av1%]+[Av2%]+[Av..n%]] <= [95% total compute available] Imagine the client observes Av2 needs way more of a share of resources than everyone else, AND we've reached a high water mark, then cut Av2s share. I hope these are ideas that spark some more out-of-the-box thinking about avatar performance.

It would be good to link such build-in variable to custom camera on avatar.

A popular use case for expressions on avatars is to do things like toggling objects on and off, adjusting blend shapes, and more. Setting up cases like these in an SDK project from scratch requires a fair amount of knowledge of how Unity and its animator system works, which isn’t always intuitive to users that are brand new to creating avatars. To help make it easier to set up common use cases like this, we’re working towards introducing a new component called the Action Driver. The fundamental idea of it is to let avatar creators bind parameters on their avatar directly to one or more “actions” that they want to trigger, which includes common tasks like turning game objects on and off. *Read more in our Developer Update .

For some avatars, the audio range being forcibly clamped at 40m is rather limiting. On some avatars that are used for specific purposes, audio involving music, effects, and interaction are relied upon for making the avatar what it is. The only solution if the audio is something like a music track, or a long-range sound effect (like on firearms, a common example) is being set to 2D, and thus, global. Setting the audio to global has the opposite intended effect most of the time, switching it from being a neat addition to "ok who is playing that audio, I am disabling their avatar immediately." Now the stated reason to the clamped range of 40 meters is "limitations are in place to prevent abuse and malicious sounds." (copied from here https://creators.vrchat.com/worlds/components/vrc_spatialaudiosource/#avatar-limitations ) However, 2D audio sources are still present, making a contradiction to this. Now whether or not this idea could be used I will include it anyway; raise the limitation to a max range of say, 500 meters, with an audio setting to either stay with the clamped 40, or have a much higher max range, with intervals for those who may want something in the middle. This setting could default to the current clamped 40, and only be changed by the user to increase the range of avatar audios they would like to hear.

won,t let me make an avatar or upload one

I would like contact senders and receivers to be able to pass values from one to another. This would remove the need to have numerous receivers on the same avatar, all looking for different tags. If a Contact Sender chose to use Parameter Pass, it would send a specific value as dictated by another avatar parameter. This could be a float or integer, as boolean is already supported. The Contact Receiver would, when contacted (And the appropriate tags are selected), read that passed value and move it into an avatar parameter of it's own. If the passed value is a float and the receiver's parameter was an integer, it'd just auto convert it, but I imagine that'd be a bit of an edge case. In addition, a few added sub-parameters that could be referenced on either side would be helpful. Example - paramname_IsContacted [Bool] paramname_Velocity[Float 0-1] paramname_Proximity [Float 0-1] I think that this change would make avatar dynamics, well, more dynamic. It'd allow for cross-avatar communication, but only on avatars with compatible props and systems and such. Even just these few changes would open a boatload of capabilities for avatar creators - and if a 'standard' was introduced, maybe even World creators, as it'd allow world creators to interact directly with avatar parameters. Included is a quick mockup of the senders/receivers I drafted up.

We'll be adding a new feature to Toon Standard for recoloring the base texture with a 4-channel mask. Here's how it will work: Each channel has a separate color to use for recoloring. Recoloring is done by first converting the masked area of the main texture to grayscale and then applying the color, meaning you don't need to author your main texture in grayscale to apply recoloring. This is similar in concept to hue shift, but a direct recolor instead of a shift from one color to another. Masks can also be used for emission through an emission slider for each channel. There are two options for blend modes: Multiply and additive. - In the multiply blend mode, the grayscale version of the main texture is multiplied by the color. - In the additive blend mode, the chosen color is added on top of the grayscale version of the main texture.

Currently float and int parameters are hard-set as 8 bit parameters... This is fine for people who don't need a lot of parameters... but it uses more bit space than what is needed most of the time (as you will rarely see anyone use even close to 255 seperate values for every interger) and the radial float puppet does not allow going into the negatives despite it being synced. I think that allowing the user to use lower bit-rate floats or ints with the limiting factor being less precision, also for floats not allowing to go below 0, Example situation: Someone makes a radial float puppet that doesn't require a lot of precision, instead of using 8 bits with half of the range being unused due to a negative being involved, use only a 6 bit float that ranges from 0-1, which is still precise enough for most cases, and some cases can use only 4 bits if they need more room. (4 bits = 16 int limit, a single 0-1 float at 4 bits is a 0.0625 increment, this is still enough for most radial puppets)

Right now, bones can move totally freely, until they hit their angle limit, where they stop suddenly. It would be nice if a falloff curve could be defined, so that attempting to move a bone further towards its angle limit would actually cause it to move less and less, as though you were pulling it into cushioning which is resisting more and more strongly the more compressed it is. So, in practice, you would have to move your hand to something like twice the limit, in order for the limit to finally be reached (but moving around closer to the rest angle would look almost normal, because the resistance is smaller there). Actually, it would also be nice if this could apply to stretch/squish as well.