2015年9月28日 星期一

Blacksmith中的皺紋貼圖處理


作者:TORBJORN LAEDRE
原文:http://blogs.unity3d.com/2015/05/28/wrinkle-maps-in-the-blacksmith/


在我們籌備The Blacksmith短片專案的時候,我們從未真的考慮過將自訂皮膚著色器提升到成為一個專門的工作。 不過,我們還是想看看能否用一些我們能做的簡單方式,讓角色的表情更生動。

在一陣腦力激盪之後,我們決定為專案增加一個執行皺紋貼圖的形狀融合(blendshape) ,為了讓表情加上深度和細節,我們確信如果能讓皺紋同時作用法線和遮擋, 採用標準著色器(Standard shader)將會給出最棒的效果 ,同時,我們也希望能通過某種方法,來對特定的臉部表情表達加以限制。

皺紋貼圖驅動設計(Enter Wrinkle Maps Driver )


我們做了一個組件讓動畫器(Animator)能夠定義皺紋層,網格的每個形狀融合都各自對應一層。 皺紋層的定義包含了紋理貼圖、強度指示器以及一組匹配於人臉各部分的遮蔽權值。 因為使用了遮蔽權值,每一個具體的皺紋層都可能作用於1~4個面部區域,並對每個區域造成不同程度的影響。



因為我們希望能夠在任何情況下混合多達四個不同的表情,單單混合就需要用到11個紋理採樣(兩個基礎紋理,八個細節紋理和一個遮罩紋理)。 對此,唯一實際作法,就是將皺紋貼圖在一個螢幕外的預渲染通道中組合起來。

我們發現ARGB2101010渲染材質格式在此非常切合我們的需求,因為它允許我們僅用10bit通道中的兩個來處理法線,而剩下的一個用於存放遮蔽信息。 在每一幀,皺紋貼圖組件都會尋找出四個最具影響的形狀融合,然後更具權值分層渲染。



一旦我們在螢幕空間內完成所有的皺紋數據合成,剩下的唯一要做的事情就是:重定向我們用於繪制人臉的標準著色器的法線和遮蔽數據的輸入。

在實際操作中,這僅需在表面著色器(surface shader)的主函數中添加很少幾行代碼。 


//皺紋貼圖被啓用時,於屏幕空間緩衝中對法線和遮蔽信息進行採樣
#ifdef WRINKLE_MAPS
float3 normalOcclusion =
tex2D(_NormalAndOcclusion, IN.screenPos.xy / IN.screenPos.w).rgb;
o.Occlusion = normalOcclusion.r;
#ifdef _NORMALMAP
o.Normal.xy = normalOcclusion.gb * 2.f - 1.f;
o.Normal.z = sqrt(saturate(1.f - dot(o.Normal.xy, o.Normal.xy)));
#endif
#endif

最終結果(Final Results) 


極度憤怒表情下,對比皺紋貼圖處理所帶來的額外細節。



我們還額外編寫了多種除錯輸出模式,使我們能夠輕鬆查看完全融合的遮蔽和法線貼圖。有助於定位各個組件在最終結果中究竟起何作用。



我們已經把這一功能單獨抽離成為一個展示專案,你可以從Asset Store下載。

專案只有角色的頭部以及兩個我們在Blacksmith短片中用到的表情,不過對於啓發你在自己的遊戲中應用皺紋貼圖而言,這應當是一個相當不錯的開頭。

2015年9月18日 星期五

Unity 5.2按幾下輕鬆使用Unity新服務!

作者:RASMUS SELSMARK
原文:http://blogs.unity3d.com/2015/09/10/unity-services-are-just-a-few-clicks-away/

上周我們發佈了Unity 5.2,讓你能在編輯器內輕鬆使用Unity Ads, Unity Analytics,Unity Cloud BuildUnity Multipalyer, 從此告別SDK!
只需幾步,就是這麼簡單!


1.打開Window底下的Unity Service,或者點右上角的「Cloud」圖示。




2.建立專案ID,請注意Project ID是您專案的唯一識別,您可以在服務視窗看到如下標籤:Services, Members, Age Designation, and Settings.



下面我們為您一一解釋每個標籤的功能:

Services

在這裡,您只需要將按鈕調成「ON」就可以使用Unity Ads和Unity Analytics。想要使用Unity Cloud Build,您需要先接受一些法律條款和說明,然後繼續使用。如要使用Unity Multiplayer,您只需設置好您的配置即可。就是如此簡單!

Members

當您需要分享您的專案給團隊其它成員時,你需要在此授權給他們。您可以直接在Members標籤直接邀請更多的成員並在您的線上專案Dashborad裡設定他們的權限。任何專案都必須有所屬組織,然而在每個組織裡可以包含很多個專案。



