When security check icon shows performance rank? and why its different from normal performance rank?
needs more information
dag-ed
Avatar's icon listed in avatar menu now have performance rank like icons on security check icon before.
I dont know this functionality and cannot found on update notes.
And... Its sometimes different from performance rank itself.
* What mean is this icon? If its not easter egg, please write update notes.
* Or something buggy from icon calculations to normal performance rank calculations?
Log In
e
euan
needs more information
e
euan
At this point all avatars have basically been reprocessed (or are queued to be), so all the issues fixed previous will have now been applied and stats should be more correct. The discrepancy with texture memory related to material swaps still exists, haven't had time to address that properly but still on my radar. Going to move this to needs more info, if I don't hear anything in the next couple weeks from anyone I'll close out this task otherwise this will stay open for ages
e
euan
Merged in a post:
[1514] Performance indicators on avatar menu are inaccurate.
DAG-XR
I noticed this bug on the open beta build before 1514, but forgot to report; much apologies.
When on the avatar menu, the performance rank icons at the top right of each icon is not matching up for the icon next to "View Avatar Details". This affects most avatars, whether it's in the Public Row, or personally uploaded by you.
A lot of my avatars display as Very Poor on the grid, when they're Good or Medium, under View Avatar Details.
DAG-XR
Funny enough, Utility BLOCKED is "Very Poor" on the VRChat website. https://vrchat.com/home/avatar/avtr_5e0b520f-f221-4f20-82e8-9cf59ba30277
Utility Loading Simple is Good on PC, Poor on Android and iOS.
HunterDaFloofer
I am so confused why it wasn't checked to ensure that the rankings are as close to the same as possible. Due to Android not allowing Very Poor avatars from being loaded; this can cause extremely troubling issues when an avatar set way under the threshold is sent all the way up to Very Poor. It can be loaded on the client fine when you have it favourited or it is in your uploaded, but not in pedestals or to other users. That is the most important thing to not have restricted
e
euan
HunterDaFloofer: The rankings have been tested to ensure things are as close as possible and in the vast majority of cases they are accurate, just we can't test for everything and due to how dynamic content it is to be expected there be discrepancies.
HunterDaFloofer
euan I assume I am unlucky as it is very inaccurate between the two in the vast majority of my avatars. I rarely have the server be accurate to the client's calculation. I do hope that this can be resolved as I know there isn't an easy solution to this problem. Luckily, the server doesn't restrict loading avatars for other players, but it does restrict pedestals. Perhaps the pedestals can not be blocked but instead show the rating. Can be a bandaid fix until there is a full fix for this issue
e
euan
HunterDaFloofer: It's likely something common between your avatars which is causing you to be affected more than others. It seems the issue you have is related to the bounds calculation which I a few days ago got an example of being off, so it's being worked on. As for the pedestals blocking switching I'm actually unaware of logic there that would be hooked up to the server side stats, I'll flag that to others on the team to look into
e
euan
HunterDaFloofer: So the bounds issue was nagging at me so attempted to look into it again, got things mostly correct now, there in some cases where the bounds are very slightly off but to a negligible amount in the avatars I've tested with so far. I've deployed the fix however it will need avatars to be reprocessed to correct, for now I've gone through a few of your avatars to manually to queue them to be reprocessed
HunterDaFloofer
euan Thank you! I have looked at my avatars, and they all match to what they were when loading on the client except for a few that mismatch on Android (in which you did address will probably happen). They aren't a major mismatch like most of my avatars were, so I am not too worried about those
e
euan
Merged in a post:
Incorrect Avatar Performance Rating Before Loading in
HunterDaFloofer
When the avatar is not loaded; it is displayed as "Very Poor" despite being "Medium" when it is actually loaded. This is a major problem as this has restricted many of my avatars that are set to "Medium" on the Android built but cannot be loaded since VRChat assumes they are "Very Poor" on the server's end when this is not the case. I can load them in the menu and equip them through it, but the pedestals do not.
This has negatively affected quite a few of my avatars and it frustrates me so much. I hope that this gets patched without having to reupload. I am only glad this doesn't affect my main avatar but it does affect all other ones that I have uploaded using the same base
e
euan
Since my last note three new discrepancies have been found
First the limit for the PhysBone collision check count for the poor rank on PC was lower than it should have been, Eai this is why your avatar was marked very poor, a fix for this is being deployed as I'm writing this message.
Second bounds were not being accounted for, fix is also being deployed right now.
Finally third is a more complex one, texture memory usage server side is in some cases higher than in client. This due to two reasons:
- Expression menu icons, these are usually tiny though and so unless you have a lot it won't impact things much, in any case I have a fix that changes things to ignore these icons now deployed. Caveat is the avatar needs reprocessed to have the stat updated, given the minimal impact of this I'm not going to reprocess all avatars.
- Material swaps, the client cannot read what an animation clip does and so does not account for these, server side however doesn't have the same limitations and so counts them. Given this actually fixes an issue I'm not going to go replicate client behaviour server side however counting all materials all at once isn't quite accurate to performance impact and so will be seeing what can be done to calculate the worst case scenario based on what animation clips can animate, a fix for this would not be quick though.
a
anmeire
euan The server-side performance ranking of my uploads are still incorrect by a large factor. Client ranking is 'Excellent', but actual result is 'Poor'. Even 'Very Poor' in one case.
Please see this [Excellent -> Poor] example:
avtr_14ec8d9f-7ca0-4ab2-8081-e2fbd3292097
My avatar does take advantage of animated material swaps, but it's hard to tell if that's the limiting factor here. Please let me know if this is the case. If it is, please make sure this statistic is calculated correctly before letting the client use it for anything more than decoration.
> ...so will be seeing what can be done to calculate the worst case scenario
The solution you mentioned of finding the worst-offending materials through looking for AnimationClips that share the same path attribute would be a great idea. Though 'seeing what can be done' gives me the impression that the team isn't sure whether this can be done easily.
Forgive me if I'm being stupid -- but after deserializing clips from the avi assetbundle wouldn't it be possible to look for a similar pattern to the one below, then iterate through each unique material reference to find the one with the most VRAM impact?
attribute: m_Materials.Array.data[0]
path: Path/To/The/Animated/RendererGameObject
e
euan
anmeire: That avatar is poor due to texture memory usage, just over the 150 MB threshold. The complication with animations is it's not incredibly difficult to calculate the worst possible scenario taking into account just animation clips but that could very well be a state in which is impossible to actually be in within the animator controller, stepping through the animator controller is where it'd get much harder. And even if something isn't super difficult if it requires a notable time investment then it has to contend with a number of other things that need worked on, that being said this is high on my list just not at the very top.
> please make sure this statistic is calculated correctly before letting the client use it for anything more than decoration
Fun fact is the minimum performance rank setting has made use of these server side stats for over a year at this point and honestly I'm amazed nobody has noticed any of the discrepancies. One of the great parts about having the calculated ranks side by side is it being quite obvious when something is off, and I'm hoping to use this as an opportunity to weed out all those discrepancies and fix them before using it for something more.
a
anmeire
euan Thanks for the information and clarification.
I've realized that animated materials aren't the cause of my avatar's miscalculated VRAM in this case. There seems to be another bug with Tex2DArrays being extremely overcounted by the security check.
I uploaded another avatar using the exact same material configuration, this time swapping my texture arrays with traditional atlases. The server deemed my avatar as 'Excellent' performance, despite using exactly the same amount of texture memory as before, only now formatted as 2048x2048 rather than 128x128x256.
I'd recommend looking into how Tex2DArrays are handled by the VRAM calculator. Something funky is going on with counting them, perhaps VRChat's server-side check is treating the entire texture's cost as if it were only the per-slice cost. Or perhaps it doesn't know what to do with arrays, giving up and treating them as uncompressed RGB(A)24/32 textures instead. It's hard to tell without solid numbers, but I hope this can be replicated on your side.
The server-side checks are otherwise fairly accurate in most cases, hope you're able to track down the culprit with Texture2DArrays ^^
e
euan
anmeire: aha, good eye there ended up being a couple things up with texture2d arrays (and cube maps), one of them indeed not detecting the format correctly. A fix has been deployed and I've reprocessed your avatar
a
anmeire
euan Thanks a ton for the fix! My affected avatars have returned to Excellent performance.
An aside, earlier you mentioned that the Minimum Performance Rank is determined using the server-side value now. There's some quirky behaviour with removed components that I can't really test whether the new security check system has caused. Would you be able to briefly comment on whether this has anything to do with the new system, or has this been the intended behaviour all along?
e
euan
anmeire: the behaviour with the minimum performance rank using the server side stats has been the case for well over a year now and generally the functionality hasn't been notably changed since then. I don't believe that canny is related to the recent changes nor generally server side processing
e
euan
Merged in a post:
Avatar grid view shows wrong performance rank icon
d v l
avtr_e2f46107-6f79-4703-b26d-65655a1d1fcd this avatar is good ranked on PC. However, when looking at it on the avatar grid view it has a medium rank icon in the top right corner (the smaller image attached). Opening full avatar details both show it as good rank (the larger image attached).
e
euan
in progress
Although fixes have been deployed going to leave this in progress for a week. Give it a few days and if there are still visible discrepancies post the avatar ids here along with the ranks seen in thumbnail and those that the avatar details list
Eai
euan
My avatar uploaded on 2024-09-22T16:57:06.102Z was rated as VeryPoor on the server even though it was rated as Poor on the client. It may be used for investigation.
id: avtr_707586e6-22e9-4802-868b-616224fc5030
lackofbindings
euan here's a ton more:
avtr_21821391-5cf0-48ad-b2f6-9621dbe13d2a says vpoor, is medium
avtr_19ff46c2-27a4-4aeb-b313-82a31412f2c3 says vpoor, is medium
avtr_efc7e282-5900-4909-8440-ae27c721757e says vpoor, is medium
avtr_2b5f66f3-efb8-48d7-a1f7-24d54393ce5c says vpoor, is medium
avtr_f5e5c33a-7d88-456f-b37b-bd56cca12b49 says vpoor, is good
avtr_c6180f44-3a27-44f8-8173-08e3e471e179 says poor, is medium
avtr_2bb7c911-7856-4740-960d-ff22204456a3 says poor, is medium
avtr_c6180f44-3a27-44f8-8173-08e3e471e179 says poor, is medium
avtr_1a22c6aa-f316-4bb9-a75d-ce42b61b99cc says poor, is medium
avtr_ee89e837-6543-4024-a265-29faabc96937 says medium, is good
avtr_1675a5fa-765c-43b5-ae5a-24b4a7c67a5f says good, is medium
e
euan
lackofbindings: Haven't checked all but from the first few it looks to be that you are using a lot of material swaps, as such the texture memory is what's putting you into the very poor category, if you scroll up in the comments you'll see my note regarding them
lackofbindings
euan I feel like unless you plan on updating the client soon to also count all textures then there really is no point to having the server count like that. Like it's a nice idea to be more technically accurate but the value in the client is what actually matters so if the server side measurement doesn't match then people are just gonna learn to ignore it. You should push it now so that it matches the client, and just keep that code in the back burner for the future when/if the client gets updated to match.
e
euan
So to explain the feature a bit the stat in the thumbnail is the performance rank calculated server side. The actual functionality in client has been sitting in wait since the security check icon was added but we never had time to implement the server side logic to calculate the performance rank, that until very recently. The logic coincidently was deployed near the same time the latest client release came out, we do hope to announce it better in some form.
With that there were a few avatar stat collection inconsistencies discovered between client and what was collected server side, this update to show the server side calculated rank in client alongside the client calculated rank has really been useful and is shining a light on any that exist. One of the issues was fixed last week but required things to be reprocessed server side, two more were just fixed a few hours ago. Alongside the later two I also queued up things to be reprocessed this meaning things should start being more in line to what they are in client, though it might take a bit
Load More
→