Developer Update - 16 March 2023

Official Dev Updates
102

No plans to do so. We already limit maximum number of active audio sources in various ways due to both Unity limits and performance concerns-- opening this particular can of worms would make an already not-super-great problem significantly worse.

If you have a performance or experience that requires more than what an avatar can carry with it, I’d encourage you to put it into a world instead! If you’ve never done it before, that’s a great opportunity to learn.

We don’t make that assumption, which is why we’re making changes to our recommendation as previously noted, and are actively developing systems to help users with lower-bandwidth connections. :sweat_smile:

edit: as a sidenote, it’s usually better to account for median rather than mean when you’re talking about continuous, distributed values that have a tendency to have an overinfluential lot of upper and lower outliers like country-wide bandwidth. Per the linked site you provided, the US has an average of ~10-13 MBps, but the median is ~25mbit. You also have to take into account that our userbase (both current and potential) is a subset of this data.

Not that I’m saying broadband in the US is fun times. I’m personally stuck with Comcast no matter what :upside_down_face:

3 Likes
103

I honestly would have preferred this to be open for a lot of people so for those that make worlds or VRChat content can have their Patreon or booth pages directly linked. This would be extremely beneficial especially for Avatar Museum.

1 Like
104

I like what Avatar Museum has done in the latest release. There is a helper application that scans the local log file for log entries that have a special key and a URL, and then the helper application opens the browser.

When it comes to the vket markets its very clear, with a confirmation that a URL will open. If a browser tab opens on my PC when I’m in VR, there is too high of a chance I wont notice it for awhile, so hopefully care is enforced.

1 Like
105

I feel like I have to point out that most people use Crunch Compression because of the Quest file size limit of 10MB.

Everyone would love the improved performance and not dealing with said limit, but most of the time avatars do not support Quest, and the ones that do usually only technically support it, avatar uploaders still have to do all the work themselves.

  • Create new materials and assign Quest-compatible shaders, you better hope there’s no shader-based transparency or complex stuff that the 3 basic shaders can’t replicate, Don’t duplicate the existing materials or use EQS unless you want to have unused hidden shader properties linking to textures like normals bloating the asset bundle.
  • Duplicate and modify layers and menus to remove any large material swaps, because the avatar is likely too large without the extra textures anyway.
  • Move any objects using Constraints to the Armature, Quest can’t even have one constraint for the one thing you can’t replicate, the World Constraint.
  • Re-animate your toggles using the new Armature object paths.
  • Re-create your layers and menus using the new animations, removing any material swaps.
  • And lower texture resolution to 1024 or 512, enable Crunch Compression, and pray it’s under 10MB, otherwise you’re spending an hour or more looking at the asset bundle using a tool trying to squeeze under the limit because the avatar creator said it’s “Quest Compatible”

I wish tearing down avatars and re-creating them from the ground up in Blender was easier, less time-consuming, and rewarding enough for avatar creators to justify spending weeks to months scraping the internet for the needed information on how to do that stuff, how to optimize their avatars and make them Quest compatible from the start, but they don’t.

I wish we had a nice easy tool like CATS or PolyTool to help, but they’re not reliable, they break things more than they help, and they’re targeted towards the avatar creators, not the uploaders, the ones that are tasked with doing all this work, because the creators don’t care, they’re on PC.

1 Like
106

After chatting with some friends recently, I guess there may be some incentive for people that don’t necessarily do avatar creation, but avatar optimization. Especially if some more features are released that further encourage the use of optimized avatars.

107

So I did some tests and compared BC7 vs DXT5 vs DXT5 Crunched and here are my results:

BC7 Compression:

Textures size: 188.39 MB
VRCA: 30.90 MB
Download time @1MB/s: 32 seconds

DXT5 Compression:

Textures size: 188.39 MB
VRCA: 13.26 MB
Download time @1MB/s: 13 seconds

DXT5 Crunched Compression (50%):

Textures size: 9.68 MB
VRCA: 9.49 MB
Download time @1MB/s: 9 seconds

So lets go straight to the point: To load this avatar that uses 188 MB of vram, crunched compression is 44% faster than DXT5 and 233% faster than BC7. So yes, there is definitively a good reason to use crunched compression where the visual difference is unnoticeable.

