2014年7月29日 星期二

2014 Unity遊戲及應用大賽頒獎典禮

2014 Unity 璀璨星空夜 引爆今夏遊戲狂潮
優美締-Unity 官方平台

7月 29日 ,Unity 璀璨星空夜(遊戲及應用大賽頒獎典禮)在一片炫彩奪目中揭開帷幕。本次頒獎盛典共決勝出16個年度獎項,代表了大中華區Unity 作品的最高水準。本次頒獎盛典作為ChinJoy的第一場火熱開場秀,晚會現場人頭攢動,處處爆滿,引爆八月遊戲盛會的熱潮!







2014 Unity璀璨星空夜是由Unity主辦,和上海普陀區、中國移動和遊戲、ChinaJoy聯合主辦,並由360、小米、CIBN、友盟、亞馬遜、雲測、Ucloud、游久時代協辦的2014 Unity 遊戲及應用創意大賽頒獎盛典,開創了國內對原創作品展示與支持的新的平台。



Unity 本地化重要里程碑
在璀璨星空夜現場,Unity 大中華區總裁符國新為嘉賓介紹了Unity 在大中華區的發展和佈局。符總表示:2014年是Unity 本地化過程中最值得紀念的一年。Unity 本身構建了九大業務模塊。其中又以Unity Games的業務走得最快、最遠。本次Unity 遊戲及應用大賽就是由Unity Games主辦的,希望通過遊戲大賽提供一個展示和交流的平台給到遊戲開發者。


眾所周知,Unity 作為跨平台引擎的佼佼者,在虛擬現實和增強現實的領域也有很強的應用性。國內有一家專注於虛擬現實技術十年的公司,在中國深圳開發出了一款屬於中國人自己的頭戴式虛擬眼鏡-3 Glasses!深圳經偉度科技的總經理王潔女士介紹了這款更適合中國用戶和開發者的頭戴式虛擬眼鏡。這是3 Glasses的全球首次發佈!




除了虛擬眼鏡,Unity 也看好中國的智慧電視市場的發展,在國廣東方的牽頭下現場宣佈成立了名為“智慧家庭娛樂聯盟”(簡稱TEA)。包括Unity、華為科技、優酷土豆、安謀咨詢、樂視TV、康佳、三零凱天、三貝德、中廣視訊、英偉達、晶晨半導體、瑞芯微電子等十幾家公司宣佈第一批加盟。



同時,Unity 還宣佈了Unity 遊戲產業投資基金即將啓動,本地化過程中重要一環Unity 天地港也開啓首批十幾家企業入駐。Unity 天地港的入駐意味著Unity 真正在大中華區落戶,也象徵著Unity 品牌真正融入到中國遊戲及應用開發領域的發展歷程中。來自十幾家平台的大佬在現場一同見證了這個值得紀念的時刻。



逐鹿星夜,血戰長空!
本次頒獎盛典有幸邀請到的頒獎嘉賓,有來自百度、中國聯通、墨麟集團、巨人網絡、EA、小米、UC、友盟、藍港互動、360等海內外知名行業大佬,諸多閃耀行業明星齊聚一堂,共襄盛舉,並且讓諸多尚未商業化的開發團隊快速得到幸運和機遇的青睞!有些沒有能來現場的行業大佬們也通過視頻送來了祝福和祝願!





本次大賽獲得原創組金立方大獎的是來自台灣的獨立遊戲開發廠商雷亞(Rayark)的《Implosion》,還有《zombeer》和來自西班牙遊戲工作室Anima Project Studio所製作的遊戲的《GATE OF MEMORIES》分別獲得銀獎和銅獎。



2014年Unity 遊戲及應用大賽商業組金立方大獎的獲得者是來自於成都動魚數碼的《血戰長空》,靈游坊的《影之刃》以及來自椰島工作室的《決戰喵星人》分別獲得商業組金立方的銀獎和銅獎。



除卻最高獎項金立方大獎之外,更有其他大獎逐一揭曉全部的獲獎名單如下:








華麗的舞台特效、炫麗的燈光秀、激情的DJ打碟,火熱的表演、激動人心的抽獎環節等一一精彩上演。在魑魅迷離的夜色燈光里,將螢光填滿每一處角落,這些帶著激情在走動著的身影,猶如矍鑠不停的音符,時而是獲得殊榮的喜悅,時而是遇到良機的雀躍,時而是夢想火花的碰撞。通過壓力的釋放,心靈的碰撞,獲得靈魂的享受,此次頒獎盛典真正開啓別開生面的狂歡模式!




2014年7月20日 星期日

【ChinaJoy】Unity 參展CJ 最全跑會指南

【ChinaJoy】Unity 參展CJ 最全跑會指南
優美締-Unity 官方平臺



2014年的ChinaJoy 跟隨著上海逐步攀升的氣溫悄悄漸行漸近,Unity 的忠實粉絲們一定很想知道2014年的CJ在哪裡能夠找到Unity 活躍的身影。Unity 官方特地準備了Unity 參展CJ最全跑會指南,Unity團隊就在那裡等著你們!




