VRchat員工都去放假了，估計一個月後回來。
...留下了奇奇怪怪大小坑，諸如安全檢查偷偷更新了粒子緩衝區(qū)檢查，可能會導(dǎo)致特效avatar莫名奇妙黑白。
SDK更新上傳，看起來顯示色確定上傳，但實際上背後是部份組件編譯已經(jīng)報錯了，上傳過不了安全檢查->黑白。
把安全檢查Server行為改了，如果現(xiàn)在安全檢查沒有真正Pass，即使你選擇加載avatar也會無限卡在下載狀態(tài)永遠(yuǎn)不能加載，導(dǎo)致所有人看你都是100%進入無限加載循環(huán)，越大的avatar需要等待的時間就越久。
除非你剛好被pass了，Server沒去篩你Avatar，否則被觸發(fā)檢查改一下你得等十幾分鐘以上，不知道什麼時候才能看到Avatar，完全沒有訊息告知。
雖然mipmap streaming上線徹底解決VRAM的問題，但是無法改串流預(yù)算和一些情況下出bug仍然還是很難徹底修好。
一直無限改資產(chǎn)加載AB包問題，想辦法控制記憶體也就是RAM開銷，但永遠(yuǎn)解決不了。導(dǎo)致不同版本產(chǎn)生額外GC開銷不同，約略10~30%的單執(zhí)行緒時間，很難檢測到。
因為LZMA解包加載資源很慢，不同CPU和資產(chǎn)壓縮約只有60~100MB/s的解壓縮速度，相當(dāng)於說解壓縮後大小是500MB你得可能解5~8秒左右...，不可能實時拿來釋放省資源。
然後GC邏輯部份導(dǎo)致浪費CPU，請注意本身GC不會直接去管理幾GB的紋理、聲音、動畫等等一堆資產(chǎn)，但有實現(xiàn)avatar相關(guān)管理資源邏輯，GC個幾MB浪費CPU時間。
如果mono這麼爛的GC硬是要管理幾GB的資源早就性能崩潰了...
所以無法直接看記憶體使用量判定Avatar的RAM開銷，實際上要看『認(rèn)可』或著說被分配的量才是真的。
聲音可能預(yù)解壓導(dǎo)致膨脹未壓縮大小部份3~10x以上的記憶體開銷，例如50MB聲音未壓縮是50MB但不同格式解碼後預(yù)載消耗150~500MB。
還有緊縮紋理等等問題會導(dǎo)致反覆請求加載到GPU上，速度大概就是1000MB/s~1300MB/s(啟用mipmap生成)
盡管只有加載時，並且現(xiàn)在有mipmap streaming規(guī)避掉這問題，這問題引發(fā)GPU爆滿VRAM後CPU也跟著爆滿增加時間的問題。
原始紋理速度約5000MB+/s。
還有例如API要求檢查網(wǎng)格等，所以網(wǎng)格這一小部份可能會雙倍或持續(xù)加載在RAM上，再加上形態(tài)鍵一些大的avatar此方面常駐100MB+很正常。
開緊縮也因為數(shù)據(jù)相依性，所以也會導(dǎo)致Unity管理上必須常駐整個紋理在RAM上。
LZMA因為解壓縮性能太低了，也同樣導(dǎo)致資源必須要卡在RAM上。
需要解決的問題太多才能把誇張浮誇的RAM開銷壓到很低，同時妥善合理利用SSD的速度。
更別說一大堆各式鑽漏洞，未壓縮500MB沒錯，但實際上各種技巧浪費直接給你產(chǎn)生1GB+以上單個avatar的RAM開銷。
在加上永遠(yuǎn)也改不完的大量avatar資源管理問題，產(chǎn)生額外的GC時間成本。
還有物理骨骼提交變換會導(dǎo)致降低整體5~10%GPU性能，希望未來支持計算著色器蒙皮和動態(tài)合併時能解決吧...盡管比形態(tài)鍵影響相對較低，大量形態(tài)鍵的問題也是坑人，盡管非常少見。
並且無視可見性，導(dǎo)致必須損失這個性能，如果搭配世界內(nèi)失控的攝像機就是幀數(shù)災(zāi)難。
動態(tài)合批(計算蒙皮)可以解決形態(tài)鍵問題，盡管無法徹底解決。
太多因素都導(dǎo)致很難不同人一起測量準(zhǔn)確性能，甚至放大特性CPU的性能。
有些時候我真的懷疑，有一大堆奇怪的bug和永遠(yuǎn)處理不完的創(chuàng)作者問題，和有些創(chuàng)作者一問三不知答非所問到底要到什時候才解決...
社群有問題 官方也有問題...
另外官方還意圖準(zhǔn)備搞mac，等ios明年正式上線內(nèi)部可能準(zhǔn)備。
但現(xiàn)在openGL ES 中間碼轉(zhuǎn)metal中間碼失敗，導(dǎo)致所有人都要上傳一次ios，還要編譯上傳腳本組件。(雖然是自動，但Unity要安裝和花時間等待轉(zhuǎn)換平臺)
那麼多的版本要處理，未來基於SRP的URP轉(zhuǎn)換得版本爆炸了。
world靠API切換管線，但場景內(nèi)的avatar通通必須考慮world是雙管線，所有組合都得上傳。
win/android/ios/mac*2=八個版本，要傳死人啊。
還有Udon2整個打掉重練改成蕎麥麵，性能和特性和開放API等等都砍個半殘...還遙遙無期不知道什時候才能進封閉進測試選項進公開測試(三種測試)
最後才能正式上線...
坑多的跟上天一下，再加上越來越濫用材質(zhì)、切分網(wǎng)格導(dǎo)致最基礎(chǔ)batch都要破30甚至50~60，開個輪廓變100+得多浪費，還沒考慮多重像素?zé)艄?多重攝像機，導(dǎo)致drawcall爆炸。
動畫層無腦往上堆破百，甚至一個不夠帶兩個。
約束不說官方有沒有徹底修好bug，但性能提升也就幾倍，全身上帶數(shù)百個活動的是想多逆天?
全身遠(yuǎn)程活動物理骨骼變換超過500+，很多條尾巴和長耳朵嗎?
![]()
就算努力把GPU的紋理記憶體導(dǎo)致的VRAM開銷解決了，但網(wǎng)格的形態(tài)鍵導(dǎo)致的體積膨脹是可以很高的，但很少人會注意。
更別提隨著時間模型亂七八糟堆積製造，CPU再強都扛不住，就算你9800X3D也只能30fps+，而且還是真的。
甚至浪費RAM到單純VRchat本身活動記憶體超過26GB，擠壓其他部分到32GB外，光遊戲本身50~60人就消耗分配約40GB+甚至45GB+。
這未壓縮500MB限制到底限制了什麼，有限制跟沒限制好像差不多，一堆開緊縮搞漏洞，實際消耗超過GB了。
下載大小依然140~190MB都有，頂多不會超過200MB了。
_________
還有BIRP一直沒維護，Unity其實內(nèi)置實現(xiàn)垂直同步存在一個bug，就是渲染提交大量頂點如千萬級每幀甚至更高會損失性能，關(guān)閉垂直同步可以修復(fù)該問題。(2020後徹底放養(yǎng)了)
可以最大損失高達30%的fps。
SRP預(yù)設(shè)會低10%fps，但開啟垂直同步後反而追加10%fps，非常奇葩的問題...
___________
VRchat改了Render的邏輯...許久沒測沒發(fā)現(xiàn)，GPU方面渲染性能與2019相似，但CPU的drawcall(batches)存在重大問題。
這導(dǎo)致像素?zé)艄庠蕉啵簿褪穷~外開其他通道的情況下，會比原本Unity中的同等drawcall/setpasscall慢更多。
另外一般而言標(biāo)準(zhǔn)著色器應(yīng)該是最快的，但到VRchat中將顯著減慢的不成比例，甚至同等每秒的drawcall中甚至比一些卡通Shader更慢。
drawcall疑似附加其他數(shù)據(jù)開銷更大，在特徵上cache miss上升但RAM的延遲週期更低一些。
並且這導(dǎo)致Skinmesh的時間更容易進主執(zhí)行緒疊加，同樣耗時下的mesh和Skinmesh其實並不相同，如果同時執(zhí)行其他如Script的時候，mesh可以並行而Skinmesh因為骨骼計算在主執(zhí)行緒累加時間，同時部份材質(zhì)受燈光通道影響時一併進入計算。
然而mesh不受此影響，即使點亮像素?zé)艄馔ǖ酪膊粫虼藢?dǎo)致累加時間。
這意味著如果是7ms(script)+10ms(mesh)則時間約10.5~11ms左右，而Skinmesh即使骨骼很少也會變?yōu)?6.5~18ms+，這是因為cache miss上升而單位更慢。
然而在VRchat中這個影響被加劇了，如果你選擇打開額外像素?zé)艄飧喈a(chǎn)生更大的drawcall，你會顯著降低速率，代表相同drawcall完全沒有參考性。
兩個像素?zé)艄夂鸵粋€網(wǎng)格 vs 一個像素?zé)艄夂蛢蓚€網(wǎng)格，正常來說應(yīng)該相等相似的性能，然而在VRchat中，前者劣於後者。
VRchat需要解釋實作問題。
其次還觀察到部份問題，骨骼可見的開銷不成比例，似乎會影響加載和卸載導(dǎo)致額外波動外，也會附加部份異常的時間週期，而不與活動avatar上骨骼或物理骨骼、動畫有關(guān)係，有待研究分析原因。
對於標(biāo)準(zhǔn)Shader，大量材質(zhì)所產(chǎn)生的drawcall隨著附加像素?zé)艄馔ǖ郎仙猎糢nity性能的兩倍慢至六倍慢(只測至額外8盞燈)，實務(wù)上VRchat中的像素?zé)艄鉀]有上限但可能會被安全檢查(實務(wù)中使用可以達128盞燈活動，但會引發(fā)VRchat嚴(yán)重卡頓爆炸，即使drawcall原本很少)。
而liltoon等卡通著色器則慢1.1倍到2.5倍左右(到8盞額外像素?zé)艄庵饾u增加)。
________
仔細(xì)想想看過的VRchat shader怎想都覺得不可能有這實力改Unity關(guān)於BIRP的渲染源碼，尤其BIRP亂七八糟的情況下。
結(jié)果仔細(xì)追蹤下去檢查原因...Graphics Jobs被禁用了?
三小，你有病是吧
創(chuàng)作內(nèi)容
近期VRchat吐槽(2024/12/20)_更2
就算努力把GPU的紋理記憶體導(dǎo)致的VRAM開銷解決了，但網(wǎng)格的形態(tài)鍵導(dǎo)致的體積膨脹是可以很高的，但很少人會注意。
被遺忘的故事 (1)