Age Designation

在美國,如果開發的項目是針對13歲以下的兒童使用的,要求必須符合「COPPA(兒童在線隱私保護),如果您的項目符合此項規定,請將您的項目中年齡設置為「13歲以下」。當然,這樣會限制一定的Unity Analytics 和 Unity Ads的數據收集,不過不會影響您在Unity Service的使用。

Settings

您可以在設定裡根據需要修改專案名稱,但是Project ID是唯一的識別,不可以更改。建立一個新的Project ID,比如有時候您需要使用一個專案作為模版,那麼只需要點擊「Unlink」即可。


就是這麼簡單!

在Unity 5.2使用服務就是如此輕鬆簡單。

Unity官方網站會有更詳細關於Unity Ads, Unity Analytics, Unity Cloud Build和Unity Multiplayer的文件!


2015年9月8日 星期二

從人體舒適度討論Unity對於VR體驗的方向


作者:張鑫 & Kelvin Lo


本文為Unity Technologies 技術支持經理 張鑫與原廠講師 羅志達共同撰寫的文稿,旨在於讓更多投身VR領域的開發者在創建專案之前,從過去,現在與未來的多重角度來瞭解Unity對VR產業的支持

VR的發展歷史與現在火爆的原因

在開始瞭解如何創建一個VR項目之前,首先需要瞭解VR的一些歷史:1935年,小說家Stanley G.Weinbaum在他的小說中描述了一款虛擬現實的眼鏡,而該小說被認為是世界上率先提出虛擬現實概念的作品,故事描述的就是以眼鏡為基礎,包括視覺,嗅覺,觸覺等全方位沈浸式體驗的虛擬現實概念;1962年,一部名為Sensorama的虛擬現實原形機被Morton Heilig所研發出來,後來被引用到空軍,以虛擬現實的方式進行模擬飛行訓練。雖然隨後從1970年到1994年的二十多年間,VR領域有許多科學家相繼投入研究,但從整體上看,還僅限於相關的技術研究,並沒有生產出能交付到使用者手上的產品,直到1994開始,日本遊戲公司Sega和任天堂分別針對遊戲產業而推出Sega VR-1和Virtual Boy,在當時的確在業內引起了不小的轟動,但因為設備成本高,普及率並沒有很大,但也為VR硬體進軍To C市場打開了一扇門。

Sensorama原形機
圖片來源:Google images


現今VR產業火爆,起因是因為2012年Oculus Rift通過國外知名眾籌網站KickStarter募資到160萬美元,後來被Facebook以20億的天價收購。而當時Unity作為第一個支持Oculus眼鏡的引擎,引導了大批開發者投身VR項目的開發中,正式點燃了這場VR大戰,但當時吸引的族群多為遊戲開發者,直到2014年Google發佈了Google CardBoard,以非常低廉的成本通過手機來體驗VR世界,導致更多開發者紛紛加入這戰局,點燃了今日的"Mobile VR"大戰

圖片來源:Google images


縱觀當今市場,從獨立開發市場分析的結果,2017年會有超過1300萬的VR硬體產出,2020年更會超出5000萬台,總市值將達30億美元

VR原理與現狀深度探討


就目前的VR體驗而言,其最亟需解決的問題就是用戶體驗時的眩暈等身體不適問題。造成身體不適的原因很多,解析度、畫面重影、畫面延遲、深度感知不連續等等。人體全身上下有許多感知器官,時時刻刻都在不斷感知周圍訊息並傳給大腦,大腦不斷對這些訊息進行處理,判斷是否正常與「合理」。

所以,如果出現了大腦無法識別的衝突訊息,大腦就會感到「困擾」而產生不適感。以上所說的「重影」、「延遲」和「深度感知不連續」等,均會讓大腦感到「困擾」,因為這些現象在人們習以為常的生活中,幾乎是不可能出現的。因此這種情況極大加速了人們大腦的疲勞,甚至出現眩暈惡心等情況,大大縮短了VR體驗的時間。

目前,沈浸式VR的體驗時間一般為每次5-10分鐘,連續體驗不宜超過30分鐘。如何提供給用戶更棒的VR體驗,已經成了當今VR領域首要解決的問題。就目前而言,主流的硬體廠商都在以下幾個方向進行不懈的努力。


提高幀率、降低延遲度


一般來說,一款PC/手機遊戲的FPS只需保持在30 FPS以上,即可滿足玩家流暢遊戲的需求。但對於沈浸式VR體驗來說,30FPS是遠遠不夠的。這裡需要先解釋一下延遲度(Latency)這個概念。


如下圖所示,所謂"延遲度"是指從頭戴式設備的陀螺儀將方位訊息傳到PC開始,經過PC/手機的計算渲染,最後傳回到螢幕顯示的時間間隔。所以用戶眼睛真正看到的實際上是幾十毫米之前的場景。



