正文

游戲ssao是干什么的（游戲sss是代表什么意思）

發(fā)布時間：2023-04-21 17:51:26 稿源：創(chuàng)意嶺閱讀： 82

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關于游戲ssao是干什么的的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關鍵詞，就能返回你想要的內容，越精準，寫出的就越詳細，有微信小程序端、在線網頁版、PC客戶端

官網：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內優(yōu)秀的企業(yè)，服務客戶遍布全球各地，如需了解相關業(yè)務請撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、ssao吃配置嗎
2、原神為什么不全局渲染了
3、對HDR，SSAO這樣的post effect應該用什么樣的抗鋸齒技術
4、上古卷軸5enb怎么關ssao

游戲ssao是干什么的（游戲sss是代表什么意思）

一、ssao吃配置嗎

還是比較吃配置的。

目前有SSAO、HBAO、HBAO+等環(huán)境光遮蔽效果，配置不好可以直接關閉，開了如果開的等級低也看不出來太大區(qū)別。

小白一句話：配置不好可以直接關閉來獲得更大資源來調高別的選項。

環(huán)境光遮蔽：

這個簡要來說就是讓光照和陰影搭配得更加真實，改善細小地方光照和陰影的效果。可以選擇關閉，這個還是比較吃配置的。

反鋸齒（抗鋸齒）：

這個前面介紹過，這里列舉一些常見的反鋸齒技術，F(xiàn)XAA（快速，效果差但還看得過去，吃資源少，開不開一般反響不大），MSAA（比FXAA更好但更吃資源，低配顯卡一般開不到這個程度）SSAA更吃資源，TXAA（NVIDIA的技術，開了之后如果處于動態(tài)，鋸齒消除的效果很明顯，如果不動，那么可以看到很多鋸齒。吃資源的水平比MSAA 4X稍低）。

游戲ssao是干什么的（游戲sss是代表什么意思）

材質（紋理）：

什么是材質呢，簡要的說就是你看到畫面里一個東西的清晰程度。譬如木制桌子，材質開高，你能看見游戲里面木制桌子表面的木頭的紋路很清晰。開低，那么整個桌面可能就是黃黃的模糊一片。

這個設置對于顯卡要求比較高，高的紋理讓畫面更加細膩真實，但是也要占用更多的顯存（顯存就好比顯卡的背包，顯卡處理的一些數(shù)據(jù)會存在這里）現(xiàn)在的大型單機，對于紋理材質一項，可能會吃很多顯存，譬如刺客信條梟雄，高材質顯存占用3GB以上。更有像泰坦隕落2能占用8GB以上，不過這些參數(shù)都是峰值。也就是說環(huán)境不復雜的地方占用不到這個程度。

小白一句話：畫面黨最好開高，實在不行就中或者低。顯存占用超出顯卡本身顯存一般是沒關系的，超出的顯存會用內存、虛擬內存等代償。

二、原神為什么不全局渲染了

首先我還沒去綠色原神的防抓幀（雖然已經有很多人破了），米哈游法務就不要動我這篇文的主意了。

首先是全局光照部分。因為原神自己宣稱是全動態(tài)光照……直接光部分好說，反正都已經延遲了，而間接光部分，做成動態(tài)的也就是lpv，以及升級版的vxgi。lpv……成本在于最開始的rsm部分，也就是和原始光照數(shù)量有關。如果只處理天光，體素再稀疏點還是有可能在手機上運行的。而且看之前有人拆包的結果，里面確實有個lpv的庫（順便一提lpv UE內置，vxgi也有插件進行支持）。

但這種東西，真想在手機上跑還是瘋狂了一些。而且原神在時間變動和天氣變動時光照其實是有跳變的，如果真是實時GI好像并不會這樣，這種跳變更容易出現(xiàn)在多套烘焙數(shù)據(jù)切換上。而且就原神的畫面效果……多套烘焙數(shù)據(jù)插值也完全能做到。所以我覺得原神使用烘焙probe方式的間接光照還是可能的，即使包里有l(wèi)pv，也可能只是放著沒用，這個要看抓幀結果了。

傳統(tǒng)lightmap肯定沒用，用了以這個尺度包體不會這么小，而且畫面上也沒體現(xiàn)出lightmap的存在感。但室內有沒有用就不知道了。