Unity 展臺各部門參與內容:
Unity Technologies技術支援:CJ現場一對一診斷預約、技術課程、技術支援服務現場諮詢。
Unity Education 教育部門:專業講師現場授課、教育培訓相關商務接待等。
Unity Games發行服務:使用Unity 製作的各平臺遊戲展示、遊戲商務洽談等。
Unity Solutions行業解決方案:行業解決方案現場商務洽談。
Everyplay遊戲視頻錄製與推廣
Unity天地港和Unity 基金:扶持、孵化項目洽談等


預約方式:
郵件預約:may@unityedu.cn
郵件主題:Unity CJ 展位 B TO B + Unity業務名稱
郵件內容:公司名稱+連絡人+聯繫電話+約談業務名稱

Unity官方微信 - UnityGreaterChina
Unity Taiwan FB粉絲頁 - https://www.facebook.com/UnityTechTaiwan





2014年7月15日 星期二

Unity 5值得期待的高性能物理元件


Unity 5中值得期待的高性能物理元件
作者 - Unity - Anthony

Unity採用PhysX2.8.3物理引擎已經有一段很長的時間了,當然我們不是單單使用PhysX,多年來由Unity的工程師開發了各種補丁不斷強化它,真心感謝這麼好的引擎帶給我們的開發體驗。在今年的GDC我們也宣布Unity5會將PhysX升級到3.3,現在就讓我們進一步來瞭解。

PhysX SDK 3是架構在原本PhysX SDK 2.x 的基礎上重新設計。基本上,PhysX的開發團隊將2.x好的創意及功能保留下來,並重新編寫了SDK。這代表SDK的程式構架是全新的,介面也是全新的,同時絕大多數功能也是全新的。

現在我們來了解一下Unity 5.0的物理元件。

首先我們從簡單的功能開始介紹。我們將PhysX的適應力設定(Adaptive Force)做成可切換的,在預設狀態是關閉的。Adaptive Force是PhysX所使用的一項特殊技術,主要用於修正PhysX在類比動態狀況時不可避免的數值偏差。

移動靜態碰撞體(Moving Static Colliders)
靜態碰撞體的移動操作所帶來開銷將會大大降低。靜態碰撞體只是附有碰撞體元件的遊戲物件(GameObject),並沒有剛體(Rigidbody)元件。在以往因為SDK假設靜態碰撞體均是靜止的,所以移動一個靜態碰撞體會觸發重建耗效能的AABB 樹狀結構,進而讓整體效率大打折扣。

但在Unity 5中,我們使用相同的資料結構來同時處理動態與靜態碰撞體的移動。可惜的是,換來的代價是會失去靜態碰撞體耗用記憶體比動態碰撞體少的優點,但是會有這項改變是因為靜態碰撞體的移動消耗是目前最影響Unity專案性能的三大主要原因之一。因此我們必須進行修改和優化。


碰撞檢測(Collision detection)
連續式的碰撞檢測效率在新版本有了大幅度的提升。這個功能主要用於防止移動速度過快的物體在碰撞檢測之前就穿過物體的情況。比如,一枚高速飛行的子彈穿過一張紙,或者在撞球檯中,速度飛快的撞球和其他球或桌邊發生碰撞等等。

在Unity 5.0當中,SDK會產生用於處理快速運動的資料,你只需在編輯器中直接打開連續碰撞檢查(continuous collision detection)即可。PhysX3採用的演算法還可以根據物體的速度來判斷是否真的需要使用消耗很大的CCD模擬,或是進行預設的連續式碰撞就可以做得很好。這功能在你開啟CCD時就會被自動啟動。





Broadphase上的剛體
PhysX3在broadphase上支持更多剛體。事實上,在PC平台上的遊戲每Frame可以支援幾十萬個剛體。在以前PhysX最多只支持6萬4千個剛體,這並不是一個能夠輕易提高的數量,想要提高這個常量必須得在SDK上節省更多空間才行。但對於一些像PS3這樣的遊戲機而言,他們仍然必須有這樣的限制。同時物理材質也有限制:在發表這篇文章之際,你仍然無法在任何平臺上使用超過64k數量的材質。

縮放網格碰撞體(Mesh Colliders)耗用低
在Unity 5.0之中,我們降低了網格碰撞體的縮放消耗。在以往當你縮放一個網格碰撞體時,你得重新產生一個縮放的網格。而這過程會佔用時間和記憶體。而PhysX3支援直接在原有網格上進行縮放,這種縮放基本上是不耗效能的的。

接下來,我們來看看與Unity4.x版本完全不同全新的兩個系統:布料與車輛模組。

布料元件(Cloth component)
我們先來看布料元件。在Unity4時,布料模擬是透過InteractiveCloth與SkinnedCloth兩個元件來執行的。InteractiveCloth元件擁有像布料一樣的網格呈現,可對其施力等特點讓它成為能與其他物理物件互動的“物理布料”。但是InteractiveCloth元件計算非常耗效能,所以Unity 4 針對角色衣物的布料模擬又設計了SkinnedCloth元件。

因為SkinnedCloth並不佔用模擬運算的管道,所以效能要優於InteractiveCloth元件。但布料元件最大的問題是兩個元件的模擬效果都不穩定,且運算效能耗用高。所以我們在整合PhysX3的同時決定不再支援InteractiveCloth元件,取而代之的是一個整體以設計角色衣物為主的布料元件,Cloth。