設備延遲度的形成原因。該圖取自Nvidia的技術文檔《Gameworks VR》。


如果延遲度過長,用戶實際看到的渲染場景是「一頓一頓」進行顯示的,這會增加VR體驗的不適感,甚至讓人感到眩暈。一般來說,延遲度需要小於20ms且越小越好,這樣才能保證較好的VR體驗。如果想要延遲度小於20ms,則必須要保證FPS至少達到75,甚至90以上。而必須兩眼都達到的情況下,即便是對於目前的主流家用PC機來說,也算的上是「苛刻」了。


雖然Oculus提出了Async Timewarp技術來盡可能在低幀率的情況下保證延遲度,但這個方法目前只適用於「頭部旋轉」(Rotation Timewarp)和小範圍慢速度的位置移動(Positional Timewarp)。對於快速移動和動態物體,效果仍有限。因此,這裡需要說明的是,在提高VR體驗時,沒有任何一種方法比"提高FPS"更為有效。


Async Timewarp方法比較適合與靜態場景的顯示,但對於動態物體,則會出現「重影」效果,進而造成一定的視覺不適。


提升解析度


目前的沉浸式螢幕需要近距離觀看,而營幕貼近眼睛很容易產生紗窗效應,使眼睛能夠看出屏幕中的格點,進而產生不適。坦白說,解析度問題需要依靠硬體方面的提升才能得以解決。


VR與人體的關係與注意事項


VR鏡頭的結構有如一雙眼睛有兩個平行的鏡頭,且各自擁有獨立的校准功能,眼睛往前看的情況下視角(FOV)範圍水平角度122°,垂直角度120°,如果是在頸部自由運動的範圍下,視角(FOV)能達到水平角度210°,垂直角度160°。有趣的是,如果以每度60x60像素來算,我們認為當螢幕技術進化到12K x 10K時,VR體驗將會非常趨近現實。

圖片來源:Google images

VR體驗最重要的環節還有聲音,但許多開發者忽略了聲音的重要性,試想把耳朵塞住看電影,整個體驗將完全沒有沈浸感,因為人的耳朵掌管許多事情,比如平衡感和聲音傳遞,它們就像是兩個心型麥克風,人腦通過聲音傳遞到兩只耳朵的強度和時間差計算出聲音的方向,分析出這段聲音是否需要被注意,進而決定你會選擇轉頭往音源方向看去,還是會選擇忽略這段聲音。也因為人腦有這樣的過濾機制,使得即使在很吵雜的環境里,如果有人叫你的名字,你也會特別容易感知到,這就是有名的"雞尾酒效應"


值得一提的是,人的耳朵接受到高頻音(3000Hz以上)時會下意識地往上看,而接受到低頻音(750Hz以下)時會往下看,因此在製作VR項目時,這都是有利於引導使用者視線走向的好方法

我們常常提到自己感覺到了速度,其實那指的是加速度,人體對於加速度是有感的。因此無論是飛機起飛或汽車加速時,你就能感覺到速度快速增加,但人體對於"速度"本身是感覺不到的,當飛機飛行到穩定速度時,你能在機艙內安穩地用餐而不會覺得飛機正在快速移動,而你現在也無法感覺到地球正在定速轉動

重力感是唯一我們無法欺騙身體的感覺,比如在某個VR項目中過雲霄飛車翻轉了180度,但實際上你的身體清楚地意識到其實你重力還是朝下,這時沈浸感就會降低,除非該專案真的搭配了能轉180度的椅子才建議做這樣的設計。

人體比想像中更容易感到疲倦,如果長時間配戴VR設備,不管是眼睛還是手都很容易產生疲勞感。如果過於頻繁地引導玩家改變聚焦距離也很容易使人感到疲倦,我們建議最佳的距離是2M-5M。而以目前的硬體設備的性能來看,最佳的內容體驗時間大約是5分鐘-10分鐘,時間過長人體就會產生疲勞感。其他比如突然晃動鏡頭,突然停止畫面或是幀率過低都會讓人體產生不舒服的感覺


真實感與移情反映

其實人類並非像我們所想的那樣,希望從VR體驗中得到真實感,或者說對真實感的追求是有限度的,這是因為人的情感系統天生帶有移情反應,會把所有虛擬現實世界裡的物體和真實世界划上等號。如果在虛擬現實世界里看到一隻朝著你搖尾巴的小狗,你會主觀地認定它對你沒有傷害而降低警覺性,而當你的專案是恐怖遊戲時,這種移情反應將會是一個非常好的切入點。舉一個有趣的例子,當你去商場買衣服的時候,你會發現假人永遠都是沒有頭或是沒有五官的幾何圖形,如果假人有張人臉反而會令客人產生恐懼感,這是1970年日本機器人專家森政弘,根據Ernst Jentsch於1906年發表的"恐怖谷心理學"所提出的理論:當人類看到與自己形體相當的假人時會產生正面情感,但是隨著假人越接近真實的人類外表與行為時,人們則會突然產生劇烈的排斥與恐懼感,直到假人與正常人類外表與行為完全一致時才會消除這份恐懼感,這樣的曲線呈現看起來像是一個山谷,因此稱為"恐怖谷理論"