路燈一類光源必定用的實時光。畢竟沒有l(wèi)m，只靠probe的精度不容易處理點光的光照邊緣。而且原神的路燈是有嚴重的漏光現(xiàn)象的，因為點光一般不投射陰影。少數(shù)幾個場景則開了實時投影，估計漏光已經到了不能忍受的程度。其實點光漏光有個visible probe的技術可以處理，在模型上記錄實時光照大概允許的角度，不清楚原神用沒用，但用了應該能緩解現(xiàn)在的問題。不過他們即使沒處理看起來漏光也不太嚴重的樣子。

體積光部分肯定沒用ray系的技術，原神體積光本來也不多。窗戶應該就是普通的片+粒子塵埃，因為正面看體積光會變弱。路燈外圍有個談談的體積光，估計是用的球形根據(jù)深度算距離積分的方式來模擬的，不是單純的片，這種只處理單個不重疊的點光的體積光還是比較物理正確的，但原神路燈的體積光很弱，大部分靠bloom，也不好講。

（好吧，之前沒認真看，白天的教堂窗戶確實是正常的體積光，但是本身側面看到的紋路就不像體積光產生的，而紋理在某個角度會消失。而晚上地面上看不到光投入了，側面看到的藍色紋理卻還在，但轉到正面看藍光就全沒了。所以可能就是體積光和片的結合，只是到了晚上，正常體積光就沒了或者降低到看不到。

但我還是有疑問的。如果是正常的體積光，那么就完全可以讓透過彩色玻璃的光帶上玻璃的顏色，但現(xiàn)在這個體積光看著卻是純色的。用ray tracing或者View體素本來很容易做到這樣的效果，沒做僅僅是因為不好看嗎？而且現(xiàn)在窗戶的體積光形狀其實很不精確，僅僅是這樣的效果，做點近似，比如近似為橢球體，就可以簡單通過計算獲得結果了，類似這個https://github.com/Fewes/VolumetricTracer。

算了，不管他，max說話本來就這樣，未必不是如此。但這樣依然沒有用ray系的技術。

教堂里柱子都沒法完全擋住體積光的部分，爆炸性漏光，肯定不是ray的方案。估計就是圓積分加深度遮擋，正好和街燈的方案一樣。）

原神的bloom……bloom的具體方案其實早就沒啥可說的了，只有卡通渲染控制bloom強度這個事情可談。原神肯定不是按物理方式處理bloom的，需要在gbuffer寫入?yún)?shù)來控制bloom的強度。但有個現(xiàn)象是，他們有些明明是黃色樹葉的樹木，卻能打出紅色的bloom來……而且明顯不是調色出來的結果，因為是逐物體的。

這說明他們bloom的顏色都是可以變換的。這就需要在gbuffer里輸出更多的參數(shù)（直接輸出bloom顏色或者映射lut）。但做到這樣的必要性真的有嗎？

而我覺得，這更像是在一般bloom外面疊了個glow。這并不用重新計算一次模糊，直接在用于計算bloom的那張rt上畫上額外的顏色，多級模糊后再疊回沒有畫額外顏色的那張圖，這種自定義bloom的方式其實比起加通道更?。ǖ驗橛蓄~外pass，只能少量物體用）

抓幀后都能明白。

原神的人物是獨立計算光照的，延遲光照時候會過濾人物的部分。人物的光照信息是獨立獲取的，主要源于間接光R0，實時點光則用不乘NoL的方式應用。但人物的光照疊加方式一點都不正確，顯然不是光照直接相加。因為在暗處依然很亮，也不是直接相乘，比較像是鎖定了光強的范圍。

原神在場景陰影下會做光照的硬切換，陰影下會直接去掉光照結果，讓人物正光背光沒有區(qū)別，這導致人物在室內缺乏細節(jié)（雖然正確）。

這里有個我無法理解的設計。原神場景陰影都是實時的，所以無法利用probe來獲取，那么即使不想人物出現(xiàn)半陰影，也可以直接用腳或者身體中點什么的采樣csm的方式來處理人物——現(xiàn)在看來是這樣做的。但即使是這樣做，也可以把這個顏色值寫入一張小rt，然后疊加顏色，最后人物采樣這個顏色，用這個方法來顯示個幾幀的過渡吧。這個的成本是很低的。

即使要考慮延遲管線的渲染順序問題也沒問題啊。倒不如說，這樣搞可以讓人物陰影可以直接用上幀的結果，人物的pass不再依賴本幀的shadowmap，那人物和basspass就可以一起畫出去也沒副作用了。

