Developer Update - 16 February 2023

That’s one solution, yes, as noted here:

65k for a skinned mesh head, and the rest for the body? Would that help with the buffer? Splitting 70k across two skinned meshes.

Avatars and worlds uploaded with the old SDK will break after Unity 2020 due to render pipeline issues, right?
I think there needs to be a strong repeated announcement about this before the SDK2 downloads are stopped.

Until there’s a mirror active and syncing physbone transforms to the mirror clone induces an excessive amount of GC calls, tanking CPU frametimes (assuming the performance tanks in game for the same reason it does in Unity with Av3Emulator when the mirror clone is active)

How “expensive” is it? Could it be made into a low priority background task, perhaps limited to scanning a limited number of objects/components per frame until finished, that executes periodically only for the avatar user, who will then communicate the current ranking to others? Additionally/Alternatively to periodic checks, a new animator state component that would trigger a rescan could be useful (though also open to abuse unless there is periodic scanning or unless the component is “injected” by the SDK at build time into all animation clips that toggle objects/components, some third party tools do something similar for other features)

Edit: Another, likely higher performance alternative - Insert a new semi-dummy component at runtime to every game object with any component that affects performance ranking (mesh, skinned mesh, particle emitters, etc), presumably that component will not be targetable by animation clips, so while it’s enabled consider the other components enabled, and while disabled consider them disabled (since it’s presumably disabled due to the game object being disabled, could add another check to verify that), the same logic could also be included with every VRC component so when a game object contains multiple VRC components (like physbones with different root/ignore transforms), turning some of them off without the game object would still allow the performance ranking to be updated.

2 Likes

We’re looking at a few solutions, none of which we’re ready to talk about yet.

We are contacting Unity regarding this buggy behavior, as well as the odd main thread dependency. We haven’t tested on newer Unity versions yet, so it’s possible that the behavior changed in later versions. Remember that Constraints were pretty new in 2019.4!

For now, we ask that avatar creators take it easy on constraints, and avoid prefabs and systems that have excessive constraint usage. Aim for 15 constraints across your whole avatar, disabled or not, max. If they aren’t in usage, turn them off by disabling the GameObject they’re on, or the Component itself.

I thought Constraints were a thing for a long while now, like since 2018 or even older. But I’m guessing you meant by the behavior of constraints. It makes sense to limit it to about 15 constraints but it sucks that constaints are stuck to a single thread which is why they’re blocked from the Quest version. I have a feeling y’all might do a Jobs variant of the constraint system, and that would be nice because tbh it would fix a lot of things to have a VRChat world constraint component to fix a lot of issues with having physbones on world constrained objects

Awesome. Even the most basic functionality that worlds can put stuff in your menu is gonna be great. Like, even if you weren’t adding udon to it, it sounds so convenient having a centralized place to put instructions or “keybinds” - the menu - rather than having to hope people know where that billboard is physically placed and actually read it

2 Likes

When are we getting composition grids for the Camera? Most real world cameras have this functionality. Is it just really difficult to implement?

For reference:


image

1 Like

We implemented a rule of third grid in our last patch. You can find it by scrolling all the way to the right in the camera UI.

There are a lot of reasons that we have not implemented a specific feature. We have a limited amount of development resources, and a very large amount of tasks that need to be done, including a lot of them on larger projects.

Adding in that particular feature doesn’t sound very difficult, but difficulty is not the thing that prevents us from implementing new features 99% of the time!

Just because we haven’t done something yet doesn’t mean that we won’t eventually do it (although it also doesn’t mean we will eventually do it either).

1 Like

Just a heads up but it’s a real pain to check changes to VRAM usage right now. The avatar stats don’t update without restarting the client (For test avatars), and test avatars in general don’t seem to update without a client restart.
Kind of makes it easier to just re-upload the entire entire each test, which is not ideal for bandwidth on VRChat’s end. :slight_smile:

Tuppers post last week even explained the rule of thirds. I’ve never seen the second one though.

Doesn’t this post explain how to calculate vram usage in a cave with a box of scraps?

Add up the sizes of textures, keeping in mind that crunch options only shrink size on disc. So a 512512 dxt1 that I make is the same size as any other 512512 dxt1

So 2048x2048 DXT5 is 5.3 mb

I just mean that it should be possible to check within the client regardless. :+1:

Ha. Coincidentally, I’m in the process of configuring a new avatar right now and I just noticed that issue too. I think I know why this happens, so I’ll take a look whenever I get the chance.
Thanks for the feedback!

2 Likes

