ScriptableRenderPass to RenderGraph: Smooth Transition in Unity 6 URP

With the official release of Unity 6 LTS, RenderGraph is no longer an experimental toy—it has become a significant evolution in Unity’s rendering pipeline. For developers using the Universal Render Pipeline (URP), how to seamlessly transition from the traditional ScriptableRenderPass to RenderGraph has become a hot topic.

The Lua-based AI System

目前規劃了一個以LUA Script為架構的AI系統，基礎框架為如下：
function Stroll_Enter(Brain, FromStateName)
end
function Stroll_Update(Brain, fDeltaTime)
end
function Stroll_Exit(Brain)
end
C++程式的部份預設會Call Stroll這個State的Enter為進入點，之後可以透過ChangeState這個C++綁定的成員函式來達到切換行為的目的，比方Brain:ChangeState("Fight")…
下列是目前有關這個Demo Game的相關AI Script的內容：

編譯Ogre1.9 IOS Dependencies及Ogre Source步驟及相關注意事項…

可能有人會想問我為什麼要自行編譯IOS Dependencies，主要是因為Ogre提供PreBuild的版本是用C++11編譯，當使用到一些ThirdParty Library沒辦法使用C++11編譯的時候或沒有Source Code的ThirdParty Library，這就很重要了（比方Particle Universe 1.6），在此跟大家分享一下相關心得，希望能達拋磚引玉的效果…

Use LUA + LUABind + MyGUI achieve WOW LUA bind UI functionality

WOW origin using the GUI binding LUA, players realize homemade one touch change equipment and small bags into one big bag of features that make me feel very stunning, can be made ​​if the player UI features, and that planning will be able to own get.

About LUABind not compiled in Xcode5 problem (already solved!!!!)

The latest version xcode has removed the non-default compiler,
so will not be able to compile luabind by gcc!
How do?
Just latest luabind from github!

 The reference link:

About the bidirectional boost bimap implementation

Use for ID To name and name to ID.
The source code is here:

關於APP資料佈署的解決辦法

　　在開發MMO的時候，這個幾乎是完全交給人工去管理…不過以之前的經驗，為了怕Load不到資料而造成問題（當機或顯示不正確…等），能不砍則不砍，結果往往導致沒有用的資料越來越多，進而導致資料過於肥大。

　　在現在APP當道，維護資料的精簡變得非常重要（因為APP要小而美，且部份平台-Andorid對於資料量的大小有嚴格的限制），能否把這件事做自動化處理呢?筆者開發了一個佈署工具來完成這件事。

　　這個佈署工具其實就是一個執行command line（system(...))的程式，那為何不用批次檔直接來處理呢?主要的原因是因為目前3D引擎是用Ogre，需要Run過Ogre的一些函式庫及Manager才會知道相關的Reference檔案，所以還是得程式化才行。
開發流程大致如下：

My First Android APP with Ogre3D

拜Ogre1.9之福，已經將遊戲引擎跨到Android層級了，目前引擎橫跨PC、IOS及Android，接下來就是WinRT了…

在此分享一下關於1.9跟Android處理的一些心得：

1. 首先就是Ogre的StringConverter，由於osstream沒辦法在所有的Android平台上順利執行，因此蠻多用snprintf取代掉了…，我自己也有用到，所以也要改。
2. std::atexit無法使用，導致只好不用Loki的Singleton，自己實作。
3. OgreStableHeaders.h漏了OGRE_PLATFORM == OGRE_PLATFORM_ANDROID，要補上。
4. 使用Nsight visual studio edition，以便於直接在Visual Studio插中斷點進行除錯（需搭配Tegra的硬體），所以就沒有使用Android MK檔的東西，Ogre專案檔也就要自己建立了…
5. OgreGLES2Prerequisites.h少定義了GL_CHECK_ERROR巨集，要記得補上 。
6. OgreGLES2FrameBufferObject.cpp有一行#Else寫成#Endif 。
7. 全使用Native Code，沒有一行jni及java code。
8. GLSLES雖然提供mat3參數傳遞的語法，但不是每個Android硬體都可以正行執行，改成傳3個Vector比較穩

