2017年6月27日 星期二

AI-RecastNavgation and Crowd avoidance system

在RTS遊戲開發的領域,Path find及local avoidance
一直是很重要的相關技術,而這兩個部份的位移處理
整合,也是令人頭痛的問題。

RecastNavgation是一套相當成熟的路徑搜尋函式庫,
作者Mikko Mononen曾在Crysis擔任lead AI programmer,
且這套函式庫廣泛被商業遊戲引擎中使用(Unreal及Unity)
,也支持動態計算導航網格。

一般的做法大部份都是使用RVO+RecastNavgation但這樣
會造成整合相當困難(RVO說要去這裡,Recast說要去這裡
,倒底聽誰的)。

另外RVO本身也支援靜態阻檔物(obstacle),但它是用一
直撞過去的方式,沒有路徑搜尋。筆者之前曾嘗試著利用
其相關資訊,動態計算出導航點,但在比較複雜的場景效
果不佳,所以就放棄了。

後來去抓最新的RecastNavgation,發現他早就支援了crowd
local avoidance的功能,而且也找到許多Unreal的開發者
早就從RVO移轉到Recast crowd system。

Unity的Path find system雖然也是以RecastNavgation為基
礎開發的,但目前卻還沒有支援Crowd,人家Unreal全部都是
C++,可能比較好支援…

話說回來,目前的專案需求是Server及Client要共用路徑搜尋
的功能,所以不能跟Unity有任何的關係,於是如果要支援
RecastNavgation及其Crowd系統,比較好的解決方案可能就是
自行設計RecastNavgation native c++ plugin

以下是初步整合的成果,此畫面目前是用Ogre來Render(之後
再整合到Unity),在走道可以通過的時候,Agent Sphere會
在那邊排隊等通過,但沒辦法走的時候就各自從旁邊繞過去了

Dream continues in...

2017年5月26日 星期五

Edit and generate RVO obstacle data with ConvexHull in unity

I use C# convex hull library to develop edit and generate RVO obstacle data.
It's just parse unity's mesh data to convex hull data, and put the convex hull vertex to RVO obstacle build function.

The c# convex hull library is here:
MIConvexHull
The c# RVO library is here:
RVO2 Library
The result is here:

2017年5月16日 星期二

Process RVO agent stuck obscale problem with fix path mechanism

Normally, RVO agent behavior have stuck obstacle problem.
So, I add fix path mechanism(data form obstacle vertex point and current agent's point)
to solve this problem.
The idea graph is here:
The result video is here:



Dream continues in...

2017年4月23日 星期日

RVO測試

RVO要是用來做大量物件近距離閃避處理的一套函式庫,有好幾個版本,主要演變過程為
RVO =>HRVO =>ORCA,詳細資訊可以參考這個網站:

2017年4月10日 星期一

在Unity下做巨量繪圖物件管理

結論:500*500個物件加五個射影機加一個Infinity ocean,fps從20到56~60。

在這邊先提一下space partition的觀念:

它是一個用來快速查尋物件清單的機制,比方我們的台灣地圖,若把它分成北、中、南三區,在找台北市的時候,當然在北部地圖這邊找。space partition的種類很多,QuadTree、Octree、 K-DTree、BSP-Tree、Grid、PVS…等,通常會依照專案的需求會採用不同的資料結構。

Space partition的用途很廣,除了在camera view frustum culling會用到之外,也蠻常用在 AI(快速查找鄰近單位,比方像RVO)、碰撞…等跟空間切割有關議題對效能優化有很大的幫助。 下面有一個相關的範例圖:


在這個範例可以發現先將整個場景切成九等份,然後把相關的物件擺放到格子中,若遇有交插兩個格子之間的物件,可以隨便決定由那一個格子統一管理(由上而下、由左而右都行)。在Camera開始拍射(畫圖)的時候,先判斷有那個大格子會被拍到,不會被拍到的,就不用管它,之後再拜訪所有會被拍到大格子裡的所有子物件,判斷是否會被拍到,會被拍到再送進GPU。

所謂的Camera拍不拍的到,指的是物件的包覆範圍(bounding volume,通常是AABB或sphere)跟Camera的視野範圍(由六個Plane所組成)是否有交集。利用space partition大包小的特性,就可以大幅降低跟物件的比較次數。

那Unity下有沒有使用space partition來管理物件呢?目前大概只有看到PVS這個東西,但是PVS的特性,比較適合應用在遮蔽物很多的情況下(比方地下城,迷宮…等)。至於有沒有用到其他開闊式場景管理的機制,就不清楚了。

在經過一些大量的測試之後,發現Unity有一個特性,就是物件的Layer ID就算不是Camera Culling mask裡的範圍,仍然會對它做View frustum culling處理,除非你把GameObject的active設成false或是Renderer Component的enable設成false。

證據是我在場景放了500*500個物件(材質不相同,所以沒有batching在一起),在只有一個Main Camera的情況下,效能在還可以維持在50~60左右,當放了自己設計的Infinity ocean時(有額外四個射影機),就發現效能降到20左右,就算把所有的物件layer都設成所有的射影機看不到的layer ID也沒用,因此推論Unity底層應該是沒有用到QuadTree、Octree…等開闊式場景管理的機制。

然而Unity在camera view frustum culling本身也是封死在底層,完全沒辦法碰到,就算自己有十八般武藝也拿它沒輒,目前只能對它的GameObject或RenderComponent開刀,之前常常聽到google大神說動態切換GameObject的ative會影響效能,所以就走設定Render enable flag的路。

後來自己導入了一個簡單的grid base的space partition的機制,效能果然從20 fps提升到56左右,目前用的測試機器是紅米note3(GPU是Adreno 510),相關的測試影片如下…

Partition View的除錯資訊,綠線是指沒看到的Grid,紅線是指看到的Grid,白格是指看到的物件

2017年3月26日 星期日

The vertex base ocean on the red mi note3(Qualcomm Adreno 510) , FPS 60

Technique:
  • Projected grid for infinity water issue.
  • Vertex shader Perlin noise (GPU base)
  • Two normal map (medium and detail) for displacement issue
  • RTT technique (Depth, Refraction, Reflection RTTS)
  • Base Fresnel terms implement
  • Foam edge process (depth base, no Sobel)
  • Gradually disappear in the distance
  • Normal distortion ( refraction and reflection)
  • Deep and shallow water color
  • use RTT technique to reduce ocean simulate huge pixel process overhead

The reference demo video is here:

2017年3月13日 星期一

Unity使用感

用Unity感覺就像是去特力屋買傢俱一樣,隨便一下子就組裝好了,就算有不牢的地方,
用點膠水(C#)就好了。

不過一旦遇到支架或卡榫不合的時候,就會讓人抓狂了,甚至用再多的膠水也形朔不出
理想的卡榫…這時候有經驗的木工師父就會覺得『還不如自己用C++做…』。

但有時候,多花一些時間再看看Unity的文件或上網Google一下,發現其實只是沒看到這
裡有個洞或卡榫而已,不過例外也蠻多的,像自己再花時間打造的水Shader就不是這樣…