因為曲線呈現一個谷的形狀而被稱為恐怖谷理論
圖片來源:Google image



正因為移情反應,開發恐怖遊戲更適合使用真實世界的材質而非卡通材質,沈浸在虛擬現實內的玩家看到鋒利的刀會不由自主的想要避開,看到熊熊烈火會想要繞開,因為有這樣的反應,所以虛擬現實也非常適合用在軍事訓練上,讓士兵習慣在危險的環境中生活。


VR的目前市場分析與硬體介紹


雖然VR硬體百家爭鳴,但目前市場上大概有三種類型的設備


第1種.必須接上電腦的沈浸頭戴式設備(HMD),這種設備的代表就是Oculus Rift,其優點在於沈浸體驗很好,但由於是有線設備,其有限的移動範圍是個障礙,因此特別合適於雙腳不需移動的應用。設備本身價格比較昂貴,因此大多都是應用於to B的領域,現在該設備上的應用大多都是短時間體驗,因此非常適合展覽或是商業活動展示,但這類活動體驗的人數較多,因此如何保持設備的衛生將是個大問題。
除此之外,還有Sony的Morpheus和HTV的Vive等設備都即將問世。


第2種.需要自帶手機的VR(Mobile VR),現在人手一部手機,因此該類設備只要簡單地將紙版折成的可容納手機的盒子就能體驗,代表性的設備有Google Cardboard及Gear VR,雖然體驗沒有PC頭戴設備好,但由於成本低廉,易於攜帶,開發應用的流程也是手游開發者所熟悉的,因此今年有大量的開發者投入Mobile VR的開發行列,進而帶動了整個VR市場的發展。


第3種.整合VR+AR技術的新型態體驗,進入CR(Cinematic Reality)新領域,要知道市場上總是有往前衝的領頭羊,谷歌所推出的Google Glass就是一個案例,雖然現已成為絕響,但也造就後面的Microsoft Hololens, Magic Leap等新型態眼鏡的快速進化。未來眼鏡的輕量化,極強的電池續航力將是次世代VR設備的重點,但為了達到眼鏡輕量化的效果,代價就是身上必須背著一個用來運算的硬體,如果運行效果能達到預期,我們將踏入次世代VR領域。


除了上述大類之外,也有許多不同的VR裝置,比如投影VR或全息VR。


如何用Unity開發VR專案


Unity 從5.1開始就把VR SDK整合到引擎內,開發者只要下載最新的Runtime Driver之後,在Player setting設定內將Virtual Reality Supported打勾,並把眼鏡連接上電腦就能直接把專案轉為VR專案,預設的鏡頭會自動切換成為VR鏡頭,VR的開發過程將與開發一般專案無異,只有在按下Play按鈕時,Game View的視角才會切為VR雙鏡頭畫面
Player setting畫面


VR專案的優化依照硬體差異會有不同的考量,但是與手機遊戲相比起來相對容易,在現今的手機上,我們建議保持下列幾點守則,以保證專案執行順暢:



1.絕對不能讓FPS突然下降
2.減少物體數量,減少物體曲面
3.多用靜態物體,採用烘焙光照
4.Draw Call保持100左右
5.小於100k的三角面
6.可以採用高解析的紋理來彌補
7.使用物理引擎來避免CPU消耗過大
8.採用LOD,遮擋剔除,批次運算


Unity 5.1的Profiling功能已經支援Oculus和Gear VR的直接報告,這代表只要裝置連接或是在同網段下,開發者就能透過Profiler來監控VR專案的效能並進行優化。




目前Unity的VR開發技術挑戰


傳統的VR渲染管線,是使用兩個相機按照視距擺放並對場景進行渲染。一般來說,渲染時需要在每個相機中依次掃描場景中需要渲染的物體,因此整個場景被渲染了兩次,如下圖所示。這種做法最為直觀簡單,但本身存在較高的性能浪費。同樣的場景,近乎一致的相機設置,卻進行了兩次視域體裁剪(Culling)操作,兩遍的圖形管線API以及雙倍的Drawcall佔用。因此,我們在Unity 5.1中針對VR的渲染管線進行了深度優化,比如場景裁剪(Culling)僅做一次,場景中的動態陰影也僅渲染一次等等。同時, Android多線程渲染功能和GPU skinning(僅OpenGL ES 3.0)技術的大力支持,讓VR方面的渲染性能得到了較大幅度的提升。