在Unity 5.0裡,布料不再與場景裡的碰撞體進行互動,也不再產生反作用力。取而代之的是一個更快、多緒、更穩定的角色布料模擬系統。當你使用全新的布料元件時,它不再對任何物體進行反應。

布料與外部世界不再相互作用,除非你手動將碰撞體加到布料元件上。要注意的是,就算你手動加入碰撞體,布料模擬過程仍然是單向的,布料會對其他碰撞體做出反應,但並不會施加反作用力。且你只能對布料元件加入三種碰撞體,球形(sphere)、膠囊(capsule),和由兩個球體組成的圓錐形碰撞體。這些改變都是為了提升執行性能及表現。

Unity 5.0中的布料模擬介面與目前的SkinnedCloth介面類似,但我們正積極的調整讓它能在5.x的時候整個操作像是整合到Mecanim系統裡。

全新的布料元件可以通過CUDA從內部支援GPU。但因為一些因素我們決定在之後的5.x版才加入這個功能。這是因為CUDA只能在Windows系統下的NVIDIA硬體上執行,但我們的開發者有很大一部分都在使用Mac和Linux。再者我們希望能先集中火力解決核心問題,之後再加入這種酷炫的元件。

全新的VehicleSDK
現在,我們來簡單介紹一下新版本的車輛模擬功能。PhysX3引用了全新的Vehicle SDK來取代之前一直在使用的WheelCollider元件。這個元件可以實現更具真實感的懸架距離和車胎摩擦力效果。另外還解決了一些存在已久的問題。

當然如果開發者們希望找到已經過精細調整、效果更真實或更高階的插件,那我們建議可以直接去Asset Store上找,比如Edy’s Vehicle Package。

來看看我們從網上下載的免費模型並花點時間做出的成果


底下這是一個Edy’s Vehicle Package中專門針對SUV的效果。

Edy 目前正在開發包含更多酷炫效果的資源包。儘管我們想向大家分享所有有關車輛模擬的技術細節,但今天還是先讓我們來看一下全新的WheelCollider示意圖,展示汽車懸架變數是如何工作的。



在上圖中輪圈和車輪直徑被標記為綠色,而懸掛的軌跡被標記橙色,施力點範圍也用綠色球體標出。在懸掛的軌跡部分上,標出了最大壓縮位置、最大下降位置,與目標位置。

正如你看到的,輪胎只能在最大壓縮位置與最大下降位置之間移動。而目標位置(也稱平衡位置)位於通過彈簧彈力得到平衡的彈簧重量上受彈力保持平衡的位置,比如當車輛靜止在水平面上時的輪胎位置。雖然校準看起來很難,但實際上最大壓縮位置就是你輪胎一開始在網格中所處的位置。

接下來,你可以指定懸掛距離和目標位置作為懸掛距離的一小部分。它們只是兩個浮點數,簡單吧!跟你說,新的車輪圖示會從模擬資料更新旋轉和位置數據,你在也不用為了定位寫程式。因為這一切都已經內建於引擎中。

效能(Performance)
我們將會支援多核心透過多工的方式來運算PhysX3,這樣我們可以在不同的核心執行不同的任務。SDK會用多執行緒來執行,並處理好所有的關係和工作分配。

到目前為止我們合理預期,有了更好的程式庫和多執行緒之後,未來的引擎效能可以倍增。在某些案例中,改進效果令人驚訝,性能提升甚至達到了十倍以上。

對效能感興趣的開發人員,可以訪問Pierre Terdiman的部落格。他是PhysX SDK的主要研發人員。

相容性(Compatibility)
新的功能外觀與使用體驗都會延續了Unity一貫的風格,但在特定情況下,或許有些舊的使用方法將不再被Unity 5所支援,即Unity 5.0的物理元件並不一定100%與Unity 4.x相容。在你將舊專案更新到Unity 5時,可能要重新檢視所有跟物理相關的程式碼。

除了今天說的這些以外,Unity 5的物理元件還有很多功能。可以到Unity 官方論壇留言。如果你會參加2014年的Unite開發者大會,我在大會會有關於Unity 5.0物理元件深度訪談的發言,記得過來跟我們打聲招呼並和我們聊兩句吧!

更多關於Unity 5的資料(英文)



2014年7月8日 星期二

Metal,一款相容 iOS 8 的全新圖形 API

Metal,一款相容 iOS 8 的全新圖形 API
作者: Unity - Aras Pranckevičius


iOS8上的圖形處理功能帶來了令人激動的時刻!
        WWDC(全球開發者大會)上,蘋果發佈了Metal技術,它是一款具有低消耗、高效率,並針對A7芯片進行了特殊設計的全新圖形API。採用Metal技術,遊戲開發者能充分利用iOS硬體的優點,開發的遊戲將更真實、更複雜、互動能力也更強。
Unity將很快支持Metal,在這之前我想帶你深入瞭解這新技術以及Metal技術為何如此重要。

初識Metal

