上一篇筆記中
為了嘗試在同時使用到多個 Cameras情境下
render to RenderTexture時讓 game object正確接收/處理 mouse events
因此爬了幾個文章
https://forum.unity.com/threads/interaction-with-objects-displayed-on-render-texture.517175/
(更完整個重新實現自己的 event input module)
https://forum.unity.com/threads/handling-event-input-offscreen.378470/
我試著參考這些資料試驗
但是因為自己尚未深入去爬 UnityEngine.UI source codes
所以對於部分 coding 還是無法理解
偶然才發現到其實 Unity 提供的 ***Raycaster 就是在處理這方面的事情
https://docs.unity3d.com/2019.2/Documentation/Manual/script-GraphicRaycaster.html
https://docs.unity3d.com/2019.2/Documentation/Manual/script-PhysicsRaycaster.html
只是之前從官方文件上看不夠仔細沒有想到而已
因此嘗試在 RenderTexture camera 中裝上 PhysicsRaycaster component
然後呢....
場景中 3D game object 就可以接收到 EventTrigger component 支援的所有事件了!
雖然我還是沒有正確接收到所有 mouse events
(OnMouseEnter, OnMouseExit, OnMouseDown, OnMouseOver ....)
但已可以實現很完整的一系列事件了
(OnPointerEnter, OnPointerExit, OnMove, OnDrag, .... 等)
可是事情總是沒有憨人想的這麼簡單 = =
EventSystems 發出的 raycasted events 僅在 RenderTexture resolution = real screen resulotion的情況下正確運作
如果 RenderTexture大小與 screen大小不符合
接收到事件的 pointer (mouse) position 就會出錯
這.....不知道算是誰的鍋了
難怪 forum 裡面建議的還是自己延伸改寫 GraphicRaycaster / PhysicsRaycaster ...
https://www.linkedin.com/in/river-wang-4118425b/
https://www.slideshare.net/riverwang54
本是個愛打電動的小屁孩
直到第一次看到FF7
就夢想有一天自己也能做出那樣等級的遊戲
但直到過了30歲才開始真的當遊戲人
雖然夢想還在遠方
但不願為了夢想而犧牲任何東西
因為另一個夢想就是當個普通人
2019年12月2日 星期一
2019年12月1日 星期日
Unity render to RenderTexture 下的事件
摸 Unity 至少也 2 年多了
不能說自己不熟
但還是有很多基本的運作方式有點摸不清
感覺自己很嫩
這次因為需求將場景繪製到指定的 RenderTexture
一切那麼自然的情況下
才發現因為使用到多個 Camera
所以繪製 RenderTexture的時候我無法正確抓到 mouse events了
因此開了一個小測試專案
場景中的 Cube會列印 OnMouseOver() 事件.
在 TestMain.unity 場景, 因為僅單純使用一個 MainCamera
因此即使繪製過程指定至 RenderTexture
仍可以正確接收並處理 OnMouseOver() 事件
TestCamera2.unity 場景中, 使用 2 個 Camera
SceneCamera將場景繪製到指定 RenderTexture
ScreenCamera僅將 RenderTexture畫到全螢幕做顯示用
但在這個情境下我就無法讓 Cube接收到 OnMouseOver() 事件了
目前無論我怎麼測試 Camera的設置調整都無法接收事件.
(1)
SceneCamera
tag='MainCamera'
Depth=-1
ScreenCamera tag='Untagged'
Depth=-10 or 10
(2)
SceneCamera
tag='MainCamera'
Depth=-1
tag='MainCamera'
Depth=-10 or 10
(3) SceneCamera透過 MainCamControl.cs控制, Update()之前先 Disable其他 cameras
目前的結論大概是
場景中同時存在多個 Cameras之下
render to RenderTexture時就無法順利接收/處理 mouse event.
不確定是不是自己有哪部分搞錯了
只能繼續爬文查資料
不能說自己不熟
但還是有很多基本的運作方式有點摸不清
感覺自己很嫩
這次因為需求將場景繪製到指定的 RenderTexture
一切那麼自然的情況下
才發現因為使用到多個 Camera
所以繪製 RenderTexture的時候我無法正確抓到 mouse events了
因此開了一個小測試專案
場景中的 Cube會列印 OnMouseOver() 事件.
在 TestMain.unity 場景, 因為僅單純使用一個 MainCamera
因此即使繪製過程指定至 RenderTexture
仍可以正確接收並處理 OnMouseOver() 事件
TestCamera2.unity 場景中, 使用 2 個 Camera
SceneCamera將場景繪製到指定 RenderTexture
ScreenCamera僅將 RenderTexture畫到全螢幕做顯示用
但在這個情境下我就無法讓 Cube接收到 OnMouseOver() 事件了
目前無論我怎麼測試 Camera的設置調整都無法接收事件.
(1)
SceneCamera
tag='MainCamera'
Depth=-1
ScreenCamera tag='Untagged'
Depth=-10 or 10
(2)
SceneCamera
tag='MainCamera'
Depth=-1
tag='MainCamera'
Depth=-10 or 10
(3) SceneCamera透過 MainCamControl.cs控制, Update()之前先 Disable其他 cameras
目前的結論大概是
場景中同時存在多個 Cameras之下
render to RenderTexture時就無法順利接收/處理 mouse event.
不確定是不是自己有哪部分搞錯了
只能繼續爬文查資料
2019年10月6日 星期日
[Unknown] #1 Base1 level 更新
繼上次筆記後這 2 周來好像只摸不到半天的時間
能空出來做自己私事的時間實在太少了
真的讓我常有想要乾脆辭掉所有工作
不想負任何責任
只想開開心心的專注於自己喜歡的事業
總之地下室 (Base1) 地板, 牆面, 斜坡車道已經初步定案
順便上簡單的 vertex color 方便日後辨識地形設計
之後針對地下室還需要加入各個設備如:
機械車位系統
停車格標示
儲藏室
抽水馬達及供水槽
汙水池
發電機配電控制室
高壓電配電室
電梯
.....等
能空出來做自己私事的時間實在太少了
真的讓我常有想要乾脆辭掉所有工作
不想負任何責任
只想開開心心的專注於自己喜歡的事業
總之地下室 (Base1) 地板, 牆面, 斜坡車道已經初步定案
順便上簡單的 vertex color 方便日後辨識地形設計
之後針對地下室還需要加入各個設備如:
機械車位系統
停車格標示
儲藏室
抽水馬達及供水槽
汙水池
發電機配電控制室
高壓電配電室
電梯
.....等
2019年9月28日 星期六
Shader Graph custom lighting + PBR master node + stripping unused
最近開始熟悉 Unity SRP 和 shader graph (SRP 還不算熟)
上過課之後
看官方的部落格介紹文章也很快進入狀況
https://blogs.unity3d.com/2019/07/31/custom-lighting-in-shader-graph-expanding-your-graphs-in-2019/?fbclid=IwAR387bG0VVwX7nF0vwRZL_7_Qmf2ZgsoXWhRL0eJnuUfTYZqQQ2XGZjobkk
差不多有感覺可以駕馭 shader graph (至少針對 LWRP)
另外延伸看到有人分享文章
https://medium.com/@larsbertram1/lwrp-and-custom-lighting-in-shader-graph-6a7c48008a1d
====
The shader compiler comes to our rescue, as it will strip all code, it thinks, which will not contribute to the final pixel. So if we set albedo to constant 0,0,0 or black the entire diffuse lighting pass will always result in 0,0,0 and thus the shader compiler will strip it, right? Setting occlusion to 0.0? Ambient diffuse and specular lighting will always be 0.0, so these parts should get stripped as well. What’s about direct specular lighting, which includes the most expensive calculations? Setting smoothness to 0.0 and specular to 0.0 as well should do the trick.
====
使用 Unlit shader 製作 custom lighting shader 無法運用 Unity 內建的 global illumination / lightmap / cascaded shadow 功能, 使用 PBR Master Node 的話又會顧慮到做多餘 PBS lighting 的 shader codes/calculations.
因此將 custom lighting 的結果直接指定給 PBR Master Node 的 Emission input, 其他用不到的 feature 就歸零, 這個方式就可以透過 Unity stripping shader codes 功能將 PBR Master Node 多餘的計算相關 shader codes 排除.
非常有用的資訊.
上過課之後
看官方的部落格介紹文章也很快進入狀況
https://blogs.unity3d.com/2019/07/31/custom-lighting-in-shader-graph-expanding-your-graphs-in-2019/?fbclid=IwAR387bG0VVwX7nF0vwRZL_7_Qmf2ZgsoXWhRL0eJnuUfTYZqQQ2XGZjobkk
差不多有感覺可以駕馭 shader graph (至少針對 LWRP)
另外延伸看到有人分享文章
https://medium.com/@larsbertram1/lwrp-and-custom-lighting-in-shader-graph-6a7c48008a1d
====
The shader compiler comes to our rescue, as it will strip all code, it thinks, which will not contribute to the final pixel. So if we set albedo to constant 0,0,0 or black the entire diffuse lighting pass will always result in 0,0,0 and thus the shader compiler will strip it, right? Setting occlusion to 0.0? Ambient diffuse and specular lighting will always be 0.0, so these parts should get stripped as well. What’s about direct specular lighting, which includes the most expensive calculations? Setting smoothness to 0.0 and specular to 0.0 as well should do the trick.
====
使用 Unlit shader 製作 custom lighting shader 無法運用 Unity 內建的 global illumination / lightmap / cascaded shadow 功能, 使用 PBR Master Node 的話又會顧慮到做多餘 PBS lighting 的 shader codes/calculations.
因此將 custom lighting 的結果直接指定給 PBR Master Node 的 Emission input, 其他用不到的 feature 就歸零, 這個方式就可以透過 Unity stripping shader codes 功能將 PBR Master Node 多餘的計算相關 shader codes 排除.
非常有用的資訊.
2019年9月24日 星期二
[Unknown] #0: 首次筆記
老樣子, 一直以來沒有時間做自己想做的遊戲
我也不知道現在算不算開始動了
總之最近開始練習 Probuilder, 打算先把 prototype level 做出來
初次更新
我想做的是有地面也有坑洞用來放置立體機械裝置
比如說機械車位系統
希望未來能持續投入時間
加油一下吧
我也不知道現在算不算開始動了
總之最近開始練習 Probuilder, 打算先把 prototype level 做出來
初次更新
我想做的是有地面也有坑洞用來放置立體機械裝置
比如說機械車位系統
希望未來能持續投入時間
加油一下吧
2019年5月13日 星期一
Next step
前一陣子已經花了蠻長的時間閱讀以前保存的技術文件
主要已 Unity engine為核心去探索較新的 game develop技術
也差不多該是準備動手做的時機了吧
該看的其實看的差不多了
不親自下海練練身手, 讀再多也只是看故事久了就忘了
這裡先整理一些重要的 references
已經深入研讀的主題包含
Unity :
------------------------------------------------------
Standard Shader
http://unitytaiwan.blogspot.com/2017/03/unity_14.html
http://geekfaner.com/unity/blog16_UnityStandardShader.html
Global Illumination*
https://lmhpoly.com/unity-5-tutorial-lighting-and-post-processing-low-poly-scene/
Post Processing*
http://geekfaner.com/unity/blog11_PostProcessStackV2.html
Scriptable render pipeline
https://blogs.unity3d.com/2018/01/31/srp-overview/
https://blogs.unity3d.com/2018/02/21/the-lightweight-render-pipeline-optimizing-real-time-performance/
https://blogs.unity3d.com/2018/09/24/the-high-definition-render-pipeline-getting-started-guide-for-artists/
https://blogs.unity3d.com/2019/02/08/we-have-you-covered-with-the-measured-materials-library/?fbclid=IwAR3VNDyX5HPbY4XI93za-2POUEpti4rFA-ZxQIjda75Z1O82RPTj4xJLR7o
http://geekfaner.com/unity/blog13_SRP.html
https://makedreamvsogre.blogspot.com/2019/03/lwrp.html?fbclid=IwAR0X2g8DoCw3GfM7Q2yUE2lSQ6QnnrenurmvmqPtFqYJ3TkVQf01EJu-y10
https://blogs.unity3d.com/2019/02/28/srp-batcher-speed-up-your-rendering/?fbclid=IwAR3m9z59QaaTWsrYrw3BKjeTIRsRgOZpHzO9Vc4Sr-LsrzF2dkQMwHZfCY4
Shader Graph
https://blogs.unity3d.com/2018/12/19/unity-2018-3-shader-graph-update-lit-master-node/?fbclid=IwAR2wx5tyhU9MbwVJldqrKNBRZmWcsEBDuwcIGxkIHVuDqoSflZAqmFS8oM4
Unity test runner
https://docs.unity3d.com/Manual/testing-editortestsrunner.html
Assembly definitions
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
Augment Reality
https://blogs.unity3d.com/2018/12/18/unitys-handheld-ar-ecosystem-ar-foundation-arcore-and-arkit/?fbclid=IwAR1q8iBdWVHIaaklZli0wsCd6kaErGEtmS6p-n5P5CJ7xqXgi1ZPK0zF7_I
------------------------------------------------------
Graphics :
------------------------------------------------------
Forward+ rendering / Deferred rendering*
https://zhuanlan.zhihu.com/p/54694743?fbclid=IwAR24BiJ-JoBOH5s2Ar0IUYKhEKWd-erl1poCx--aiRUMuueJX4-LfH5ioxs
Screen space reflection
https://bartwronski.com/2014/01/25/the-future-of-screenspace-reflections/
https://www.gamasutra.com/blogs/DavidArppe/20170405/295240/How_to_get_Stunning_Graphics_with_Raymarching_in_Games.php
Physically based shading
http://geekfaner.com/unity/blog5_PBR.html
High dynamic range rendering
http://geekfaner.com/unity/blog1_gamma.html
------------------------------------------------------
Allen大神的指引永遠都像金玉良言
https://www.ptt.cc/bbs/GameDesign/M.1556422552.A.4CE.html
主要已 Unity engine為核心去探索較新的 game develop技術
也差不多該是準備動手做的時機了吧
該看的其實看的差不多了
不親自下海練練身手, 讀再多也只是看故事久了就忘了
這裡先整理一些重要的 references
已經深入研讀的主題包含
Unity :
------------------------------------------------------
Standard Shader
http://unitytaiwan.blogspot.com/2017/03/unity_14.html
http://geekfaner.com/unity/blog16_UnityStandardShader.html
Global Illumination*
https://lmhpoly.com/unity-5-tutorial-lighting-and-post-processing-low-poly-scene/
Post Processing*
http://geekfaner.com/unity/blog11_PostProcessStackV2.html
Scriptable render pipeline
https://blogs.unity3d.com/2018/01/31/srp-overview/
https://blogs.unity3d.com/2018/02/21/the-lightweight-render-pipeline-optimizing-real-time-performance/
https://blogs.unity3d.com/2018/09/24/the-high-definition-render-pipeline-getting-started-guide-for-artists/
https://blogs.unity3d.com/2019/02/08/we-have-you-covered-with-the-measured-materials-library/?fbclid=IwAR3VNDyX5HPbY4XI93za-2POUEpti4rFA-ZxQIjda75Z1O82RPTj4xJLR7o
http://geekfaner.com/unity/blog13_SRP.html
https://makedreamvsogre.blogspot.com/2019/03/lwrp.html?fbclid=IwAR0X2g8DoCw3GfM7Q2yUE2lSQ6QnnrenurmvmqPtFqYJ3TkVQf01EJu-y10
https://blogs.unity3d.com/2019/02/28/srp-batcher-speed-up-your-rendering/?fbclid=IwAR3m9z59QaaTWsrYrw3BKjeTIRsRgOZpHzO9Vc4Sr-LsrzF2dkQMwHZfCY4
Shader Graph
https://blogs.unity3d.com/2018/12/19/unity-2018-3-shader-graph-update-lit-master-node/?fbclid=IwAR2wx5tyhU9MbwVJldqrKNBRZmWcsEBDuwcIGxkIHVuDqoSflZAqmFS8oM4
Unity test runner
https://docs.unity3d.com/Manual/testing-editortestsrunner.html
Assembly definitions
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
Augment Reality
https://blogs.unity3d.com/2018/12/18/unitys-handheld-ar-ecosystem-ar-foundation-arcore-and-arkit/?fbclid=IwAR1q8iBdWVHIaaklZli0wsCd6kaErGEtmS6p-n5P5CJ7xqXgi1ZPK0zF7_I
------------------------------------------------------
Graphics :
------------------------------------------------------
Forward+ rendering / Deferred rendering*
https://zhuanlan.zhihu.com/p/54694743?fbclid=IwAR24BiJ-JoBOH5s2Ar0IUYKhEKWd-erl1poCx--aiRUMuueJX4-LfH5ioxs
Screen space reflection
https://bartwronski.com/2014/01/25/the-future-of-screenspace-reflections/
https://www.gamasutra.com/blogs/DavidArppe/20170405/295240/How_to_get_Stunning_Graphics_with_Raymarching_in_Games.php
Physically based shading
http://geekfaner.com/unity/blog5_PBR.html
High dynamic range rendering
http://geekfaner.com/unity/blog1_gamma.html
------------------------------------------------------
Allen大神的指引永遠都像金玉良言
https://www.ptt.cc/bbs/GameDesign/M.1556422552.A.4CE.html
2019年5月7日 星期二
Tests in Unity
過去幾年接觸過 TDD (Test-Driven Dev)的概念後
就一直想要在自己的專案中實現 unit test實作
但礙於時間不夠充足之類的前提讓我一直沒有動工
最近工作上的專案算是比較有空下來的時間
所以針對 Unity 官方提出的 test環境進行一番研究與探索
算是準備的差不多可以執行自己的 test programming了吧
當然也歸功於 Unity官方準備的開發環境與說明文件真的很方便
所以感覺要實現 TDD概念開發這點也不是那麼難了
幾個關鍵可先參考官方文件
Unity Test Runner
https://docs.unity3d.com/Manual/testing-editortestsrunner.html
https://docs.unity3d.com/Manual/PlaymodeTestFramework.html
這份則是比較舊版的官方中文翻譯文件
https://docs.unity3d.com/Manual/PlaymodeTestFramework.html
基本上簡易的unit test script可說是無痛實現
照著官方說明操作就可以建好完整的 test環境
但事情總是不會只有這麼簡單
像我目前的專案經過長期粗暴醜陋的"封裝"
我想進行測試的大部分內容已經牽涉到 internal / private / protected封裝
所以在 [Test]函式中是無法存取到該內容的
這一點算是老問題了, 所以 .NET官方早有解法
[assembly: InternalsVisibleTo(“UnitTests”)]
http://anthonygiretti.com/2018/06/27/how-to-unit-test-internal-classes-in-net-core-applications/
但在 Unity Test Runner環境下要如何實現這一點呢?
我首先必須把 assembly正確區分出來, 這個屬性才能派上用法
因此查過官方文件後, 我該做的就是針對所有 scripts設定正確的 assembly definition asset
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
好啦, 問題來了, 誠如官方文件所說, 如下圖