傳統的VR渲染管線。


接下來的Unity開發計劃還會加入更多VR設備相關的API,比如眼球追蹤API等。渲染管線也會繼續優化,預計5.1之後的渲染管線會有幾種走向:


1.渲染場景時,只掃描一次場景,每個物體只送出一次,但根據照相機的不同Viewport和Transform渲染兩遍。這方法較易實現,且與舊的VR渲染管線相比好些,大量的圖形管線API僅呼叫一次,但缺點是渲染時仍需要消耗兩倍的Drawcall。

改進後的VR渲染管線。


2.原理同方法1,不同的是通過Command Buffer(DX11)來送出和渲染場景中的物體。所以優點也方法1一樣,缺點同樣是兩倍的Drawcall消耗,以及需要硬體設備支援Command Buffer功能。

3.在掃描場景進行渲染時,通過硬體Instancing技術針對每個物體渲染兩個instance,一個用於左眼相機,一個用於右眼相機。這樣做的好處不僅保證了對圖形管線API的一次呼叫,同時還可以大幅降低Drawcall的佔用,即雖然顯示於兩個相機中,但只需要一倍的Drawcall。這方法的缺點是不支持Open GL ES 2.0的設備,同時與標準的Instancing技術也會產生衝突


結語


雖然VR硬體廠商如潮水般的湧入市場,但目前仍缺乏一個商業化思維,簡單來說就是尚未找到一個能夠賺錢的方法,但這和軟硬體發展有極大的關係與空間,相對於VR,反而AR領域目前還比較能夠找到商業模式。但VR前景仍被看好,我們也相信隨著更多人投身該行業,相應的商業模式也會迅速確立。

這幾年的科技產業變化突飛猛進,我們對於VR產業是相當樂觀的,預測短短幾年內我們就能在生活中體驗到各種VR或AR項目,以Unity的角度來看,保持技術領先,永遠以幫助開發者為前提,和所有的硬體公司和開發者保持良好互動,並提供一個良好的開發環境來創建出未來優質的VR產品,是我們不會改變的目標。

THE BLACKSMITH中獨特的角色陰影

作者:TORBJORN LAEDRE
原文:http://blogs.unity3d.com/2015/05/28/unique-character-shadows-in-the-blacksmith/


那是一個風光明媚的早上。我想應該是去年秋天的某個時候,我們終於等到了引頸期盼的消息:維京挑戰者角色終於來了!

當時它仍是一個粗模:一個光頭,
尚未賦予任何材質沒有任何皮膚貼圖,但我們為他的到來感到興奮無比。 「快來人啊,把給這壞小子給我打上材質,然後放進我們的場景吧!」

完成後,它確實看起來非常酷。除了……有些地方看起來怪怪的。

「呃,這傢伙真的有接收動態陰影嗎?」

事實上他真的有接收動態陰影,然而並非以我們期望的結果。

總體看來角色並沒有收到任何影子,因此我們斷定問題就出在陰影上,它看起來很奇怪,而且影子參差不齊。

問題所在


我們快速的對著色器(shader)進行了研究之後,醜陋的真相就原形畢露:不但一半的角色沒有陰影,而且這角色陰影看起來有種塊狀的詭異感。


「為什麼會這樣呢?」
你可能感到好奇。不管怎說,Unity5不是採用了全新的陰影演算法嗎?

確實如此,而且的確很強大。

我們的場景最遠有3000M的距離,而且我們想要從很遠投射陰影到視椎的每一個像素上。現在,我們當然竭盡所能地調整了級聯分裂(
cascade splits)和陰影偏移(shadows biases),讓近距離或是離鏡頭非常非常遠,效果看起來都很不錯。

然而,到目前為止,我們卻從未經歷過一種情況,那就是在一個如此宏大的場景中放一個離相機很近卻又很複雜的角色。

問題出在我們缺乏用在角色身上的陰影解析度,為確保場景美觀深度偏移過大,導致它將陰影偏移角色的一半身體。

我們才了解,一塊皮帶在距離它1cm的盔甲上投射出陰影,和一塊中等尺寸的岩石在地面上投射出陰影完全是兩回事。

又有誰能料到呢,嗯?
因此我們需要尋求一個解決方案來解決這困境。我們可以將Quality Setting裡陰影級聯(Shadow Cascades)的第一級移動到非常非常靠近相機的位置,但代價就是這場景浪費了一級可用。

它僅僅會在我們的角色們真的非常非常靠近相機時才會運作,但已經足夠解決我們眼下遇到的問題了。

解決方案


