製遊: 2019

2019年12月4日星期三

(完) PhysicsRaycaster + RenderTexture camera

繼續前面的筆記

https://riveragamer.blogspot.com/2019/12/unity-render-to-rendertexture.html
https://riveragamer.blogspot.com/2019/12/render-to-rendertexture.html

在網路社群上發問, 經別人提點後
想起一開始需求其實是跟分割畫面比較有關係
所以根本不用搞這麼複雜
就算是在 LWRP 流程中多個 camera viewport 不重疊就可以順利進行分割畫面繪圖

但所謂頭都洗下去了
forum 文章, source codes 也爬了(一些些 ....
就改寫了一個自己的 RTPhysicsRaycaster class (繼承 PhysicsRaycaster)
原理其實很簡單
只是將計算 raycast 用途的 ray 從 Camera.ScreenPointToRay() 改採用 Camera.ViewportPointToRay() 而已
https://github.com/riveranb/UnityRTEvents/blob/master/Assets/RTPhysicsRaycaster.cs

目前這樣改之後, 所有 EventSystem發出的事件在 off-screen rendering情況下都可以正確接收/處理了

2019年12月2日星期一

(續) render to RenderTexture 下的事件

上一篇筆記中
為了嘗試在同時使用到多個 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 ...

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.
不確定是不是自己有哪部分搞錯了
只能繼續爬文查資料

2019年10月6日星期日

[Unknown] #1 Base1 level 更新

繼上次筆記後這 2 周來好像只摸不到半天的時間
能空出來做自己私事的時間實在太少了
真的讓我常有想要乾脆辭掉所有工作
不想負任何責任
只想開開心心的專注於自己喜歡的事業

總之地下室 (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 排除.

非常有用的資訊.

2019年9月24日星期二

[Unknown] #0: 首次筆記

老樣子, 一直以來沒有時間做自己想做的遊戲

我也不知道現在算不算開始動了

總之最近開始練習 Probuilder, 打算先把 prototype level 做出來

初次更新

我想做的是有地面也有坑洞用來放置立體機械裝置

比如說機械車位系統

希望未來能持續投入時間

加油一下吧

2019年5月13日星期一

Next step

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

好啦, 問題來了, 誠如官方文件所說, 如下圖
Predefined versus manually defined assemblies

Predefined versus manually defined assemblies

手動設定的 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結構重構還是逃不了的

2019年4月12日星期五

繼續, processing..., waiting...

閱讀, 練功, 發想, 遊戲開發?...
目前還是一直在無限循環

這次在看這個系列主要還是以 Unity底層技術為主的技術文章

http://geekfaner.com/unity/index.html

雖然部落格作者本身做了很多佛心的心得分享
但主要以他本身研讀 Unity相關的底層文件/coding經驗為主
所以在沒有經自實作相關技術前, 閱讀這類文件的幫助有限

一系列文章探討著 Unity如何實現
Physics Based Shading,
Standard Shader,
Command Buffer,
Scriptable Render Pipeline,
Post Processing Stack 等

系列快要看完了, 但還是必須找時間親自研究實作出來,
才算是把技術學起來, 練功成功

雖然一件自己的 indie案子都還沒開始但 keep going.

2019年2月16日星期六

無方向

寫一堆心得, 是當成個版周記了逆

ㄟ....這本來就是我的個版厚

這兩周....不對....這兩年(這8-10年)來還是持續一成不變的作息

滿腦子想著我該做點什麼遊戲了

但完全想不到可以做什麼題材? 或該從哪些點子開始動手出發

然後還是不停的在挑以前累積看不完的學習筆記

有時當作學新知識/技術, 有時想把以前挑戰失敗的技術重新看懂/練習

反正時間還是都花在閱讀上了, 連真正動手練習的次數都超少

從開始想認真開始 indie develop計畫時, 真的會有種我到底都在幹嘛的心情

突然可以理解到前幾個月前同事勇敢想跳進 indie坑的時候

跟我聊到每天都不知道在幹嘛的那種空虛恐懼感覺

.
.
.

嗯....還真的只有這些, 我連該寫些什麼都想不太到

最近還是重覆花時間看 computer graphics pipeline / Unity engine底層相關技術文獻

(不過其實也花了幾周認真把 Bloodborne破完一輪就是了)

只是這些跟真的要開始動手都還是兩回事

所以我到底現在要寫什麼?

大概只是想表達我還在猶豫我應該先開始動手做哪件事吧..

2019年1月27日星期日

2019 indie計畫思考(反省

最近兩周剛花點時間想去研究(玩)一下 nVidia hair work (integration for Unity)
參考 https://lab.uwa4d.com/lab/5b6657ebd7f10a201ffb0359?fbclid=IwAR3P8rgfkZALrf3mw3lq7PBfXIu5w8GKn5qcAjEIby51NMtpoyr-cavEFXI

但花點時間裝好 unitypackage後才發現其實裡面沒什麼 source資訊
真的 source codes/manual 都還是在 nVidia developer官網那 (nVidia HairWorks 1.1.1)

在還沒花時間深入研究完整的 source codes之前
我是無法理解 nVidia提出的高品質 hair shaders如何實作, 甚至如何使用的

以我自己的現況, 靠自己目前僅能達成低品質的 fur shaders
就算我本來認為在不追求高畫質為前提之下
我還有建模型和動作素材這些問題待克服
只能說在完全沒計畫前想像的開發方向真的蠻天真的

現在呢........我是不是該認真思考一下
我真的要自己去學 blender學建模與動作
還是想辦法買適合的美術素材來繼續測試自己想做的 prototype cores

或是........我該挑一個完全可以先跳過美術素材的題材
先試試身手完成一款小遊戲呢? 但題材可能要重新想過吧.....

至少今年該先好好思考這個問題

訂閱：文章 (Atom)

2019年12月4日 星期三

2019年12月2日 星期一

2019年12月1日 星期日

2019年10月6日 星期日

2019年9月28日 星期六

2019年9月24日 星期二

2019年5月13日 星期一

2019年5月7日 星期二

2019年4月12日 星期五

2019年2月16日 星期六

2019年1月27日 星期日