108

What is the unpacking time like? If I save 4 seconds to see someone’s avatar, but the world hangs for one of those seconds am I really saving anything?

2 Likes
109

These difficulties are kind of just inherent to Quest development. Given the huge variation in how avatars are made and how complex they are, there’s no real way to reliably automate the process.

You really have to design your avatars with the Quest in mind right from the first edge loop.

110

Decoding crunched textures is fast, even negligible unless you have an avatar with over 1 GB of textures maybe ? I did another test in a real users case and deleted my VRC cache, I loaded the crunched version in 10 sec and DXT5 version took 14 sec. Didn’t noticed any hitches so it should be the latest thing vrc devs should worry about.

From left to right BC7, DXT5, Crunched DXT5:

111

Keep up the good work : p

112

200mb VRAM is a lot of VRAM. If you had lower VRAM numbers, the final difference in download time I imagine would decrease to be mostly-negligible.

(Then again, so would the de-crunching time, so :man_shrugging:)

113

I upscaled the textures on purpose to show that crunching compression is NOT what devs should worry about. If the game freezes when loading an avatar, it’s because it has to load everything at once (shaders, audio source, lights, skinned meshes, etc…)

The VRChat devs does not allow us to optimize our avatars by enabling streaming mipmaps, LODGroup and masterTextureLimit. Those things are what the community is waiting for.

114

I wonder why those features haven’t been enabled? I’m sure there’s some reason for it (it’s not like nobody has suggested these things before), but I don’t know what it could be.

115

You should also compare it to DXT1, since DXT5 the same size in VRAM as BC7 and only serves a benefit when the texture needs alpha, plus DXT1 is half the size of BC7. It also would be nice to see it compared to a resolution step below, to see if perhaps a 1 step lower BC7 could be better than a higher step DXT1/5 compressed/crunch.

Considering the comparison between DXT5 and BC7, I think that is completely fair and proves that DXT5 is useful for textures that need alpha (assuming the quality loss isn’t significant), considering the compression in this instance.

However, you also said “visual difference is unnoticable” but provided no comparisons for a very subjective (and mildly objective) thing. You can use something like slow.pics for this, provided you take the screenshot at the same resolution/camera angle.

This also doesn’t consider how much different textures can be compressed, and how they look with compression. Some textures may compress well and still look good/great. But other textures may compress well, but look terrible. Some may also look terrible and not compress that well.

This is also misleading. It should also be 188.39 MB. Crunch does not reduce VRAM usage.?

Sorry, I realized you were actually intending actual texture size and not texture size in VRAM.

Ultimately, to really get a good answer, we would need to test many different textures at many different resolutions. Your initial test was useful, but it doesn’t consider all the design considerations and options that people need to make when making an avatar. Lower res BC7 may work wonders for one avatar (especially flat colors), while another would benefit from DXT1 Compressed, and maybe even one with DXT5 crunched.

This is why a testing procedure would be more beneficial. Or perhaps even a tool to test out material sizes and quality automatically and provide a report (could take inspiration from Thry’s Avatar Performance tool).

200+ MB of texture memory is actually the norm in a lot of places I go to :skull:

This is why I am desperately wanting mipmap texture streaming to be added to the game.

116

I found a gist that mentions being tested against unity 2021, I haven’t tried it yet, but it might be information in the right direction for getting textures export from the editor for inspection.

Unity also has the crunch code available in a fork on GitHub, but I’m not sure what’s needed to compile a tool out of it.

117

The closest thing I found was this, but it still is only a PNG so the compression size will be different. Though this would be good for comparing textures I guess. But also, a texture may look bad on it’s 2D representation, but may look good on the model, and vice versa. The UV mapping and lighting can play a big role in how good a texture looks.

What I was thinking was an editor script that can automatically scale the textures, check their sizes, take a screenshot of the avatar with it (like this?), and then compile or export a report of sorts so there is no guesswork involved.

But I guess the hard part would be to check bundle sizes since it needs to go through the entire process of building for upload. This may at least help for testing textures, maybe, but even then, people can use Thry’s Avatar Performance tool to check VRAM sizes and go through each texture, reducing their quality until it is on the border of visually acceptable.