When can we get max simultaneous audio sources uncapped from 3? Even 5 would be miraculous for versatility. But honestly, with having safety settings, reliable avatar volume setting, and earmuffs, limiting avatar audio should be mostly unnecessary, especially when it comes to breaking the volume (the ducking system is egregious).
It’s been a standard since like the 90s to have systems that manage audio priority, for sounds that are closer and louder to have higher priority and farther/quieter sounds to be the first to get culled, preventing buffer overflow. Hard limiting audio playback count it ridiculous.
Crunching hitches can be absolutely abysmal… crunching and having a lot or long audio sources defaulted to decompress on load, will tank the main thread, which is already bottlenecked by a great many other things in unity, and cause like 3-10second lag hitches on load not infrequently, which are horrendous. The decrunching i’m pretty sure also happens on swapping meshes with toggles etc, as it loads the materials and skins the meshes that were previously disabled.
Anyone supporting crunching other than extreme rare cases doesn’t understand anything. Space savings are not overly significant (maybe 10mb filsize at most on a high quality avatar with a few 4k textures, and we’re talking an avatar that is like 70mb - the difference between DXT compressed vs DXT crunched, not DXT crunched vs BC7), and the quality is disgusting, and the load time is unacceptable. You are better off setting textures to BC7(high quality) and lowering the res one mip (will prob look better than crunching same res).
It’s unfortunate unity doesn’t have access to BC6 non-HDR because then people could encode high quality textures without wasting an alpha channel when not needed.
Seems I can’t trim out the other posts, so forgive the long reply then (Edit oh good it didn’t copy it all XD):
The world I’m currently updating is using the current SDK. I’ll look into that Network ID thing, but I’m barely understanding Udon as it is x,x This s*** be hard man…
As i’ve heard… another thing i noticed is how horrendous rigidbody object sync gets over udon (haha funny wiggly poltergeist floating) - it was so clean and simple in sdk2.
People need cleaner simpler and easier (with flexibility to implement optional complexity), not forced more complex and more points of failure.
Most people don’t know how to use udon at all, and heavily rely on prefabs, which is not good for optimized, unique, quality creations.
I’ve found that turning off crunch compression has significantly increased visual quality and only increased asset bundle size by single-digit mb’s. My avatars are entirely custom and carefully atlased though. Results will most likely vary.
It would be nice if there was some indicator of download size in the SDK. Obviously the final size of the asset bundle can’t be determined until after it’s built, but it could possibly list the size of the uploaded and local testing avatars under content manager.
The “different versions” of DXT1/5 respectively are just how unity displays them. Crunched DTX1/5 textures need to be uncrunched after load to become compressed DXT1/5 in GPU memory.
So yes, they are being “converted”, but its literally just unitys representation, that isn’t even relevant in runtime.
BC7 has the disadvantage, that it cannot be crunched, as you can see in the list there is no “Crunched BC7” at all. If you enabled crunch compression and then “Override” the texture on PC to BC7 you don’t actually get any crunch in the end.
That is why I use and recommend DXT1/5 for most textures and the higher filesize, higher quality, uncrunchable BC7 only for e.g. skin textures or anything with subtle gradients, where you need to prevent color banding and similar artifacts.
Note though, crunch compression may help with some textures only, and may not help with others. In my assetbundle about half of it is meshes, so 25mb are always going to be there until I get rid of some. the remaining ~23mb are mostly textures, with two audio files and a few shaders.
changing all textures to non-crunch compressed DTX1/5 (no BC7) will give me 2 more mb savings, enabling BC7 on the body again negates that again.
In the end running crunch compression on only the textures, that report bigger sizes here AssetBundleStat seems to be the most helpful in my case
As pointed out by other users, it can differ a lot from avatar to avatar and depends on many factors with their textures. Some textures may compress more with the lossless LZMA compression in assetbundles while some may compress better using crunch.
And not everyone has baller internet, if everyone is running around with 100+mb avatars I need to wait for 5 to 10 minutes when joining a big lobby to load everyone in.
I currently have ~170mbps, but this is far above the norm in the country I live in.
Not too long ago I was still at 50mbps and the country wide average was 20, not sure if it has gone up much over the past years, but yeah…
I don’t wanna sound like a broken record, but Any updates on fixing shader fallbacks? Standard, standard Specular, and Autodesk interactive based shaders don’t fall back properly, even with the VRCFallback tag added properly. It does work with Toon, but not any other built in shader. See the updated Canny for more info. Seriously this would help shader creators and vram usage as we could store extra data in the unused texture channels with our custom shaders, but still fallback the data that is used by the built in ones.
I think you have outdated info there, Tupper.
The network ID tool is being used by us and some other creators to solve this very old sync issue, worked fine for a while, but broke with one of the latest updates: Canny I talked with Phasedragon a week ago and they were able to confirm the issue in our world, but no word regarding a fix since then.
I don’t think that’s the point they were trying to make; What I took away from that was that by telling people crunch doesn’t help VRAM, people will avoid crunching because it doesn’t help with something they thought it did, BUT crunch compression likely will still DRASTICALLY reduce download size which is a MAJOR issue for people with slow internet connections. It can take an obscene amount of time to download everyone’s avatars sometimes and if everyone now thinks “Oh, Tupper said don’t bother crunching!” they’ll upload uncrunched avatars which in turn will likely be much larger in download size.
But we’ve established (I hope) that crunching is more of a last resort for reducing file size, since it both lowers quality and hitches load time (which is likely adding to the chance for a crash for some users), rather than a crucial step.
Like I said earlier, it seems to be highly dependent on the avatar and scenario. A lot of people don’t see much of an improvement from it, and really if someone’s avatar is so big that they are going from 100 MB to 70-80 MB, why do they even have such a large avatar?
If someone can see a better visual quality by going from 4K DXT1 to 2K BC7, why shouldn’t they? It should still reduce asset size more than 4K DXT1 Crunched would, no?
My avatar does not use crunch, looks good, and only uses 45 MB of texture memory and is < 8 MB download. This is while having some props and different atlased clothes.
Crunching is not a last resort. It is a useful tool alongside downscaling and memory compression. As pointed out by several users here the effects of crunch compression can be quite drastic. For Example:
On my avatar as I looked up yesterday crunch compression only reduces filesize by about 2mb, but for them it saves about 7, which is relevant at scale.
Assuming a average crunch compressed avatar is 35mb and a average non crunched avatar is 50:
In an instance with 60 users you will need to download 60*50 mb, thats 3000mb, 3gb. in the same instance with on average 35mb instead that would be 2.1gb.
Of course I’m not saying everyone has these huge avatars, but especially in instances with that many people I tend to find a surprising amount of people with really big avatars, so the average would probably look something like that. Or maybe even worse actually… looking at all the people with 100+mb avatars