然而,我們決定用一種比較老派的技術解決於這個問題。

「如果我們針對角色另外渲染一層陰影貼圖呢?」試試看。

寫了兩百行程式碼後,結果出現了:


此時,我們已經能夠產生足夠多的數據來呈現任何可能的陰影了。但時間不允許我們花太多時間去做最佳化微調,我們決定做一個類似於Nvidia光導開關[註1]的一個距離感知取樣方案。

我們還設有一個選項用來捕捉人物對焦領域之外的陰影投射數據,
這裡就沒抓圖了。比如說,我們仍然需要有靜態的世界的陰影透射到這些動態的角色上。

這類投影被會被投到陰影渲染鏡頭最近平面上,確保他們在陰影濾波方案中總是具有最大的攔截與接收距離 。

如此一來,剩餘的唯一的問題便是如何將上述工作整合到渲染管線(rendering pipeline)了。

在研究過後,結果我們發現原來有一個非常簡單的方法來對常見的Unity shader陰影方法進行重寫。

經過幾次改良,我們簡化為只需添加兩行額外的程式就可以對著色器加上這種陰影:

#pragma multi_compile _ UNIQUE_SHADOW UNIQUE_SHADOW_LIGHT_COOKIE
#include "UniqueShadow_ShadowSample.cginc"

請注意,為確保能夠正常運作,這裡的「include」部分必須寫在其他的engine includes之前。

因為我們在這裡用了一個include文件來將真正的複雜部分給覆蓋了。
為了避免誤導,若有人想要做類似的事情,這裡本質上可以歸結為:

#if SOME_CONDITION_ENABLING_OUR_FEATURE
#include "AutoLight.cginc"
#undef SHADOW_COORDS
#undef TRANSFER_SHADOW
#undef SHADOW_ATTENUATION
#define SHADOW_COORDS(i) SOME_OTHER_COORD(i)
#define TRANSFER_SHADOW SOME_OTHER_TRANSFER
#define SHADOW_ATTENUATION(i) SOME_OTHER_ATTEN(i)
#endif


這裡的條件判斷決定了是否啓用這種獨特的陰影,以及我們目前是否正在呈現一個定向光。

而第二個條件判斷則決定了能否與其他類型的投影光源和平共處。

成果!



在經歷了所有艱苦的工作之後,我們究竟獲得怎樣的結果呢?下面就是同一個場景下打開和關閉這種「獨特陰影」技術時,所呈現出來的場面。

老派技術最終得分獲勝!

總結



有一點需要注意的是,如同像絕大多數其他的渲染功能一樣,增加陰影貼圖到場景是有代價的。

陰影貼圖會佔用更多的顯卡記憶體,而且渲染會產生額外的draw call,同時這種方式也增加了著色器對於頻寬使用和運算性能的需求。

在The Blacksmith中,我們對系統進行了設定,使得我們能夠根據角色和相機的距離來決定這種獨特的陰影技術是否被啓用。因此,我們只在那些人物佔據畫面大部分的鏡頭中才會啟用這功能付出額外的渲染成本。

對於一個普通的遊戲而言,在玩家正常遊戲的過程中可能永遠不會出現角色如此靠近相機的情況,我想可能只有在特定的過場動畫時,才需要啓用這種技術。

為了更好地展示這一功能,我們已經把它抽離到了一個小的專案,你可以從Asset Store下載它。

這專案包含了一個基本場景,用來模擬一些在大場景裡距離相機非常近的角色細節。

即使第一級層陰影級聯覆蓋僅1%的陰影距離,在左側運用了這「特殊陰影技術」和右側用了一般級聯陰影技術的維京挑戰者之間,依然存在著顯著的差異。


參考資料:
[註1] 英文

2015年9月7日 星期一

幾個未來Unity即將放棄的圖形功能

作者:ARAS PRANCKEVIČIUS
原文:http://blogs.unity3d.com/2015/08/27/plans-for-graphics-features-deprecation/


很多時候我們為了讓Unity更好,我們發現有些太舊的設備或技術限制總是綁手綁腳。好比說為了確保不同Unity版本之間的兼容性,但是,有時候移除掉一些老舊的功能可以帶來的好處更多,希望這些移除可以帶來最少的影響。

以下就是我們計劃未來要從Unity移除的部分圖形功能,但是請注意,這只是計劃但尚未執行,所以我們希望能聽到您的建議,幫助我們做的更好!

不再支持預編譯(precompiled)著色器資源


「預編譯」著色器在沒有源始碼的時候是很有效的,在這裡替代了可讀的HLSL代碼。這些著色器包含了已裝配的編譯著色器或者微程式碼、或是在多平台上翻譯著色器
程式碼。

