As people use dynamic lighting more and more, there are still a large number of independent meshes that are not merged and the same meshes are copied repeatedly, which makes drawcall and setpasscall higher and higher.
In addition to being quickly visible without having to bake, the volume of the world can also be effectively reduced and the effects of object changes can be dynamically reflected.
In some scenarios this will cause the single thread of rendering to become a bottleneck and limit the frame rate.
Perhaps we can use an X3D CPU to roughly get about a 30% fps improvement, or use a higher frequency and lower CL dual-channel memory to get an extra 5~10% fps for ourselves.
A more effective method is to replace Built-in with URP, which will allow us to obtain SRP batch and obtain several times the rendering power.
You can also halve the CPU overhead in rendering by updating to DX12 (which may cause more bugs such as MFAA?).
In some cases, there is a problem with the way post-processing works that causes low CPU and GPU usage…
I would love that we go for Vulkan in the future, the problem is that for Quest still a experimental feature, and jumping to Vulkan could be a problematic thing for now, I don’t consider DX12 at all for VRChat, there’s nothing in DX12 that VRChat could take advantage off, that already doesn’t exist in Vulkan. SRP (URP and HDRP) are cool, but I don’t think any of the features that exist in SRPs can’t be re-implemented on BIRP, the only advantage being the ease of use for most technical artists and in VRChat we don’t have much access to the engine internals (which is good most of the time) so alot of the stuff that BIRP can do is limited behind such limitations (like compute shaders 
).
The only cool feature that I would like to have from SRPs is VFX Graph. Because that’s like the only thing that I feel that Unity will not backport to BIRP like they did for shader graph. VFX Graph is just a shader graph that’s specialized for particle shaders, and we have particle systems on BIRP, but they’re CPU-bound and can only generate a finite amount of particles compared to VFX graph.
The fundamental problem with SRP is that would limit for more technical inclined people the experimentation on VRChat. Because I’m sure that VRChat would not give access to all the APIs SRPs make available on the C# side. So alot of the cool stuff you can do by customizing your rendering pipeline would be closed on VRChat because of safety concerns so it would be more limiting than usable.
All these ideas are cool and such but there’s 2 issues in the way.
- Legacy Content; unless you spend the dev time VRChat could lose everything user generated in the process, something that would likely kill the platform. As much as creators would love the new tools needing to port everything could be a massive pain if not impossible for people will low technical skill.
- Dev Time; even if VRChat doesn’t care about Legacy Content they would still need to spend a lot of dev time porting everything and in the meanwhile “old VRChat” would get no updates since anything added would also need to be ported adding to the overall dev time needed.
I’m sure some things like DX12 and maybe Vulkan are tinkered with every once in a while but they aren’t silver bullets nor will they likely be added on the Live Client any time soon.