這個暫且不提。原神人物基本還是崩三那套，而固定繪制的陰影區(qū)域現(xiàn)在在光暗處也生效，這樣保留了一些暗處的細節(jié)，室內沒有直接光的情況也不至于不能看了，但因為這個也讓一些特寫畫面下固定陰影和實時陰影連接的地方很違和。

另一個是明暗交界處有了額外的過渡顏色。一般認為是ramp，但通常ramp都沒有計算快，所以也可能是公式算出來的。

原神人物完全沒有自陰影。這肯定是不好的，雖然是穩(wěn)，但是自陰影是貢獻光照變化很好用的要素，好多游戲用了也沒有任何問題，屏蔽臉上的陰影就夠了。原神整體配置要求不低，csm精度也很高，直接csm精度都有可能夠，不夠也可以做per-object的自陰影，限制數(shù)量也沒啥成本。

原神人物有個邊緣發(fā)光的效果，是固定左右兩次采樣深度差算出來的，強度和直接光方向有關。但是這個變的顏色其實是能變化的（切換人物會瞬間亮一下），所以并非后處理（否則就要把這個變化值寫入gbuffer太浪費了），那么，就必須在畫人物的這個pass能拿到深度，所以即使是延遲，也用了pre-depth？這個需要抓幀確定下。

場景和天空交界處也有類似的描邊，但這種就可以后處理直接做了。

原神是有ssr的，只是能夠看到明顯ssr效果的地方很少。水是ssr做的，倒影絕對不會反射出屏幕內沒有的內容，但天空盒是例外。在倒影采樣點快出屏幕的時候會漸變?yōu)樘炜蘸小?/p>

不過這個天空盒也是動態(tài)的，上面有云，這個需要花費一些成本來處理。

ssao體現(xiàn)在場景上，效果比較弱。因為原神沒有l(wèi)m，再沒有實時ao畫面實在撐不住。原神畫面就結果來講雖然還行，但整體畫面確實缺少光照細節(jié)，看起來很平，幾乎全是簡單直接光的貢獻。雖然這確實更有卡通的感覺，但是“平”的感覺也是實實在在的。

人物和場景靠近的地方不僅有ssao，還有非常明顯的橢球距離場陰影。在平時走路的時候也可以在腳附近的陰影處看到這個效果。這個特性是用計算（lut）來代替ray tracing，效率很高，否則如此不明顯的效果早被砍掉了。總體效果還是不錯的，以后的游戲也可以用。但是算它還是在延遲管線更方便點，前向有屏幕空間陰影流程也差不多，沒有也沒事，總之透明物體能取到深度圖的游戲都能用上。

原神當然還有個視差貼圖。它證明了卡通渲染和視差很搭，因為卡通渲染光照簡單而且缺乏高光，所以和法線圖一直不搭，導致最終結果缺乏細節(jié)。但視差的結果還是可以的。

視差肯定是陡峭視差，具體是哪種看不出來，如果是pom……采樣數(shù)感覺得有16，至少也有8。雖然都是可以接受的成本，在手游上大規(guī)模用這種東西也是挺恐怖的。視差畢竟也是ray tracing系的特性。

原神有幾個秘境出現(xiàn)了大規(guī)?？蛇M入的云海，肯定不是粒子，是ray tracing云。應該是利用了多幀抖動處理過的，手機上理論上是能跑的，但這個云細節(jié)和精度還是很足的，有一定挑戰(zhàn)。主線沒有，放在完全可以不去的秘境可能也是出于一些保守的考慮……但這個云的效果真的不錯，得做。

這個估計項目后期實現(xiàn)的，否則大世界頂端那片云海沒道理不用的。

下一步就是要想辦法弄可交互云了。

對了，還有個臉部法線修正。那東西其實是忽略了模型法線，然后用一張圖來完全指定法線的具體位置，并且在計算的時候忽略了光照Z方向。

當然也可以是等價的其他方案。

其實原神這種處理方式……還是穩(wěn)，但并不是很好，轉光的時候太違和了。但確實這方面也沒有完美的解決方式。

但用忽略模型法線的貼圖來處理法線的方式是ok的，比改模型法線方便多了。

再補充一句，原神沒有使用msaa，而是用smaa和taa（默認smaa）。但游戲里并沒有感覺到鋸齒的存在。所以，msaa很可能是不需要的，這能省去很多麻煩。

當然，原神不用msaa多半是因為延遲管線不好支持的原因。但結果看上去，沒有msaa確實是可以的。

UE一直不內置smaa也是個迷。

手機版更新：

閹割了視差貼圖，橢球距離場陰影，還有RayTracing云，但是體積光還留著，所以應該是那個球模擬的體積光。