預編譯著色器有一個問題,有時候它會在特定平台上無法執行。也就是說如果你的著色器是預編譯給DX9、OpenGL或者OpenGL ES 2.0上用的,那麼,這個著色器就有可能無法在Consoles、Metal、DX11等平台上無法工作。這是其一我們要移除這一功能的理由。

另外一個原因是我們希望可以保持著色器在硬碟中載入和執行的記憶體序列化格式更有效率。目前我們的著色器格式,老實說,是一個相當低效的文字格式,需要很長的載入時間和佔據較多記憶體。在我們目前的測試中,我們發現使用更有效的著色器格式可以大幅減少載入時間和記憶體耗用(由於著色器的不同,可以帶來幾Mb到幾十Mb的減少)。因此,我們認為移除舊版本Unity的預編譯著色器是不錯的方式。

移除後的優點:
. 著色器在遊戲包中將佔據較少的空間(可能是數倍的空間的減少)
. 著色器載入會變快,特別是不同步載入造成的「主線程卡頓」時間會減少。
. 在執行時,著色器會佔據更少的記憶體。
. 在DX11上的已編輯的程式碼就會顯示在著色器屬性選單上,以替代那些龐大複雜的程式碼。

移除後的缺點:
. 預編譯的著色器程式碼(著色器的屬性配置」Show compiled code」)未來若直接使用將不會有效果。

影響範圍:需要使用預編編譯著色器的開發者。

預計移除時間:Unity 5.3(2015年12月)

不再支援DirectX 9著色器的2.0 GPUs模組


DX9 SM2.0 GPUs 確實已經非常老了,我們將不再支援它。在您的Unity遊戲中以下的GPU我們將不再支
:2004年前的NVIDIA(pre-GeForce 6000),2005年前的AMD(pre-Radeon X1000)和2006年前的Intel(pre-GMA X3000/965),總之,超多10年以上的GPU我們都不再支了。

請注意我們不會放棄支
DirectX 9,因為它在Windows XP上是唯一的選擇。因此,對於DirectX 9的渲染支將會繼續(基於Shader Model 3.0 或更新的 GPUs)。

移除後的優點:

  • 減少編寫著色器的麻煩。目前,有很多新的著色器已經被預設為最低規格並放入Unity(著色器model 2.0),如果你想要更多高階的功能(比如:vertex textures, dynamic branching, derivatives, explicit LOD sampling 等等),你需要增加比如"#pragma target 3.0",若我們放棄了支SM2.0,最低的規則會相應地提高,這點毋需操心。
  • 對於Unity自己來說減去很多的麻煩。您無法想象,我們花費了大量的時間精力在試圖將Unity 5基於著色器的物理呈現在DX9 SM2.0。現在,我們可以將精力放在更有價值的地方了。

移除後的缺點:
  • Unity的遊戲將不能在Intel GMA 950 / 82945 GPU上運行了。

影響範圍:Windows單機玩家的開發者

預計移除時間:Unity 5.4版本(預計2016年3月)

不再支持Windows Store Apps DX11 feature level 9.1 GPUs

幾乎所有的Windows Store Apps設備都至少是DX11 兼容 level 9.3(包括全部Windows Phone設備),但是或多或少有一些必須支持9.1的級別,如果我們仍然支,那麼就會降低整體的規範。

移除後的優點:

  • 所有的WSA/WP8著色器將會被編輯到9.3級別的水平,以前無法實現的一些功能就可以實現了(比如:multiple render targets, derivative instructions in pixel shaders等等)。
  • 我們可以去掉一些只支援9.1之前版本的程式碼。

移除後的缺點:
  • 您的Windows Store Apps將不再支持9.1的設備(就意味著「Surface RT tablet「不再被支持)。請注意Windows Phone不會被影響,所有的手機現在至少都支持9.3了。

影響族群:Windows Store Apps的開發者
預計移除時間:Unity 5.4版本(預計2016年3月)

不再支持在Android OpenGL ES 2.0上的native shadow maps


陰影貼圖可以透過GPU支
(從陰影貼圖直接取樣可以獲得陰影數值,也可以使用PCF過濾器),或者用「手動」(從陰影貼圖取樣深度,可從外觀深度比較去決定是否在陰影內)

以上的第一種方式是推薦的,特別是現在很多的GPU已經可免費提供 2×2PCF過濾器了。在絕大部分的平台上,我們可以提前知曉被支
的陰影模式,但是Android OpenGL ES 2.0 很奇怪,一些設備支援透過 EXT_shadow_samplers延伸「陰影貼圖」,但是有些設備不支。這代表在Android ES 2.0上,我們不得不使用兩種不同的著色器去解決這個問題。

數據顯示,安卓設備上很少支
EXT_shadow_samplers(大約只有1-2%的設備)。所以我們認為不再支這功能是很值得的。我們把Android ES 2.0 作為一個「手動比較深度陰影」的平台。

