Avatar Bugs & Feature Requests

Automatically trigger a photo every 'user-selectable timeframe (~3-5 predefined values)' until manual stopping (or the storage-device is full [bursts]) TLDR#2: So you dont have to cramp-grab the cam-UI while smashing the trigger every second just to end up with a scuffed "hand in picture"-pic. Trash/Keeper-Ratio: 75%|25% Attached a couple "cam-grab-cramp" jank-piXx - can add like 200 more if ya want me to! :P THX <3

The expression menu lacks various controls types and features used by VRChat's native Action Menu, limiting our approach to creating more complex toggles that depend on one another or simply to provide clearer intent/description to users. Some of the features missing include the following: * Making a control unclickable (to indicate it depends on another function, typically another toggle, such as the various personal mirror settings only being accessible once the mirror is shown, but also some of the action menu settings depending on whether you're in VR or not). * Control tooltips (as used by the Custom Emojis and stickers controls when you're not subscribed to VRC+) Alternate toggle looks: * On/off capsule instead of the spinning circle overlay (support for icons would be a bonus, with a smaller capsule and the option to choose whether it appears above or below the icon) * Alternate icons (similar to the microphone and gestures toggles)

When opening a radial menu, the animation visually play from 0 to 100 lightning fast, then settle at the value set prior the opening or not. Instead of being at the normalize value set locally. Those issue only occur remotely. No difference when using a single state or a blend tree.

I'm aware that we have the avatar scaling parameter exposed and can use them to drive other things, but the ability to do the opposite would be incredibly useful. Example case: I have an avatar that has a werewolf transformation. Ideally, part of the effect would be having the avatar slowly grow from 1.47 meters to 2.2 meters tall. Currently, this is impossible as setting parameter drivers to the scaling parameters do nothing ingame (even though they work fine in editor) Avatar scaling is already something we have direct control over in our menus. There is no reason we should not be able to write directly to the parameters themselves.

Yesterday I had to download an update to start the game. When I did, I noticed that it ruined all my avatars - my hair doesn't move in any of them. Neither in the old avatars I made a few years ago, nor in the newer avatars. The best thing is that the dynamic bones work normally for the person I made avatars for in the same way. Only for me, none of them work. I didn't change anything in the avatars. When I put on avatars from the ''test'' tab - the bones work normally. But when I re-upload the avatar via Unity - nothing works. The hair doesn't move. Will there be an update that will fix this? Do I have to fix each avatar one by one? I have a lot of them, it will take a lot of time!

I recently found out about Thry's Avatar VRAM Calculator. I didn't really have any idea that I should be looking into how much VRAM my models were using before uploading them. I realized this week that most of my complex models could easily go up to 800MB in VRAM with all features enabled. I feel like I would have made a more conscious effort to keep this number low if it was made aware to me via the SDK. It is really nice to know how bad my model could impact others with these metrics. Thry's VRAM Calculator very bluntly let's you know how much Video Memory is being used. Please add some form of metric for this with the Avatar SDK or Creator Companion.

Like visemes, allow us to add facetracking blendshape options for generic facetracking with an autofill option. This will save us from having to make much of this on our own and take up the 160 or so parameter slots.

The idea is that there should be 2 different local modes: Local-to-Touch: This behavior would allow avatar creators to make things on their model that remote players that interact with the contact would only see. So as an example, if there's an animation on my model that turns a cube from red to green, only those that touch the cube would see the cube turn green, while those that aren't touching it would see it red. This would behave similarly to the VRLabs Selective Animation Prefab without needing the Final IK components to do this trick. (Source: https://github.com/VRLabs/Selective-Animation ) Local-to-Self: This is the current behavior of local contacts, especially in regards to triggering animations that you can see for yourself.

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.

Animators area huuuge reason VRChat performs so poorly, mainly as FX layers stack up. FX layers, while cheap, adds animator idle time linearly. Blend trees while more expensive due to typecasting most times, seems to be the way to go to avoid the mass load of layer idle timers. All this comes down to Compute Time, it can be labeled as "Active Animator Time", measured in either Microseconds or Milliseconds. This can be done on the server as animators are single thread and most single thread workloads on servers are generally about as slow as a mid-range VR PC, and thus the time it takes to compute on the server then gets graded into Excellent, Good, Medium, Poor and Very Poor ranks, with a hard compute time limit (Medium or better?) set on mobile platforms like Android, iOS, and Quest Standalone which don't have as much CPU horsepower.