Metal技術之所以能實現低消耗,更多的效能監控和更好的可編程性,是因為Metal含有如下的關鍵思想:

.盡可能地建立和驗證前期狀態
著色器可以在離線狀態下編譯和部分優化。所有與渲染(著色)通道相關的操作都可以在渲染之前就先被創建和驗證,如:著色器,頂點佈局,混合模型,渲染目標格式等。這代表在每一個drawcall中將需要更少的狀態監測,而節省大量的CPU運算

.更靈活的運用多線程技術
可以在任何線程中創建資源,並提供了好幾種方法在多線程中並行地準備drawcall的執行。

.所有的iOS設備上,CPUGPU是共享記憶體的
這就不需要將數據透過CPU從記憶體中拷貝到顯卡記憶體(這是一個很耗時的運作),只需要修改指標的指向,因為GPUCPU的內存是共享的。

.讓用戶(引擎)處理同步
OpenGL ES不得不通過大量的循環操作,來處理各式各樣的場景(事實上對於很多場景是沒有必要的)。在Metal技術中,用戶自己負責GPUCPU中數據同步,這樣引擎就可以省去大量沒有必要的操作。

.iOS設備上的GPU都是基於Tile-BasedDeferred Rendering架構
這一點明確表現在MetalAPI中,尤其是在渲染目標上。所以與緩衝區相關的操作如tile的載入與儲存,反鋸齒等都已明確地完成了,即API不在需要多餘操作。

以上幾點都意味著CPU開銷的大幅降低及性能可預見性的大幅提高
我們會為圖形和著色器引進新的基於C/C++之上的語言。這代表iOS可以進行著色器操作,原子操作,以及任意的緩衝區寫入操作等。

在這全新的設計中,Metal API非常精簡。它還有一個非常有用的”除錯,可以做很多額外的工作,並通知你程式中的所有錯誤。

關於Draw Call
如果你在製作遊戲,尤其是手機遊戲,你對draw call問題也許會很在意。每一個被繪制的物體都會有CPU開銷,現在的手機還不能繪制過多物體(大於上百個)。在遊戲中的運行邏輯,物理計算,AI運算,動畫等等都會消耗CPU。所以Unity自身採取了一些辦法來最小化draw call數量,比如靜態&動態批次處理,遮擋剔除,LOD等等。

這裡便會有一個疑問:為甚麼渲染物體時會有CPU開銷?渲染物體畢竟是GPU的工作

這其中的部分開銷來自引擎CPU需要不斷的確定可見物體,指出哪一個著色器的pass需要被渲染,哪一個光源照亮哪一個物體,指定哪一個材質參數等。其中有一些開銷是緩存操作的,有一些開銷是多線程操作,一般來說都是與發佈平台無關的代碼。每一次Unity的發佈,我們都在嘗試優化這一部分,通常情況下Metal不會對這一部分有任何影響。

CPU開銷另一方面在圖形API和驅動。不同的遊戲這一部分開銷有大有小。Metal會想辦法解決這樣的問題,來減少OpenGL ES中大量多餘的操作。預先渲染狀態的創建&驗證,渲染目標載入&儲存的顯式操作,API不同步等這三個操作都有助於降低CPU的開銷。

根據我們目前的測試,API+driver的開銷降低到只佔CPU時間的百分之幾甚至更少。和之前的15%-40%比起來差別很大。這代表大量的CPU資源可以用在我們自己的程式上面。
我們正在嘗試讓Metal進行多線程繪制,當然對於我們而言,這也是一個非常有意思的優化機會。

Compute Shader(新的著色器)
有了MetalGPU可以在典型的Vertex+Fragment Shader外面進行計算(被稱為”Compute Shader”).大致上講,能在GPU中的許多小型處理器上進行各種類型的並行計算Compute Shader有一個局部存儲器的概念——CPU上一塊執行效率非常高的記憶體,在並行操作時,用來共享數據。這塊特殊的內存使GPU可以更加容易顯示一些舊的VertexFragment Shader不易於顯示的效果。
Compute Shader可用來做很多有趣的事情:優化後處理效果,粒子系統,陰影和光線剔除等
雖然目前在Unity中還沒有大量地使用Compute Shader,但我們正在嘗試將它用在越來越多的地方,值得期待!

常見問題
甚麼時候能使用到Metal
我們已經迫不及待想要發佈它,但是目前還無法確定具體的日期。我們已經做了大量的工作,但還有很多方面需要完善。當前重要的是完全整合Metal,以此大幅度提升CPU方面的性能。我們希望在之後的Unity5.0版本對Compute Shader的支援(在我們內部Compute Shader已經某種程度上支援了)

對平台有甚麼樣的要求?
iOS8和含有A7芯片的設備(iPhone 5s, iPadAir, Retina iPad Mini).

我該如何利用好Metal技術中的CPU低消耗的優勢?
簡單說不需要做任何事情。一旦Unity中支持Metal技術,它的使用將會非常地自動化。所有你現有的項目,著色器和圖形特效都應該可以一如既往地工作。

因為Metal技術有不同的程序語言,那著色器會不一樣嗎?
我們會處理這個問題的,現在你用Cg/HLSHshaderUnity自動將其轉化為GLSL。對於Metal,我們也會進行相類似的做法。

