先說上次面試的結果沒上，度的。主要是因為要求遠距吧，但除非是很資深的人或已經有合作過，不然一開始就遠距還是有難度的，所以就先不考慮ㄌ
不過這是小事，報告一下而已，這篇的重點還是接下來遇到的，出乎意料的收穫。
另一封信前幾天我收到另一位前輩的來信，也是看到簡歷對我感興趣的業界前輩，說想和我聊聊，就約時間去找對方了 :D
這次就不是面試了，次比較像技術討論？雖然基本都是我聽對方解說各種東東，但光聽就賺爛了，得到一堆資訊。大概談了快一小時，比上次面試長一倍
![]()
一開始也是談我的近況、自學原因還有那份簡歷的內容，後面就是聽對方分享一些它研究過的技術，還有其他建議和走向之類的事，對方人好好
![]()
這次我是邊聽就邊筆記了，不然資訊太多我記不住，以下是最後整理出的筆記內容，順序不一定正確就是了
DOTS, ECS, Job System, compute shader簡歷裡有放我搞的 DOD 和 ECS 的那些東西，所以也和對方談到。ECS 的重點主要是在架構方法上，效能是其次，至於 DOTS 的主要效能優勢是在 Job System 做的並行。
雖然 Unity 的 ECS 很雷，但 job System 還是將對穩定的，可以放心用，所以之後我如果自己搞 ECS 還是可以搭配 Unity 提供的 job System 做並行。
還有講到 compute shader 的事情，我那時有說到是不是能用 compute shader 來做 ECS 的並行工作。答案是不適合，主要因為把資料從 CPU 和 GPU 傳遞資料的開銷不低，如果讓 compute shader 算完再傳回來的話會很慢 (CPU > GPU > CPU)
所以並行的話最好還是資料丟進去，算完後 compute buffer 給其他地方同樣是 GPU 的地方使用，像渲染或什麼的，能省下很大開銷
(CPU > GPU > GPU)會提到 compute shader 主要是我之前看到一篇戴森球計畫的文章，我誤會一些東西了。
DOD 的部份沒錯，但我以為它們是把物理資料傳進 compute shader 並行再拿出來做 Update 的，但應該不是。它們只是把動畫資訊傳進去，然後算完位移就直接渲染，所以還是 CPU > GPU > GPU，沒有回傳開銷。
這樣的話物理應該還是用 Job System 去算的？文章沒說到這裡，不知道它們什麼時候打算寫文章後篇 D:
參考文章
游戏性能优化（前篇）
GPU 視錐裁剪
說到 compute shader，對方也介紹了他研究的其中一個東西，草繪製，可以用筆刷刷出一堆草，物件多到只能用畫的。
我原本以為是透過左上角那張 Texture，然後 compute shader 生成頂點畫出草的。後來問才搞清楚，他是先用 GPU instance 生成一堆草，然後 compute shader 做視錐裁剪，至於那張 Texture 只是 visible map 而已，用來判斷要不要把那裡的草渲染出來。
超酷，之後我也要來研究看看
![]()
GPU 和 CPU 傳遞資料的問題GPU 和 CPU 之間的資料傳遞開銷不低，為了將低開銷通成有兩種作法，Batch 和 GPU instance。
Batch 是將大量的物件合併成一個 mesh，然後一口氣傳入 GPU，Bath 的優化點是降低資料傳遞的「次數」。
GPU instance 則是重複使用相同資料，如果要繪製相同的物件，只需要傳入一筆頂點資訊就好，繪製在不同位置就只是不同矩陣資料而已，優化點是
降低資料傳遞的「資料量」。
光照技術渲染管線做到最後都是指向光照的，但 Unity 的光照計算是以物件為單位做剃除，這樣會導致光線只不過摸到物件邊邊，也會在大量的像素做無意義運算。尤其遊戲場景本來光源就是東一盞西一盞的，會浪費掉太多成本。
更理想的方法是
將光照剃除的精度提高到像素等級，這樣的話會省下很多成本，能夠讓場景支援上千盞燈光。關鍵字 forward plus 應該可以查到資料
Unity SRP 和 unreal engine
Unity 的預設管線是 camera base 的渲染，這其實做的不是很好。正常渲染應該要是 target base 的，重點在輸出的位置，而 camera 只不過是矩陣資料而已。
（對方是說的，我大概能知道意思，但可能要等開始摸 SRP 才會真的了解吧）
現在 Unity SRP 就改成 target base 的，要自訂管線也更容易。不過其實在 SRP 出來以前能達到接近效果的手段的樣子，得到一個超棒的資源 >
CustomSRP
unreal 雖然也是開源，但它們的架構對修改渲染管線很不友好，不動到非常底層很難達成，而且易遇到版本問題。
unity 就做的比較好，SRP 提供了很方便的自訂管線，而且不用擔心版本問題，要修改管線也很方便。
對方也說到我的那個距離場齒輪也算一種渲染管線，只不過是渲染單一物件的。但遊戲中不會只有一個物件，所以重點就是如何處理多種物件，整合和規劃渲染流程。
![]()
學習方向往圖形技術深入的話主要有兩種方向。
第一就走深入，往單一演算法讀很深，追逐效能極致或研發新技術的，通常這種就是走遊戲引擎開發。
第二是走整合，
把各種功能整起來，客製化渲染管線的，通常是走遊戲開發，我應該是會往這走的，畢竟我想做遊戲
![]()
Shader 相關的職位主要就是
TA (Technical Artist)，但正常國外會分成
Technical Artist 或
Graphics Programmer
Graphics Programmer 比較重遊戲中渲染管線相關的技術，而 Technical Artist 才是提供美術輔助的技術人員。導進來臺灣這邊之後可能因為省人事成本吧...一個當兩個用，不愧是過勞島 D:
這樣聽起來 Graphics Programmer 應該更符合我的目標才對。一般的公司裡 Graphics Programmer 會是職缺相較少，主要是也不需要那麼多人，比例的問題。
除非是做引擎的公司，不然一般遊戲公司可能一個專案就配一兩位而已。但因為這方面的要求會非常客製化，所以薪水一樣是很可觀的那種，就算老牌公司也會出高薪找人。
數學，傅立葉轉換的水面稍微提到的，能夠在移動設備上穩定運行的水體
![]()
還有聊到尋路 AI對方做的尋路系統，用 recast navmesh 函式庫提供的功能去做。
那時我有說到是不是拆成網格，不過網格會遇到交界邊緣不精確的問題。就算用四叉樹也一樣，本質還是網格，只不過拆的更小。它那時有給我看其他作法，雖然也是網格，但會在交界處拆成更細的 mesh。
程式分工
每間公司的分法不同，但大致上有兩種分法，從完整系統去分和從程式概念去分。
從完整系統去分的話，可能一個人或團隊負責把這個系統做到底，包括核心機制、界面、伺服器、網路連線這些。
至於程式概念的話就是把邏輯、視覺、資料庫拆開來分工的這種，可能某個人負責所有UI，某個人負責所有資料庫相關的內容。
遠端作業
我也有問到遠端作業的問題，對方說到它們疫情嚴重的時候有遠端過，但效率不理想。主要是公司專案庫和網路是不對外的，所以在家辦公權限什麼的會很麻煩，如果解決這個問題會好很多。
至於溝通上就是會每隔一段時間開會而已，其他部份的話可能看團隊開發模式，大致上有敏捷式開發、瀑布式開發或任務式開發幾種。任務式就是一個分成一個個小組，專注達成某像作業，任務式好像更適合遠端？
這部份我還沒細查，不過有關鍵字就行了，之後去找資料讀讀看。
話說好像還有一種叫做隕石式開發的樣子
---
談話的內容大致是這樣，希望沒有漏掉什麼重要的東西。我盡量筆記了，這一個小時的資訊量真的多到爆炸。然後對方也有在寫技術日誌，雖然是公開的，但我不確定對方會不會介意我放連結，所以就沒放了。
至於工作的事他有問過它們的人事了，主要卡到大學和兵役的問題，以我的狀況會不方便收，所以先不考慮。能理解，畢竟我自己也不是真的打算長期工作...窩想讀大學拉 QAQ
也有和對方聊到大學的事，對方說對我會失敗蠻意外ㄉ，果然學校的觀點還是和公司不同。我自己是知道原因拉，百川畢竟要跟其他領域的人搶，阿資工就...沒競賽成績。
我也不會後悔啦，畢竟這才是我的目標...但還是很幹就是了，花那麼多時間自學技術，結果升個學搞到連備案都不知道有沒有效。
![]()
算了越說越難過，聊點別的
我好喜歡走路噢我發現我蠻喜歡走路的，但不是趕路的走路，是超級慢、用最輕鬆的腳步慢慢走。這兩次出門我捷運都故意搭到離目的有段距離的位置，然後慢慢走過去。我時間也抓的蠻充裕的，所以能放心走，大概走了半個小時吧。
上衣裡面穿件發熱衣，最外面再套層擋風的薄外套，衣服不會厚到感覺太重，也保暖到不會感覺冷，冬天這樣走在外面有夠舒服的，真是奢侈阿
![]()
但前提還是有要人行道能走拉，不過我都走在主幹道上，所以旁邊人行道蠻寬的能放心走。
對的，
先進國家該有的寬敞人行道，不用擔心離道路太近，被違停或障礙物擋住，給人走的人行道。放個沿途上拍到的巨大飲料架。
![]()
另一篇文前陣子想起我初學程式時做過的趣東西，有蠻多內容可以寫的，應該會掛達人
![]()
![]()
內容完成差不多了，但我還想寫更豐富一點，所以預計預計下週或下下週才會發，開天窗，等我甚麼時候完成就甚麼時候發ㄅ :P
敬請期待~
至於 2021 回顧和新年文章什麼的，都等我事情告一段落在說吧
![]()
就醬，愛你們
創作內容
【閒聊】不是面試，但比面試更棒
--- 重點文章 --- (0)
