VRchat doesn’t really use Compute Skinning mesh, which allows the inefficiencies caused by Compute Skinning to be solved.
This makes self-exporting scenes that involve the skinning mesh for Avatar analysis in the scene ineffective.
Efficiency is similar to Unity2019 rather than Unity2022.
In some of the scenes I created for analysis
Performance analysis of the same 24 avatars under a lot of dynamic light shading
There are errors in the data and some corrections are needed.
Unity2022
Merged avatar 49fps (1 avatar 1 skinmesh)
Original avatar 36fps(1 avatar 24 skinmesh)(Original error data is 27fps, corrected to 36fps)
VRchat
Merged avatar 45fps(1 avatar 1 skinmesh)
Original avatar 41fps(1 avatar 24 skinmesh)
Unity6 (not confirmed if Batched Compute Skinning is enabled)
Merged avatar 70fps(1 avatar 1 skinmesh)
Original avatar 61fps(1 avatar 24 skinmesh)(Original error data was 54fps, corrected to 61fps)
Perhaps the scene performance of a large number of avatars can be improved by 47~55% on average?
Maybe this data can accelerate VRchat to switch to Unity6 (currently it’s still at Unity6 P) It’s expected to reach Unity6 official release by the end of this year.
There’s a good chance this feature is working, although I haven’t fully analyzed it yet.
It’s just that this function cannot be written in C#, and its function operates in the core of C++.
Perhaps in the future, better implementation methods can be used to improve the utilization of compute shaders and get rid of the inefficient geometry front-end data fetch.
For larger scales (the above uses 3GPC/SE GPU), there will be a greater proportion of improvement.
Dynamic compute shaders will be much slower than static compute shaders , but the ideal multi-pass implementation will be very close to the performance that static compute shaders can achieve.
Possible analysis estimates that the rendering performance may eventually be improved by 60%+. (Lots of skinned meshes and meshes)
It’s just that this is only relevant to Unity, and VRchat is the beneficiary.
If you try to use nvidia’s profile for analysis, it will fail. The overhead caused by its compute shaders is hidden.
GPU Occlusion Culling is available in Unity 6, but it must be enabled by the GPU Resident Drawer, and can only be used on systems with SRP (e.g. HDRP or URP).
The implementation is Hi-z Culling, which is expected to be much more accurate than the bounds method and save about 5~10% in normal state, and a few extreme scenes such as avatar culling behind the wall can save more performance, which is caused by many problems with bounds.
Switching to URPs is a very long and difficult thing to do in the future.
((Fixed stupid mistake…))
other:
Unity6 URP17
Merged avatar 63fps(1 avatar 1 skinmesh)(Original error data is 77fps, corrected to 63fps)
Original avatar 68fps(1 avatar 24 skinmesh)(Original error data is 41fps, corrected to 68fps)
Unity6 URP17 forward+
Merged avatar 61fps(1 avatar 1 skinmesh)
Original avatar 66fps(1 avatar 24 skinmesh)
Unity6 URP17 forward+ GPU Occlusion Culling
Merged avatar 61fps(1 avatar 1 skinmesh)
Original avatar 65fps(1 avatar 24 skinmesh)
Light sources limited by URP cannot guarantee that the effect will be consistent with BIRP, and the data is for reference only.
After merging, it is slower because more triangles need to be processed, but the utilization growth is limited.