再問一次,在低CPU開銷下,我能做甚麼?

更好的物理效果,AI和更複雜的遊戲邏輯。在螢幕上顯示更多的內容,或者節省更多電量。這一切都取決於你!

2014年7月3日 星期四

Unity 5.0 中酷炫的新動畫功能

Unity 5.0 中酷炫的新動畫功能

作者:Unity - Pierre Paul Giroux



Unity 的動畫團隊一直很努力的準備讓 Unity 5.0 發表時具有令人印象深刻的功能。
下面為你介紹有關新動畫功能的簡要概述,希望可以對Unity 開發者們有所幫助!


狀態機行為(State Machine Behaviours)
在 Unity 5 中,你將能夠將StateMachineBehaviour 腳本加到行為狀態中,並在播放時收到以下回應:

• OnStateEnter
• OnStateUpdate
• OnStateExit
• OnStateMove
• OnStateIK

你可根據需求在行為狀態中加入多個 StateMachineBehaviour。例如要在狀態上加入 IK,或執行自訂邏輯,只需要將 StateMachineBehaviour 腳本拖到它上面。

基本上,遊戲中任何需要某種StateMachine 邏輯的物件(無論是否有動畫)均可使用這種方式。

此功能的一大好處是不會有大量類似下面的代碼:

if(animator.GetCurrentAnimatorStateInfo(0).isName("Idle") )
    DoStuff()
(我打賭你的程式碼裡面應該有許多這樣的碼)現在只需用StateMachineBehaviour 即可!


狀態機轉換(State Machine Transitions)

狀態機變得越來越複雜,因此我們導入了“狀態機轉換”這個概念,能在 StateMachine邏輯上提供更高層次抽象的表示。

在 Unity 5 中,我們已經在StateMachine 中添加了“Entry”和“Exit”節點。這兩種節點都會在狀態機轉換中用到。

Entry:當轉換到 StateMachine 時,動畫系統會從進入節點分析條件並轉到目的地。

Exit: 轉到退出節點時,動畫系統會檢查正在進行的 StateMachine 轉換,並轉到適合目的地。

注意,您可混合轉換:State->State、State->StateMachine、StateMachine->StateMachine……


另外,我們還對動畫系統的 UI 進行了修改,因此你可以針對參數和層排序。

資源創建 API(Asset Creation API)

在 Unity 5 中,你可以用程式來建立像是(animation assets; StateMachines, States, Controllers, Layers, Blentrees等等的資源)。

有兩種API:高階 API由 Unity 來管理資源,低階級API由開發者手動管理資源並可連結外部參照。

兩種API都會有文件,後面我會有個API的小例子。


直接混合樹(Direct Blend Trees)

我們新增了一種新型BlendTree,可將參數直接傳到 BlendTree 子物件上。

如果你有使用BlendShape 動畫或附加動畫,這真的非常方便。

根動作創作(Root Motion Authoring)常規模式

Unity 5 也允許你為動畫製作動畫效果並將轉化成 root motion(即 Delta Animation)。只需要建立一個動畫,在最上層的物件做平移/旋轉,然後在 AnimationClip 按一下“Generate Root Motion Curve”(產生根動作曲線)即可!

更多讓讓動畫製作更輕鬆的功能:

• 改進動畫預覽,鏡頭現在能像場景裡的鏡頭一樣平移和縮放。

• 即時存取像是名稱或是預設值等參數

• 小圖示可以顯示根位置、ik 位置等

• 改進的重新定位系統

• 運行效能優化

• 大量的臭蟲修復

我們希望開發者們也分享我們你的心得
Unity 動畫團隊敬上


以下是簡單的API範例程式
// Creates the controller
var controller = UnityEditor.Animations.AnimatorController.CreateAnimatorControllerAtPath ("Assets/Mecanim/StateMachineTransitions.controller");

// Add parameters
controller.AddParameter(“TransitionNow”, UnityEditor.Animations.AnimatorControllerParameterType.Trigger);
controller.AddParameter(“Reset”, UnityEditor.Animations.AnimatorControllerParameterType.Trigger);
controller.AddParameter(“GotoB1″, UnityEditor.Animations.AnimatorControllerParameterType.Trigger);
controller.AddParameter(“GotoC”, UnityEditor.Animations.AnimatorControllerParameterType.Trigger);

// Add StateMachines
var rootStateMachine = controller.layers[0].stateMachine;
var stateMachineA = rootStateMachine.AddStateMachine(“smA”);
var stateMachineB = rootStateMachine.AddStateMachine(“smB”);
var stateMachineC = stateMachineB.AddStateMachine(“smC”);

// Add States
var stateA1 = stateMachineA.AddState(“stateA1″);
var stateB1 = stateMachineB.AddState(“stateB1″);
var stateB2 = stateMachineB.AddState(“stateB2″);
stateMachineC.AddState(“stateC1″);
var stateC2 = stateMachineC.AddState(“stateC2″); // don’t add an entry transition, should entry to state by default

// Add Transitions
var exitTransition = stateA1.AddExitTransition();
exitTransition.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, “TransitionNow”);
exitTransition.duration = 0;