I should also add that both the main menu and avatar gesture menu can exponentially increase frame times as well, and that I only noted the issue (including the mirror one) within VR, desktop does not appear to be affected the same way or to the same degree, the effect is once again most notable with “heavier” avatars, only for the wearer.
For somewhat lighter avatars (that aren’t affected by just the menu), an active mirror + open menu will reproduce the issue, and again if the source of the issue is the same in-game as it is with Av3Emulator, it’s the excessive amount of GC calls (multiple times a second, depending on framerate and allocations), likely caused by variables being discarded every frame.
With avatars that border the exponential spike threshold frametimes jitter quite a bit (most notable with a mirror) between 6~12ms.

It’s obvious that the impact of an avatar on frametimes might double when another instance of it is created, but the increase with mirrors/menus is often exponential, total CPU frametime going from 3~6ms (depending on the avatar) to 10~16ms (rarely tends to exceed 16ms*, even with avatars far more complex/heavier than others that reach the same frametimes), meanwhile having an actual second instance of the avatar (a friend using the same avatar) does not reproduce the same exponential leap in frame times, it’s also not reproduced when someone else uses the “poor” avatar while the local user uses a performant one*, even with a mirror.
*One exception with a single heavy avatar, which affected frametimes heavily away from mirrors, even when only a remote user used it, and even when viewed in the avatar favorites preview.

All these numbers and scenarios are from tests with the default VRChat home world and it’s mirror, I use fpsVR to monitor the frametimes in-game.
Specs: Ryzen 9 5950X, RTX 2080Ti, 64GB RAM.

I also had a thought about a potential improvement to VRAM management, though I honestly don’t know if that’s something that can be done within Unity (haven’t worked with it much besides modding games), or with the way avatars are currently built, or if it might already be a thing in VRChat/Unity so it might look silly but here goes:
Many avatars tend to use the same meshes or textures, be it clones, identical but separate uploads, common assets and the like, so instead of loading meshes/textures as part of an avatar, what if they were (down)loaded to a cache of assets, matched by hash (ideally pre-computed at build time, but could be computed on existing avatars on load by the wearer, then stored on the servers) and referenced from the cache in memory (or an already downloaded instance of the asset, to reduce download sizes), effectively the same way an avatar can make multiple references to the same texture with different materials or have multiple copies of the same mesh without increasing VRAM usage thanks to GPU instancing, but for an entire scene, unused assets could be unloaded/marked for discard and in theory scenes with many copies of the same avatar(s) would see a significant reduction in VRAM usage, it may also encourage the creation of more avatars with a variety of the same “base” textures/meshes, especially for group events.

Would it be possible to have a filter to block avatars over a certain VRAM size like you can download size?

You know, I was a professional photographer for a few years and I’ve never seen this in my life. Granted that was like, 10 years ago, but still.

2 Likes

If you use Thry’s Avatar Performance Tools, you can see the VRAM usage (including meshes) in the editor, and recalculate them before you upload or test. This is using the VRAM calculator.

It is also nice because, for instance, someone I know had 120 MB of texture memory, but due to the blendshapes on their avatar and clothes, it actually is 270 MB of total VRAM.

Though these days, I just upload every test avatar anyways. The build and test feature doesn’t update, sometimes even with restarts, and the avatars only update when you restart the game. They need to fix this.

These are composition lines. There’s actual rules on how to compose a scene to make it look more appealing, though I can’t remember the specific one or what it was called. I remember seeing a good explanation on starry night, but the associated material costs like $150 for a textbook, lol.

So just like the rule of thirds, there are other rules about composition. A popular one is the golden triangle. It is basically this. You can see how there are clear elements in each section, and then the focus points are around where the lines intersect. The second guideline example is a way to help with this sort of composition.

3 Likes

I’ve only had issue with local avatars when I forget to change out of then before a rebuild. I do see the issue come up a lot so maybe it needs working around. Add Unix time to the local file name?

Just need to remember to have the client handle that first.

Including VRAM stats into performance rank is great news!
Sucks for people who will have their avatars demoted, but it has to be done. The limits are pretty reasonable.

Also I’m excited for the Udon UI extensions. Hopefully, after this is implemented, I wouldn’t have to run around looking for the “Resync” and “Screen FX” buttons in every club world.

I’ve discovered a bug with the Vram stats that should really get fixed. Apparently textures from matswaps and animations aren’t included in the stat.

Someone could make an avatar that has 1k textures by default that get swapped to 8k on load. The stats would claim it’s fine all while it’s filling up vram.

More details in the canny: https://feedback.vrchat.com/bug-reports/p/1281-texture-memory-stat-doesnt-include-textures-from-matswaps-and-animations

1 Like

Actually I made a canny for something similar like this a few days ago :stuck_out_tongue:

1 Like

Yes I agree hehe

1 Like