隨意寫寫，可能偏向抱怨?沒太多數據可說...
隨著今年五月發布VRchat SDK Roadmaps後，今年大多數VRchat上性能上的弊病和限制會逐漸脫離吧。
在解決了約束(constraint)和Udon遷移到Udon2，透過複製和包裝器執行到基於.Net上的Blazor，擺脫了許多問題...雖然按照給的數據仍遠慢於編譯的Unity C#，不過等待後續公開測試時進行測試即可。
像是過多的沉重的使用方式所造成昂貴的CPU開銷的，至少掃除大半，可能七八成有吧?大概剩下Animator和Render的問題沒解決了，或許Physbones也可以稍作改進?
Animator的問題大概就是大多數懶得用或有限制所以沒辦法做成單層的開關，再加上Unity其實已經很久沒好好去更新這方面的設計了，操作GameObject這些Core的組件並行的效率並不是很好可能發揮出2X~3X的加速比吧，更別提曲線這些導致動畫沒辦法直接合併到單層一起執行，做了不必要的IK和Rig的工作。
雖然說Animator不幹太多實事可以輕鬆用到16thread並行，但實際上加速比如何又是一回事了...
Unity Tech也算怠惰許久了，Mono這些遷移到.Net真正有現代化高效率的執行後端還要許久，直到今年五月進度仍然不明，如果真正遷移到.Net8完成至少GC的開銷可以極大幅縮減可能至四五分之一去了?
再加上Span<T>和Memory<T>這些去實現避免複製和高效與Core的C++的引用交互，更規避了GC的危害程度，要將許多API底下的實現逐步替換來提高記憶體的訪問效率...
這些對於提高用C#實現的上層功能至關重要，避免昂貴的cache miss。
Render這方面基本上沒太大的問題，可能就是管線沒辦法貼合所有人需求吧?不過對於需要大量動態光源來說執行效率很高了，除了少數老頑固還在只提出自己意見卻沒有Demo或數據分析
我想不通在VRchat上怎會有人覺得URP可能不如BIRP的，怎不看那些風景世界有的沒的動態光源給你打滿，反覆重複著色昂貴的Skinmesh和材質?
雖然URP會造成場景基本的開銷高不少，但是其Single Pass Forward Render(或說one Pass?)的設計，注定了在大量光源避免重複著色造成昂貴的drawcall和setpasscall，這對於一些沒有陰影但是大量光源的世界來說甚至可以將性能翻倍。
不過VRchat要更換成URP主要難點在於Avatar可以到任意World，所以困難點是如何將這些Shader從BIRP自動遷移到URP上，畢竟現在已經在準備ios平台了(目前實際上有windows+Android(包含quest這類VR))，更多平台每個都要創作者上傳一個版本還要逐步遷移URP，一個組合爆炸的體現...
在URP中跑帶輪廓的toon shader，原本24個avatar共計Tirs 3M 輪廓後6M URP中需要計算深度Pass又要一個3M共計9M
實測速度152fps(深度優先選項後156fps)
在BIRP中帶輪廓的toon shader，原本24個avatar 3M*2=6M 9次約53.6M。
實測速度73fps
雖然打滿燈光測試可能不公平就是了，但也能呈現一定差距，在1主要1附加光源下差距不大(大量avatar)，沒什麼光源影響場景和沒有多少人的情況下會更慢，但這種情況下一般fps都很高不用很在意，甚至有些場景本身負荷高就是因為動態物件與動態燈光反覆計算造成的浪費。
在Unity6之後Compute Shader batch也解決了SkinMesh在過多零碎的計算著色器上低效的問題，並帶來相比現有VRchat的頂點著色器高約50%+的『整體』渲染性能，你沒看錯2022版本的VRchat還在頂點(為了部份相容和性能問題?)。
不過對於如果用上了URP來說可以規避掉大量動態光源所容易造成的幾何性能瓶頸。
在目前BIRP中，24個帶toon的輪廓的在密集燈光下...
這是URP Forward的數據
如果未來GPU架構在L2的頻寬上大幅提升，估計性能還能大幅拉出30-40%甚至50%的fps...比起有限的難提升，用上了計算著色器蒙皮合併還是有瓶頸的情況...
如果是BIRP中用Deferred也能獲得如此巨大的提升，只是變成VRAM和L2雙重遠超其他部份的瓶頸...(VRAM被G-Buffer cache miss帶來的頻寬壓力壓垮了...)
不過隨著Forward+和不知道未來有沒有Deferred+ 基於tile可以節省掉大量頻寬...，雖然在十幾個光源以內提升幅度有限，對比目前URP的實現來說，可能需要同時對一個物體擁有數十上百甚至一千個光源照射?
目前VRchat長期來看仍可能保持在Forward 即使切換到URP，能使用的光源影響到單一網格最多九個，想要呈現出極華麗的效果仍有很長一條路要走。
不過至少如果切換到URP後可以更自由使用燈光，而不是像現在打個主+附的動態燈光，不小心多打一盞燈幾何瓶頸，顯卡不夠好體驗很差，而且一部份也解放了多邊形的自由，玩家不用那麼在意一個模型的多邊形造成多麼沉重的負荷了。
且相比BIRP的Deferred，半透明物體會需要到Forward反覆渲染的鉅額開銷來說，使用URP也能更自由使用半透明物體而不恐懼其大量半透明物體造成的沉重開銷。
陰影的話，陰影貼圖生成是獨立於Forward和Deferred的Pass，所以仍然要重複計算。(而且G-Buffer也無法處理這問題，不說後處理的話)
不過陰影無論BIRP或URP，雖然會大幅增長drawcall，但造成的CPU開銷遠遠小於多盞燈重複著色蒙皮網格和材質所造成的影響，幾乎多少或感知不大的CPU開銷。不過目前URP的陰影可能繪製上會稍微更貴一些，不過可以調低品質降低成本即可。
_____
還有一個問題，當初官方人員說快解決的流式紋理又變得有點遙遙無期，導致大量浪費的VRAM的問題仍然沒被解決，僅手動標記為感興趣待解決...
連流式紋理都要搞很久，更別提未來動態加載物件來處理網格的VRAM開銷等的需求了，還有很多改進執行效率和顯示記憶體佔用的方法沒使用...
沉重的轉換包袱，不知道何時才能將VRchat的硬體成本大幅降低且同時提高順暢程度，並讓畫面和功能真的到下個時代...
