一直很喜歡《奧術》那種筆觸感強烈的風格化渲染,雖然懂部分原理但從未親自實踐,這次在專題組員的協助下總算有可見成果了。
前言
大家好!我們是 4a.m.就寢 ,是來自南臺多樂系的遊戲製作團隊。
今天要來分享我們在大二升三的暑假期間做的實驗專案《太空漂流》,主要目標是研究風格化的美術製程和渲染技術,為專題長期計劃的準備工作之一。
成果展示
先上成果,圖中所見都是由團隊成員製作的歐!
![image display error, please report: [/devlog/stust-project/research-project-1/result-1.gif]](/devlog/stust-project/research-project-1/result-1.gif)
左邊是 Unity 編輯器檢視,右邊是遊戲視角(gif)。
※團隊成員
成員一共有六人,工作分配如下:
-
小呈(筆者):企劃 / Planner&Designer、技術美術 / Technical Artist
-
Snoweve:程式 / Programmer
-
Avis Shih:概念美術 / Concept Artist(Art Director)
-
izumige:概念美術 / Concept Artist
-
YukiO3O:3D 美術 / 3D Artist、UI/UX Designer(Art Leader)
-
Natsu37:3D 美術 / 3D Artist
※團隊社群
這是我們的 FB 粉專,文章最後會再放一次連結:4a.m.就寢
團隊粉專目前還沒有任何東西,主要會配合後續計劃發文,如果對我們的後續發展感興趣,或想第一時間接收新資訊的話都歡迎追蹤噢!
注意事項
本文會簡單介紹遊戲機制、設計等基本資訊,並分享美術成員在過程繪製的作品與解釋相關技術原理。主要想跟大家分享團隊協作心得與踩雷紀錄,並用筆者個人名義宣傳團隊。
專案目前廢棄,主要原因是規模與後續計劃,文章末尾會再解釋。
以下正文!
專案介紹
《太空漂流》是一款太空x奇幻的劇情向放置手遊,故事講述的是一位迷失在太空中的孩子,他搭乘浮空島嶼在宇宙中漂流,將在與不同星球的交流中解開自身謎團。
![image display error, please report: [/devlog/stust-project/research-project-1/intro-reference.jpg]](/devlog/stust-project/research-project-1/intro-reference.jpg)
尋找的參考和用 AI 生成的示意圖,故事氛圍很大程度參考了《小王子》
選放置遊戲(Idle Game)是為了配合專題計劃,因為根據本系機制,我們三年級上下需要各製作一個指定題目的小專題。
而我們根據歷屆資訊猜測題目是「有内購功能的手機遊戲」,所以為了把重點放在美術研究上,我們決定選相對單純的放置類型製作。
遊戲機制
因為設計門檻的問題,我們選擇製作「非增量型」的放置手遊,簡單來說就是不把堆疊數值當核心,而是透過劇情與蒐集物品推動遊戲進程,類似遊戲《旅行青蛙》《天國旅立》
遊戲核心迴圈如下:
- 放置採集:資源會隨時間累積生長,玩家需要上線採集獲得基本貨幣。
- 放置探索:玩家需要決定探索地點並出發,並等待角色抵達地點觸發事件。
- 獲得物品:事件回報為資源或物品,玩家的目標是蒐集完一系列任務道具。
![image display error, please report: [/devlog/stust-project/research-project-1/intro-loop.jpg]](/devlog/stust-project/research-project-1/intro-loop.jpg)
但為了豐富度內容我又加了三大遊戲系統,主要圍繞探索與養成設計。
- 地圖系統:地圖會隨機出現可前往的地點,可能是主線、支線、隨機事件或交易地點。
- 事件系統:玩家抵達地點時觸發的互動事件、劇情演出等等。
- 布置裝扮:讓玩家改變小島布景和角色裝扮,會提供數值加成。
![image display error, please report: [/devlog/stust-project/research-project-1/intro-mechanism.jpg]](/devlog/stust-project/research-project-1/intro-mechanism.jpg)
發想時用 miro 拉的示意圖與畫面關聯性
雖然還有細節想分享,因為專案廢棄就不多介紹了,接著說故事概念吧!
劇情故事
劇情概念是組員 Avis Shih 提供的,我再進行細節填充,這裡也簡單介紹過。
![image display error, please report: [/devlog/stust-project/research-project-1/intro-story-history.jpg]](/devlog/stust-project/research-project-1/intro-story-history.jpg)
補完劇情設定的世界背景,示意圖,不用細看沒關係
宇宙中的一個高等文明因為看見「真相」而分裂,內戰不斷最終走向衰亡,部分遺族利用星際庇護島將後代送至宇宙邊緣避難。經過無數時光後,主角在宇宙一隅的小島上甦醒,此時新興種族已讓過去的遺址再次繁榮。
玩家扮演的「並非」主角,而是一個能控制小島的意識體,是來自異世界的協助者。玩家能控制小島的移動,但無法與主角互動,而主角則視小島的移動為命運,帶著自己漂流宇宙。
![image display error, please report: [/devlog/stust-project/research-project-1/intro-story-concept.jpg]](/devlog/stust-project/research-project-1/intro-story-concept.jpg)
組員 Avis Shih 在前期繪製的視覺圖
玩家的任務是帶領主角踏上歸鄉之路,並在途中見識宇宙的壯闊與豐富的文化,探索太空文明的遺址、與宏偉的宇宙生物相遇、與異種族交流互動、見識各種思維的衝突,並隨著經歷了解自身文明的歷史真相。
總之是個宏大旅程 :P
美術設計
接著分享美術在研究期間的成果,包括概念藝術、物件設計與 3D 模型,點擊圖片可以放大噢!
概念藝術
首先是概念美術,這裡是對遊戲風格的嘗試,由團隊藝術總監 Avis Shih 繪製,我們也會盡可能將其重現進遊戲,包括用色方式、筆觸效果等。
![image display error, please report: [/devlog/stust-project/research-project-1/art-concept-1.jpg]](/devlog/stust-project/research-project-1/art-concept-1.jpg)
組員 Avis Shih (Art Director) 繪製的遊戲風格概念圖
除了美感與風格,遊戲的功能性畫面也交給她繪製,下面這張是遊戲地圖介面的概念圖,玩家可以旋轉圓盤改變目的地。
![image display error, please report: [/devlog/stust-project/research-project-1/art-concept-2.jpg]](/devlog/stust-project/research-project-1/art-concept-2.jpg)
組員 Avis Shih (Art Director) 繪製的地圖畫面
以及供玩家採集基本資源的畫面,我們使用「星星」作為遊戲的貨幣,而採集工具是天文望遠鏡,畢竟這是一款超現實主義的遊戲。
![image display error, please report: [/devlog/stust-project/research-project-1/art-concept-3.jpg]](/devlog/stust-project/research-project-1/art-concept-3.jpg)
組員 Avis Shih (Art Director) 繪製的資源採集畫面
還有事件演出與特殊資源採集的畫面,這裡把所有圖再合併展示一次。
![image display error, please report: [/devlog/stust-project/research-project-1/art-concept-all.jpg]](/devlog/stust-project/research-project-1/art-concept-all.jpg)
組員 Avis Shih (Art Director) 繪製的概念圖總覽
物件設計
物件設計,指遊戲中會用到的物件,例如小島上的家具、可蒐集的道具或是可以探索的地點等,由 Izumige 與 Avis Shih 兩位美術一起進行。數量較多這裡就節錄部分展示。
![image display error, please report: [/devlog/stust-project/research-project-1/art-object-izum.jpg]](/devlog/stust-project/research-project-1/art-object-izum.jpg)
組員 Izumige 繪製的傢俱、道具、奇幻生物與星球
![image display error, please report: [/devlog/stust-project/research-project-1/art-object-avis.jpg]](/devlog/stust-project/research-project-1/art-object-avis.jpg)
組員 Avis Shih 繪製的道具、小島與功能傢俱
我們在這裡踩了很多雷,其中之一是美術設計的(初版)奇幻生物太可愛,與遊戲整體風格不符,以及部分功能型傢俱的樣貌與預期差異過大。
![image display error, please report: [/devlog/stust-project/research-project-1/art-object-cute.jpg]](/devlog/stust-project/research-project-1/art-object-cute.jpg)
第一版奇幻生物
問題主因還是我(企劃)的需求不夠明確,因為需求描述只有:「太空奇幻生物,可以參考深海生物如鯨魚、水母等,或將天體與天文現象擬人化。」而已,而世界觀的基礎設定也很模糊,只有說「奇幻」、「超現實」。
身為企劃,我得把想法表達的更清楚才行 D:
3D 建模
我們要做的是 3D 遊戲,有設計圖後還要建模與繪製貼圖,由美術組員 YukiO3O 與 Natsu37 負責。我挑了幾個物件讓他們做來實驗用,但因為拋棄式的就沒要求面數、佈線之類的規格。
首先是組員 Natsu37 製作的傢俱模型,包括星象盤、書櫃、桌子與天文望遠鏡,使用 Substance Painter 繪製 PBR 貼圖,並放進 Unity 渲染(預設材質)。
![image display error, please report: [/devlog/stust-project/research-project-1/art-object-natsu.jpg]](/devlog/stust-project/research-project-1/art-object-natsu.jpg)
組員 Natsu37 製作的傢俱物件
再來是組員 YukiO3O 製作的星球與小島,貼圖是用 Substance Designer 輔助製作的風格化筆觸圖,製作細節會在後面解釋。圖片同樣是在 Unity 渲染出的(預設材質)。
![image display error, please report: [/devlog/stust-project/research-project-1/art-object-yuki.jpg]](/devlog/stust-project/research-project-1/art-object-yuki.jpg)
組員 YukiO3O 的小島和星球物件
介面設計
這裡是沒有圖能放的篇章,因為我們在溝通上踩了很大的雷 D:
應該先畫出概念圖?還是先設計完 UI/UX?
我們的問題是,概念美術與介面設計是由不同組員負責的,兩位擅長的部份不太一樣,如果先畫概念圖可能缺少必要的介面資訊,但先設計介面又可能與概念美術想要的感覺對不上。
這個問題我在規劃時就苦惱過了,當初問組員以及前輩們的結論是…都可以,但我還是不知道該怎麼辦,所以沒特別處理,讓雙方同時進行,有問題再互相討論,最後才發現會互搶到職責、同時畫面也缺東漏西。
![image display error, please report: [/devlog/stust-project/research-project-1/art-ux.jpg]](/devlog/stust-project/research-project-1/art-ux.jpg)
組員 YukiO3O 繪製的功能地圖(Functional Map)
後來因為一些機緣與綺麗前輩約了面談,尋求建議時就把發生的狀況再具體敘述一次,而答案也是——都可以,無論介面或概念圖誰要先都沒差。
遊戲領域的 UI/UX 會被分開,因為 User Experience 涉及遊戲的體驗問題,而顯然體驗設計是企劃的責任 ,所以通常狀況是企劃處理完介面原型再讓美術直接繪製成品。
當時想說自己不了解 UI/UX 就全部交給組員做了,同時讓兩位美術同步畫圖,然後就出事了。交給組員也不是問題,真正的錯誤是我沒先跟組員討論…
![image display error, please report: [/devlog/stust-project/research-project-1/planner-mene.jpg]](/devlog/stust-project/research-project-1/planner-mene.jpg)
遊戲開發梗圖,出自台灣糾結
總之,最後組員們討論了下個專案要用的新流程:
- 企劃先給出功能地圖(Functional Map)後跟 UI/UX 討論,釐清想法。
- UI/UX 接手進一步整理並製作線框圖(Wireframe)的原型,並跟企劃、程式討論功能能否實行。
- 線框圖(Wireframe)設計完整後再讓概念美術參考,繪製出遊戲最終樣貌的預期。
- 最後 UI/UX 根據概念圖繪製更精細的 icon 結果。
![image display error, please report: [/devlog/stust-project/research-project-1/art-ux-flow.jpg]](/devlog/stust-project/research-project-1/art-ux-flow.jpg)
組員 YukiO3O 繪製的流程示意圖
學到教訓了,還好這次只是實驗性質的專案,至少踩過的雷不用再踩一次…痾…還是踩了…但至少踩的沒那麼大力。
技術美術
文章後半的壓軸就是技術美術(Technical Artist)部分啦,嘿對是後「半」部分噢 :P
避免大家忘記,這裡再插一次團隊社群的連結,對後續發展感興趣的話歡迎追蹤噢 >///<
Facebook: 4a.m.就寢
接著就比較技術向了,部分內容沒有先備知識可能無法看懂,篇幅問題這裡也不會逐一解釋,但我會適度插入一些註解補充,並多放圖讓內容看起來有趣一點。
製作時的參考資料也會提供噢,有相關知識的人要重現不是難事。
筆觸貼圖
我們主要的參考對象是《奧術》、《96 號公路》與《極樂迪斯科》這種筆觸鮮明的風格,但會更著重在整體氛圍的奇幻感。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-reference-1.jpg]](/devlog/stust-project/research-project-1/brush-reference-1.jpg)
引用自《奧術》、《96 號公路》與《極樂迪斯科》的視覺圖
原以為可以用 Shader 與數學搞定一切(因為我美術底子不好),但研究後發現還是得靠美術,終究是逃不過的。
總之,先下個過於簡略的結論:
物體的筆觸真的是用「筆刷」刷上去的,可以用 Photoshop 畫在貼圖上,或用 Substance Designer、blender 直接對模型繪製。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-1.jpg]](/devlog/stust-project/research-project-1/brush-explained-1.jpg)
其實就跟 2D 電繪一樣,很多質地效果都是靠特殊筆刷完成的,不過 3D 物件是繪製在表面貼圖上。
最好理解的是基本色(Base Color),畢竟是直接反應物體顏色的貼圖,所以只要用適當的筆刷繪製就能讓模型有筆觸感。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-1_1.jpg]](/devlog/stust-project/research-project-1/brush-explained-1_1.jpg)
但 3D 渲染會受到模本體形狀影響,物體表面與光源的角度會影響亮度,只有基本色會讓物體在受光時看起來很「平滑」,畢竟模型表面就是平滑的,如下圖左邊的範例。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-2.gif]](/devlog/stust-project/research-project-1/brush-explained-2.gif)
筆觸法線貼圖對比,左邊是沒有修改法線,右邊是修改過的(gif)
想讓光影與筆觸一致就要靠法線貼圖(Normal Map)把物體的表面朝向也畫成筆觸的樣子。這裡截出一張明顯的對比,可以看到兩者光影交界處的差異。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-2-2.jpg]](/devlog/stust-project/research-project-1/brush-explained-2-2.jpg)
筆觸法線貼圖對比,左邊是沒有修改法線,右邊是修改過的
嗯…
情況開始詭異了起來,「畫」法線貼圖聽上去不是什麼好點子,畢竟他儲存的不是真正意義上的顏色,而是表面朝向的向量資料,更別說常見的法線圖還一片藍,要怎麼畫?
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-3-1.jpg]](/devlog/stust-project/research-project-1/brush-explained-3-1.jpg)
專案中使用的法線貼圖
貼圖呈藍紫色是因為它儲存的是切線空間(Tangent Space)…總之與向量、數學和資料儲存方式有關,這裡就不展開解釋了。
但除了切線之外,還有另一種的法線儲存方式用的是物件空間(Object Space),看起來就不是一片藍,而是像彩虹一樣的漸層色,代表表面的各個方向。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-3-2.jpg]](/devlog/stust-project/research-project-1/brush-explained-3-2.jpg)
總之,想「畫」法線得從物件空間進行,筆觸就只是把漸層抹開而已,加上特殊筆刷就有更精緻的效果了。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-4.jpg]](/devlog/stust-project/research-project-1/brush-explained-4.jpg)
圖片引用自 Making 3D animation look painterly
修改法線後物體受光就會有筆觸效果,但麻煩的是筆觸走向要與基本色一致,否則兩者效果會不匹配。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-5.jpg]](/devlog/stust-project/research-project-1/brush-explained-5.jpg)
圖片引用自 Making 3D animation look painterly
雖然 Substance Painter 支援多貼圖繪製,但這還是相當折磨人。總之…做是能做到,但讓美術手刻所有東西顯然不明智。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-6.jpg]](/devlog/stust-project/research-project-1/brush-explained-6.jpg)
我們需要更有效率的做法,例如程序生成!
目前最主流工具是 Substance Designer 吧,但台灣好像沒什麼人提?我也是買對岸場景課的教學才知道的。
離題了,總之經過某些懶得描述的設置後,我使用 Tile Sampler Color 完成工作,能自動生出筆刷一致的貼圖。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-7.jpg]](/devlog/stust-project/research-project-1/brush-explained-7.jpg)
程序化減少了九成開銷,而且效果還不錯,UV 交界之類的缺陷再手修就好。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-result-1.gif]](/devlog/stust-project/research-project-1/brush-result-1.gif)
展示使用筆觸貼圖的猴子模型(gif)
總結,我們的製作流程大致如下:
- 建模、拆 UV、烘培 Object Space NormalMap、繪製 BaseColor
- Substance Designer 生成 NormalMap 筆觸和 BaseColor 筆觸
- Substance Painter 修正生成筆觸後產生的問題
- 烘培 Tangent Space NormalMap
- 放進引擎渲染
3D 美術們也根據製程將製作貼圖,下面是組員 YukiO3O 的作品。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-object-yuki.jpg]](/devlog/stust-project/research-project-1/brush-object-yuki.jpg)
以及組員 Natsu37 的作品。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-object-pjie.jpg]](/devlog/stust-project/research-project-1/brush-object-pjie.jpg)
實際應用的過程發現不少問題,這裡也分享我們的解決方式。
※問題1:物件角度過大
物件角度過大時生成的法線表現不理想,解決方法為手動繪製倒角,此修正由組員 YukiO3O 獨立完成。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-issue-1.jpg]](/devlog/stust-project/research-project-1/brush-issue-1.jpg)
※問題2:生成筆觸汙染
UV 太接近時,生成出的筆觸可能覆蓋到其他部分,修正方式是在 Substance Designer 添加 ID Mask 後合併。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-issue-2.jpg]](/devlog/stust-project/research-project-1/brush-issue-2.jpg)
※問題3:過於細小的物件
細長條物件的筆觸效果不理想,解決方式為手動繪製精細的筆觸,此修正由組員 YukiO3O 獨立完成。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-issue-3.jpg]](/devlog/stust-project/research-project-1/brush-issue-3.jpg)
下圖是由組員 YukiO3O 製作並完成多項修正後的小島物件。
![image display error, please report: [/devlog/stust-project/research-project-1/brush-result.gif]](/devlog/stust-project/research-project-1/brush-result.gif)
小島物件的引擎渲染圖(gif)
我們有一份製程的逐步教學文件,是由組員 YukiO3O(Art Leader) 學習後獨自編寫的,但屬於團隊資產就不公開了 :P
※參考資料
Making 3D animation look painterly
Painterly Blender Shader Technique You should know about
3d paintings in blender! My two cents on hand-painting normal maps.
Auto-Painterly look on 3D animation (Shockingly Easy!) Blender + krita tutorial
Paint on Normal Map: Painterly Texture Maya/Substance Painter
場景光照
模型做好就能進引擎佈置了,我用 AI 生了一些氛圍參考圖,讓組員 izumige 分析並繪製參考圖、提供拆解後的樣貌。
![image display error, please report: [/devlog/stust-project/research-project-1/scene-analysis.jpg]](/devlog/stust-project/research-project-1/scene-analysis.jpg)
雖然是技術美術,但本人的美感素養相對匱乏,需要讓美術組員分析後才知道實作方向。
※場景
剛開始只是把主體星球放進場景,然後用 Substance Designer 生成一張背景放在畫面後方,再拿一些星星貼圖點綴而已。
![image display error, please report: [/devlog/stust-project/research-project-1/scene-build-1.jpg]](/devlog/stust-project/research-project-1/scene-build-1.jpg)
※光照
但我發現預設材質效果不理想就用做了新的,主要是增加邊緣光(Rim Lighting)和減弱背光面亮度,除此之外還用 2D Sprite 加了背版光,並添加額外光源給小島。
![image display error, please report: [/devlog/stust-project/research-project-1/scene-build-2.jpg]](/devlog/stust-project/research-project-1/scene-build-2.jpg)
有試過陰影投影,但覺得效果不理想就放棄了。
![image display error, please report: [/devlog/stust-project/research-project-1/scene-shadow.jpg]](/devlog/stust-project/research-project-1/scene-shadow.jpg)
組員 Avis Shih 也根據當前畫面繪製了優化的參考圖,包括陰影差異、筆觸效果與氛圍混色等。
![image display error, please report: [/devlog/stust-project/research-project-1/scene-director.jpg]](/devlog/stust-project/research-project-1/scene-director.jpg)
氛圍混色
Avis Shih 繪製的參考圖有告示一些氛圍渲染用的混色,遊戲中最簡單的實現方式就是疊半透明,於是我給物體前後加了帶有筆觸的圖片。
![image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-effect.gif]](/devlog/stust-project/research-project-1/atmosphere-effect.gif)
開關氛圍混色的對比圖(gif)
2D 遊戲蠻常用這種方式堆疊場景氛圍,光影雲霧等等,而那些技巧也適用於固定視角的 3D 遊戲。
但混用可能會遇到圖片裁切的現象,需要用深度圖做交界淡出,是煙霧、火焰特效的常用技巧。
![image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-fade.jpg]](/devlog/stust-project/research-project-1/atmosphere-fade.jpg)
※圖層混合
透明度混合的問題是前景會吃掉背景色,導致畫面細節被弱化,為了解決我也嘗試了繪圖軟體中的圖層效果,例如柔光、加亮顏色等等,Shader Graph 有 Blend Node 可以直接完成計算。
![image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-blend-1.jpg]](/devlog/stust-project/research-project-1/atmosphere-blend-1.jpg)
問題在與螢幕顏色的混合上,片段著色器(Fragment Shader)無法像 Blend mode 可以用 Src, Dst 之類的關鍵字直接混背景色,需要先取得色彩緩衝區(Color Buffer)中的像素顏色才行。
雖然 URP 可以取得渲染完不透明物件後的畫面顏色(Opaque Texture),但無法像 Built-in 的 GrabPass 一樣取得「當前」的畫面顏色。
![image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-blend-2.jpg]](/devlog/stust-project/research-project-1/atmosphere-blend-2.jpg)
這就導致混色效果會把其他不透明渲染吃掉,而不同的混合效果重疊時也會互吃。
![image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-blend-3.jpg]](/devlog/stust-project/research-project-1/atmosphere-blend-3.jpg)
雖然可以自己寫 Render Pass 處理,但重複抓整個畫面的資料不是好主意,這可能也是 URP 拋棄 GrabPass 的原因?總之這條路可能不通我就沒繼續深入了。
植被濾鏡
毛茸茸的草地與花朵是風格化渲染的重要部分,我們主要參考 View Finder 中出現的油畫場景,經過一些分析後我得知他們是靠 Alpha Card 植被與濾鏡達成的效果。
![image display error, please report: [/devlog/stust-project/research-project-1/filter-reference.jpg]](/devlog/stust-project/research-project-1/filter-reference.jpg)
花草植被因為組員 YukiO3O 先做過就拿來用了,雖然這次是手動複製貼上的,但有用 GPU Instance Material 讓效能不至於炸裂。
![image display error, please report: [/devlog/stust-project/research-project-1/filter-grass-1.jpg]](/devlog/stust-project/research-project-1/filter-grass-1.jpg)
最麻煩的還是濾鏡,我真的看不出 View Finder 是怎麼算的,最後決定找現成的來用:Image Effects | Part 6 - Painting Joy,我只把他整合到 URP 中並做一些強度控制而已。
![image display error, please report: [/devlog/stust-project/research-project-1/filter-grass-2.gif]](/devlog/stust-project/research-project-1/filter-grass-2.gif)
為了展示效果有特別調高強度,看草會更明顯,雜訊是 gif 壓縮造成的(gif)
目前的效果差強人意,除了模型本身還有小島表面的貼圖要調整,我們也讓組員 Avis Shih 畫了後續方向的參考。
![image display error, please report: [/devlog/stust-project/research-project-1/filter-director.jpg]](/devlog/stust-project/research-project-1/filter-director.jpg)
雲霧粒子
星球設計圖有把雲畫出來,我首先想到的就是粒子效果。找教學做了簡單的風格化雲,用球體模型加頂點變形著色器做出雲,再用 Unity 粒子系統生成。
![image display error, please report: [/devlog/stust-project/research-project-1/cloud-particle.gif]](/devlog/stust-project/research-project-1/cloud-particle.gif)
雲粒子的展示(gif)
我還試過使用筆觸貼圖卡片,但效果不理想就沒深入了。
![image display error, please report: [/devlog/stust-project/research-project-1/cloud-brush.jpg]](/devlog/stust-project/research-project-1/cloud-brush.jpg)
※參考資料
Creating stylized clouds with Shader Graph and Shuriken in Unity3D
Ultimate Clouds with Shader Graph in Unity, Made Easy
體積透明
最終項目是半透明,與前面氛圍混色不同,這次是要給冰塊之類的物件使用。我想讓星球的冰柱在剔透的同時具有厚度,但一般的透明混合會讓物體看起來很薄,即使雙面渲染仍感覺是空心的。
![image display error, please report: [/devlog/stust-project/research-project-1/trans-default.jpg]](/devlog/stust-project/research-project-1/trans-default.jpg)
※深度體積
首先想到的就是根據物體「厚度」改變透明度,所以我嘗試用兩顆材質球(或兩個 pass)渲染物體的兩面,靠深度差計算出厚度。這個手段在渲染不透明物件(Opaque)中有效,但在透明物件(Transparent)上則會引發一些…奇怪的結果。
![image display error, please report: [/devlog/stust-project/research-project-1/trans-error.gif]](/devlog/stust-project/research-project-1/trans-error.gif)
詭異的顏色跳動問題(gif)
再試了幾種方法(如 ColorMask、VFACE)仍未果後我就放棄了,決定另找方案。
※菲涅耳體積
沒有真正的體積就只能偽造了,我想到的是菲涅耳透鏡(Fresnel effect)在球體上的漸層效果,只要反轉就跟厚度很像了。至於與其他物體的交集就用深度圖(Depth Buffer)計算即可。
![image display error, please report: [/devlog/stust-project/research-project-1/transparent-Fresnel.jpg]](/devlog/stust-project/research-project-1/transparent-Fresnel.jpg)
用菲涅耳計算體積的問題是只在球體上有效,不適用複雜結構,我花了幾個小時仍無果決的不該再花時間就放棄了…?也不算,因為我想通一件蠻重要的事。
既然效果只適用於球體,那就乖乖用球體,因為星球的透明效果也不是必需的,不如為現有的成果另尋用途,例如用額外的球體包裹星球,利用透明度做出冰層、大氣或濃霧的效果。
![image display error, please report: [/devlog/stust-project/research-project-1/transparent-atmosphere.jpg]](/devlog/stust-project/research-project-1/transparent-atmosphere.jpg)
即使研究目標沒達成,我們還是得到了意外收穫。
![image display error, please report: [/devlog/stust-project/research-project-1/jappy-accidents.jpg]](/devlog/stust-project/research-project-1/jappy-accidents.jpg)
※參考資料
Models using transparent shader are overlapping themselves
Rendering Object Thickness/Volume with Two-Pass Shader
效能…
沒概念 (´・ω・`)
![image display error, please report: [/devlog/stust-project/research-project-1/performance-idk.jpg]](/devlog/stust-project/research-project-1/performance-idk.jpg)
說來慚愧,我對效能和優化是相當不熟悉,因為自身還沒什麼實踐技美知識的經驗,所以也沒遇過真正的要解決的效能問題。有時間可能碰碰 Memory profiler 吧,但除非效能問題超嚴重,不然專題也沒什麼優化需求。
成果總結
總結暑假三個月的成果就是開頭展示的圖片!
![image display error, please report: [/devlog/stust-project/research-project-1/result-1.gif]](/devlog/stust-project/research-project-1/result-1.gif)
搭啦~最終成果畫面(gif)
這次研究核心還是在貼圖製程上,也把過程的畫面跌代排列給大家看:
![image display error, please report: [/devlog/stust-project/research-project-1/result-Iterate.jpg]](/devlog/stust-project/research-project-1/result-Iterate.jpg)
心得感想
自己從遊戲程式起家的,從高中自學到現在也花了不少時間在程式上,但專題會逐漸轉向企劃、專案管理和技術美術,基本等於踏入新的領域了。
最後再盤點一次期間的收穫!
※企劃
發想機制、遊戲設計、系統企劃,我在企劃時也向前輩們尋求了不少建議,最後在第四版補上時間預估、人力分配、設計策略等等內容。
![image display error, please report: [/devlog/stust-project/research-project-1/end-planning.jpg]](/devlog/stust-project/research-project-1/end-planning.jpg)
系統企劃中的某些清單
這是我首次在實作前想那麼遠,不然以前有想法就直接開始寫程式了,但也是試過才知道弄清楚自己的想法有多困難,很多自以為清楚的東西寫出來才知道是模糊的。
雖然企劃書還有很多缺陷,但也不能一直寫下去,畢竟暑假的首個月都花在相同工作上了。
除此之外,暑假時間我也報了夢想方舟(CGArk)的課程,是由雷亞總監 Tony 大大主講的企劃入門課《遊戲企劃思維:從創意到現實》,學了更多企劃應有的思考方式和知識,企劃職位、產業蓋覽、遊戲循環、敘事、美學到最後的行銷和創業都有,受益良多。
![image display error, please report: [/devlog/stust-project/research-project-1/end-cgark.jpg]](/devlog/stust-project/research-project-1/end-cgark.jpg)
在 CGArk 那裡拍的照片
※程式
這裡也補充一下程式組員 Snoweve 的工作內容。
由於專案的研究性質,規劃時我把重點放在學習上,所以程式部分比較多讓他接觸 Google Apps Script、SQLite、Zenject 與乾淨架構這些超出學校範圍的知識,所以正文才沒提及程式工作。
對程式工作內容感到好奇的人可以到他的巴哈姆特小屋(snoweve99183 的小屋)觀看噢,後續也會進行一些開發日誌更新。
而對我來說,則是要克服想做習慣工作的慾望。
畢竟程式職位已經交給組員了,得把時間花在只有我能做的事上,幫助隊友要透過調整設計、寫清楚文件與降低溝通成本之類的方式,從企劃層面降低其他人的工作量。
※專案管理
我們是用 Trello 分配工作、Miro 發想和 Notion 留存文件,而 PM 的內容就是考慮工作項目、時間安排、進度規劃和分配組員工作,並確保阻塞不會發生。
![image display error, please report: [/devlog/stust-project/research-project-1/end-pm.jpg]](/devlog/stust-project/research-project-1/end-pm.jpg)
專案用的 Trello 與 Miro 截圖
這方面的知識又更難找了,主要是邊做邊學,然後靠網路資訊和前輩的建議修正方向。
我們也用了 git 做版本控管,這也是第一次特別做分支管理,不然自己做都嘛全推到 main。有分支就能同步讓程式開發功能、技美研究與美術更新素材了,不怕動不動遇到衝突。
![image display error, please report: [/devlog/stust-project/research-project-1/end-git.jpg]](/devlog/stust-project/research-project-1/end-git.jpg)
分支示意圖與版控工具 fork 截圖
※技術美術
最後就是技美相關,正文講完了硬知識,這裡分享一些軟知識收穫,主要是思考方式的變化。
先前個人在學都是遇到某個有趣項目就不計代價的深入,嘗試解決難題或完成某些很酷的成果,但這次身為團隊技美、企劃、專案管理,新的身份讓我考慮更多現實的問題,例如時間。
所以要先思考「該花多少時間研究技術方案?」
畢竟真的沒必要重複造輪子,要克制住追根究底的好奇心,研究出次優方案就收手,有現成解方就用,有插件能解決就買。
有時也要質疑某些問題「真的有必要解決嗎?」或「真的有這種需求嗎?」
很多時候也沒必要執著於原本的目標,方案有缺陷也沒關係,因為「需求能改」,技術缺陷可以用設計彌補,而且失敗品也不用拋棄,可以另尋用途,就像正文提到的透明效果,畢竟所有資源都很珍貴。
之前就在專案或工作中用過 Shader 知識,但從這次經驗後我才認為自己開始接觸到技美這項「職位」,主要是思考方式上的成長。
而它的範圍之廣,這次的工作也只是偏向 Shader 與 Workflow 的一小部分,希望專題過程能逐漸把技能樹點開。
![image display error, please report: [/devlog/stust-project/research-project-1/end-ta-skills.jpg]](/devlog/stust-project/research-project-1/end-ta-skills.jpg)
圖片引用自 Technical Artist Job: How To Prepare, What To Expect
總之技美真的是很酷的職位 :D
後續計劃
《太空漂流》目前處於廢棄狀態,原因是規模過大,這也是前輩們看過企劃後的普遍觀點,複數系統加宏大的敘事野心都不是專題數月内能完成的規模。
拋棄成果很可惜,但原先目的就是學習與研究,這只是專題計劃中的第一步而已,重要的是所有知識與技術都能被帶到後續專案中。
新專案會配合學校進度執行,名稱暫定《太空生態球》。
這次會縮減規模並讓機制簡單許多,我們沒打算深入新專案的遊戲玩法,而是要把重點放在團隊磨合與熟悉開發流程上,畢竟學習仍是三年級專題的首要目標。
![image display error, please report: [/devlog/stust-project/research-project-1/end-next.jpg]](/devlog/stust-project/research-project-1/end-next.jpg)
土炮出的引擎示意圖與 Miro 發想截圖
至於最終會做到什麼程度?我不確定 :P
理想情況當然是做出能完整展示內容的 Demo,但也不強求,敬請期待之後的分享文章 :D
※社群經營
社群方面,我們會在官方帳號釋出專案的穩定成果,而過程中的零碎進度則透過成員的個人身份分享。最後再放一次粉專連結,歡迎各位點讚追蹤!
Facebook:4a.m.就寢
![image display error, please report: [/devlog/stust-project/research-project-1/end-facebook.jpg]](/devlog/stust-project/research-project-1/end-facebook.jpg)
特別感謝
感謝好友 ROB 以及 chiaoho、燈塔、shanzeng 與言靈幾位前輩提供的建議和回饋!
感謝走鹿前輩的企劃建議和接受我各種專案管理問題轟炸!
感謝綺麗前輩提供的各方面建議,包括企劃、專案管理、美術流程、UI 和概念圖、工作效率、時間評估、AI、專題建議和出路等等!
感謝 CGArk 和 Tony 大大開設的企劃入門課程!
感謝可靠的組員與閱讀到這裡的你 (´▽`ʃ♡ƪ)"