手動設定的 assembly (.dll)都無法參考到預設的 Assembly-CSharp.dll
因此如果我想要為專案正確設定 assembly definitions,
等於要將整個專案所有的 scripts做一次完整重構了吧
是說這一步驟也是該做, 只是當初一開始只想著輕鬆實現 unit test開發環境
沒想到還是得先經過大規模的重構才有可能完成有意義的 unit test
如上所述如果整個專案都正確區分成正確的 assemblies,
應該就會有個對應的 test assemblies (Tests.dll)去參考想測試的部分 (如 Main.dll, Stuff.dll, ...)
然後在 Tests.dll中實現 unit tests
當然總是還是有更偷懶的做法
準備一個 Editor資料夾, 在其中建立 test scripts
如此一來 test scripts便會被加入預設的 Assembly-CSharp-Editor.dll
因此整個專案仍然維持最原始單純的 Assembly-CSharp.dll 與 Assembly-CSharp-Editor.dll
因此接下來只要在某個想被測試的 script file中,
設定上面提到的 InvernalsVisibltTo attribute
我自己測試都是在 namespace外側設定該 attribute, 如下所示
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("Assembly-CSharp-Editor")]
namespace MYWORK
{ ... }
如此做後, Assembly-CSharp-Editor.dll 中所有 scripts
都可以看到 Assembly-CSharp.dll裡面所有的 internal內容,
至於 private/protected內容的話則可以透過 Reflection手段取得
之後我有深入玩過的話再另外分享一篇吧
我知道這招很髒, 不過偷懶嘛, 只是為了先求快
之後真的要實現完整的 unit test, scripting結構重構還是逃不了的
就一直想要在自己的專案中實現 unit test實作
但礙於時間不夠充足之類的前提讓我一直沒有動工
最近工作上的專案算是比較有空下來的時間
所以針對 Unity 官方提出的 test環境進行一番研究與探索
算是準備的差不多可以執行自己的 test programming了吧
當然也歸功於 Unity官方準備的開發環境與說明文件真的很方便
所以感覺要實現 TDD概念開發這點也不是那麼難了
幾個關鍵可先參考官方文件
Unity Test Runner
https://docs.unity3d.com/Manual/testing-editortestsrunner.html
https://docs.unity3d.com/Manual/PlaymodeTestFramework.html
這份則是比較舊版的官方中文翻譯文件
https://docs.unity3d.com/Manual/PlaymodeTestFramework.html
基本上簡易的unit test script可說是無痛實現
照著官方說明操作就可以建好完整的 test環境
但事情總是不會只有這麼簡單
像我目前的專案經過長期粗暴醜陋的"封裝"
我想進行測試的大部分內容已經牽涉到 internal / private / protected封裝
所以在 [Test]函式中是無法存取到該內容的
這一點算是老問題了, 所以 .NET官方早有解法
[assembly: InternalsVisibleTo(“UnitTests”)]
http://anthonygiretti.com/2018/06/27/how-to-unit-test-internal-classes-in-net-core-applications/
但在 Unity Test Runner環境下要如何實現這一點呢?
我首先必須把 assembly正確區分出來, 這個屬性才能派上用法
因此查過官方文件後, 我該做的就是針對所有 scripts設定正確的 assembly definition asset
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
好啦, 問題來了, 誠如官方文件所說, 如下圖

