vrchat吧 关注:33,255贴子:280,678
  • 35回复贴,共1

Avatar特性發生了變化

只看楼主收藏回复

可能是最近也可能是之前,許久沒進行測試。
在Physbones限制256組件後官方總是不提及太多關於物理骨骼的改變。
隨著最近發現自己視角測量的frametime的一些變化
發現有以下特性變化:
物理骨骼(PB)與蒙皮網格變換分離了,這使得物理骨骼本身再多也不影響額外的GPU開銷等。
這使得自身視角的物理骨骼開銷低得多,目前物理骨骼與他人視角的開銷是一樣的...
但是新的問題來了:
自身視角的蒙皮網格和網格始終是運作的,大約24個蒙皮網格會對自身產生(5600X 標準4.65Ghz)1ms~1.1ms的CPU開銷及多餘的多邊形開銷(必然可見且一定完全看到)
這促使在擁有更多光源/陰影或一些處理的地方,會大大加劇多邊形開銷(對像素影響很低或沒?)從而導致自身的GPU負荷,但對於他人視角來說看不到即是零。
而且同時也會增加自身的CPU開銷甚至達1.5ms到2ms左右的自身耗時。(網格則比蒙皮網格便宜數倍,但不建議擁有數倍於蒙皮網格的網格,因為網格數量會導致『超級嚴重』的frametime波動,嚴重影響自己體驗)
所以蒙皮網格和網格盡可能合併,或是不需要活動(即使自己看不到)也要保持關閉從而讓自身開銷降低。
現在物理骨骼自身和他人視角相等且都很低。
這些特性無法在編輯器中直接測量出來,只能在遊戲中實際獲取數據。
________
小知識,可以藉由前端部份的頻率和前端的數量計算多邊形性能,一般來說使用頂點著色器著色普通網格和蒙皮網格,效率僅5%~20%,且越少多邊形效率越低(呈現平方關係),並存在更多瓶頸(前端獲取數據瓶頸,導致頂點著色器效率極低下)。
實際效率通常低於10%,理論上一個5GPC(或換成AMD的SE)擁有最大每週期5個三角形吞吐,以2.5Ghz運作時大概擁有12.5GT/s(125億三角形性能每秒)
(這裡不講複雜的極限效率如何到達和許多瓶頸限制)
實際上只能跑到約1.25GT/s(12.5億),並且多邊形不能和像素後端一起並行,這意味著一幀的時間僅只能有限完成多邊形負荷後跑像素負荷。
如果你希望頂點著色器負荷在50%左右耗時,則實際上一秒內僅只能擁有6.25億三角形,剩下給像素著色器工作。(一個25萬活動三角形->Unity優化後至50萬->背面剔除25萬->陰影(提升到50~75萬)
以此計算50萬在有陰影情況下(多光源多陰影更貴不納入計算)->30個avatar約1500萬,所以只能跑41.67fps。
像素著色器大致上填充率效率通常有50%以上,分辨率越高直到帶寬/光柵化/寄存器/緩存瓶頸為止。(每個分辨率的像素根據不同情況在2D約5次像素 以50%計至少10填充率 live2d約15~20次像素(40填充率) 3D toon目前水準約40~60次像素(80~120像素)3A更高(以TMU/ROP計)
_____
可以自己估計一下對於自己GPU開銷有多大


IP属地:中国台湾1楼2024-05-04 20:43回复
    當然一般而言多邊形高到這種程度,效率可能不只10%,只是這裡可能考量到Unity愚昧的計算蒙皮不合批造成的影響...
    實務上純頂點沒有通信開銷,單個夠大蒙皮網格和陰影貼圖計算都能足夠提高一些效率,能到20~30%應該還是允許的(極端情況下動態陰影+多光源負荷會極大,但效率可以媲美鑲嵌著色器達50~70%效率,不過效率很高會觸及到多GPC或SE並行效率極限(例如12個GPC實務上可能僅有6~7個三角形吞吐上限? 即使利用Mesh shader/CS優化)
    主要由陰影貼圖計算拔高了利用率...


    IP属地:中国台湾2楼2024-05-04 20:56
    收起回复
      不错,晚上狠狠奖励你


      IP属地:广东来自Android客户端3楼2024-05-04 21:59
      收起回复
        不错


        IP属地:广东来自Android客户端4楼2024-05-04 22:42
        回复
          另外人多的時候繪製會到第二至第三線程 主線程的只負責一點渲染的管理
          所以實際上1ms的開銷在人多的情況下 由於第二至第三的渲染線程負荷很難超過主線程 所以對於frametime影響很小(同時可以並行提高CPU的利用率)
          (渲染線程即使到2xms 也很難超過主線程20~30ms 所以相當於影響非常小)(可並行關係 async下一幀)
          足以渲染數百個蒙皮+與之相當多的材質 或擁有較多燈光陰影pass等 兩三百個蒙皮+材質
          邏輯或著說主線程和渲染線程屬於並行關係 frametime取決於誰負荷特大(較少情形會渲染比邏輯重 從而限制幀數)


          IP属地:中国台湾5楼2024-05-04 23:15
          收起回复
            青月


            IP属地:山东来自Android客户端6楼2024-05-05 08:08
            收起回复
              額外部份:
              像素開銷取決於被光柵化的多邊形覆蓋面積
              通常來說不透明可以透過Z深度來將後續像素開銷去除掉
              不考慮細微的結構變化和面積
              有些小細節如光柵化最低是2x2 意味著無論多小三角形至少產生4個像素開銷(雖然前端通常在此遠慢後端 可以忽略額外像素影響)
              大概固定的物件外觀 複製多倍 二十倍左右的多邊形 會是原有3+倍像素開銷(不考慮半透明導致無法剔除)
              以分辨率4096*2048為例 (近似4000*2000=800萬)
              800萬 考慮toon著色加其他一些效果(2個+) 約40個像素 考慮效率後為80填充率
              8M*80=640M(TMU or ROP 這裡如果你開啟後處理或需要HDR 則ROP瓶頸)每幀
              你的顯卡如果100GP/s 在不考慮多邊形開銷下可以跑到156fps
              上述假設整體因為風格一致 使用shader效果繪製全面
              如果你使用粒子系統(2D)及半透明因為深度剔除問題容易過度繪製
              一般而而會過度繪製(overdraw)但屬於輕度的(基於網格不太會超過5)
              大量面片的草地等大概2~3(看密度) 所以你可以156/2~3/約78fps到52fps左右,如果你需要繪製陰影或光照等需求則會到約30~50fps左右。
              基於粒子系統不容易被剔除掉的情況下 過度繪製的程度可能高達20+以上
              雖然單個shader簡單2D僅計算5次像素(考慮面積遠近導致的光柵化效率 填充率會在25~75%來回劇烈,這裡採50%)為10次填充率
              那麼8M*20*10=1.6GP 對於100GP僅只能到達62.5fps(不考慮粒子受光等更複雜問題)


              IP属地:中国台湾7楼2024-05-05 10:28
              收起回复
                其他部分:粒子系統等一些需要顯示的 也會一同在內影響但輕薄許多
                主因是像素部份似乎是不納入其中的,但過多粒子也會產生一定的多邊形負荷和drawcall(多邊形也會產生些微固定像素開銷) 但比起直接見到粒子來說負荷會低很多,可能有數十倍的差異。
                如果你在網格上使用鑲嵌著色器例如毛髮或尖刺、草等效果,由於這些可能基於分辨率細分等,在不看到的時候不產生額外開銷,但看到的時候會產生相當多的多邊形和與之衍生的部份像素開銷。(尤其越近細分度越高)
                也就是如果你在遠處開啟粒子系統沒有看到 對於自身的負荷會很低
                如果是3D粒子會如何? 首先3D粒子會受到較大的限制 其次似乎會將其大多數視為剔除掉 所以其造成負荷與2D粒子自身視角不會差距太大(3333 3D~=10000 2D)
                所以主要造成性能影響最大還是屬於蒙皮和網格 請盡可能保證其為關閉狀態 從而節省自身不必要的CPU和GPU開銷


                IP属地:中国台湾8楼2024-05-05 11:54
                回复
                  细节啊,平常哪会注意到这部分


                  IP属地:湖北9楼2024-05-05 22:27
                  回复


                    IP属地:浙江来自Android客户端10楼2024-05-06 12:08
                    回复
                      關於VRchat 使用Unity2020~Unity6之前(未包含Unity6 準確是2023.2之前 也未包含2023.2)
                      在這些Unity下計算蒙皮在Unity上的實現是有問題的 而VRchat禁用掉回退至頂點著色器
                      所以合併蒙皮對效率提升有限


                      IP属地:中国台湾11楼2024-05-06 21:18
                      回复
                        狠狠的奖励你


                        IP属地:湖南来自Android客户端12楼2024-05-07 08:58
                        回复
                          我錯了 沒徹底分離 可能還需要等待優化
                          所以還是能造成他人視角蒙皮網格計算
                          自身視角下關閉所有物理骨骼->節省有限 蒙皮網格變換成本仍然在->你需要完全算自己一份
                          他人視角下物理骨骼活動,所有活動蒙皮網格跟著計算一次(產生GPU多邊形開銷一次+CPU開銷一次 僅變形)
                          然後你看別人蒙皮網格仍然會再度產生一份多邊形開銷 直到受光照陰影影響 產生額外二至三份多邊形開銷
                          所以總計大概四份多邊形開銷 吐了


                          IP属地:中国台湾13楼2024-05-08 00:44
                          收起回复
                            問題原因
                            .....
                            world或avatar存在一個攝像機沒有關閉所造成 處於活動狀態
                            由於PB需要變換 邊界剔除的判定會比較大一些 所以造成奇怪的問題


                            IP属地:中国台湾14楼2024-05-09 01:05
                            收起回复