接下來就是Demo影片…

分析Ogre關於材質及物件數量對效能的影響…

結論：

1. 能共用材質的話，儘量共用，對效能有極大影響。（在其他的引擎好像也有這樣的特性，比方Unity）
2. 能Combine成一個Static Geometry，儘量Combine，在材質共用的情況下，有極大幫助（不過如果Triangle數量太多的話，分成不同的Page Cull掉也許會比較好）
3. 實際應用上，還是有其限制，同材質且同一個Mesh的做法，比較適合大量的小型物件（比方花花、草草之類的），Page Geometry應該就是用這個做法來最佳化。

相關測試數據：

關於最近在處理行動平台上Pixel Shader的效能問題…

最近行動平台紛紛流行起高解析度與視網模技術，雖然提高了解析度，但有些硬體卻沒相對提升Pixel Shader的Core能力，導致有發生了相同的Pixel Shader程式碼在Ipad2上比New Ipad執行效能還要好的狀況，這讓小弟非常的不高興（因為小弟就是買了New Ipad這個過渡時期的產品…），於是踏上了研究相關應對做法之路…

經過實驗後，整理出相關的解決方法…

The Ogre3D technique work follow

首先慶祝一下部落格文章突破一百篇（買份鹹酥雞吃吃…）!!!!!!!!!!

最近使用不少關於Render to texture的部份，在Ogre3D的Technique架構下，ViewPort的取用Technique的流程如下：

關於GUI函式Bind及數值顯示處理…

常見的做法都是判斷GUI名稱來進行相關處理，比方…
m_pHPBar = GUIManager.GetUIObject("HPBar");
m_pHPBar->SetPos((CurrentHp/MaxHp)*BarRange);

OnButtonClieck(GUI* pGui)
{
　　if(pGui->GetName() == "StartGame")
　　　　DoStartGame();
}

好一點的話，只是把Name Bind到函式，但這都是寫死的方式，企劃如果要調整名稱或重新做新的UI，這些工作都要再來過，而且一定要透過程式才能進行相關測試，非常麻煩…

如果函式及顯示的綁定可以交由企劃做，就像魔獸的GUI可以讓User自行編輯一樣，或許狀況可以改善一些，以下是用MyGUI處理顯示方面的例子：

跨GLSL與GLSLES shader code

主要目的是為了能在PC Windows上可以直接測試glsles（雖然有很多GLSL的內建變數無法使用，可能會造成GLSL可以跑，GLSLES卻無法執行的問題…），這樣可以加快開發GLSLES Shader的速度。

停留在DX9及GLES1.0的秘辛…

最近在整合GLES2.0 Shader Pipeline，有一些感想…

 原來大家都停留在DX9並不是因為DX10太爛或DX11不熟，而是進入DX10以後，所有Fix Function Pipeline所做的事情，都要自己做（尤其是Multiple Lighting的計算），這也是為什麼要保持在DX9版本的原因之一（基本的交給Fix Function Pipeline，特殊效果另外做Shader）。

 而GLES就沒這麼好過了，GLES1.0僅允許使用Fix Function Pipeline，而GLES2.0僅允許使用Shader Pipeline，沒有共存的版本，這也是為什麼目前市面上的APP大都使用GLES1.0，而沒使用GLES2.0的原因之一。

 展望未來，在GLES2.0上使用Shader將是一大門檻，跨過這道後將擁有畫面上更多的可能性，大家一起來玩Shader吧!

PS： 最近筆者終於把這道門檻跨過，不過這只是起步『革命尚未成功，同志仍需努力』 夢想

仍在持續中…

Triangle Base Projection Texture

緣起於因為Add Frustum Pass無法解決投射超過二個Texture的問題，於是開啟了Triangle Base Projection Texture之路…
Frustum Pass的問題：

1. 增加不必要的三角形數（因為MultiPass的關係，尤其是Polygon數多的物件…）
2. 有機會投射超個二個以上的Texture，常發在生上下有疊層的場景中…

但Triangle Base也有一些需要犧牲的問題：

1. 需做動態碰撞處理（AABB to Triangle），以取得投射範圍的Triangles
2. 需做動態LockBuffer（含Vertex及Texture Coordinate Buffer）