var resetTransition = stateMachineA.AddAnyStateTransition(stateA1);
resetTransition.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, “Reset”);
resetTransition.duration = 0;

var transitionB1 = stateMachineB.AddEntryTransition(stateB1);
transitionB1.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, “GotoB1″);
stateMachineB.AddEntryTransition(stateB2);
stateMachineC.defaultState = stateC2;
var exitTransitionC2 = stateC2.AddExitTransition();
exitTransitionC2.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, “TransitionNow”);
exitTransitionC2.duration = 0;

var stateMachineTransition = rootStateMachine.AddStateMachineTransition(stateMachineA, stateMachineC);
stateMachineTransition.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, “GotoC”);
rootStateMachine.AddStateMachineTransition(stateMachineA, stateMachineB);

2014年7月1日 星期二

Mecanim人形動畫淺談


【技術分享】Mecanim人形動畫淺談
原文來自於Unity - robertl




我們今天來紹Mecanim針對人形動畫的一些技術,包括運作方式、優勢和局限性,來探討如何在最佳化必須做的一些決策以及一些使用經驗。

人形骨架(Humanoid Rig)和肌肉空間(Muscle Space)
Mecanim所採用的人形骨架和肌肉空間是一種用來模擬人體骨骼的層次和變形,用來表示人體動畫的一種解決方案。




人形骨架用來描述人體的骨架節點,它可辨識一組人形骨骼並為每個骨骼創建肌肉數據參考。’讓肌肉在旋轉時具有範圍局限和坐標軸標記。




肌肉值[-1,1]用來規範骨頭的移動範圍 [min,max] 。請注意:肌肉值可能超出範圍低於或高於 [-1,1],此範圍非硬性規定,只是一個正常的移動範圍。在特別需求下可以增大或縮小移動範圍。

肌肉空間是人形骨架上所有肌肉值的集合。這是一個標準的人形姿勢。如果骨骼座標為0(min=max),代表骨骼上沒有肌肉。
例如,肘部的 Y 軸沒有肌肉,因為它僅能拉伸(Z軸)和轉動(X軸)。肌肉空間由最多47個肌肉值組成,這已經完全可以描述人形身體姿勢了。


肌肉空間的優點是它可直接應用於任何人形骨架,並始終建立合理的姿勢。另一個優點是肌肉空間很好做動畫補間。與標準骨骼姿勢相比,肌肉空間可以在State Machines或在Blend Tree混合的過程中,在動畫之間自然地進行補間動畫。

運算方面優勢是,因為肌肉空間可視為向量,因此可進行線性的動畫補間,這與四元數(Quaternions)或歐拉角(Euler angles)不同。


人類身體和人類運動的相似

為人形特徵或任何MoCap的動作構建的每個新的人形骨架都是模擬人類身體和行為。無論用多少骨骼或多好的 MoCap 硬體,結果都只能近似真實的人體運動。所以不同的產業(遊戲公司、學校或電影工業)各自會有自己最能代表自己產品的的人形結構需求。

Mecanim人形骨架和肌肉空間的設計遇到了一些艱難的選擇。我們必須在效能和動畫品質或開放性和標準化之間作出權衡。

2塊脊椎骨
這是一個難題。為什麼是 2 塊而不是 3 塊?或者任意數量的脊椎骨?在這裡就先不解釋因為今天不是生物醫學研究。(注意:如果您一定需要這種水準的精確度,那麼您可使用 Generic Rig)。



一塊脊骨明顯無法精確定義,加入第二塊有很多好處,但再多對最後的結果意義就不大了。觀察人體脊椎如何彎曲時,您會發現胸腔上的脊柱部分幾乎是僵硬的,位於脊柱底部和胸腔底部是兩個主要的彎曲點。瑜珈演員的極限姿勢清楚的說明了這一點。基於這些考量,我們決定讓人形骨架具有 2 塊脊骨。

1塊頸椎骨
這比脊柱要簡單一些。要知道許多遊戲人形骨架甚至沒有頸骨,僅依靠頭骨來製作人物。

旋轉DoF(自由度)
與大多數人形骨架一樣(遊戲亦同),Mecanim人形骨架僅支援旋轉動畫。不允許骨頭改變相對其父骨的局部平移。一些3D軟體往往支援一定數量的骨頭平移,以類比關節彈性或擠壓和伸展動畫。我們正在考慮是否要增加平移DoF,因為這是一種計算性能較不負擔的方式,可用細節較少的人形骨架補償動畫品質。它還允開發者建立可重定位的擠壓和伸展動畫。


沒有扭骨
通常將扭骨加到人形骨架是為了防止手臂和腿部的皮膚在極限扭曲中發生表皮變形問題。


扭骨有助於降低四肢所可能發生的變形。
在肌肉空間中,扭曲的量由肌肉表示,並始終與四肢的父骨關聯。例如:前臂的扭曲發生在肘部,而非腕部。
人形骨架不支援扭骨,但透過Mecanim你可以從父骨上取出扭骨比例,並指定在四肢的子骨上。預設值是 50%,它對於防止皮膚變形很有幫助。

人形根節點和重心(質量中心)

