20
| 本文作者： 王銳 | 2016-01-18 13:56 |
【編者按】作者王銳，VR行業(yè)資深從業(yè)者。
每一位游戲玩家，無論是傳統(tǒng)的PC和主機(jī)游戲，還是時新的手游以至VR游戲，都會對這樣一個名詞有著特殊的理解和關(guān)注，那就是FPS（幀速率，F(xiàn)rames Per Second）。FPS太低的話，畫面就一卡一卡的，玩起來不舒服；如果是戴上VR頭盔的話，因為暈動癥的影響，玩家甚至?xí)杆俑械筋^暈和惡心，一天都無法心情舒暢。
FPS顧名思義就是每秒鐘渲染的幀數(shù)，也就是說，顯卡和顯示器每秒鐘都會更新數(shù)十張不同的圖像（幀），進(jìn)而形成一種動畫的效果。
從傳統(tǒng)動畫的角度上來說，每秒10幀以上的畫面就可以形成連續(xù)的動畫效果（例如中國古代的走馬燈），而不需要任何交互的電影放映，則采用每秒25幀或者接近30幀的播放速度，讓觀看者自在地欣賞大片。
但是加入了交互元素之后，例如可以快速轉(zhuǎn)動視角的鼠標(biāo)，手柄，以及VR頭盔，人們對于幀速率的需求就直線上升了——如果是面對平面液晶顯示屏的話，受限于IPS屏幕本身的刷新率特性，內(nèi)容本身通常需要達(dá)到60FPS的渲染速度；而戴上VR頭盔之后，采用OLED屏幕的內(nèi)容則可以達(dá)到75FPS的更新，事實上，出于盡量避免暈眩的考慮，游戲內(nèi)容的畫面刷新也必須達(dá)到這個數(shù)值。
然而這談何容易：交互游戲并不是預(yù)先拍攝好的電影和動畫片。它需要根據(jù)玩家的操作來觸發(fā)不同的邏輯，并渲染出不同的畫面內(nèi)容。而游戲場景可能是復(fù)雜的，細(xì)碎的，并且有很高的真實感和特效方面的要求——而這一切都必須在短短的1/75秒內(nèi)完成！就算顯示硬件的水準(zhǔn)逐年提升，這依然是一個極具挑戰(zhàn)性的話題：如何優(yōu)化我們的場景和渲染策略，在如此有限的時間要求內(nèi)，實現(xiàn)高效與細(xì)節(jié)并存的游戲內(nèi)容呢？
本文將針對這一話題做適當(dāng)?shù)挠懻摚欢掝}本身的技術(shù)含量已是深不見底，所以文章也只能淺嘗輒止，只期望為讀者和同行們小啟一扇門扉。
在描述一些晦澀難懂的名詞之前，我們不妨先來看一個例子：
假設(shè)我們有一個果園，每天它都要派出一輛卡車，走固定的路線運送水果到市里去。如果運送的水果總量為10噸，而這輛卡車一次能夠承載200千克水果的話，那么顯而易見它需要跑上50趟才能完成這一任務(wù)，也許這會花費整整一天的時間才能夠完成。
顯而易見，我們并不希望這項工作花掉那么多的寶貴時間，那么一種直截了當(dāng)?shù)慕鉀Q方案是：給這輛卡車換上更為給力的發(fā)動機(jī)，比如NVIDIA的戰(zhàn)術(shù)核顯卡，讓它跑全程的速度減半再減半，同樣50趟的任務(wù)，這回只要一個上午就可以搞定了。
當(dāng)然生活也許并不總是那么如意的，也許果園的工作人員早就心懷怨氣，每次給卡車只裝了50千克水果，于是可憐的司機(jī)就需要走上足足200個來回，直到別人吃上早飯了還垂死地奔波在路上……
幸好，拯救他的方法也不止一種，比如，裝上戰(zhàn)術(shù)核顯卡之后，他至少能夠和別人一樣每天拉完50趟再按時回家吃飯了。
但是一個智商正常的果園老板應(yīng)該不會把這當(dāng)成是最合理的決策吧……難道不應(yīng)該先開除那個裝貨的？讓爺?shù)男】ㄜ噭e這么傻兮兮地跑上200個批次嗎？
結(jié)束我們的遐想，而現(xiàn)實卻也許傻得有些可愛：當(dāng)作為內(nèi)容開發(fā)者的我們同樣遇到了“卡車花在路上的時間太長”這種問題的時候，第一選擇往往是換用更逆天的顯卡和系統(tǒng)，而不是好好琢磨一下該死的工作人員藏哪兒了。
沒錯，送了200趟水果的卡車，就好比跑了200個渲染批次（Draw Call）的顯卡，而每個批次的執(zhí)行都是會消耗固定時間的。而為了縮短這一時間，進(jìn)而提升幀速率的開發(fā)者們，與其直接買入更新的顯示設(shè)備，倒不如先坐下來仔細(xì)想一想，渲染批次過多的瓶頸是什么（那個作孽的裝貨工？），我又能把它優(yōu)化到什么地步（至少恢復(fù)到50個批次的正常水準(zhǔn)？）。而這成百上千噸的水果就好比是復(fù)雜和精致的VR場景內(nèi)容，同一時間內(nèi)能夠送達(dá)的越多，它能夠表達(dá)的內(nèi)容真實感與細(xì)節(jié)程度也就越詳實。
渲染批次（Draw Call）在以往并不是一個被十分重視的概念，制作游戲場景的美術(shù)人員更愿意用“三角面數(shù)”（Triangle Face）來描述內(nèi)容的復(fù)雜程度或者制作水準(zhǔn)，譬如：這是一個足有1000萬面的卡通少女（她的每一根毛發(fā)也許都清晰可辨），又或者這是一個只有100萬面的故宮實景模型（然而我的高超技巧讓這一藝術(shù)瑰寶依然栩栩如生）。
殊不知，對于實時渲染而言，三角面數(shù)并不足以決定渲染的效率以及幀速率結(jié)果。僅用了一個批次就完成渲染的1000萬面模型，和用了1萬個批次才渲染完成的100萬面模型，其執(zhí)行效率恐怕是天壤之別。后者在實際執(zhí)行當(dāng)中的表現(xiàn)，恐怕一定會讓那些自信于低面數(shù)模型的人們大跌眼鏡。
然而這就引起了另一個有趣的論題：為什么會有大量的Draw Call呢？既然每一位開發(fā)者都能明白這樣的道理，為什么不一開始就設(shè)計成一次Draw Call執(zhí)行全部場景物體的渲染操作呢？就算是因為承載力的問題不得不分成多個Draw Call，這種簡單粗暴的設(shè)計依然應(yīng)當(dāng)是最優(yōu)的解法無疑吧？
然而這樣的愿望往往無力成為現(xiàn)實，因為現(xiàn)代圖形渲染底層接口對于Draw Call的實際執(zhí)行，是在繪制實際幾何體圖元（Draw Primitive）的階段；而每次繪制圖元的操作之前，我們只能為這組圖元（可能是200個三角面，也可能是10萬個三角面）設(shè)置一張紋理圖像（Texture），以及一組著色器（Shader）——而這兩者正是虛擬現(xiàn)實和游戲應(yīng)用當(dāng)中用于表達(dá)物體材質(zhì)和真實感的最核心組件。一張圖像能夠容納和清晰地表達(dá)一個精致美女的肌膚，秀發(fā)，慧眼，紅唇，絲衣，高跟鞋，LV包，以及其他種種細(xì)致入微的內(nèi)容嗎？當(dāng)然不能。所以我們也沒有辦法在一個渲染批次里搞定美女模型的一切。
而與此相關(guān)的另一個問題也會困擾著更深層次的圖形開發(fā)者：場景內(nèi)容的管理。例如一座數(shù)字化的虛擬城市，每一棟樓，每一個房間，每一輛車，每一位居民，都應(yīng)當(dāng)是獨立存在的個體，對這些模型資源的管理也顯然應(yīng)當(dāng)按照相似的分類方法。然而從渲染的角度來說，這樣產(chǎn)生的Draw Call恐怕遠(yuǎn)遠(yuǎn)不是最優(yōu)的選擇，甚至輕而易舉就會讓前文中送水果的卡車司機(jī)崩潰掉。
如果按照材質(zhì)把模型重新分組和整合，倒是可以進(jìn)一步提升渲染的效率，不過資源的管理工作卻無疑會讓人崩潰。試想一下，在公安局的戶口本上，你不再屬于某個家庭，而你身體的各部分則分別隸屬于短發(fā)組，麻臉組，格子衫組，灰褲子組……這種“按材質(zhì)分組”的行為看起來多少有點“漢尼拔”似的驚悚氣氛了。
然而，場景優(yōu)化面臨的麻煩還遠(yuǎn)沒有盡頭。
試想一位畫家，揮毫潑墨，將現(xiàn)實中的山水人物躍然紙上，描繪得栩栩如生。這些山水人物原本是自然存在的，繪制到紙上，就成了油彩，湊近去看，就會有濃重的顆粒感——雖然大多數(shù)情況下這并不妨礙我們觀瞻就是了。
現(xiàn)代計算機(jī)的圖形渲染過程與此類同。把復(fù)雜的場景模型躍然于屏幕之上，這一過程稱作光柵化（Rasterization），而屏幕上的像素點，近看起來同樣存在顆粒感，低分辨率的屏幕則更為明顯。這種顆粒感對于VR類的內(nèi)容來說更為顯著（因為VR眼鏡相當(dāng)于放大了屏幕分辨率對畫面質(zhì)量的影響），而它也是破壞場景真實感和效果的主因之一。
那好辦啊，有人可能會說，那就拼命增加屏幕分辨率不就好了。從現(xiàn)在的1080p，到2K，到4K，到8K……總會有徹底解決這個問題的一天吧？
然而事情并沒有這么簡單，還是回過頭來談?wù)勎覀兊漠嫾遥涸谝粡圓4紙上畫簡筆畫，也許他只需要1-2分鐘而已；如果是10米長卷，那么也許要一天的時間；如果是在萬里長城上……那么畫家可能直接就跳下去了，搞這么一輩子的工程，生不如死啊。
沒錯，這里的畫卷可以類比為我們所說的屏幕分辨率，而畫家求死的原因，只因為要畫的東西太多，而他對畫卷內(nèi)容的填充率（Fill Rate）太低了，因而渲染效率也變得慘不忍睹。
這個問題的解決方案，無非三種，弊端也是一目了然：
一，改用小點的畫卷（降低屏幕分辨率和用戶體驗）；
二，換個瘋狂的畫家（升級硬件，提升填充率）；
三，少畫點花里胡哨的東西（降低渲染內(nèi)容的質(zhì)量）。
聽起來都不是什么一勞永逸的選擇，并且大多數(shù)開發(fā)者一定會選用最直接的那個方案，沒錯，換更瘋狂的畫家，搞硬件的軍備競賽。
不過從場景優(yōu)化的角度來說，方案三反而成了最靠譜的一條道路，并且這給各路算法豪俠和數(shù)學(xué)家們也提出了一個有趣的命題：如何在渲染質(zhì)量還看得過去的前提下，盡量少畫點“對用戶沒用”的內(nèi)容呢？
對這句話的詳細(xì)解釋就是：用戶看不到的場景不要畫出來，把它提前裁減掉（Culling）；而用戶可能本來也看不清的場景，就用更低的細(xì)節(jié)程度（Level of Details）把它畫出來。
這里必須要解釋一句。顯卡并不是多么聰明的一種硬件產(chǎn)品，它并不能主動分辨出當(dāng)前提交的渲染指令中，包含的信息是否真的能夠被顯示到屏幕之上；而是選擇了另一種更為簡單的策略：不管有多少東西都先畫上去，如果不幸沒畫到紙上的話……反正你也不在乎對不對？畢竟最終用戶關(guān)注的只有紙面上的內(nèi)容而已。
然而古今中外，那些為了優(yōu)化場景而苦思冥想的開發(fā)者們，卻僅為了這一個目標(biāo)前赴后繼，傷痕累累。
當(dāng)然，這里所說到的“填充率”一詞，只是相關(guān)圖形系統(tǒng)運行機(jī)制的冰山一角。它還可能被進(jìn)一步細(xì)分為像素填充率（光柵化操作和屏幕緩存繪制的速率）和紋理填充率（紋理在模型表面映射和采樣操作的速率）。而實際執(zhí)行過程中，還可能受到顯存帶寬（顯卡在單位時間能夠傳輸數(shù)據(jù)的總量）參數(shù)的影響，而這些信息往往都會標(biāo)識在具體顯卡品牌的性能說明文檔中，作為發(fā)燒友比較和購買的依據(jù)（雖然它們實際上并無統(tǒng)一標(biāo)準(zhǔn)可言）。
不過這并非本文所要繼續(xù)深入闡述的命題了，我們關(guān)心的，還是那些圖形學(xué)和VR領(lǐng)域的先行者們，為了哪怕一點點的優(yōu)化效果做出過的努力。
之前的長篇大論，列出了各種看起來棘手和不可逾越的問題，在這里歸結(jié)起來，無非有以下幾點：
一，渲染批次（Draw Call）的合并與優(yōu)化問題；
二，裁減看不到的物體，降低渲染批次和填充率；
三，對于看不清的物體（比如距離玩家位置較遠(yuǎn)的物體），改變細(xì)節(jié)程度并降低填充率。
單純合并幾何體數(shù)據(jù)也許只是一個數(shù)學(xué)和幾何拓?fù)鋵W(xué)上的問題而已，然而每個渲染批次只能使用一組材質(zhì)，這就大大提高了工作的難度和策略性。
一個聽起來還不錯的方案就是，將不同的材質(zhì)合并到一起，這樣對應(yīng)的渲染批次也就合并在一起了——這一過程通常被稱為Atlas。
沒錯，就是《云圖（Cloud Atlas）》那部電影中所體現(xiàn)的，把不同的碎片（紋理）拼合在一起。
這一工作并不像想象中那么簡單，因為你要合理地選擇被拼合的紋理圖像，以及考慮拼合的結(jié)果是否真的就提升了你的渲染效率？因為紋理Atlas的結(jié)果無非是一張更為龐大的紋理圖像，而這實質(zhì)上增加了紋理填充的時間。過度的Atlas只能讓系統(tǒng)變得更慢，甚至遠(yuǎn)低于拼合之前的結(jié)果。只有將那些本來就零散細(xì)碎的小塊紋理拼合起來，并且合并對應(yīng)的繪制過程到同一個Draw Call當(dāng)中，才有實際的價值和意義。
然后是數(shù)據(jù)的裁減（Culling），同樣是一個簡單而又復(fù)雜的命題：如何定義“玩家看不到的物體”？
最簡單的一種情形是，他視野之外的物體。也就是說，如果把人的視野當(dāng)作是一個空間的錐體的話，那么暫時丟掉這個視錐體之外的所有物體，讓它們不要被渲染出來即可，即視錐體裁減（Frustum Culling）。
另一種麻煩但是很有意義的情形是，被其它什么東西擋住的物體。比如床底下的皮球，穿在外套下的襯衣等等。他們雖然在觀察者的視野范圍內(nèi)，在當(dāng)前時刻卻不可能被看到。此時我們也可以選擇直接剔除掉這樣的物體，因而降低渲染批次和填充率——不過前提是，我們能盡快先找出那些確實被遮擋住的物體來，也就是遮擋查詢（Occlusion Query）和遮擋裁減（Occlusion Culling）的概念。
不幸的是，在空間中進(jìn)行復(fù)雜形體之間的遮擋判斷，絕非易事。就算有合理的數(shù)學(xué)方法可以最終遍歷和找到所有被遮擋的物體，這一運算過程耗費的時間恐怕也早已超過了直接渲染它們所花費的時間。因此，更為簡化和高效的裁減算法研究也成為了一個仍在持續(xù)進(jìn)行的話題，近年來更有了不起的開發(fā)者群體實現(xiàn)了自己的軟件光柵化過程，僅用作快速的遮擋判斷。不過相關(guān)技術(shù)的普適性驗證和推廣，還有很長的一段路要走。
另一種同樣重要的優(yōu)化方式就是場景物體的細(xì)節(jié)層次（Level of Details，LOD）劃分。
當(dāng)物體距離觀察者較遠(yuǎn)的時候，采用粗糙層次的物體模型；靠近觀察者之后，采用精細(xì)層次的物體模型。這種策略對于大規(guī)模場景的渲染（尤其是那些動輒以數(shù)十?dāng)?shù)百GB來算的地球級場景數(shù)據(jù)），往往有著不可替代的價值和意義。
當(dāng)然，單純的離散模型LOD也有種種的弊端，譬如切換層次時的突兀感，以及資源管理的復(fù)雜性等等。人們也在不斷研究更新的分級，自動處理，分頁調(diào)度等策略，只為了讓更多更好的內(nèi)容躍然于那不斷增幅的畫紙之上。
而高質(zhì)量的渲染畫面，對于場景優(yōu)化的負(fù)面影響，往往也是不可忽略的。比如游戲中最為常見的陰影圖技法（ShadowMap），從光源的角度重新渲染一次非黑即白的場景，再映射到原始的場景畫面當(dāng)中，形成逼真的陰影效果。這個看起來必不可少的需求卻讓我們苦心降下來的Draw Call直接翻倍。又比如多重采樣抗鋸齒（MSAA），實時反射（Reflecting）等種種效果需求，都是快速吃掉有限渲染效率的大殺器……為此，已是熬成謝頂與白發(fā)的開發(fā)者們也只能重整旗鼓，在場景優(yōu)化的狹小空間里再耕耘，再奮戰(zhàn)；而這一切，也許從未被屏幕前的玩家所知吧。
VR這個領(lǐng)域的火熱，也直接帶來了一個現(xiàn)實的問題——內(nèi)容由誰來完成，高質(zhì)量的內(nèi)容如何去呈現(xiàn)？
VR眼鏡本身具有左右眼分別渲染的特點，因此這也意味著實際場景也要根據(jù)左右眼的位置和視角分別渲染一次。這就意味著渲染批次的直接翻倍，填充率指標(biāo)也大受影響。一些原本在PC顯示器上流暢運行的逼真游戲，一下子跌入“卡頓”的谷底。
而這還遠(yuǎn)遠(yuǎn)沒有盡頭，VR行業(yè)的研究者們已經(jīng)證明，60Hz的傳統(tǒng)顯示器刷新率，遠(yuǎn)不能滿足VR游戲內(nèi)容的需求，75Hz也只是剛好可以避免過快的暈動癥而已，90Hz乃至更高的刷新率和渲染幀速率才是人們的期望。沒錯，翻倍的渲染壓力，以及近乎翻倍的幀速率要求……這就好比一個“二?！彪A段才勉強(qiáng)夠上一本線的高中生，突然被告知“必須考上清華北大，不然就回去拾荒”時候的心情吧。
但是，心情歸心情，現(xiàn)在這些低劣的VR游戲場景騙不了最終的消費者，各種幼稚和簡單的游戲邏輯也絲毫無助于VR元年的期望。
AAA級別的大作在哪里？黑客帝國一般的幻境在何處？要為此付出巨大努力的絕不只有硬件工程師們，也絕不可以簡單歸罪于美術(shù)人員的無能。要知道，縱使是Unity和Unreal這樣的成熟商業(yè)引擎，面對VR的苛刻需求和毫無優(yōu)化可言的套用的傳統(tǒng)游戲場景，其渲染性能也會捉襟見肘，狼狽不堪——而這一切的始作俑者，正是缺乏圖形底層知識和深入實戰(zhàn)經(jīng)驗的開發(fā)者自己；能夠想到方法，脫出困局的，也只有靠這群戰(zhàn)士發(fā)奮后百倍千倍的努力。
是的，屬于VR的戰(zhàn)斗，才剛剛開始。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