PS:以上僅要重設位置時需執行，不重設位置則不用

如何做：

1. 執行AABB to Triangles碰撞，以取得交集的三角形集合
2. Lock and fill Vertex and Texture Coordinate Buffer

重算UV的公式如下：
TranslateMatrix*ScaleMatrix*RotMatrix*DestUVW（三角形的點）

相關的範例程式：

Ogre3D1.8整合心得報告

1.8與1.7最大的不同，如下：

1. 支援OpenGL ES 2.0（這個版本後，才有對Shader的支援）
2. 就是不再支援orientation mode（底層會自行建立好View Controler）
3. 與Run Time Sahder Lib的整合（因為OpenGL ES 2.0不支援Fix Function Pipeline，所以利用Run Time Shader Lib來進行動態建立Default Shader的相關處理）

Build Ogre的心得：

1. 切記儘量讓CMake所有相關的Dependency皆能找到，不要出現紅色的訊息。
2. 關於FreeType的部份，用Ogre Dependency裡面的，不要用系統內建，之前在整合1.7時，被這個問題卡很久。

Run Time Shader Lib的整合：
基本上參考SimpleBrowser的Source Code，即可輕易整合，要注意的是在Ogre::RTShader::ShaderGenerator::initialize()時，要先把System Manager準備好，因為建立ShaderGenerator時需要用到。

PageGoemetry整合：
這是最麻煩的部份，因為原Lib並沒有處理GLSL ES Shader的部份，而且他的Shader Source Code是寫死在程式裡面，新的Ogre Materil Script架構，允許指定對應到不同的Shader檔，所以關於跨平台的部份，可以在Script裡面做，於是筆者就自行修改了這部份的source code，並做好對應的相關Shader code。

相關Demo影片：

PageGeometry介紹

緣起於之前做的MMO RPG專案，常常被嫌棄物件數量太少（因為效能量的考量），所以開啟了找尋解決render大量物件的solution之旅。
PageGeometry是一個處理大量物件的solution，是一套Ogre3d的addon lib。其最佳化的架構概念始於Ogre原生的static geometry，是捨棄物件資訊將其合併到一個Page的做法（處理單位為page，大量減少物件相關的view frustum culling的CPU判斷），因而達到height performace render 大量物件的目標。不過也因為沒有物件概念了，所以編輯工具的撰寫上會比較麻煩，需搭配paint objects編輯系統來運作可能會比較方便。

測試程式相關：

1. 作業系統：win7
2. CPU：Intel Core i5-2400 3.10 GHz
3. Nevdia GeForce GTX 560 Ti
4. 測試數據 ：100000個物件，平均FPS為707.359

測試影片：

XML與物件掛勾後的感覺真好…

在寫工具的時候，物件屬性的編輯是很麻煩的問題（要開一大堆的介面、一大堆的判斷式、繁瑣的通知事件…等等），有沒有更的的做法呢?其實有，那就是讓XML跟物件掛勾…
掛勾有什麼好處？要怎麼掛勾呢？

BCGControlBar，進化了…

關於BCGControlBar17.0版的更新內容實在讓我心動，這幾年來一直陪著我的BCGControlBar終於推出了17.0版（BCGControlBar為MFC最佳解決方案之一，可惜不便宜…），終於推出了讓我驚艷的功能（雖然有很多Free的lib也有做，但是整合起來有點麻煩，不是一整套的…）Diagram，相關參考圖如下：

還有這個也不錯…

快速自製windows下MemoryLeak檢查函式…

相信很多人都已經知道VC的crtdbg不錯用（MFC也是用這個檢查Memory Leak），在此提供給不知道的人參考，相關打包函式如下（記得放在.h，覆寫掉New操作元）：
//WindowsMemoryLeakCheck.h
#include < crtdbg.h >
#ifdef _DEBUG
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif
inline void EnableMemLeakCheck(unsigned int uiBreakID = 0)
{
  _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) |
    _CRTDBG_LEAK_CHECK_DF);
  if(uiBreakID != 0)
    _CrtSetBreakAlloc(uiBreakID);
}
…