自然空間中可表示人體位置和方向的最佳方法是什麼?
骨骼結構中最上層(通常是臀部,或稱為骨盤)是標準人形骨架中在空間位置和方向曲線的位置。在特定的情況下可能運作沒問題,但如果要指定到不是骨盤為最上層或不同選轉軸的人形結構重定位時就會有問題。



肌肉空間使用人形重心用來表示它在自然空間中的位置。重心是模擬人體平均身體部位的質量分布。我們假設模型的比例調整過後,任何人物動作的重心都應該一樣。這是一個大概的假設,但目前為止運作的都很好。

的確,對於站立或行走動畫,重心位於臀部周圍,但對於後空翻等更動態的運動,您會發現身體是如何偏離重心,以及感覺重心是整個動畫中最穩定的點。

身體方向
類似於重心對肌肉空間的自然空間位置的作用,我們用身體的平均朝向來作為人物在空間的方向(身體平均朝向的Up和臀部和肩部的中點計算而來)。身體面對方向是由Up和Left/Right, hips/shoulders的平均值所算出來。同樣預設人形姿勢的身體平均朝向對於所有人形骨架是相同的。在行走或跑步時,也會計算上下身體的重心補償。

根節點運動(Root Motion)
之後會有根節點運動更深入的文章,這裡簡單介紹,重心和身體平均朝向用來自動產生根節點運動。重心和身體平均朝向是人形動畫的穩定屬性,因此會產生可用於巡徑導航或動作預測的穩定根節點運動。

縮放
要建立完整的人形姿勢,肌肉空間還缺少一個東西,就是整體尺寸。我們正在尋找一種可描述人形尺寸的方法,這種方法不依靠頭骨位置等特定的點,因為不同的骨架會有不同的點。 一個好品質的T-Pose角色不管怎麼縮放都可以直接使用。肌肉空間的重心位置按該比例劃分,來產生一個標準化人形姿勢。也就是說,肌肉空間對於T-Pose且高度為1 的角色重心進行標準化。肌肉空間中的所有位置均是以標準化的米為單位。

手和腳的初始位置
將肌肉空間指定到人形骨架時,由於骨架比例不同,手和腳最後可能偏離初始動畫的位置和方向。這可能導致腳滑動或手不能恰當伸展。因此,肌肉空間會視情況選擇手和腳的初始位置和方向。在肌肉空間中,手腳的位置和方向會對人形根節點(重心、身體平均朝向和人形縮放)進行標準化。那些原來的位置和方向可用於修復和重定位骨骼位置,以使用 IK 匹配初始自然空間位置。


IK運算器
IK 運算器主要是讓手臂和腿在肌肉空間裡可以順暢的銜接手和腳的位置和方向。在Mecanim 控制器狀態中啟用“Foot IK”時,可以看到圖片的執行狀況。


在這些情況下,重定位的骨骼位置絕不會偏離初始 IK 目標太遠。IK要修復的錯誤較少,因為錯誤僅僅是由人形骨架的縮放導致的。 IK運算器僅對重定位的骨骼位置稍作修改,產生與初始位置和方向匹配的最終姿勢。

由於IK 僅對重定位的骨骼姿勢修改,因此不太會產生膝蓋或肘部突出等動畫瑕疵。即便出現這種情況,IK運算器的Squash and Stretch計算器也會發揮作用,防止手臂或腿接近最大伸展長度時突出。在預設情況下,允許的擠壓和伸展量限制為低於等於手臂或腿總長度的 5%。肘部或膝蓋突起比起拉伸5%的腿更加明顯難看。要注意的是可將 Squash and Stretch 設為0% 來將其關閉。

後面還會有更深入的 IK文章。該文章將闡述如何處理物件節點、使用多個 IK 通道、與環境或人形角色之間進行互動等。


可選骨頭
人形骨架有一些可選的骨頭。像是胸、頸、左肩、右肩、左腳趾和右腳趾。即使如此。許多現有的人形骨架沒有其中一些可選骨頭,但我們仍然希望使用這些可選的骨頭來創建有效的人形。
人形骨架還支持左眼和右眼。眼骨各有兩塊肌肉,一塊上下移動,另一塊內外移動。還可利用類人操縱LookAt運算處理眼骨,從而將權重分散到脊柱、胸、頸、頭和眼睛的位置調整上。之後的人形 IK 文章將更詳細介紹LookAt計算器。

手指(Fingers)
最後,人形骨架支援手指。每根手指可能有 0 - 3 的值。0 代表未定義手指。1會有兩塊肌肉(拉伸和擴展),2和3只會有一塊肌肉(拉伸)。請注意,未定義手指不會被當成手。

人形骨架要求
中間骨骼(In-between bones)
在許多情況下人類骨骼中的骨骼會比人形骨架定義的多。中間骨骼是指在人形骨架定義的骨骼之間的骨骼。例如在3DSMAX 中創建的Biped模型中的第三塊脊椎骨會被視為中間骨骼。人形骨架是支援這些骨骼的,但Mecanim不會對中間骨骼進行動畫處理。相對於人形骨架中定義的父骨骼,這些骨頭將始終待在其預設的位置和固定方向。

