Ooooo, it’ll be nice to have that natively implemented! A lot of booth outfits come with way too many meshes by default.
But a small question.
Does the mesh merger have any consideration for polys?
For example, an avatar could be 300k polys total split between multiple outfits. Would the merger merge all of those meshes/outfits into 1 mesh and use UV discard? Or would it split by outfit visible?
If it’s all 1 mesh, the GPU still has to render all those polys despite most not being visible most of the time.
It’ll be enabled by default, but there’s an option to preview the result and you can disable it whenever. All optimizations are performed non-destructively on upload - nothing happens to your avatar in the original scene, to make it as easy as possible to keep working on your avatar.
The optimizer will have stuff in place for reducing polycount. It’s also implemented in such a way where we avoid doing as much as possible with the triangles when they’re not being rendered, with a handful of different hints to let the GPU skip the work early.
thanks for answering I was just wondering because Avatar making friends was worried about miles of support questions from folks not realizing the optimizer was potentially the source of their Avatar trouble?
I know they mean well, but the built in optimizer is gonna be a disaster. VRChat’s SDK can barely upload an avatar without crashing these days, you really think an optimizer is a good idea? Even the gold standard for this sort of thing, D4rk’s Optimizer, breaks things more often than not and is best used very sparingly. I just know I’m gonna be getting so many support requests from this stupid thing.
Thank you for testing the very poor avatars on Android mobile. I can enjoy VRChat while away from home. Just need an headphone mic set to have clearer mic and keep the voices in game.
I’m really concerned to hear the avatar optimizing feature will be enabled by default.
Unless VRChat is going to fix any breakage no matter how minor it is, please don’t enable optimization by default.
I’m worried that community support resources will be overwhelmed if any avatar (pattern, outfit, gimmick) are broken by the optimizer. Additionally, I feel we cannot expect fixes soon since release cycle of VRCSDK is very slow.
Actually I’m working on AAO: Avatar Optimizer, a avatar optimizing tool and as a part of this tool I created fully automatic optimization, which aims to not break any avatars. This feature performs similar optimizations to VRCSDK one.
However, I’ve faced many difficulties to not break avatars.
Based on my experience, I’m concerned about the potential issues.
I’m inclined to agree. Lots of avatar creators and asset creators will likely get swamped in support requests or questions from people who purchase their content, due to inevitable issues with the VRCSDK Optimizer breaking these assets.
I think rolling it out as off by default and then reconsidering on by default at a later date would be a more effective move. It’d allow creators to test out the feature and see how it works, and give feedback to VRChat about it.
How is that supposed to work is a majority of toggles are enabling/disabling gameobjects or mesh renderers??
The whole thing with mesh combining is people have to change their animations into blendshapes (which need to be made) or material toggles.
Would need some kind of ai system. THAT SAID we need distance LoDs for avatars!!!
I sure hope systems like this don’t further funnel everyone into using awful overdesigned shaders like poiyomi.
Oh so this is what you meant, and yes it’s doing exactly what i feared. This sounds great on paper, but it’s going to suffocate creativity by forcing everyone to use the very very very very few shaders that use this improper hacked together system that exists nowhere else in the industry.
…and add complicating factors that normal people will not know about.
ps: this is NOT actual UDIM please don’t give incorrect information. and yes, like @Fallen_Ninja was concerned, this would mean that it would not work with shaders disabled unless vrchat implemented the same system to all it’s built-in shaders. Poiyomi’s “uv tile discard” is literally using basic atlas uv tiled integers to “cull” triangles by yeeting them outside of the frustum in the vertex pass before the fragment runs (this is very hacky and improper), and there is no actual UDIM.
UV tile discarding trades off a few active skinning passes, and some extra materials and triangles (“discarding” the triangles by moving them in the vertex shader shouldn’t reduce skinning cost anyway, but rather increase it because you have to skin all of the polygons instead of just the active ones **mesh skinning is the heaviest pass!!) with forcing maximal vram usage, and pressuring people into using more complex shaders that support this unnecessarily.
.
UV tile discard is NOT a good longterm solution. They should be converted into regular atlases with uv correction (scale/offset) in mesh if necessary (ideally for reducing mesh count per outfit rather than everything), and blendshapes. (not ideal but the only fair method that is compatible)… you could blendshape the geometry a thousand miles away for all i care.
I love the idea of a native sdk auto-optimizer, but it can’t be proprietary jank, it has to be a system that will work most of the time on most avatars with most shaders including standard & unity common shaders (unitychan etc), not something that needs special programming.
Being on by default is not good because of the limitations and issues i’ve been covering.
***The biggest issues with avatar performance has always been 2 key factors: shader complexity (gpu burden) and animator layer count / total property count (cpu burden). Material count is not that bad, and mesh count is irrelevant if most of them are disabled most of the time - the cost is total active and skinning, not total total. They don’t even buffer the vram for their materials until they’ve been enabled the first time (and this usually resets every world switch). I usually tell people to not be afraid of mesh renderer toggling if they don’t have too many enabled at any given time, because it saves on compute and vram, especially on avatars with numerous outfits. Combining everything on avatars with numerous outfits can very much have the opposite effect - worsening performance, especially active vram usage!!
More importantly…
Make an optimizer that crushes animator layers into blendtrees.
It’s better to start sooner, especially given how now since VRChat is still in close beta with iOS that the only modern graphics API that VRC has now is Metal, we’re still technically stuck on older and outed pipelines like OpenGL ES and DX11 or at the very least allow for shaders to compile for Vulkan (even DX12) so the transition can be a bit smoother in the future.
We’ll certainly take this feedback into consideration, but I don’t want to make any promises.
The intent of this feature is to make optimization easier for your average user, and to lean in toward optimization as a default, considering that the most common complaint about VRChat is that it isn’t “performant.”
Will more optimization methods be considered for the optimizer in the future? One that’d be appreciated is having all FXLayer toggles merged into a direct blend tree.
If we start moving in this direction it’s more likely that we’ll create an alternative to the Unity animators that we can make more efficient. We intend for existing optimization tools to be able to cooperate though!
(Direct-write optimization isn’t always 1:1 and can break animations quite easily, and doesn’t address the sort of higher outlier avatars we’re trying to address here - animators are still pretty cheap, most of the time!)
Unity is already on track to making a new animation system that’s extremely optimized. It’d still work with the current Mecanim system we’re using currently, but the catch is the render pipeline VRChat currently uses (BIRP) is officially deprecated.
Alright i’m going to try and cover what i said before but try to do a better job of explaining what i ranted about above in a more approachable format. Some good friends recommended i rewrite my thoughts better.
Using a mesh combiner that obligates shaders with particular systems in place has a couple of major issues:
Obligation to certain shaders or shader systems funnels creativity to those specific shaders, and adds a layer of complication when it’s requirement is not understood or obvious to the layperson, and also forces more people into the well known shaders which may be way heavier than necessary and don’t leave room for others.
The particular system in question, ie the titular ‘‘uv tile discard’’ as seen in poiyomi is not as beneficial as it is made out to be. And is only truly beneficial in certain controlled circumstances.
. . . The system uses vertex pass of the shader to move triangles outside of the frustum in order to save them from being calculated in the fragment(pixel) pass of the shader. It is not UDIM and does not benefit from the memory benefits of having different resolutions per tile in the UDIM format, amongst other hardware supported functionality.
.
a) this does not reduce the mesh skinning – which is the most expensive pass on the mesh – as this happens entirely before the material’s drawcall, and doesn’t benefit from moving the vertices offscreen.
.
b) due to combining all geometry which would not be enabled normally, you are increasing the skinning cost for active geometry by rendering which would otherwise not be.
.
c) due to combining all meshes and atlasing the textures, you are forcing all of the avatar’s texture memory to be loaded with the avatar…
***normally meshes that are not loaded do not preload into vram, and only do this after they are enabled for the first time; and this applies per instance load as memory is dumped when you leave a world, and also includes extra shader passes when not used (such as ForwardAdd used for realtime lights, hence the lag stutter when lights are turned on or things are toggled).
.
d) as implied, this can often times make an avatar perform worse, even if it has lower numbers in it’s stats list. it can at times be much better to keep parts of avatar not in active use disabled and unrendered entirely (especially if not being switched on at all) to make a truly optimal avatar.
. . . the true cost is total active skinned meshes at any given time not total existing skinned meshes.
None of this is meant to be antagonistic, it’s just not helpful to spend a bunch of time and energy building a system that stifles creative expression and doesn’t benefit performance much if at all anyway. Even most games separate toggled articles on characters into independent meshes to unload them when not in use.
This is just not true.
Anybody can test this and prove it not to be true. Most people make avatars that have at least a couple outfits, each with multiple toggle states, and a few prefabs that have various things they do (gogoloco, gimmicks, and certain common systems) resulting in dozens if not hundreds of animator layers. This is atrocious for performance, and one of the heaviest cpu costs especially when numerous avatars are present (and also why you couldn’t regain it with the range hider) - especially when that cpu time is competing with udon, drawcalls, and a lot of other things.
I don’t like having to explain to people all the time that the 3 most impacting on performance in vrchat are: animator layer count, and udon complexity for cpu time… and shader complexity for gpu time. You can have many drawcalls with light shaders and this not be significantly impacting on performance.
Avatars do not take up a lot of screen real-estate so triangle quad overdraw is not a massive issue, meaning stuff like polygon count is not that bad until you’re peaking like the 100k+ range in active rendered geometry (not total), as their cost is mostly incurred in the skinning - though combining and forcing it all active will worsen this, due to more total actively skinned geometry. There’s also the difference between drawcalls, setpass calls, and other subpasses which have difference performance impacts that are seldom understood.
*Animators are likely the most significantly impacting factor on performance for most users, especially because it is one you cannot improve by any means other than crushing into blendtrees to reduce layer count.
One of the biggest complaints from creators is that VRChat breaks content. If the auto optimizer breaks enough things, the default for community creators will be “disable the automatic VRChat optimizations because they break stuff” which is counterproductive for everyone so I hope compatibility is a high priority here. I would not be surprised if avatar authors just started shipping scripts to disable it at some point if it was bad enough.
At the very least I’d say don’t enable decimation by default (the appearance is often quite different especially re: clipping clothes when moving), and be sure you’ve worked with Senky to ensure there are no hiccups with the way VRCFurry does things. (And imo the default texture size for an atlas should be 4k, despite the memory usage)
that aside, i wonder if there are any issues for different linux distros, as they tend to have some different ways of doing things; or if this really is the “everything” solution. if so, awesome! this’ll open the door for moving more things to linux for people that primarily use it.