手動設定的 assembly (.dll)都無法參考到預設的 Assembly-CSharp.dll
因此如果我想要為專案正確設定 assembly definitions,
等於要將整個專案所有的 scripts做一次完整重構了吧
是說這一步驟也是該做, 只是當初一開始只想著輕鬆實現 unit test開發環境
沒想到還是得先經過大規模的重構才有可能完成有意義的 unit test
如上所述如果整個專案都正確區分成正確的 assemblies,
應該就會有個對應的 test assemblies (Tests.dll)去參考想測試的部分 (如 Main.dll, Stuff.dll, ...)
然後在 Tests.dll中實現 unit tests
當然總是還是有更偷懶的做法
準備一個 Editor資料夾, 在其中建立 test scripts
如此一來 test scripts便會被加入預設的 Assembly-CSharp-Editor.dll
因此整個專案仍然維持最原始單純的 Assembly-CSharp.dll 與 Assembly-CSharp-Editor.dll
因此接下來只要在某個想被測試的 script file中,
設定上面提到的 InvernalsVisibltTo attribute
我自己測試都是在 namespace外側設定該 attribute, 如下所示
[assembly: InternalsVisibleTo("Assembly-CSharp-Editor")]
namespace MYWORK
{ ... }
如此做後, Assembly-CSharp-Editor.dll 中所有 scripts
都可以看到 Assembly-CSharp.dll裡面所有的 internal內容,
至於 private/protected內容的話則可以透過 Reflection手段取得
之後我有深入玩過的話再另外分享一篇吧
我知道這招很髒, 不過偷懶嘛, 只是為了先求快
之後真的要實現完整的 unit test, scripting結構重構還是逃不了的
訂閱:
文章 (Atom)