標準層次結構(Standard Hierarchy)
人形骨架必須符合標準層次結構才能與我們的人形骨架相容。骨骼可具有位於人形骨骼之間的任意數量的中間骨骼,但必須符合以下模式:
臀部– 大腿– 小腿– 腳– 腳趾
臀部– 脊柱– 胸– 頸– 頭
胸– 肩– 手臂– 前臂– 手
手– 近端– 中段– 末梢

T-Pose

T-Pose是人形骨架建立最重要的步驟,因為肌肉創建基於此。 T-Pose被定義為標準姿勢是因為容易進行概念化,只要符合下列幾點:

- 面向z 軸站立
- 頭和眼睛面向 z 軸
- 腳著地,與 z 軸平行
- 手臂打開,沿x 軸與地面平行
- 兩手平舉,手掌向下,沿 x 軸與地面平行
- 手指伸直,沿 x 軸與地面平行
- 拇指伸直,與地面平行,位於 x 和 z 軸的中間(45度)
所謂“伸直”,並不是說骨頭一定要完全對齊。取決於皮膚如何依附在骨骼上。一些骨架的皮膚可能看起來是伸直的,但下面的骨骼並非如此。因此,為最終蒙皮(Skinned)完成後的角色設置T-Pose是非常重要的。如果您要創建人形骨架用來重定位MoCap 資料,最好透過 MoCap 套件捕捉到角色處於 T-pose姿勢的動作。

肌肉範圍調整
預設情況下,肌肉範圍設置為最能代表人類肌肉範圍的值。一般來說不應該修改它。對於一些較為卡通的角色,可以縮小範圍,防止手臂與身體難以分辨,或擴大範圍以使腿部運動更為誇張。如果您要創建人形骨架來重定位 MoCap 資料,則不要修改範圍,因為產生的動畫將不符合預設設定。

重定位和動畫片段
Mecanim重定位分為兩個階段。第一階段會轉換一個骨骼結構成為一個標準化人形動畫片段(或肌肉片段)。這一階段發生在編輯器中導入動畫檔時。我們稱為“RetargetFrom”。


第二階段發生在播放模式下,此時肌肉片段被應用到人形骨架的骨骼中時。我們稱為“RetargetTo”。將重定位分為兩個階段有兩大好處。第一個好處是處理速度。一半的重定位過程在離線狀態下完成,只有另一半在運行時完成。另一個好處是場景複雜性和記憶體使用。由於肌肉片段完全為初始骨骼抽象化,要執行重定位,並不需要在運行時包括源骨骼。

第二個階段是很好理解的。一旦您擁有優質的人形骨架,即可通過RetargetTo將肌肉片段應用上,這會自動完成。

第一階段是將骨骼動畫轉換為肌肉片段,這可能有點難理解。骨骼動畫片段以固定率取樣。對於每一個樣本,骨骼姿勢均轉換為肌肉空間姿勢,且在肌肉片段中添加一個keyframe關鍵幀。並不是所有骨骼都合適,有許多不同方式可創建人形骨支架並對其進行動畫製作。一些人形骨架會產生有效輸出,但也可能丟失資訊。我們現在來瞭解如何創建無損的標準化類人動畫注意事項。

請注意: “無損”指的是從人形骨架重定位到肌肉片段,再重定位回到同一個人形骨架,仍保持動畫完整性。事實上這幾乎很難完整。手臂和腿的原始扭曲將丟失,而由 Twist的計算結果替代。正如本文檔先前描述的,肌肉空間中沒有扭曲的表示。

• 人形骨架中的骨骼位置和動畫檔的中骨骼位置必須一致。有時會發生用於創建人形骨架的骨骼與動畫檔的骨骼不一致的情況。請確保使用完全一致的骨骼。如果沒有使用完全一致的骨骼,則在導入時控制台將發送警告。

• 中間骨骼必須沒有動畫。有時 3DSMAX 匯出的骨骼動畫會出現這樣的情況:第三塊脊骨同時有移位和旋轉動畫。 Bip001 用作臀部時和骨盤都具有一些動畫時也會發生這種情況。如果中間骨骼有動畫,則在導入時控制台將發送警告。

• 人形骨架和動畫檔中的中間骨骼的局部朝向必須一致。使用 Skin Bind Pose 來自動配置和創建T-Pose的人形骨架時可能發生這種情況。請確保中間骨骼的“蒙皮綁定姿勢”旋轉與動畫檔中的一致。如果中間骨骼有動畫,則在導入時控制台將發送警告。

• 骨骼不支持移位動畫,臀部除外。 3DSMAX 匯出的Biped 模型有時會對脊骨採用移位動畫。如果不是臀部骨骼,則在導入時控制台將發送警告。

在這裡,我們認為3DSMAX Biped人形骨架使用在Mecanim是有問題的。因為它非常普及因此我們絕對會遇到必須搭配與Mecanim使用的可能性。所以請務必注意如果您要用Mecanim人形動畫創建動畫,請記得遵守上述規則。當然違反上述一些規則的現有動畫,仍然是可行的,Mecanim retarget 功能強大,可產生有效輸出,但不保證生成無損轉換。



著作人