CSM精度距離搞得很低，而且裁剪非常不保守，城里有面墻直接兩級CSM都沒有繪制導致了顯示錯誤。

不過，距離搞這么近，就能看出原神除了最高一級CSM，其他其實都是有更新頻率的，而且頻率很低。這樣的CSM性能就還行。

視差貼圖我看著是完全閹割了。按說替換成一次采樣的那個就行了，可能是效果不行？

距離場陰影按說性能成本不高，但是效果確實很不明顯，這可能是閹割掉的原因。

RayTracing云整個干掉了，搞成和大世界里一樣的方案。

基本上，稍微高級點的特性都被干掉了。所以LPV根本一點使用的可能性都沒有。我覺得有可能是用的LPV的中間烘培數(shù)據(jù)，這也能解釋為何包里會有LPV的代碼。

原神手機版的性能也就這樣，這大概能看出手機能夠使用的特性級別，目前很不樂觀。如果想使用高級特性，估計還是只能PC用。

但……原神手機也在繼續(xù)使用延遲管線，而且據(jù)其他人反映并沒有做onclip的SubPass（這個需要比較高的硬件API），本來性能也會非常糟糕，所以……它性能不好確實也說明不了任何問題。

現(xiàn)在發(fā)售的手游比較靠譜的還是繼續(xù)使用Forward管線，因為SubPass的支持率太低，做不了延遲。那么原神為什么沒有在移動端做一個前向管線？是因為真的在目前的特性下做不出來，還是僅僅是項目技術管理的問題？

不過問了下抓過幀的人，大概了解了下情況。原神雖然是延遲，但是和一般F+然后輸出GBuffer提供給SSAO和SSR繼續(xù)后面流程的做法差的也不遠。Cluster Lighting其實不管是延遲還是前向版本性能都差不多，也就差一個ColorBuffer的帶寬。那么即使換成F+，只是節(jié)約一個ColorBuffer，性能恐怕也不會多少提升，說不定還會因為額外的Pre-Depth變得更差。

所謂前向和延遲，也都僅僅是處理BasePass和直接光照時的差異。后面的部分其實大家都差不多，而那部分往往占的比例不小。現(xiàn)在Cluster延遲也就是輸出ColorBuffer然后一個Pass完成光照輸出到HDR，Cluster前向則是前面一堆Pass直接輸出到HDR，兩者也就是差一次ColorBuffer拷貝，而類似這種數(shù)據(jù)拷貝后面還會進行多次，能差多少呢？

只要還想要SSR這些高級特性，恐怕帶寬也不容易比原神更低了（當然，前向有參數(shù)更加自由的優(yōu)勢，但這并不是性能上的優(yōu)勢）

也就是說，只要你還想要SSR，你也很難在手機上做的比原神好。這就是現(xiàn)況。

有onclip，其實也好不到哪里去。這東西又解決不了切RT的問題，也無法降低GBuffer僅一次讀取和寫入的成本，只能把N次變成一次而已。

另外……原神現(xiàn)在的性能問題，反正對我這臺855plus來講，主要是發(fā)熱，而不是幀率。我開全高，只要解鎖了30幀還是能上到接近60幀的（反正比30高），但是會火速變成暖手寶。只有在它的默認配置下才能正常玩。而帶寬出問題一般也會很容易表現(xiàn)為發(fā)熱。

一般玩家玩這個，保持默認配置可能會好點。它這個配置多半是考慮了發(fā)熱和耗電后的結果。而且就算開全低，其實也沒有那么差。

（比較建議原神在玩家硬把設置改成紅條的時候彈窗提示下可能導致設備發(fā)熱或者掉電，堵下嘴）

但原神的30幀體驗確實不好，它的動畫幅度都太大了，幀率低的感受很明顯。即使明明是鎖30，你依然總會覺得幀率低于30。那些30幀游戲都是控制了物件運動速度的。

三、對HDR，SSAO這樣的post effect應該用什么樣的抗鋸齒技術

again，post effect不用抗鋸齒。進來一個像素出去一個像素。

你仍然沒有搞清楚問題的本質，甚至沒有辦法描述清楚問題。從你的文字上看，我猜你想說的是，場景渲染的結果有抗鋸齒，SSAO的結果沒有抗鋸齒，結果合起來不好看？這問題顯然不是出在SSAO本身，因為他就是個post process，沒有幾何體的概念。

毛

病在于你給SSAO的輸入，是不是一個已經resolve過、沒有subpixel信息的depth