移除後的優點:

  • 減少在Android ES 2.0上變異型著色器的編譯、運行時間。

移除後的缺點:
  • 將會有大約1%的Android ES 2.0設備不再支援PCF取樣的陰影,在著色器裡做深度的材質比較會更慢。值得注意的是所有可以使用OpenGL ES 3.0 的設備是被支援的(他們都是被建立了PCF)。

影響範圍:在OpenGL ES 2.0上的Android開發者

預計移除時間:Unity 5.4版本(預計2016年3月)

2015年9月1日 星期二

淺談Unity的斷言庫(Assertion Library)

作者:TOMEK PASZEK
原文:http://blogs.unity3d.com/2015/08/25/the-unity-assertion-library/

Unity 5.1為開發者帶來了全新的斷言庫。本篇文章中,我們將為您闡述何為斷言庫,以及您如何用它以提升遊戲中執行錯誤的診斷效率。

斷言是什麼?為何要用它?


一個斷言就是一種檢查狀態的方法,如果這個狀態為true,那麼執行就會繼續下去。若有任何突發異常或期望狀態沒有出現,一條你自訂的訊息就會被印出在呼叫堆疊。讓我們看下這個範例:
//Make sure the player GameObject is active
Assert.IsTrue(playerGameObject.isActive, “Player GameObject is not active”);

如果範例中的GameObject沒有啟用,那麼一條錯誤提醒就會顯示在呼叫堆疊里並印出訊息:」Player GameObject is not active」


如很多開發者所知,斷言源於單元測試。在單元測試中採用Arrange-Act-Assert來比對期望值和結果是測試的最後一個環節。斷言不僅僅是測試,你還可以利用它檢測在執行過程中特定變數被修改時獲得警示。但是,並不是所有的斷言只能被用在執行(Runtime)代碼中。

單元測試框架中的斷言庫適用嗎?


極有可能您是第一次在單元測試框架中遇到斷言。作為一個例子:讓我們試試NUnit,NUnit是一個用於斷言測試有著非常豐富並已用於大量實戰的庫。那麼,問題來了,為什麼你僅僅想要利用這個庫去測試你的產品代碼呢?

NUnit斷言允許你去測試許多東西。從最簡單的對比狀態測試到複雜的蒐集測試傳遞異常。但是問題是執行花費時間很長。低階的斷言需要為了不花費額外的耗費盡可能的精簡。斷言庫就是用來幫助您減少額外的耗費和不必要的執行。

一個斷言庫最好是能從發佈包外呼叫。因為斷言在產品發佈週期對開發者會很有用處,但是結束之後斷言庫對於用戶毫無意義。當你在打包最終版本時你會想要去除所有的斷言呼叫。你可能會採取注釋所有的代碼,但是不是一個聰明的辦法。還好.NET有一個條件編譯機制。斷言庫只會在符合條件玩家使用的開發包里呼叫斷言。但是,仍有可能包含被編譯選項(英文)採用的斷言。

最後但也是很重要的,通常單元測試的斷言庫是建立在異常的基礎上的。一個異常出現在一次執行的失敗時。顯然,這針對執行階段時的代碼並不理想。斷言庫已經集成到Unity Log系統,錯誤發生時,一條訊息就會被記錄。斷言庫通用於所有的Unity支持平台。這就意味著即使不支持異常反饋的AOT平台上也能執行斷言。

那麼,這個斷言庫里都包含了什麼內容?


這個庫提供了多種不同類型的比對方法和一個對等比較器。以下舉列一些斷言方法:

. AreEqual -一般比較器,用來最基礎的對等比較。默認的對等比較器。
. AreApproximatelyEqual - 近似比較器,它可以默許一些比較的錯誤。常用來比較浮點數。
. IsTrue - 快速簡易的布林檢查。

所有的方法都收錄在斷言文件中:

最酷的是這個斷言庫的設計跳出固定思維,它與Unity測試工具是兼容的。無需任何額外的動作,任何被保護的呼叫代碼集成測試,斷言都是會失敗的。

斷言庫的延伸性


當你想要獲得一個新功能,最好的方法自然是擴展它。斷言庫里的AreEqual方法允許你傳遞一個你自己的特定類型比較器,這個比較器必須在 IEqualityComparer的界面上執行。

該庫提供用於比較浮點數的 FloatComparer,它可以允許你去做一些相對誤差檢查的比較。這個比較器收錄在AreApproximatellyEqual方法。

總結


使用斷言庫來找出代碼里的Bug以及非預期的狀態是很有效的。你現在就可以開始使用,我們也會持續提升斷言庫的內容,也我們歡迎您多多提出任何建議!

著作人