正文

本篇主要是解釋在2D系統下，實現紙娃娃系統的方式，希望有興趣或高手可以來指導討論。

首先，就我所知紙娃娃系統有兩種方式實踐：

1. 利用Spritesheet的疊合，有一個沒穿衣服沒頭髮的基礎Spritesheet，然後疊上同等大小Spritesheet的頭髮、眼睛、衣服、武器，就可以達成紙娃娃系統的實踐。
2. 利用3D技術概念，模組根據骨架來做旋轉的方式。而在2D中，則需要美術有使用過2D骨架的使用經驗，若使用的軟體有支援引擎，甚至可以在遊戲中控制骨架選轉擺出各種Pose。

根據程式的能力Dowen當然是選用第二種…，不對是第一種方法，因為網路上沒有找到有套用2D骨架的素材，而且就算有，也未必該骨架有支援引擎的插件，

這邊就來推薦幾個2D骨架軟體：

1. Spriter，一款有免費與付費的2D骨架軟體，其實這款沒用過，不過評價不錯。
2. Dragonbones，這款是中國開發的2D骨架軟體，完全免費，而且擁有許多中文教學，所以滿推薦入門者的。
3. Spine，業界公認唯一最好的2D骨架軟體，這款只有試用版與付費版，而且支援的引擎相當之多，而且最重要的是，這款工具是使用Libgdx做的，所以學Libgdx不是完全沒好處的哦！(?)

至於你問為什麼不會畫畫還敢推薦，這個嘛，Dowen的推薦看看就好，因為開發時，觀察市場變化與評價，上面是Dowen得出幾個算社群大名聲大的軟體，可惜台灣會的美術好像不是很多。

成果

前言

本篇為無靈感開發的開發者，欲開發Rpg風格遊戲所留下的心得，簡單講述用非Rpgmaker開發類風格遊戲所需要的知識。其實只是又一胎死腹中的專案啊(汗。

正文

使用過Rpg製作大師的人都知道，製作Rpg風格遊戲(後文皆稱如此)，使用介面中各種方便的工具，配合第三方大師們的插件，就可以讓自己的遊戲越來越完美，並讓有邏輯的遊戲創作者利用其事件系統，就可以創造出一款基本的Rpg風格遊戲，而且MV版本還支援輸出手機的功能了！

但若不使用其強大的製作工具，又想開發類似風格，就必須要一些工具與知識來輔助。首先Dowen當然是使用Libgdx來進行開發。用來製作地圖使用的是Tiled。

Tiled網路上有各種教學資源就不多說，只是連結Libgdx時，會有些許困擾。首先最上方的圖應該注意到了，有各種樹、房子、柵欄，其實還有些帶編號的物件。如果直接將檔案匯入遊戲會發現，所有物件都像是一張圖，接下來這邊有兩個解決辦法：

1. 拉多邊形建立碰撞。 其好處是建立地圖時，就可以直接的與物理世界做結合，但缺點就是無法連結實體物件，像是一棵樹，想要同步移除幾乎是不可能的。

2. 建立虛擬的框格物件，使用客製編號，在程式中對應位置建立物件，其壞處是每個東西，樹、房子、柵欄，都必須要透過程式內部定義好，才可以根據虛擬框格對應位置，當然有幾百個物件就要定義幾百個藍圖。好處也是極端的多，畢竟進入程式，每個物件想擁有物理屬性，想搭配特效，想自己會動，擁有數不盡的好處。

身為一個程式，理所當然使用第二招，目前使用還算順暢，只是如果程式比例一開始沒訂製好，例如人物放大兩倍，那物理矩形全部都需要重新定義，也是最糟糕的一環。

建立好場景與各種物件後，來基本的物件移動，其中有兩個問題。

1. 物理移動需要進行調校。
2. 人物移動遇到障礙物處理。

第一個問題，參考物理的力與衝量就可以解決問題。

第二個問題又有很多解決方案，根據網路上觀察的Rpg風格遊戲，有幾種處理方式。
1.根據手指(滑鼠)指標直線移動
2.使用四方按鈕來代替移動
3.點擊位置，自動移動。

前兩個方案就不用說了，算是簡單的實作，第三個倒是需要技巧的問題，Dowen見過有Google Play上有遊戲的方式特別神奇，像是Dowen使用A* Pathfinding，而某遊戲，雖然不知道是使用何引擎，不過其使用偏1.與3.的混合方法，有點詭異但還滿順暢的。

最後提一下，由於二維沒有深度，所以角色被遮蔽的效果可以靠Y軸來達成，等等見到成果，就可以看到效果。

成果

基本上Prototype會遇到的問題，都提到了，就來看不才的Prototype吧！

# 由來

最近正在開發一款Tile為美術核心的遊戲，本來使用Tiled，將場景各個物件擺好後，再新增一個Object層，來擺放一些幾何的元素，讓Box2D進行碰撞。y在場景與碰撞都設定好後，剩下的人物則需要在Object層指定位置，額外在程式中產生。人物的額外產生不是問題，因為每個動作影格都是固定Size的，但場景物件支援可以拆除或新增就不同了，畢竟場景元素都是Tile組成，例如一棟房子可能會是各種Tile的集合體，更甚之，一個房子還會有其他招牌什麼的，這樣就會使房子變成許多層Tile的集合體，因此也沒有固定的碰撞區域或固定圖格。

# 截圖

撇開程式要處理多層級Tile不說，還有其物理碰撞。這篇主要是要介紹Dowen花了點小時間製作的TileRetriever，用處在於程式中製作物件時，可以輕鬆得知各個Tile分別在圖格座標系的$ (x, y) $位置，如下圖所示：

如果要產生一棟房子，勢必要知道各個Tile所在位置，像是得知如下格式:

    final int[] TILE = { // x,y ....
            33,0,34,0,34,0,34,0,34,0,35,0,
            33,1,34,1,34,1,34,1,34,1,35,1,
            33,2,34,2,34,2,34,2,34,2,35,2,
            1 ,4, 2,4, 4,4, 5,4, 6,4, 3,4,
            1 ,5, 2,5, 4,5, 5,5, 6,5, 3,5,
    };

就可以產生出最開始遊戲截圖中的房子(雖然還有些額外資訊要給)。

其實本來想找網路上有沒有相關檢視器，可以幫忙做這件事，但是搜尋好久無果，且Tiled只提供長寬資訊，所以就拿Javascript來打造一個囉！如果有人需要進階改版，請跟Dowen說一下，再開個 github 一起維護 :)

# 閒談

由於有看直播的習慣，對觀看的品質，有自己的一套講究，如果再觀看的時候有什麼覺得怪怪的，就會想盡自己所能把功能輔助寫出來，既然寫出來了，也想分享給有同樣需求的人使用囉！

# 插件

Twitch管理插件 - 特色:

1. 增大文字。
2. 亮色過濾。
3. 暱稱移除。
4. 刪除文字恢復(效能問題，預設關閉)。 備註:根據Twitch愛改版網頁的頻率，部分功能可能失效。

17網頁版音量插件 - 特色: 就...不知為何17故意把網頁版的音量條藏起來，我就加回來了。

# 安裝

0. 安裝Tampermonkey。
1. 開啟Tampermonkey。
2. 創建空腳本。
3. 複製插件.js內容，完全取代空腳本。
4. 重整頁面。
5. 看看有什麼變化吧。

歡迎任何人fork插件，讓插件更美好。

# 起源

老毛病了，總是想做個遊戲，也想了許多特色跟腦中的構想，但又突然被技術吸引過去，一個死工程師的概念，所以我決定一旦有什麼技術測試完成就立即撰下幾筆。

# 正文

在開始講正式的路徑搜尋前，可以先思考如果要自己發明的話，該如何實作。首先假設這裡有個$30x51$的網格，最左下是起點，右上是終點，然後沒有障礙物。用眼睛看最佳的路徑，一定是不走回頭路即可。

但當障礙物一多的時候，哪一條才是真正的最佳路徑呢?哦，抱歉，如果是想找最佳路徑，可能得按上一頁了，因為A*也不是找最佳路徑的演算法。

看上方這張圖，由於是用隨機產生演算法，可能會讓讀者覺得好走，但對電腦就不同了，給一個點跟目標，必須嘗試過往右往上，如果遇到障礙物過多，甚至還要回頭呢。

# A* Path finding(簡稱A*)

情境大概建立起來了，接下來就進入正式的演算法上。該演算法主要的參數有$f\left(G\right), f\left(H\right), f\left(F\right)$，G代表與上一步累加的距離，F代表G+H的總和可以說是一個總權重，那H就特別了，稱為啟發值(Heuristic)，而要每個人需根據自己需求，改變產生啟發值函式。不瞞讀者，Dowen用的只是數學的距離公式$\sqrt{\left(x_0 - x_1\right)^2 +\left(y_0 - y_1\right)^2}$當啟發值而已。
而演算法有些難說明，就搭配Wiki的Persudo-code來說明吧。 closedSet := {}，在每回合演算法執行(Loop)，最佳的節點就會被存在closedSet。 openSet := {start} 每回合都會加入根據上一回合演算的可能性，其實就是鄰居啦。 comeFrom 紀錄每個節點的最佳上一步，或說這個點最好的走法是從上個點來的。 gScore := map with default value of Infinity 會根據每回合算完後...等等會說到，既知道為何要無限大。 gScore[start] := 0 同上 fScore := map with default value of Infinity 同上。 fScore[start] := heuristic_cost_estimate(start, goal) 同上。 current := the node in openSet having the lowest fScore[] value 找當前最佳f值來當要走的下一步。 openSet.Remove(current) 剔除掉當前最佳節點，就不會再算一次。 closedSet.Add(current) 把算過的放進來。 if neighbor in closedSet 鄰居是算過的就跳過。 if neighbor not in openSet 鄰居不在待運算區，就放著等下回合算。 tentative_gScore := gScore[current] + dist_between(current, neighbor) g權重是由上一個節點和與上個節點的距離所算出來的，所以起始節點是0，右邊可能是1，下面可能是2，然後右邊的右邊從1+距離，下面的任一邊也是。 if tentative_gScore >= gScore[neighbor] 這裡避免覆蓋已有的最佳g值，由於可能被算過(在openSet內)，所以要確保不會覆蓋最佳值。 cameFrom[neighbor] := current 幫鄰居設定當前節點是最佳的來源節點。 gScore[neighbor] := tentative_gScore 覆寫或第一次寫入g值。 fScore[neighbor] := gScore[neighbor] + heuristic_cost_estimate(neighbor, goal) 只是個總權重值。 return failure 找不到任何路徑。

影片中，各種綠框框代表Box2D的靜態Body物件，必須寫個方法將物件映射到一個虛擬格子地圖上，之後才可使用。這影片中還有很多問題存在：

1. 村民碰撞矩形會導致虛擬地圖判斷可行走，實際不可的問題。
2. 若靜態物體為多邊形，則需要一個公式映射，並且會導致肉眼認為可行走，演算法不行的一致性問題。
3. A*演算法尚可經由許多調校，像是格子紀錄用更好的資料結構，Dowen用2D矩陣。還有啟發值產生函式，也還有其他可能性。

一些優化： A1. 也許將判斷不可行走的區域，設定為直直朝向，或是找到附近可行走區域後，在直直朝向，就可以解決Box2D世界與虛擬地圖的問題。 A2. 多邊形格子，如果要將多邊形映射完成，首先必須要了解其他演算法，不然就像Dowen一樣，自己限制城矩形吧(誤)。

# 資源

A* Pathfinding-1

A* Pathfinding-2

A* Pathfinding Wiki

Tile maps

# 前言?序章?

Libgdx是我目前最喜歡的遊戲開發引擎，或稱之為框架。它的厲害在於對跨平台的彈性很大，但我最喜歡說的一句話「優勢即是劣勢」，由於彈性很大，所以要磨合的地方就很多。譬如我第一個App，需要自行撰寫Android API，去理解各種Android版本所需的程式碼，現在本篇要展示Libgdx的一些知識技術，由於可選擇各種第三方插件與Libgdx相互融合，所需理解的就是許多的第三方與磨合知識。最後提一個唯一覺得是缺點的，Libgdx在撰寫UI上，藏有許多可怕的小細節，因此如果要使用Libgdx，就要跟這些細節搏鬥，好在是Open Source，底層是Lwjgl，所以就算有問題，自己創造亦是一條路！

# 學習?開發?

在讓UI有點醜，經過多次改版才把bug修到很少的第一個App告一段落後，本想開發一款遊戲，但是苦於找不到點子，所以就到各大論壇看一下找點子的方法。不外乎得到的是，出去晃晃、多觀察、多找人聊天啊之類的，最後我選擇了以實作把爛點子做個Prototype出來的方法，這個方法強調的是，做好一個Prototype後，才可慢慢增加元素，把遊戲裝飾得更加美好。這個方案我看了很滿意，因此就開始了Libgdx漫長的Prototype開發之旅。

人家說Prototype要在一兩週最多一個月內完成，由於不知道要做什麼，所以又跑去Itch.io，裡面找素材讓自己有做Prototype的靈感，買了些便宜的或看似不錯的素材後，萌生了一個Run game的想法。

在有素材後，憑藉著有前一款App的開發經歷，本以為可順利打造出一款遊戲，但是事實總是殘酷的，由於以下幾點

1. 沒有實際Prototype想法，或說沒有很明確要做Run game，那樣純粹的想法。
2. 遊戲開發上，總是考量到擴充性問題，所以把OO的觀念放一邊，學了遊戲最佳的架構概念(後面在提)。
3. 想玩遍所有Libgdx技術，所以玩了各種插件。
4. 想閱歷Libgdx先天們的經驗，東學西學，偷推廣啟蒙老師。
   
   

# 插件?選用?

Box2D，2D遊戲界頂頂有名的物理引擎，由於其**自己自足(Self-Contained)**的特性，且不用相容於任何UI，使其可以在C++、Java...任何語言之間游走。其善於物理碰撞偵測與碰撞過濾器，還有可調式物理參數，讓使用者不必太在意太深細節，而專注於遊戲開發。

小提一下，由於Box2D世界是屬於Meter，因此初學者滿容易不懂Meter與Pixel如何轉換的問題，這些相關概念，有時間(?)在發篇文吧。

Ashley，一個擁有大量共同編輯的開源ECS系統，何謂ECS，即是Entity Component System，遊戲界中極為重要的系統，以前見ThinMatrix寫3D引擎時有用到，當初若我開發3D引擎時有學到就方便多了。

簡單介紹何謂ECS，Entity代表任何單位，可以是攝影機、人物、場景...天地萬物，只要認為有意義皆可，至於何謂有意義，等了解System就懂了。Component代表元件，像是血量、位置、速度或狀態...等。System代表處理系統，不論是什麼Entity，只根據使用了特定Component(s)的Entity來做處理，因此才有RenderSystem、ParticleSystem，這樣使用特別的系統來處理特別的Entity們(Renderable Componet -> Render System, Particle Component -> Particle System)。

gdx-AI，這個最頭疼的傢伙，由於其文件糟糕程度，使得不是專門領域的人，難得其門而入，而且範例的概念，完全與Ashley背道而馳，因此為了使用gdx-AI，耗費時間甚鉅，學到的仍是皮毛，這裡就不提了，畢竟領悟不夠。

重要的三大插件都在上面，順便聊一些玩過的東西。

Overlap 2D，本來想用來當遊戲編輯器，但是由於其跨平台性似乎有缺陷，且使用上沒想像中好用，所以放棄了。

Tiled，一個很棒的圖塊專業編輯器，還佛心免費，讓我學習了馬力歐開發的好物，不過因為我腦中的Run game不偏圖塊，因此最後沒選擇使用它。

TexturePacker，不錯的材質包裝器，基礎功能算免費的，用來將分散的材質打包成TextureAtlas(其實應用Libgdx內建工具)，，旗下還有PhysicsEditor使用過還算不錯，但要收費，因此後來學習使用免費的Physics Body Editor，雖然有點麻煩，不過還算堪用。

2D Particle Editor，內建的特效產生器，學習資源足夠，是個好工具。

# 成果?

此篇文章，是因想把專案告一段落，等有時間在把專案弄得更完整。

####目前的成果大致如下:####

#####遊戲編輯器:#####

遊戲編輯器不需要太花俏，基本功能有即可，撰寫的時候，也有想像過如何做一個Platformer遊戲通用的編輯器，不過成本頗高，加上沒什麼想法，編輯器再好也是無用。不如談談裡面的技術，主要透過Json來管控各個遊戲元件與關卡，且將遊戲資源與關卡分成*.brpj與*.lvl兩種，一種連結相依遊戲素材，一種儲存遊戲識別器與位置，就可有個簡單的關卡編輯器，但想深入一點，對話編輯、特殊事件之類的尚無想法耦合，畢竟若每一關用一個Class來做，那好像又超過了，不過也許是多想了，畢竟遊戲是能完成才好，不是完美架構與多重測試的商業軟體。

#####視窗/手機/網頁:#####

視窗

手機

網頁

從做遊戲變成嘗試各種可能後，遊戲變成研究性質的東西，這邊就透露一些學到的技術吧！

1. ECS應用於畫面上的各種元件，繪製系統、平行背景系統、移動系統...等。
2. Gdxai應用於敵人的製作上，而且投入架構的緣故，把AI完全移植到一個工廠模式上，因此可將不同敵人套用不同AI，希望這模式到PathFinding或一些高深的技術時不會有問題(汗)。
3. Box2D用在各種碰撞，只是有tweak成One way walls，讓人物可以從平台下方穿越上方平台，雖然限制需要方形，但網路上還沒有完美多邊形解法。
4. Particle-2D，Libdx原生特效產生器，學會如何控制特效後放在綠瓢蟲屁股，其實好像沒什麼難的。
5. Lighting Shader，沒使用Box2DLight，好歹也是圖學出生的，就親自操刀，把3D光源技術的PointLight Shader搬到了遊戲中，不過若是做光源，Box2DLight已足夠用。若要做類似刺客教條的鷹眼特效，那就需要客製Shader。題外話，縱然主OpenGL，我仍是ShaderToy中的滄海一粟中的一個小細胞啊。

跨平台上，視窗版與Android版基本上沒有什麼太大問題，iOS雖沒裝置但應比不上網頁版困難，網頁版的輸出上由於GWT的關係與撰寫Shader，導致輸出各種錯誤，好在經過數十小時的努力下終於建構出網頁版，也因此知道為何PS4/PS3會出現PSP畫質遊戲了，因為某些裝置支援的繪製能力就是比較低弱，網頁就是跨平台中最低弱的輸出平台。

還有很多繁瑣的地方，畢竟不像Unity有方便的各種系統，不過引擎只是一種工具，這些總能渡過的。總之仍是推薦使用Libgdx開發2D啦！

# 最後的最後?

也許是因太投入在技術，忘了遊戲的感覺，也太久沒有玩到遊戲，都在打Overwatch(?)，所以完全沒有做遊戲的靈感，因此沒有達成做出遊戲上架Google Play的目標。

不過最近想到了一個新專案且與友人合作，如果有成，也許可以暫緩找工作的念頭，如果沒有就去找工作啦!

# 資源

給看到最後的人一點別的東西 Let's make an indie game專家，尤其AI與ECS融合部分。

Brent Aureli，就是想再提一次這位大神。

Learnopengl，我圖學的啟蒙網站。

ECS detail，詳細的ECS解釋。

Music/Sound-1，找音樂或音效嗎?到這裡吧。

Music/Sound-2，找音樂或音效嗎?到這裡吧。

Git最佳概念，相信我，學這套足以打下半邊天！

免費遊戲素材，雖然免費但要看懂一堆License，被這網站License轟炸後，現在略懂一點了。

ShaderToy，只是提出來讓自己覺得圖學能力還遠遠不夠的網站。

One way walls，多邊形單向平台解決方案。

###開發心得:### TabberClock是我第一個App，花了大概有四個月的時間完成，由於第一次決心要寫一個體面的Android App，所以這次卯足了勁，經過了無數的設計失敗，跟無數的波折，終於克服了Libgdx的環境難關，不過一般寫App的人可能不知道是什麼，簡單來說，我是用遊戲框架開發App，這樣聽起來好處是不是很多呢？錯，學習曲線很高之外，也增進了合作上的困難。硬要說適合就是幾個精英開發者，剛好喜歡或是有一些計算機圖學底子的人來開發，當然不用計算機圖學也是可以，只是如果有你會對框架原始碼各個環節感到很安心，因為都看得懂，又知道如何修改原始框架或擴充原始框架來達成自己的目的。

###For English User### This article is google-play-alternative to communicate directly with developer, If you have any suggestion/comments, feel free to talk below with Disqus. Any advice and suggestions will be greatly appreciated :)

###App介紹### 說說這個App的好處，當你打開鬧鐘軟體，自然的就是想要新增鬧鐘、刪除鬧鐘、找尋鬧鐘…，這些就會產生因人而異數量的鬧鈴。然而，當鬧鈴數量越多，想要提醒的事情越多，鬧鈴頁面自然就會越加凌亂，要從鬧鈴清單中找尋自己設定過或是已響鈴的鬧鈴，就會顯得支絀。舉個例子，假設你有設定工作相關的鬧鈴、休閒活動相關的鬧鈴、甚至女朋友相關的鬧鈴，那你就必須從一個鬧鈴清單中找尋哪幾條是什麼相關的鬧鈴，才可以修改、刪除、檢視相關鬧鈴，而我開發的App主要是加入了一點分類功能，讓使用者可以歸類不同種類的鬧鈴，讓畫面保持一定的整潔，根據研究顯示，保持整潔的畫面、輕易的找到自己想要的目標也是可以讓人心情舒爽的方式之一呢。

你可能會問，我如果有需要提醒的事，用行事曆App不就好了？但是，根據不同使用者需求，像是我總是只用鬧鈴來提醒重要的事情或是近的事情，不會用行事曆。此外功能完整的行事曆App，多半可供設定選項之多，對如我這般使用者來講，看得頭昏眼花不知道要看哪裡，倒也是行事曆的優點與缺點。當然可以怪罪這樣的使用者自己的毛很多，不過這就是**「一樣米養百樣人」**的真諦呀。

###本篇目的### 這篇主要目的是當此App的網路首頁，因此就不需要另開個網頁來進行App討論，也可以透過除了Google Play外的方式與開發者我直接聯繫。

App in google play:Tabber Clock Beta

開發引擎是我用來考驗自己的方式，學習、理解並實作以往學到的各種圖學概念，並用上自己對物件導向與程式語言的熟悉度，希望能完成一個基本的如場景建置、粒子效果、物理碰撞、模組動畫...等等的功能。而更甚之希望當OpenGL或圖學界中有什麼新功能，可以在自己最熟悉的環境中依照概念實作。

系統環境: Windows 10 開發軟體: Visual Studio 2015 硬體設備: i7-3770 and GTX960 核心接口: GLFW/GLEW/GLM/Assimp/SOIL2/Bullet Physics 輔助插件: Nshader for Visual Studio 2015/Glslify

####其他事項#### ** 2016/09/05 前的日誌乃日根據記憶回朔，09/05方開始打算紀錄。 **

# 2016/12/14

為了優化引擎，確保以後物件多到不行而Lag的問題，這次實踐了「Frustum Culling」。這是一個很常用且對優化來說非常實用的功能。假想我有兩萬個物件，螢幕中，從人物的角度看出去卻只有五百個物件，那如果每個都與OpenGL溝通，讓GPU判斷，會導致非常大量無謂的Draw Call，換言之就是減少溝通次數，從某些層面來看比減少面數的優化實用又輕鬆多了！

關於技術的部份，Frustum Culling是透過Projection Matrix與View Matrix來產生出一塊虛擬的可視區(或是相關輸入參數)，透過投影矩陣可以解析出一個基本可視區，而透過視野矩陣，可以使其反矩陣後得到旋轉與位移量。透視矩陣會解析出六個盤子(跟Narrowphase碰撞偵測類似，有興趣看參考Plane Math)，乘上反矩陣就會得到世界座標的可視區，最後的步驟是，根據自己每個物件的AABB來進行篩選。說是這樣，不過還是做了好幾天啊ORZ

最後附註，由於這樣的區域看不見，因此順便努力地實踐了相對的Graphics Debugger與旁觀者Camera，雖然不是什麼新技術，不過看得到對Debug還是很有幫助的。

這部分比較難看出任何效果，因為是到視窗外才會拋棄繪製，不過可以注意到的是畫面拉近到某個距離，角色就會被迅速拋棄，這樣比較細微變化。

# Reference:

View Frustum Culling Plane Math 1 Plane Math 2 Cross Product Calculator Anonymous Function in C++

# 2016/12/6

這次紀錄，要說的專有名詞與失敗的嘗試也是非常多，就先從我要導入引擎的技術開始說起了，這次要讓引擎能有Level Of Details的優化效果，也就是說越遠的物體，所畫面數減少，這樣可以降低GPU的負擔，進而提升效能(以前我是不信的)。

在開始前，想投過學術的方式達成這項功能，也就是載入物件後，自動進行簡化技術。舉例來說，自動為每一個物件做出簡化的三種模型，其實是想產生三種EBO物件。而欲使用的技術為Half-Edge Collapse，其技術基本上來說就是，將物件統整為Half-Edge Structure，這樣的好處是，可以輕易查詢哪個邊、點或面使用哪個邊、點或面，此外還可以查詢鄰近的邊點面，對以後如果有需要做模組網格即時查詢很有幫助。

學習與實作完Half-Edge Collaspe技術後，不是指標無法找尋到對應的邊(Opposite pair)，就是無法削減任何一面，因此又開始了一段痛苦的找問題之旅。

起初經過不斷測試，懷疑演算法不夠堅固或邏輯有誤，因此找上了專門網格的第三方函式庫「OpenMesh」，導入引擎雖然有些難處，不過經過很多次導入的磨練，這倒不成問題，但問題還是出現了，使用函式庫對網格簡化所提供的ModQuadric演算法，也無法消除任何一面，這樣的事情等同宣告問題出在資料來源。

詳細看過資料來源的時候，經過一些發問與深度查詢，才知道原來Assimp導入的資料是所謂的Non-Manifold網格，當然這是Assimp對OpenGL/DirectX的friendly支援。而這樣的支援出現了問題，無法建立出Adjacency Graph，就無法產生Half-edge structure，而如果自行實作物件讀取器，又無法多檔支援。至於為什麼Assimp的格式會這樣? 仔細想過，如果一個Vertex只支援多個Normal還有多個TexCoord(也許還有bone weight)，那寫讀取器的時候，到底是要怎麼讓Vertex擁有多個資料還要知道是哪個面的? Assimp就將點分為多個不同但同位置的點，然後讓一個Vertex只帶一組Normal和TexCoord。

想通箇中困難後，本來趨近於放棄實作Lod，但是靈機一動想到，改寫程式架構，使一個物件可以承載多個物件，就可以在適當的時候做切換。這樣的好處是，可以控制簡化後的模型，還有品質也是自己控制的。壞處是，必須先做好多種模型。因此這裡想到了一個很好的解，就是在Blender寫一個專門的lod格式的obj檔，然後寫一個專門的讀取器，可以讀一個物件帶多個EBO，那就解決了。不過壞處是，只支援obj檔。

# Problem And Slove

在自己實作期間遇到的問題與解決: Edge Collapse with Assimp Mesh Simplification with Assimp and OpenMesh

# Reference:

The Half-Edge Data Structure The Halfedge Data Structure Mesh Simplication 1 Mesh Simplication 2 Mesh Simplication 3 Mesh Simplication Code Mesh Decimation Framework by OpenMesh Halfedge and Mesh Simplication Explaination Halfedge and Mesh Simplication Issue Meshlab

# 2016/11/25

又一次革命性系統改革，將以前天真的架構砍了，又把原本碰撞系統各種關聯全部砍掉，為的就是引進新的物理系統**「Bullet Physics」**。透過天才所做的物理引擎，可以節省實作碰撞系統與物理模擬的各種難題與測試。當然換引擎的代價也是很大的，學習使用一個引擎除了要有豐厚的經驗才能搭建橋樑外，還有原本的架構擺好卻要大修改，此外還牽涉到讀檔與圖形暫存記憶體管理的部分，實在非常之多啊。

當然換新引擎不是沒有缺陷，這樣的引擎由於物理特性十足，有時候要模擬像是人物走路或者一些簡單動作的時候，在我之前粗鄙的引擎下十分容易且順暢，但是在成熟引擎擁有各種質量、摩擦力...的特性，所以為了表現如我想像，經過了很多調校，終於調整到看起來舒服的樣子，雖然還是有點小問題，不過都是等以後熟練後就能駕馭。

此外Graphic Debugger，在這段實作上仍佔十分重要的地位，當初未了解Bullet Physics，所以自行以挖資料的方式實作一個，但某天發現Bullet Physics竟然有提供這樣的介面！就花了幾天實作了出來，其中碰到記憶體管理問題，還會讓網頁或影片炸裂，差點害我以為顯卡被我玩壞了，不過也因為碰到這問題才知道VBO的管理是十分必要的，如果每次產生物件都不去理會暫存，那爆掉的那刻，影響的不只是程式，而是用到GPU的所有程式。

這邊就不列出到底改了什麼就簡單提點一下實作關鍵。

1. Debug模式下測試個位數的Bullet Physics物件，Release模式下測試大量物件，否則會Lag。
2. 架構最好不要多重繼承，雙重就已悲劇，不管如何都要使用介面或抽象方式。
3. 若要渲染多筆相似物件，可以考慮渲染前再存入Buffer，一次送給GPU，此非Instancing，不過也適用。
4. 動態物件必須要做Convex Reduction，否則物理引擎會受不了(?)
5. Bullet Physics的原點是質量原點，繪製原點則是:

$\begin{bmatrix} Origin_{visual}.x \\ Origin_{visual}.y \\ Origin_{visual}.z \\ \end{bmatrix} = \begin{bmatrix} Origin_{bullet}.x \\ Origin_{bullet}.y + Offset_{localspace} \times Scale_{entity} \\ Origin_{bullet}.z \\ \end{bmatrix}$

最後Release模式下，未開圖形除錯器:60fps，開了:35fps，差異是多繪製了幾十萬條線，也許以後需要其他方式優化。

# Problem And Slove

在自己實作期間遇到的問題與解決: Few rigidbody cause Bullet Physics slowly Debug mode or Release mode

# Reference:

btShapeHull vertex reduction utility Bullet Physics Tutorial Bullet Physics Collision Callback Character Movement in physics engine Sphere Vertices Generation 1 Sphere Vertices Generation 2 Bullet Physics Object Origin 1 Bullet Physics Object Origin 2 Collision Margin Technique 1 Collision Margin Technique 2 Graphic Debugger for old opengl example

# 2016/11/5

消失了將近一個月，其實是碰撞系統實在是太難實作。由於以為上一個部分的SAP Broad Phase Collision Detection 實作完畢且正確，導致我在這部分卡了個天荒地老，還好期間有接案來騙自己這段時間沒有白費(?)，不過經過這一番戰役，我確定打了個敗仗，當然收穫還是很多的。

首先這個月來實作的是Narrow Phase Collision Detection，光看Paper花了約一週詳細了解數學，但是發現其中的數學寫得並不完整，只給公式不講解由來的部分也有，所幸後面部分有附一些關鍵程式碼，還可以納入自己的系統中。Paper位於後方參考。

再來經由無數的失敗直到前幾天，才知道原來Broad Phase的部分，在AABB Box原來並不是想像中的那樣，當時不了解Graphics Debugger的精隨，現在終於懂一點了。這部分影片中會展示。

目前碰撞系統缺陷

1. 兩動態物體無法完美碰撞，因此拿掉此部分。
2. AABBbox 範圍不夠大，會導致Narrow Phase演算法判斷失敗。

經歷這場敗仗的收穫

1. Graphics Debugger很重要。
2. 不要過度Reinvent the wheel。
3. Broad Phase Collion Detection代表可能碰撞的物件。
4. Narrow Phase Collion Detection代表測試物件詳細碰撞表面並予以回應。

# Reference:

collision detection and response deeper article - dynamic bounding volume deeper article - octree

# 2016/10/09

研究了好幾天，看了Paper無數遍，終於完成了Sweep And Prune的碰撞系統!(其實是卡了作者講了一句我看不懂的話卡了好幾天，到現在仍是未知 .汗)，在碰撞物件排序上使用了Radix Sort，不過在碰撞物件不到過萬，Radix Sort根本耗時，因此換成Quick Sort。

# Subject: 基礎碰撞偵測系統

# Add:

1. 新增CollisionSystem，專門將Entity指標轉為碰撞專用Rigid指標。
2. 新增PropertyMaster，任何實作此介面者，可作為屬性大師(?)，目的是讓Entity物件以後需要各種屬性時使用，像是加上Rigid屬性，CollisionSystem便可從該實例中取出該屬性，注意的是PropertyMaster只能同類別(Property Type)只能擁有一個Property。
3. 新增SAPCollisionSystem，透過CollisionSystem呼叫後，會經由此系統判定後回傳物件碰撞結果。

# Note&Imp Note:

1. 雖然此碰撞系統速度很快，算是Broad-Phase Collision Detection，但仍要進行非常多優化，像是物件不該每個frame重新移除加入後判定，還有使用Uniform Grid與Dynamic AABB tree，加速取得碰撞物件的技巧。
2. 除了碰撞系統外，其他系統也是不該每個迴圈重新運算，完全是測試取向。
3. 接下來的開發會針對碰撞偵測與優化，因為下個目標是實作Narrow Phase Collision Detection，當然會花時間重新構築整個引擎與各系統。
4. 優化的目標項目有: View Frustum Culling，Edge Collapse Algorithm。
5. 最後最遠的目標: Multiplayer, Water, Shadow Mapping, Deferred Shading...。

# Reference:

SAP paper FastBoxIntersection Paper Quick Sort Radix Sort Radix Sort Chinese

縱使目前引擎如Note處描述有多糟糕，但是fps仍有18以上。好啦，是非常糟糕，希望過幾個月後能大幅提升效能。順道一提，本碰撞系統測試影片中約300多個碰撞物件的碰撞測試，只讓樹與人加上碰撞屬性。

# 2016/10/02

# Subject: Skybox

# Add:

1. 新增Skybox，目前支援日夜變化，與天體旋轉。
2. 新增SkyboxShader，繪製天體的Shader，支援迷霧遮蔽天體。
3. 新增SkyboxRenderer，日夜變化參數控制，繪製單一Skybox。

# 2016/10/01

這幾天學了一個強大的工具glslify，雖然是屬於Nodejs的範疇，但是並不用懂任何javascript或原生語法，只需要依照管理概念去分散Shader，就可以達到Reuse的最大效用。

# Subject: 引入多光源系統

# Add:

1. 新增DirLight，繼承基本光源，用不到的屬性可用來繪製光源位置。
2. 新增PointLight，繼承基本光源。
3. 新增SpotLight，但目前尚不實作出來。

# Modify&Improment:

1. 修改基本Shader檔，透過glslify產生。
2. 修改Mesh Shader檔，透過glslify產生，並修正VertexShader產生的Normal Vector錯誤。
3. 修改Terrain Shader檔，透過glslify產生。

大概的使用如圖:

當前畫面:

# 2016/09/29

# Subject: GUI系統實作

# Add:

1. 新增GuiTexture，專門用來顯示在GUI系統中。
2. 新增GuiRenderer，稱為GUI系統，也可稱為Renderer。
3. 新增GuiShader，綁定GuiRenderer。

# Note:

1. GUI實作不可使用Normalized位置，傳入Shader後做矩陣轉換會導致圖像變形。 (雖然可以想像得出原因，但還不太好解釋)
2. 將系統架構定義為視窗中間為原點的架構，左右則為視窗的視窗像素寬高，例如原點為$(0,0)$，那$X$軸的範圍就是$\begin{bmatrix}\frac{-width}{2} \thicksim \frac{width}{2}\end{bmatrix}$，而$Y$軸的範圍就是$\begin{bmatrix}\frac{-height}{2} \thicksim \frac{height}{2}\end{bmatrix}$。
3. GUI元件做縮放旋轉可依照3D世界的概念，但位移必須額外傳入Shader，詳細解方寫於Other中的解答區。

# Other:

1. 在google找尋解決2D圖片變形的GUI問題，皆沒人解答，Dowen克服後到其中一篇稱為Keep 2d GUI shape through rotation提出解決方案。

# 2016/09/26

終於完成了一個簡單的人物動畫系統，雖然程式架構上有許多需要改進的部分，但模組動畫的引入實作，到這裡終於可以告一段落，從上個階段完成的讀取單一動畫，到變成一個可以載入多模組動畫的架構，真的是認識到C++許多物件導向與指標的糾葛，如有一日要完整重構，可能目前許多地方都得改成指標才能避免無謂的資料複製與操作。

# Add:

1. 新增AnimatablePlayer，繼承Player，隨人物移動觸發動畫移動事件。
2. 新增CustomPlayer，繼承AnimatablePlayer，為實作AnimatablePlayer控制動畫移動。
3. 新增Animation，將動畫一切資訊與操作從MeshModel移至此。

# Modify:

1. 修改AssimpLoader，將原本載入MeshModel且動畫資訊的地方，改回只讀MeshModel與骨架資訊。
2. 修改MeshModel，改回純粹的Mesh模組。
3. 修改MeshesModel，用來管理整個模組的所有骨架基本資訊(inverseBindPose, index)，並接受自定義動畫名稱與動畫實體，但需注意動畫名稱需與實作AnimatablePlayer者相同。
4. 修改AssimpLoader，新增專門載入模組動畫的函式。

Modify.3中提到的使用者傳入自定義動畫名稱與實體。

# 2016/09/24

過了一周的Assimp動畫實作與各種數學矩陣的轉換後，終於在自己的引擎中可支援骨架動畫，起初實作。不了解背後數學公式與一些OpenGL技巧，導致最後連模組都無法出現，到中期了解數學公式後，在OpenGL中將Int資料填入Shader必須使用 glVertexAttribIPointer。還有glBindAttribLocation的使用時機，導致需要重整ShaderProgram相關程式。最後末期，由於Assimp文件中有些地方解釋模糊，在Stackoverflow發文後，還是靠自己無數的Debug後，才知道該矩陣的意義。

# Modify:

1. 修改ShaderProgram、StaticShader、MeshShader、TerrainShader。
2. 修改MeshModel，以支援骨架與動畫資訊。
3. 修改AssimpLoader，支援骨架與動畫的格式，主要使用COLLADA(*.dae)。

# Debug:

1. 修復glBindAttribLocation在基底Shader中的呼叫情況。
2. 從glVertexAttribPointer 修復為glVertexAttribIPointer在Loader載入Vertex Attribute為Int資料上，無法傳入的問題。
3. 修復骨架矩陣上的各種問題。

# Other:

1. Stackoverflow的發問與自解。

# Reminder:

1. 發表關於glBindAttribLocation的蠢問題文章。
2. 發表關於如何利用Assimp載入模組與動畫知識的文章。

# Reference:

1. Skeletal Animation With Assimp
2. Matrix calculations for gpu skinning
3. OpenGL : Bone Animation, Why Do I Need Inverse of Bind Pose When Working with GPU?
4. Game Engine Architecture
5. Blender Matrix to OpenGL Matrix
6. I can't figure out how to animate my loaded model with Assimp

(模組躺著是因為Blender座標系統與OpenGL座標系統有出入，以後慢慢修復。)

# 2016/09/19

# Target: 引入3D模組動畫

# Progress&Record:

1. 了解骨架空間矩陣運算
2. 了解模組動畫Keyframe
3. Game Engine Architecture Jason Gregory, page 11.1 ~ 11.5節很重要。
4. 了解需注意開發環境與輸入檔案是否同為左手或右手座標空間，若不同則需轉換。
5. 了解GLM與ASSIMP矩陣上，前者為Column Major，後者為Row Major，在骨架使用上皆必須先轉置，否則結果將不如預期。

# Other Other:

研究螢幕閃頻與檯燈閃頻問題。 護眼螢幕: 淨藍光、不閃頻 護眼檯燈: 不閃頻、抗眩光

# 2016/09/15

Learn: 3D模組建構

1. 認識基本3D模組建構。
2. 認識模組UV Mapping。
3. 認識模組比重繪製。
4. 認識基本骨架。
5. 認識骨架綁定。
6. 認識控制骨架。
7. 使用Paint.Net繪製UV Mapping。

模組切割紀錄

骨架操作紀錄

# 2016/09/14

# Think&Imp: Texture Atlases

1. 支援多材質圖片。

# Note 1: ##### 相關使用如樹木四季變化,不同樹葉同模組草地。

# 2016/09/12

# Think&Imp: 地形碰撞偵測，場景物體貼齊地形

1. 記錄地形每點高度，利用重心座標系平緩高度變化。

# Note 1: ##### 地形碰撞偵測使用到Barycentric Coordinate，相關數學知識紀錄於數學筆記區中。

# Big Isuue: ##### 許多資料型態都應使用指標較符合使用情境，C++中動態記錄陣列必定要使用指標為宣告方式，否則會被馬上解構，因此地形全使用指標式，從表層改入裏層。難怪Cocos2d任何物體都使用->來操作物件，而不是.。C++真是個難開發的語言阿...。

# 2016/09/11

# Think&Imp: 進階地形&整理程式

1. 支援24bit Height Map調整地形起伏變化。
2. 增加地形Normal向量，支援光影變化。

# Note 1: ##### 地形之Normal是以Finite Difference方法算出，相較於Cross Product 法更為節省效能，不過也有在Geometry Shader利用GPU負擔的算法，也許以後可以實驗比較。

# Note 2: ##### 首次用到位元位移技巧，利用SOIL提供讀取完後的unsinged char*位移轉換可將24bit存入32bit int中。原先利用std::bitset<24>，但實在過於緩慢，方自己寫24bit -> int。而若使用到透明度，可以從原本支援地形變化16,777,216種變為4,294,967,296種。

# 2016/09/10

# Think&Imp: 第三人稱攝影機

1. 新增滑鼠點擊與滾輪的Callback事件。
2. 新增第三人稱攝影機PlayerCamera。

# Issue: ##### glfw事件屬於driven式，雖然是poll check，不過沒driven到就不會觸發callback，因此在滑鼠滾輪事件上需要添加Timestamp來製作Mouse靜態Class的調整。

# 2016/09/08

# Think&Imp: 地形多重材質混合

1. 新增TerrainTexturePack，包含四個顏色。
2. 修改TerrainRenderer與TerrainShader配合BlendMap概念。

# Other: ##### 地形利用RGB與黑色達成四個材質混合，如果利用透明度可達成五個材質，又有聞之用其他色彩數學方法可達成八材質，Unity基本支援即是八種材質地形。

# Issue 1: ##### 縱使單一材質地形仍須使用BlendMap。

# Issue 2: ##### 需要一所見及所得的編輯器比較好製作BlendMap。

# 2016/09/07

# Think&Imp: 增加草地物件與迷霧效果

1. 修改SOIL讀取圖片格式從SOIL_LOAD_RGB -> SOIL_LOAD_RGBA，支援透明度。
2. 修改一般Shader中遇到透明會自動discard。
3. 將Texture.ID改為Texture.GetID(),C++的Readonly public variable不可信任。
4. 草地運用trick: Fake Lighting，使Normal都朝上，讓光源一致。
5. 將各種Shader從Renderer中拔出，將共同參數交給MasterRenderer一起設置，以免未來更改Super Shader需要從每個Renderer中逐一修改。
6. 針對單一天空顏色產生遠處迷霧效果，僅光源暫時不參與迷霧效果。

# Question: ##### 迷霧效果是實踐於Vertex Shader，其原理與常用的深度轉換FragCoord.z相似，是否應實踐於Fragment且改用深度轉換效果較佳，因為Vertex Shader到Fragment是Intepolate的方式產生插值，就如早期光影Gouraud Shading的視覺差異。

# Other: ##### Terrain的迷霧密度不小心調太高導致畫面不協調。

# 2016/09/06

# Think&Imp: 增加平坦地形相關繪製功能

1. 增加Terrain物件。
2. 增加TerrainRenderer利用效率較高的GL_TRIANGE_STRIP繪製地形。
3. 增加TerrainShader，繼承一般Shader，擁有基本光影。

# Issue: ##### 樹木物件數量繪製達500有些微Lag，至1000有明顯Lag，以後需要新增Instancing功能。

# 2016/09/05

# Think&Imp: Renderer分割責任

1. 引入Template，將Entity<模組>，代表任何模組都可擁有位置、旋轉等基礎參數。
2. MasterRenderer: 總繪製器，儲存使用者不同的物件Entity List。
3. LightSourceRenderer: 光源繪製，目前專門繪製PointLight的光源。
4. MeshesRenderer: 模組面集合繪製，將模組載入之所有面進行繪製。
5. Renderer: 一般的Renderer，只繪製擁有一張貼圖的物件。
6. CubeShader: 目前當作光源繪製著色器，只接受基本光源參數。
7. ModelShader: 模組用，也許未來需依照模組新增其他模組著色器，目前支援單一光源的Phong光影特效。
8. StaticShader: 僅適合單一材質物件，不過也支持光影特效。
9. 優化Texture載入次數。

# Issue: 優化在C++中的問題

若Texture相同，就不重新載入，但遇到std::map跟std::unorder_map使用問題，由於std::unorder_map太難實作，故利用std::map並讓TextureModel可以互相比較來建立材質索引表。所幸TextureID OpenGL控制得很好，載入過的材質僅讓使用者維護編號，因此利用TextureModel當std::map的key可行。

# 2016/09/04

# Think&Imp: 新增著色器與不同Renderer與引入Assimp，並實作簡單光影。

1. 引入模組載入AssimpLoader，新增一組MeshRenderer與MeshShader來專門繪製模組。
2. 加入Phong Model的光影特效。
3. 利用Debug版Assimp載入史丹佛龍約略7秒，Release版約略1秒。

# 2016/09/03

# Think&Imp: 基礎架構與模組載入

1. 修改核心模組，將Keyboard、Mouse、ErrorCheck、Debug等訊息以靜態方式呼叫。
2. 新增TextureModel概念，擁有BasicRenderModel及一組材質讀取。
3. 加入Entity概念，Entity代表物件的位置、旋轉角、縮放...等基礎屬性。
4. 實作讀取簡單obj file的ObjLoader。

# Issue: 模組讀取速度

對於讀取一個史丹佛龍來講，C++的getline實在非常緩慢，大概要一分鐘才可載入完200,000行的OBJ。思考引入Assimp。

# 2016/09/02

# Think&Imp: 基礎架構

1. 基礎四元素 Renderer, BasicRenderModel, Shader, Loader
2. Renderer: 目前專門繪製單一BasicRenderModel。
3. BasicRenderModel: 只是一個存取用的資料結構，存放VAO與繪製點數(Indices)。
4. Shader: 延伸Shader，繼承Shader介面者，代表一組特殊的著色器，未來可分為一般物件著色氣、模組著色器、地形著色器...。
5. Loader: 載入資料與創造BasicRenderModel，並且具有資源管理，管理所有VAO,VBO。

# 2016/09/01

# Re-Contruct: 架構除了核心部分打掉重練。

# Re-Target: 失敗經驗，並吸收外國專家經驗，重新架構。

# 2016/08/31

# Think&Imp: 加入地形材質

# 2016/08/30

# Think&Imp: 繪製平坦地形

1. 了解地形結構。 概念:

Vertex: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Indices: 0 5 1 6 2 7 3 8 4 9 9 5 5 10 6 11 7 12 8 13 9 14 14 10 10 15 11 16 12 17 13 18 14 19 19 15 15 20 16 21 17 22 18 23 19 24

由於使用GL_TRIANGLE_STRIP每兩排結尾都加上一些多的Vertex，開發日誌就不多說了。

# 2016/08/29

# Think&Imp: 繪製平面與正方體

1. 依照CCW順序，自行建構正方體的Vertex與Index。

# Issue:

1. 開發有點吃緊，許多參數如位置、旋轉...等不知如何參與。

# 2016/08/28

# Issue:

1. 實作並思考後發現，對於Renderer與Shader的定義不明確。
2. Renderer依照此模式下去，只有一個而且責任非常小，將限制RenderOjbect開發。
3. Shader目前定位非常虛幻，每一個新物件必須重新實作且綁定。

# 2016/08/27

# Think&Imp: 繪製基本物件架構。

1. 每個基礎的可繪製物件稱為RenderObject。
2. RenderObject大致為StartUp,Shutdown,Render。
3. RenderSystem繪製RenderObject抽象的集合。
4. 繼承RenderObject者可任意實作自己的繪製函式。

# 2016/08/26

# Target: 依照書中所見的sb7來嘗試實作一個類似的開發環境。

# Think&Imp: 建立基礎環境。

1. 建立Core類別存放核心標頭GLFW,GLEW,GLM。
2. 匯入Shader類別，提供vertex,fragment,geometry,tessellation...基礎建構功能，從檔案載入。
3. 匯入Camera類別，提供基本攝影機移動。

最近Dowen正在將模組動畫引入到遊戲引擎中，期間遇到的一個超級隱藏Bug就是glBindAttribLocation。引入模組動畫最重要的就是傳入該頂點會使用到的骨架索引與骨架權重，而Dowen這次綁定的位置，離原本定義的Position、Normal、TexCoord稍微遠一點，大概是5、6的位置，所以才發現到原本綁定的方式是錯的。總之，要說的是Shader發生錯誤真的是一丁點資訊都沒有啊，還認為裝了Nsight可以Debug Shader，除了不太會使用外，只指出了Dowen在圖片載入的地方有些誤用而已。

# glBindAttribLocation

glBindAttribLocation是一個幫Shader Code綁定沒定義的輸入頂點屬性位置的函式，至於問為什麼要手動定義這個問題，Dowen還無法確切地回答，不過就使用經驗來說，是為了能讓各個Shader統一頂點屬性，在寫VAO用glVertexAttribPointer載入上會比較容易，還有在寫新Shader上，也不用在意每個頂點屬性的位置，但是仍要注意屬性名稱寫對，就可以輕鬆的在程式上操控每個頂點屬性的輸入。

接下來就是蠢問題示範:

enum VertexAttributeLocationRule
{
	position = 0,
	texCoord = 1,
	normal = 2,
	boneID = 5,
	boneWeight = 6,
};

BasicRenderModel Loader::LoadRenderModel(float position[], int pdataLength, int indices[], int indexLength, float texCoords[], int texCoordLength, float normals[], int normalLength, int boneID[], float boneWeight[], int boneLength)
{
	GLuint vaoID = CreateVAO();
	BindVAO(vaoID);
	BindVertexAttribute(VertexAttributeLocationRule::position, 3, position, pdataLength);
	BindVertexAttribute(VertexAttributeLocationRule::texCoord, 2, texCoords, texCoordLength);
	BindVertexAttribute(VertexAttributeLocationRule::normal, 3, normals, normalLength);
	int boneDimension = (int)((float)boneLength / (float)pdataLength * 3);

	GLuint vboID;
	glGenBuffers(1, &vboID);
	vbos.push_back(vboID);
	glBindBuffer(GL_ARRAY_BUFFER, vboID);
	glBufferData(GL_ARRAY_BUFFER, boneLength * sizeof(GLint), boneID, GL_STATIC_DRAW);
	glVertexAttribIPointer(VertexAttributeLocationRule::boneID, boneDimension, GL_INT, boneDimension * sizeof(GLint), (GLvoid*)0);
	glEnableVertexAttribArray(VertexAttributeLocationRule::boneID);
	glBindBuffer(GL_ARRAY_BUFFER, 0);

	BindVertexAttribute(VertexAttributeLocationRule::boneWeight, boneDimension, boneWeight, boneLength);
	BindIndices(indices, indexLength);
	UnbindVAO();
	return BasicRenderModel(vaoID, indexLength);
}

GLuint ShaderProgram::LoadShader(const char *vertex_path, const char *fragment_path,
	const char *tcs_path = nullptr, const char *tes_path = nullptr, const char *geo_path = nullptr) 
{
	// 準備頂點著色器  // 創造頂點著色器
	GLuint vertShader = CreateBasicShader(0, vertex_path);
	// 準備像素著色器  // 創造像素著色器
	GLuint fragShader = CreateBasicShader(1, fragment_path);
	GLuint tcsShader = -1, tesShader = -1, geoShader = -1;
	if(tcs_path != nullptr)
		tcsShader = CreateBasicShader(2, tcs_path);
	if (tes_path != nullptr)
		tesShader = CreateBasicShader(3, tes_path);
	if (geo_path != nullptr)
		geoShader = CreateBasicShader(4, geo_path);

	/*********************建立程式綁定著色器**********************/
	//std::cout << "Linking program" << std::endl;
	Debug::Log("Linking program");
	// 建立著色器程式 // 創造著色器程式
	//GLuint program = glCreateProgram();
	this->program = glCreateProgram();
	// 將需要的著色器載入到著色器程式中
	glAttachShader(program, vertShader);
	glAttachShader(program, fragShader);
	tcsShader == -1 ? tcsShader = -1: glAttachShader(program, tcsShader);
	tesShader == -1 ? tesShader = -1 : glAttachShader(program, tesShader);
	geoShader == -1 ? geoShader = -1 : glAttachShader(program, geoShader);
	// 載入完後連結到著色器
	glLinkProgram(program);
	GLuint tester1 = glGetAttribLocation(program, "boneID");
	GLuint tester2 = glGetAttribLocation(program, "boneWeight");
	// 確認著色器程式是否成功連結
	DebugProgram(program);

	// Bind Attributes
	BindAttributes();

	// 刪除不用的著色器
	glDeleteShader(vertShader);
	glDeleteShader(fragShader);

	return program;
}


void ModelShader::BindAttributes()
{
	StaticShader::BindAttributes();
	BindAttribute(VertexAttributeLocationRule::boneID, "boneID");
	BindAttribute(VertexAttributeLocationRule::boneWeight, "boneWeight");
}

void ShaderProgram::BindAttribute(int attributeLoc, const char* attributeName)
{
	glBindAttribLocation(this->GetProgram(), attributeLoc, attributeName);
}

以上問題已經過簡化，原本BindAttributes()是寫在每個繼承中的Contructor，後來的新寫法是依照Template Pattern重新寫在Init()的函式中。額外提一下，這期間遇到的問題是，Template Pattern在C++中，無法在Contructor調用純虛擬函式，因此只好把每個Shader的初始化分成Contructor與Init兩段。

回到正題，上方的Code，會導致boneID與boneWeight的綁定初始為3、4，這是為什麼呢?因為position、normal、texCoord已佔領0、1、2，剩下的補位3、4就是boneID與boneWeight。因為BindAttributes或說BindAttribute，又或說glBindAttribLocation被呼叫的時機點是glLinkProgram之後，再來看一下glBindAttribLocation的文件說明。

# glBindAttribLocation

glBindAttribLocation can be called before any vertex shader objects are bound to the specified program object. It is also permissible to bind a generic attribute index to an attribute variable name that is never used in a vertex shader.

@opengl.org

了解狀況後，將呼叫glBindAttribLocation移動到glLinkProgram之前即可。

GLuint ShaderProgram::LoadShader(const char *vertex_path, const char *fragment_path,
	const char *tcs_path = nullptr, const char *tes_path = nullptr, const char *geo_path = nullptr) 
{
	// 準備頂點著色器  // 創造頂點著色器
	GLuint vertShader = CreateBasicShader(0, vertex_path);
	// 準備像素著色器  // 創造像素著色器
	GLuint fragShader = CreateBasicShader(1, fragment_path);
	GLuint tcsShader = -1, tesShader = -1, geoShader = -1;
	if(tcs_path != nullptr)
		tcsShader = CreateBasicShader(2, tcs_path);
	if (tes_path != nullptr)
		tesShader = CreateBasicShader(3, tes_path);
	if (geo_path != nullptr)
		geoShader = CreateBasicShader(4, geo_path);

	/*********************建立程式綁定著色器**********************/
	//std::cout << "Linking program" << std::endl;
	Debug::Log("Linking program");
	// 建立著色器程式 // 創造著色器程式
	//GLuint program = glCreateProgram();
	this->program = glCreateProgram();
	// 將需要的著色器載入到著色器程式中
	glAttachShader(program, vertShader);
	glAttachShader(program, fragShader);
	tcsShader == -1 ? tcsShader = -1: glAttachShader(program, tcsShader);
	tesShader == -1 ? tesShader = -1 : glAttachShader(program, tesShader);
	geoShader == -1 ? geoShader = -1 : glAttachShader(program, geoShader);
	// Bind Attributes
	BindAttributes();
	// 載入完後連結到著色器
	glLinkProgram(program);
	GLuint tester1 = glGetAttribLocation(program, "boneID");
	GLuint tester2 = glGetAttribLocation(program, "boneWeight");
	// 確認著色器程式是否成功連結
	DebugProgram(program);
	// 刪除不用的著色器
	glDeleteShader(vertShader);
	glDeleteShader(fragShader);

	return program;
}

# 小結

該怎麼說，OpenGL function使用有誤真的很難檢測，因為不會有任何警告或錯誤，果然還是得依靠經驗與長年累月的Debug。雖然如此，但是還是滿喜歡從底層搞起，方可看見3D世界中的各種原理，也可以由自身經驗判斷不同遊戲引擎好壞，算是滿開心的一件事。

重心座標(Barycentric coordinate)是Dowen應用於地形碰撞偵測上的數學，此外在OpenGL的Tesselation中也會用到，如此重要的座標概念，幾乎沒有中文文獻，或許是因為容易理解，不過對Dowen來說還是花了不少時間。

# 重心座標 (Barycentric coordinate)

國中的時候我們教過，三角形中腺交於一點稱為重心，而重心公式大家應該都還記得就是三點相加後除以三。

$G = \frac{1}{3}A + \frac{1}{3}B + \frac{1}{3}C$

而其中的三個$\frac{1}{3}$，化為向量就是$\left(\frac{1}{3},\frac{1}{3},\frac{1}{3}\right)$，而重心座標系的性質即是三個參數相加為一。

# 正式定義

重心座標系中，定義每個點各自擁有一個比例參數$\lambda$，其各點乘上比例參數可以完美地表達該點座標。而這樣的比例參數化為向量就是重心座標系中的座標。以下面這張示意圖來看，要表達點$P$，用重心座標系的表示法就會如下:

$P = \lambda_A A + \lambda_B B + \lambda_C C$

在國中時，通常會給各個線段的比例與一些值，但實際上到了圖學中，我們所知道的反而是$A$,$B$,$C$,$P$，然後要求出各個比例參數，看起來很不可思議，但是接下來我們會利用向量來解決這樣的問題。

# 比例參數

首先引入下方這張圖，代表我們會使用到的概念:

那麼$P$點的表達示如下:

$P = A + u \cdot (C-A) + v \cdot (B-A)$

然後以向量表示且將A位移後:

$P - A = u V_0 + v V_1$

由於這個公式中有兩個未知數$u$,$v$，因此需要兩條公式才可以求解，因此利用向量的內積，產生兩條式子。

$\begin{cases} V_2 \cdot V_0 = u V_0 \cdot V_0 + v V_1 \cdot V_0 \\ V_2 \cdot V_1 = u V_0 \cdot V_1 + v V_1 \cdot V_1 \end{cases}$

整理過後得到解果如下:

其化為程式最佳寫法如下:

// Compute vectors        
v0 = C - A
v1 = B - A
v2 = P - A

// Compute dot products
dot00 = dot(v0, v0)
dot01 = dot(v0, v1)
dot02 = dot(v0, v2)
dot11 = dot(v1, v1)
dot12 = dot(v1, v2)

// Compute barycentric coordinates
invDenom = 1 / (dot00 * dot11 - dot01 * dot01)
u = (dot11 * dot02 - dot01 * dot12) * invDenom
v = (dot00 * dot12 - dot01 * dot02) * invDenom

回到原本說需要有三個比例參數。為什麼只剩下兩個?讓Dowen在往後推幾步，就會有所明瞭。

第一步 將向量換回座標:

$V_2 = u V_0 + v V_1$

第二步 展開，並將$A$移回去:

$\begin{aligned} P &= A + u \cdot C - u \cdot A + v \cdot B - v \cdot A \\ P &= (1 - u - v) \cdot A + u \cdot C + v \cdot B \\ P &= \lambda_A A + \lambda_B B + \lambda_C C \end{aligned}$

提取出三個$\lambda$成為$(\lambda_A ,\lambda_B, \lambda_C)$，就取得重心座標系的座標了。

而要換成我們一般直角坐標就是利用$P = \lambda_A A + \lambda_B B + \lambda_C C$，就可以得到原座標。

# 小結

本篇從直角坐標系推倒出重心座標系，又從重心座標系轉回直角坐標系，直觀上不出什麼有用的價值，但是在圖學中地形上，我們有一個三角形與一個缺少高度的XZ座標或說UV座標，做法是只看XZ平面，算出測試座標在XZ平面上的哪一個重心座標系，利用重心座標系在三角形平面上的比例將頂點三點的高度做轉換，即可獲得3D直角坐標系的高度座標，即可完成地形的碰撞偵測。

參考資料:Point in triangle test

經過數年，Sublimetext3官方依然沒有對不同解析度中文字體的解決方案，網路上指流傳著一個一定要屈服才可顯示中文的方法"dpi_scale" : 1.0，逼著大螢幕的中文程式設計師使用小到極致的字體來用這套完美的軟體。而如今終於有專家提出藥方，接下來就跟著本篇慢慢實裝到自己的環境吧！

# 老方法

首先大家知道的老方法還是提一下，就是Preferences -> ** Settings-User** 裡面增加一行文字:

{
	"dpi_scale": 1.0
}

抱歉，舊方法實在太令我印象深刻了，如果有人因為這行滿意就不用往下看下去。

# 新方法

根據此議題最新的Issue報告，Vova Kolobok專家提出了一道解方，就是在Default.sublime-theme中新增以下文字，左方的側欄字體就會變大。

[
    {
        "class": "sidebar_label",
        "font.face": "monospace",
        "font.size": 18
    },
    {
        "class": "tab_label",
        "font.face": "monospace",
        "font.size": 18
    },
    {
        "class": "tool_tip_label_control",
        "font.face": "monospace",
        "font.size": 18
    },
    {
        "class": "quick_panel_label",
        "font.face": "monospace",
        "font.size": 18
    },
    {
        "class": "quick_panel_path_label",
        "font.face": "monospace",
        "font.size": 18
    },
    {
        "class": "quick_panel_score_label",
        "font.face": "monospace",
        "font.size": 18
    },
]

Q1. Default.sublime-theme 在哪? 點Preferences -> Browse Packages可以到Package資料夾，點進User後，自行新增Default.sublime-theme，記住副檔名是**.sublime-theme**，不是**.txt**。

Q2. 你說側邊攔中文字體仍顯示方框? 因為必須搭配老方法，"dpi_scale" : 1.0才可以正確的使字體變大。

Q3. 左方中文字體變大後很醜怎麼辦? 接下來介紹最後一個方法將是目前最完美的解決方案。

# 完美解決方案

意外地找到SODA這個SublimeText3的主題插件，本來只是想將左方側欄也弄成黑底，但意外地SODA提供了一個Retina的功能，把Mac的解析度方案搬到Sublime插件裡，Dowen稱此插件作者是天才也不為過。

0. 開啟清單(Ctrl + Shift + P)。
1. 使用 Package Control: Install Package 打上Theme - Soda。
2. Preferences -> ** Settings-User**
3. 新增theme參數，完成後側邊欄位應為黑/白色。

{
    "theme": "Soda Dark 3.sublime-theme"
    //"theme": "Soda Light 3.sublime-theme" // If you want light theme
}

4. 將老方法**"dpi_scale": 1.0**移除，新方法與本方法步驟都正確的話應該會跟Dowen的Sublimetext長得相似。

# 額外補充

新方法中調整過font.face改成微軟正黑體(Microsoft JhengHei)後字體雖然會變好看，但是使用搜尋欄(Ctrl + F)時，會產生破圖現象。不過字體大小不會影響破圖與否，可以盡情調整。另外，讀者如果有更好的方法，希望可與Dowen分享，謝謝！

最近在正藉由開發遊戲引擎將以往學過的各種技巧逐步整合起來，像是Phong，Normal Mapping，gBuffer，Assimp，Instancing，Parallax Mapping...等。然後參閱網路上神人的概念，左吸收右吐納總算是有點雛形，但其中遇到最Impress的問題是glGetUniformLocation，就由它來做蠢問題系列的第一集主角吧！

# glGetUniformLocation

glGetUniformLocation是碰到Shader即會用到的function，但是Shader爆炸了，卻找不到問題，首先就會面對的也是glGetUniformLocation。

先展示一下Dowen有問題的Shader與Code:

Shader:

#version 330 core
struct Material 
{
    sampler2D diffuse0;
    sampler2D specular0;
    float shininess;
};  

struct Light 
{
    vec3 position;
    vec3 ambient;
    vec3 diffuse;
    vec3 specular;
};


in vec2 TexCoords;
in vec3 FragPos;
in vec3 Normal;
out vec4 color;

uniform vec3 viewPos;
uniform Material material;
uniform Light light;

void main()
{
	vec3 lightPos = light.position;
    // Ambient
    vec3 ambient = light.ambient * vec3(texture(material.diffuse0, TexCoords));
	
	// Diffuse
	vec3 norm = normalize(Normal);
	vec3 lightDir = normalize(lightPos - FragPos);  
	float diff = max(dot(norm, lightDir), 0.0);
    vec3 diffuse = light.diffuse * diff * vec3(texture(material.diffuse0, TexCoords));

	    // Specular
    vec3 viewDir = normalize(viewPos - FragPos);
    vec3 reflectDir = reflect(-lightDir, norm);  
    float spec = pow(max(dot(viewDir, reflectDir), 0.0), material.shininess);
    vec3 specular = light.specular * spec * vec3(texture(material.specular0, TexCoords));
    //color = vec4(1.0f, 0.5f, 0.2f, 1.0f);

	//color = vec4(ambient + diffuse + specular, 1.0f);  
	color = vec4(specular, 1.0f);  
} 

CPP原始碼的部分:

void StaticShader::SetDiffuseTexture(GLuint texture)
{
	glActiveTexture(GL_TEXTURE0 + diffuseCount);
	glBindTexture(GL_TEXTURE_2D, texture);
	std::string diffuse = "material.diffuse" + std::to_string(diffuseCount);
	int loc = GetUniformLocation(diffuse.c_str());
	if (loc == -1) Debug::Log("Diffuse texture Setting Fail.");
	glUniform1i(loc, diffuseCount);
	diffuseCount++;
}

好了，看起來完美地有做debug處理，所以自製的Debug在Visual Studio下方的輸出視窗中印出了這樣的訊息。

Diffuse texture Setting Fail.
Light Ambient Setting Fail.
Light Diffuse Setting Fail.

原因是glGetUniformLocation回傳$-1$，意思是找不到該Uniform位置。然後我Double Check，Triple Check，....Check，複製貼上確保命名問題正確等手法，還是出現同樣地訊息。

Diffuse texture Setting Fail.
Light Ambient Setting Fail.
Light Diffuse Setting Fail.

之後想找更深入的Debug方法，於是就找上了列出所有Attribute與Uniform的偵錯技巧，原文。

function ListAttributes() 
{
	GLint i;
	GLint count;

	GLint size; // size of the variable
	GLenum type; // type of the variable (float, vec3 or mat4, etc)

	const GLsizei bufSize = 16; // maximum name length
	GLchar name[bufSize]; // variable name in GLSL
	GLsizei length; // name length

	glGetProgramiv(program, GL_ACTIVE_ATTRIBUTES, &count);
	printf("Active Attributes: %d\n", count);

	for (i = 0; i < count; i++)
	{
	glGetActiveAttrib(program, (GLuint)i, bufSize, &length, &size, &type, name);

	printf("Attribute #%d Type: %u Name: %s\n", i, type, name);
	}
}

列出來的訊息如下:

Active Attributes: 3
Attribute #0 Type :35665Name : normal
Attribute #1 Type :35665Name : position
Attribute #2 Type :35664Name : texCoord
Active Uniforms: 8
Uniform #0 Type :35665Name : light.position
Uniform #1 Type :35665Name : light.specular
Uniform #2 Type :5126Name : material.shinin
Uniform #3 Type :35678Name : material.specul
Uniform #4 Type :35676Name : model
Uniform #5 Type :35676Name : projection
Uniform #6 Type :35676Name : view
Uniform #7 Type :35665Name : viewPos

果然少了原本應該要出現的那幾項，因此Dowen就開始反覆的重建專案，清除，重建，重開整個project，想說這招也許能成功，一個非常祈禱式的Debug(?)。

最後終於找到了一篇理念型文章，告知了我一些重要的概念，原文在此，整篇的大致概念是這樣的。glGetUniformLocation是一個取得Active Uniform，Active Uniform，Active Uniform的一個function。又什麼是Active Uniform呢? 假設手上有Vertex Shader跟Fragment Shader，將兩者合為一個Program之後，OpenGL會非常貼心地，幫我們把那些不會被用到的變數給移除，就如之前貼的Shader來講好了。

vec3 viewDir = normalize(viewPos - FragPos);
vec3 reflectDir = reflect(-lightDir, norm);  
float spec = pow(max(dot(viewDir, reflectDir), 0.0), material.shininess);
vec3 specular = light.specular * spec * vec3(texture(material.specular0, TexCoords));

//color = vec4(ambient + diffuse + specular, 1.0f);  
color = vec4(specular, 1.0f);  

Diffuse texture Setting Fail.
Light Ambient Setting Fail.
Light Diffuse Setting Fail.

由於輸出的color是藉由specular的值，然後specular是源自於material.specular0，跟material.diffuse0完全無關，所以diffuse0就被從Shader Code中移除，而light.ambient跟light.diffuse也是同material.diffuse0一樣，被斷定為無用之人，因此被踢出了菁因工會，哦不是，我是說Shader Program。

在理解到這個精粹(?)後，Dowen將註解解開(本來是想單獨檢視specular所以才這樣註解)，然後將目前的輸出註解掉。天堂的門就打開了！

# 小結

希望對剛使用OpenGL，然後Debug一整天的人有幫助，像Dowen解了有五小時之多啊！

本篇將會大略的提及OpenGL中Buffer,Unifrom還有一點點Shader Storage Block的部分，而關於Atomic或同步問題，就先略過。如果對Shader中GPU與CPU不熟，可能會對本篇閱讀有礙。畢竟藍寶書竟然將Shader的部分放在後頭，Shader連結部分都還不熟，就先切入細節Buffer,Uniform的部分。

# Buffer

對於Buffer的使用第三篇與第二篇，足夠初學者使用，因此這部分將章節所使用到的Buffer函式列出來逐步講解。

• glCreateBuffers(GLsizei n, GLuint* buffer) : 與OpenGL要buffer的編號，與glGenBuffers功能相同。
• glBindBuffer(GLenum target, GLuint buffer) : 將某編號buffer綁訂在要求的target容器上。
• glBufferStorage(GLenum target, GLsizeiptr size, const void* data, GLbitfield flags) : 將指定容器的空間與資料填入,並告訴OpenGL後續用途，這樣才會配置最佳存取空間。
• glNameBufferStorage(GLuint buffer, GLsizeiptr size, const void* data, GLbitfield flags) : 與 glBufferStorage相同，只是指定的是buffer編號。
• glBufferSubData(GLenum target, GLintptr offset, GLsizeptr size, const GLvoid* data) : 根據offset與size的定義，將資料放在指定記憶體位置處。
• glNameBufferSubData(GLuint buffer, GLintptr offset, GLsizeptr size, const GLvoid* data) : 同glBufferSubData。
• glMapBuffer(GLenum target, GLenum usage) : 從指定容器取出Pointer，可直接進行記憶體配置，不須像glBufferStorage或glBufferData需要多一個copy。
• glMapNamedBuffer(GLuint buffer, GLenum usage) : 同glMapBuffer(GLenum target, GLenum usage)。
• glMapBufferRange(GLenum target, GLintptr offset, GLsizeiptr length, GLenum usage) : 指定要修改的記憶體區域，回傳Pointer可直接進行記憶體配置 。
• glMapNamedBufferRange(GLuint buffer, GLintptr offset, GLsizeiptr length, GLenum usage) : 同glMapBufferRange。
• glClearBufferSubData(GLenum target, GLenum internalformat, GLintptr offset, GLsizeiptr size, GLenum format, GLenum type, const void* data) : 用來清除buffer特定區域的值，然後可用data取代。
• glClearNamedBufferSubData(GLuint buffer, GLenum internalformat, GLintptr offset, GLsizeiptr size, GLenum format, GLenum type, const void* data) : 同glClearBufferSubData。
• glCopyBufferSubData(GLenum readtarget, GLenum writetarget, GLintptr readoffset, GLintptr writeoffset, GLsizeiptr size) : 將Buffer資料複製到指定Buffer中。
• glCopyNamedBufferSubData(GLenum readtarget, GLenum writetarget, GLintptr readoffset, GLintptr writeoffset, GLsizeiptr size) : 同glCopyBufferSubData。
• glVertexArrayAttribBinding(GLuint vaobj, GLuint attribindex, GLuint bindingindex) : 從binding區域中取出buffer，之後對應到vao使用的shader中的位置。
• glVertexArrayVertexBuffer(GLuint vaobj, GLuint bindingindex, GLuint buffer, GLintptr offset, GLsizei stride) : 將buffer的指定記憶體區域綁定到binding區域。

####Binding區域#### Binding區域是一個OpenGL定義的一個待綁區，可以想像成一串陣列，可根據指定vbo buffer或是簡稱buffer，將有資料的buffer放到指定綁定索引後，不同的vao即可以方便使用同個buffer。

• glVertexArrayAttribFormat(GLuint vaobj, GLuint attribindex, GLuint size, GLenum type, GLboolean normalized, GLuint relativeoffset) : 定義第幾個location讀取buffer資料時，要以什麼方式進行讀取，如同第三篇所用到的glVertexAttribPointer。
• glEnableVertexArrayAttrib(GLuint vao, GLuint index ) : 啟動第幾個位置，不啟動Vertex Shader無法接收。
• glDisableVertexArrayAttrib(GLuint vao, GLuint index ) : 關閉VS的接收。

# Uniforms

Unifrom與VertexAttribute的差別對初學者來說應該差異不大，因為都能夠傳送資料進入Shader。不過這裡可以先給一個概念，VertexAttribute強調的是Vertex，也就是根據每個頂點，而有所變動。而Unifrom的中文意思是制式，不變的，利用Unifrom通常只會在一個繪製才能變動一次值，畢竟跑Shader的時候，Uniform的值已經進入GPU。

而Unifrom有兩種形式，一種稱為Default Block Uniforms，另一種稱為** Uniform Block**。

# Default Block Unifroms

Uniform的使用，最傳統的方式如下:

uniform float time;
uniform int selection;
uniform vec4 backgroundColor;
uniform mat4 mvp;

而進階一點可以定義每個uniform的位置，如果沒定義，如上方的形式，就會預設自動配一個，因此通常沒必要定義。

layout (location = 87) uniform vec4 specificStuff;

而如果沒有定義location的一般用法，要傳值的話需要使用glGetUnifromLocation(program, name)，傳入編譯好的program與想要傳值的變數名稱，就可以取得其location。

# 實際情形模擬

假設實際位置如下:

layout (location = 0) uniform float time;
layout (location = 1) uniform int selection;
layout (location = 2) uniform vec4 backgroundColor;
layout (location = 3) uniform mat4 mvp;

那麼再傳值的時候就要用適當的glUnifromXY，X代表數字Y代表型態，如下:

glUseProgram(program);
glUniform1f(0, (GLfloat)systemTime);
glUniform1i(1, 2);
glUniform4f(2, 1.0f, 0.0f, 1.0f, 0.0f, 1.0f);
glUniformMatrix4fv(3, 1, GL_FALSE, glm::value_ptr(mvp));

# Uniform Blocks

有時候不同Shader會傳入相同的值(如光影中幾乎需要攝影機的位置)，這時候Uniform Block就派上用場了，在OpenGL程式中，定義一個Uniform Buffer Object，然後傳入每個需要用到此Uniform的Shader中，直接從記憶體傳入GPU就可以免去每個Shader程式都需要用glUniform來傳遞。

layout (location = 0) in vec4 position;
layout(std140) uniform CommonParameter
{
	int invisible;
	float time;
	float strange[3];
	vec3 camera;
	mat4 mvp;
	int another;
} common;

void main()
{
	... // some shader code
}

上面就是Unifrom Block最常用的方式，而std140代表的是標準格式，代表每個型態的格式大小規範。而定義的模式是，一筆資料的邊界必須是16 bytes對齊，float代表16 bytes，vec1~2代表8 bytes, vec3~4代表16 bytes，mat則是4個16byte。概念如下:

layout(std140) uniform CommonParameter
{
                          //base_aligment-aligment_offset
	int invisible;        //  4-0
	float time;           // 16-16
	float strange[3];     // 16-32
	                      // 16-48
	                      // 16-64
	vec3 camera;          // 16-80
	mat4 mvp;             // 16-96
	                      // 16-112
	                      // 16-128
	                      // 16-144
	int another;          //  4-160
} common;

# 初始化UBO

GLuint ubo;
glGenBuffers(1, &ubo);
glBindBuffer(GL_UNIFORM_BUFFER, ubo);
glBufferData(GL_UNIFORM_BUFFER, 160, NULL, GL_STATIC_DRAW);
glBindBuffer(GL_UNIFORM_BUFFER, 0);
glBindBufferBase(GL_UNIFORM_BUFFER, 0, ubo); // binding point to 0

# 填入內容

通常會在loop的階段使用，除非永遠是Const，那glBufferSubData就可以在迴圈外使用。

GLuint invisible = getInvis();
GLfloat time = geTime();
glm::mat4 mvp = getMvp();
GLfloat strange[3] = getSomeStrange();
glm::vec3 cameraPos = getCamPos();
GLuint another = getValue();
glBindBuffer(GL_UNIFORM_BUFFER, ubo);
int offset = 0;
glBufferSubData(GL_UNIFORM_BUFFER, offset, sizeof(GLuint), glm::value_ptr(invisible));
offset += sizeof(GLuint);
glBufferSubData(GL_UNIFORM_BUFFER, offset, sizeof(GLfloat), glm::value_ptr(time));
offset += sizeof(GLfloat);
glBufferSubData(GL_UNIFORM_BUFFER, offset, 3 * sizeof(GLfloat), glm::value_ptr(strange));
offset += 3 * sizeof(GLfloat);
glBufferSubData(GL_UNIFORM_BUFFER, offset, sizeof(glm::vec3), glm::value_ptr(cameraPos));
offset += sizeof(glm::vec3);
glBufferSubData(GL_UNIFORM_BUFFER, offset, sizeof(glm::mat4), glm::value_ptr(mvp));
offset += sizeof(glm::mat4);
glBufferSubData(GL_UNIFORM_BUFFER, offset, sizeof(GLuint), glm::value_ptr(another));
glBindBuffer(GL_UNIFORM_BUFFER, 0);  

# Shader綁定UBO

這段不用再迴圈內，事先定義好要取得的BindingPoint，Buffer不管怎麼變，Shader都取的到。

GLuint shaderUsedUBO1 = glGetUnifromBlockLocationIndex(program1, "CommonParameter");
GLuint shaderUsedUBO2 = glGetUnifromBlockLocationIndex(program2, "CommonParameter");
GLuint shaderUsedUBO2 = glGetUnifromBlockLocationIndex(program3, "CommonParameter");

glGetUnifromBlockBinding(program1, shaderUsedUBO1, 0);
glGetUnifromBlockBinding(program2, shaderUsedUBO2, 0);
glGetUnifromBlockBinding(program3, shaderUsedUBO3, 0);

# Shader Storage Block

與UBO很相似，但不同的地方在於這裡可以讓Shader進行修改裡面的內容，而且這會影響到OpenGL程式端的Buffer內容。定義如下:

layout (binding=0, std430) buffer stblock
{
    vec4 data;
    int test;
    vec3 color;
}

主要是把uniform改為buffer，而這裡的std430代表一個更嚴格的格式，在此不多做說明，用std140即可。

# 其他

Shader Storage Block還有一個Atomic的應用，主要關於平行處理中的一些細節問題。還有一個特別的Atomic Counter是一些進階技巧，Dowen也未曾碰過。

# 小結

在書中的第五章剩餘還有Texture的部分，是有關於材質貼圖的部分，算是一個極為重要的一Part，但是需要介紹到一個新的圖片載入函式庫，可能會使篇幅變得如同第四篇一樣巨大，因此本篇就先到此結尾。

藍寶書本來認為是一本適合入門者的書，但是漸漸的發現，完全跟入門無緣。因此標題從「OpenGL 入門教學」更改為「OpenGL 藍寶入門教學」，跟著藍寶書走馬看花，真的想用藍寶書學習者可以跟著教學走。打個遊戲的比方來說，如果說學習OpenGL有分為簡單、普通、困難、極難來講，Dowen認為本書屬於困難到極難的等級，而自己是普通的一周目玩家，要通關這本書，可能要技巧性的完成，比方說將一些艱深，身為初學者根本用不到且體會不到的部分先略過，僅提及而不深究。

自己照著藍寶的教學，隨興才會寫，目前Dowen打算先自己看完，教學先擱置，如果有讀者需要幫助可以留言詢問，或許會促進我發文的動力。終於體會到論壇中，「你的回覆是我發文的最大動力」這句話了XD

這一章節主要是介紹一些數學的基礎，如果發現哪個部分不熟的話，最好能親自磨練一下，因為以後常常需要的時候，如果不懂箇中原理，那麼在偵錯或是實作上，會遇到一些麻煩。當然領悟過後能寫起來是最推薦的方式，以後忘了的時候瞟一眼就行了。初學者如果看不懂本篇的話，可以暫且跳過無妨，當有用到再回頭看，因為現在的文章是搭配官方藍寶書的章節推進，而藍寶書比較適合中階以上閱讀者，所以本篇對初學者來說應該很吃力。 接下來會介紹的內容基本上有:

• 向量
• 反射與折射
• 矩陣
• 相關座標系統
• 攝影機
• 透視投影與正交投影
• 直線與曲線
• GLM

# 向量

這邊應該大家都有學過，在此只是把我自己領略的概念描述出來，如果不懂的話，請參閱其他數學專業網站。

# 何謂向量

向量的定義是一個方向附帶著一個量的數值，而為什麼需要一個有數值的方向呢？因為想將向量運用到各種不同的地方，這樣就可以不需要同樣的原點與終點來重現這樣的動作。我們假設一個二維的座標平面，上面有一個點 $p_1$ 還有一個點 $p_2$ ，用 $ p_2 - p_1 $ 所得到的就是從 $ p_1 $ 指向 $ p_2 $ 的向量，如果想不通就想成 $p_2$ 與原點 $ o $ 的關係是 $ p_2 - o $，也就是從原點指向 $ p_2 $ 的向量。

# 基本性質

向量的加減性質跳過。

# 長度

如果向量是 $ (1,2,3) $ 長度的定義是 $ \sqrt{1^2 + 2^2 + 3^2} $，向量已經是兩點相減的結果，所以只要將各個分量平方後開根號就是長度。

# 單位向量

若向量是 $ (1,2,3) $ 則單位向量就是其向量除以長度，也就是 $ \left(\frac{1}{\sqrt{14}},\frac{2}{\sqrt{14}},\frac{3}{\sqrt{14}}\right) $ 這樣的好處是，可以得到往該方向一個單位長度需要多少向量。也就是說上方的各自平方後相加長度等於一。而單位向量的概念在OpenGL中稱之為Normalize。

# 內積

內積的定義是這樣的 $ \vec{a} \cdot \vec{b} = a_xb_x+a_yb_y+a_zb_z $ 直接看看不出它的意義是什麼，他還有另一個特性是 $ \vec{a} \cdot \vec{b} = \left| \vec{a} \right| \left| \vec{b} \right| \cos{\theta} $ 在圖學中內積常常用來求的是角度，也就是說根據上方的另一個性質，將長度移到左方然後算出內積的值，就可以得到 $ value = \cos{\theta} $ 的情況，也就是可以知道角度是多少，這是內積常常運用在圖學中的部分。至於上方的兩定義由來就不探討。

# 外積

外積的定義是 $ \vec{V}_1 \times \vec{V}_2 = \vec{V}_3$

$\begin{bmatrix} V_3.x \\ V_3.y \\ V_3.z \\ \end{bmatrix} = \begin{bmatrix} V_1.y \cdot V_2.z - V_1.z \cdot V_2.y \\ V_1.z \cdot V_2.x - V_1.x \cdot V_2.z \\ V_1.x \cdot V_2.y - V_1.y \cdot V_2.x \\ \end{bmatrix}$

得到的 $ \vec{V}_3 $ 就是垂直於 $ \vec{V}_1 , \vec{V}_2 $的向量，依照弗萊明右手定則就可以知道該垂直向量應該往哪裡垂直，且別擔心，不管怎麼比都會在定則內的。在圖學中，會用到的就是外積算出來垂直於表面的特性，也就是Normal Vector，這個光影特效中時常使用的向量。

# 反射與折射

# 反射

反射有個特性，就是入射角等於反射角，然後依照圖片所示，我們要算出反射角的方法有兩種。一種是不用將入射角反轉，直接位移兩個垂直平面的分量。另一種是將入射角反轉，移動兩個水平分量，而這裡介紹的是移動兩個垂直分量的方法。 結果公式為: $R_{reflect} = R_{in} - (2N \cdot R_{in} )N$ 解釋 : 反射分量 = 入射分量 - 兩個垂直表面的分量。

正式理解，我們直觀來看入射角 $R_{in}$ 應該要減去兩個垂直於法向量 $N$ 的 $R_{in}$ 垂直分量。直觀來看就是 $R_{in}$ 加上兩個 $\left| -R_{in} \right| \cos{\theta} \times \frac{N}{\left|N\right|}$，而 $-R_{in}$ 代表反的入射角，因為要跟垂直分量算夾角，必須要兩向量都從頭個原點出發才行。那為何是 $\left| -R_{in} \right|$ 呢?因為透過三角形的畢氏定理，就可以換算成在該垂直分量上的長度多少，之後再轉回向量，也就是要乘上 $N$ 的單位向量 $\frac{N}{\left|N\right|}$，就可以得知在該方向上的分量是多少，這裡運用到投影向量的技巧，需要自行去熟悉一下。

來認真的推看看: 原式:

$R_{in} + 2 \times \left| -R_{in} \right| \cos{\theta} \times \frac{N}{\left|N\right|}$

化簡多餘的部分(對了N固定是單位向量，也就是長度為1): $R_{in} + 2 \times \left| -R_{in} \right| \cos{\theta} \times N$

由於 $-R_{in} \cdot N = \left| -R_{in} \right| \left| N \right| \cos{\theta}$

又可以是 $-R_{in} \cdot N = \left| -R_{in} \right| \cos{\theta}$

因此化簡為: $R_{in} + 2 \times -R_{in} \cdot N * N$

負號提出來: $R_{in} - 2 \times R_{in} \cdot N * N$

最後將上方的原式拿來比較:

$R_{reflect} = R_{in} - (2N \cdot R_{in} )N = R_{in} - 2 \times R_{in} \cdot N \times N$

得證相等，與理解的無誤。

# 折射

折射的部分，Dowen也尚未理解，公式牽涉較深物理，理論是說，入射方介質 $ \eta $ 小於折射方介質$ \eta $ ，那折射方就會偏向法向量，反之就會偏離，不是物理學者，我想知道概念足矣。

# 矩陣

說到矩陣，以前完全想不透為何經過矩陣轉換，得到的東西是一個有意義的東西。某日深研後，發現矩陣是由方程式的演變而來的，聽起來很理所當然，不過當題目做多了，反思一下卻忘了本源是什麼，就有點慌慌的。接下來就用方程式與矩陣一起說明，不直接用矩陣說明的方式來教學。至於矩陣的乘法，在這裡就不贅述，矩陣只是一種方程式變相的工具使用而已，如果有疑慮請詳閱專業數學相關網站。

# 位移

假設一物體位於三維空間中 $p_{old} (x, y, z)$ 點上，那要移動至 $p_{new} (x + 2 ,y + 3 ,z-5)$ 的點在方程式上該如何表示呢?

位移在方程式上算是比較特殊的轉法，一般我們矩陣是3x1(新座標) = 3x3 * 3x1(原座標)。但是可以發現相乘後，只會縮放各個x, y, z的座標後相加。

$\begin{bmatrix} a_1 & b_1 & c_1 \\ a_2 & b_2 & c_2 \\ a_3 & b_3 & c_3 \\ \end{bmatrix} \begin{bmatrix} x_{old}\\ y_{old}\\ z_{old}\\ \end{bmatrix} = \begin{bmatrix} a_1 \cdot x_{old} + b_1 \cdot y_{old} + c_1 \cdot z_{old}\\ a_2 \cdot x_{old} + b_2 \cdot y_{old} + c_2 \cdot z_{old}\\ a_3 \cdot x_{old} + b_3 \cdot y_{old} + c_3 \cdot z_{old}\\ \end{bmatrix}$

在這裡加上一個四維座標空間的概念，圖學中常常使用到，但實際上仍是三維的一個輔助法。

$\begin{bmatrix} a_1 & b_1 & c_1 & w_1 \\ a_2 & b_2 & c_2 & w_2 \\ a_3 & b_3 & c_3 & w_3 \\ a_4 & b_4 & c_4 & w_4 \\ \end{bmatrix} \begin{bmatrix} x_{old}\\ y_{old}\\ z_{old}\\ w_{old}\\ \end{bmatrix} = \begin{bmatrix} a_1 \cdot x_{old} + b_1 \cdot y_{old} + c_1 \cdot z_{old} + w_1 \cdot w_{old} \\ a_2 \cdot x_{old} + b_2 \cdot y_{old} + c_2 \cdot z_{old} + w_2 \cdot w_{old} \\ a_3 \cdot x_{old} + b_3 \cdot y_{old} + c_3 \cdot z_{old} + w_3 \cdot w_{old} \\ a_4 \cdot x_{old} + b_4 \cdot y_{old} + c_4 \cdot z_{old} + w_4 \cdot w_{old} \\ \end{bmatrix}$

擴充成四維空間後，這樣看起來沒什麼意義。但是當在不必要的地方填入0，還有必要的地方填入1後，就會變以下這樣。

$\begin{bmatrix} 1 & 0 & 0 & w_1 \\ 0 & 1 & 0 & w_2 \\ 0 & 0 & 1 & w_3 \\ 0 & 0 & 0 & 1 \\ \end{bmatrix} \begin{bmatrix} x_{old}\\ y_{old}\\ z_{old}\\ 1\\ \end{bmatrix} = \begin{bmatrix} 1 \cdot x_{old} + 0 \cdot y_{old} + 0 \cdot z_{old} + w_1 \cdot 1 \\ 0 \cdot x_{old} + 1 \cdot y_{old} + 0 \cdot z_{old} + w_2 \cdot 1 \\ 0 \cdot x_{old} + 0 \cdot y_{old} + 1 \cdot z_{old} + w_3 \cdot 1 \\ 0 \cdot x_{old} + 0 \cdot y_{old} + 0 \cdot z_{old} + 1 \cdot 1 \\ \end{bmatrix} = \begin{bmatrix} x_{old} + w_1\\ y_{old} + w_2\\ z_{old} + w_3\\ 1\\ \end{bmatrix}$

這樣子就變成一個位移專用的矩陣，仍然不會用到我們擴充的第四維，但是又可以輔助三維空間的位移。

$\begin{bmatrix} 1 & 0 & 0 & 2 \\ 0 & 1 & 0 & 3 \\ 0 & 0 & 1 & -5 \\ 0 & 0 & 0 & 1 \\ \end{bmatrix} \begin{bmatrix} x_{old}\\ y_{old}\\ z_{old}\\ 1\\ \end{bmatrix} = \begin{bmatrix} 1 \cdot x_{old} + 0 \cdot y_{old} + 0 \cdot z_{old} + 2 \cdot 1 \\ 0 \cdot x_{old} + 1 \cdot y_{old} + 0 \cdot z_{old} + 3 \cdot 1 \\ 0 \cdot x_{old} + 0 \cdot y_{old} + 1 \cdot z_{old} - 5 \cdot 1 \\ 0 \cdot x_{old} + 0 \cdot y_{old} + 0 \cdot z_{old} + 1 \cdot 1 \\ \end{bmatrix} = \begin{bmatrix} x_{old} + 2\\ y_{old} + 3\\ z_{old} - 5\\ 1\\ \end{bmatrix}$

以上就是位移矩陣的由來。在定位一個物體在世界座標中哪個位置時常使用。

# 旋轉

旋轉矩陣我在這篇文章中有寫過，因此把結果提出來，讓我們知道方程式與矩陣的關係。 原本的方程式如下:

換成矩陣後:

$\begin{bmatrix} \cos{\theta} & -\sin{\theta} \\ \sin{\theta} & \cos{\theta} \\ \end{bmatrix} \begin{bmatrix} x_{old}\\ y_{old}\\ \end{bmatrix} = \begin{bmatrix} x_{old} \cos{\theta} - y_{old} \sin{\theta} \\ x_{old} \sin{\theta} + y_{old} \cos{\theta} \\ \end{bmatrix}$

如果要放到3D世界來使用，有兩點要思考。

1. 這樣的旋轉在3D世界中是屬於依照X還是Y還是Z呢? Ans: Z
2. 要位移怎麼辦?只能是XYZ軸嗎? 這篇文章介紹每個大概，只介紹依照XYZ軸的旋轉，如果是依照任意軸，或更勝之是四元數，這些較適合以後開文章討論，或是請讀者至參考連結去閱讀，如果有問題可以提出來討論，Dowen在寫這篇文章的時候都已閱讀完畢。

####歐拉角#### 以旋轉矩陣來進行旋轉的集合統稱為歐拉角，順序有先XYZ, ZYX ,YZX, XZY...各種組合。如果是以世界座標的XYZ旋轉，不會產生問題。但是如果以物體座標的話，就會產生意想不到的問題。怎麼說呢? 拿起手機，螢幕對著自己，當作Z軸指向自己，上方當作Y軸，右方當作X軸。 那如果以ZXY的矩陣來旋轉會產生什麼問題呢?首先以Z轉任意角度，X轉90度，之後Y的選轉軸，與Z就重合了。有人會想物體的Z也在變阿? 實際上，電腦藉由矩陣運算的時候，轉完Z之後，轉了X後，Z已經不會有任何改變，因為那是之前轉完的。而X轉了90度後，Y剛好與原Z軸重合，導致Y與Z軸只能轉一樣的方向。 這就是所謂的萬向鎖(Gimbal Lock)

先擴充成以Z軸的三維旋轉

$\begin{bmatrix} \cos{\theta} & -\sin{\theta} & 0\\ \sin{\theta} & \cos{\theta} & 0\\ 0 & 0 & 1\\ \end{bmatrix}$

以上讀者可以以之前的方式自行證明。接下來要擴充成四維空間，原因是之前說過的，為了位移的技巧。

$\begin{bmatrix} \cos{\theta} & -\sin{\theta} & 0 & 0\\ \sin{\theta} & \cos{\theta} & 0 & 0\\ 0 & 0 & 1 & 0\\ 0 & 0 & 0 & 1\\ \end{bmatrix}$

順便列出剩下兩個以x與y的旋轉。

以Y軸旋轉

$\begin{bmatrix} \cos{\beta} & 0 & \sin{\beta} & 0\\ 0 & 1 & 0 & 0\\ -\sin{\beta} & 0 & \cos{\beta} & 0\\ 0 & 0 & 0 & 1\\ \end{bmatrix}$

以X軸旋轉

$\begin{bmatrix} 1 & 0 & 0 & 0\\ 0 & \cos{\alpha} & -sin{\alpha} & 0\\ 0 & \sin{\alpha} & cos{\alpha} & 0\\ 0 & 0 & 0 & 1\\ \end{bmatrix}$

順便一提，如果自己推出的矩陣與上不符，不一定是錯的，只是在圖學中，上方是符合右手定則，逆時針旋轉，以Z軸旋轉來說，就是Z不變, X軸朝向Y軸移動形成看起來逆時針的旋轉。(圖學中Z軸永遠指向螢幕外，也就是指向自己)

# 縮放

縮放其實很簡單，不論你原本的點是在負向的部分還是正向，經由縮放後，會靠近0，或者遠離0，矩陣如下。

$\begin{bmatrix} x_{old}\\ y_{old}\\ z_{old}\\ 1\\ \end{bmatrix} \begin{bmatrix} S_x & 0 & 0 & 0\\ 0 & S_y & 0 & 0\\ 0 & 0 & S_z & 0\\ 0 & 0 & 0 & 1\\ \end{bmatrix} = \begin{bmatrix} S_x x_{old}\\ S_y y_{old}\\ S_z z_{old}\\ 1\\ \end{bmatrix}$

# 相關座標空間

使用OpenGL需要接觸到許多三維座標空間，看到以下列出這麼多，也不需要太慌張，其實都是一點一點演變而來的，這一連串的座標空間都息息相關。

# 笛卡爾座標

這是我們最常使用到的座標系統，直角坐標系統，也稱為笛卡爾座標系統，這個就不多做說明。

# 齊次座標

先來看下面這張圖。

圖片引用自圖庫網

鐵軌旁邊兩條平行的軌道，理應是一直線不會交合的，但是現實世界中，他們越遠就會越相近。而距今約兩百年前的天文學家 奧古斯特·費迪南德·莫比烏斯（August Ferdinand Möbius) 發展了齊次座標的概念，使用齊次概念的座標系統，都要在其維度多增加一維。 (而剛好的，增加一維又可以讓位移矩陣發揮作用，這不知道是不是一種數學的巧合呢?)

而齊次與笛卡爾的關係如下: 二維: $ (x,y,w) = \left( \frac{x}{w},\frac{y}{w} \right) $ 三維: (投影矩陣部分詳細說明, 先看二維就好) $ (x,y,z,w) = \left( \frac{x}{w},\frac{y}{w},\frac{z}{w} \right) $ 舉例如下: $ (2,3,5)_h = \left(\frac{2}{5},\frac{3}{5}\right)_c $$ (4,6,10)_h = \left(\frac{4}{10},\frac{6}{10}\right)_c = \left(\frac{2}{5},\frac{3}{5}\right)_c $$ (2a,3a,5a)_h = \left(\frac{2}{5},\frac{3}{5}\right)_c $

利用齊次的概念讓兩條平行線有交集:

$\begin{cases} Ax + By + C = 0 \\ Ax + By + D = 0 \end{cases}$

在上方的笛卡爾空間中，這兩條線除非 $ C = D $ ，否則不可能有交集。 而利用齊次的概念就是將 $ w $ 放進來，把 $ x $ 取代為 $ \frac{x}{w} ， y $ 取代為 $ \frac{y}{w} $ 而w 的範圍是 $ 1 \ge w > 0$ ，其意義是遠近的意思。 越遠$w$值越小。

$\begin{cases} A \frac{x}{w} + B \frac{y}{w} + C = 0 \\ A \frac{x}{w} + B \frac{y}{w} + D = 0 \end{cases}$

如果 $ w = 1 $ 那一切都沒變，但若 $ w $趨近於0，就會發生一件事，前兩項參數的值過於巨大，導致C,D的影響完全不重要。不過換個角度看的話會更明顯，這次改成這樣。

$\begin{cases} Ax + By + C \times w = 0 \\ Ax + By + D \times w = 0 \end{cases}$

這樣很容易就可看出越遠C,D值越小，導致最後匯聚於一點的狀況。這就是在笛卡爾空間中運用齊次座標的效果。

以圖來表示:

• 紅線: $r = 5x + 50$
• 藍線: $b = 5x - 50$
• 綠色: $g = 5x - 50 \times w$
• 紫色: $p = 5x - 50 \times w$
• $w$(深度): $w = 1 - x/100$ (只要看x = 0 ~ 100的範圍, 超過都不在實驗範圍) 上圖表示到$ x = 100$這個點的時候會聚在一起，而且是逐漸匯聚。

# 物體座標

不管事人物、花瓶、球，任何物體在建置的時候都有一個Local Space，稱為物體座標，在這物體座標中，建置的每個點都是相對於原點。通常都會把物體的每個頂點都定義在原點附近，因為這不是真正在遊戲或場警中出現的位置，所以在這個空間建置的模型，只需要專注建模即可。

# 世界座標

把物體放到世界座標(World Space)，我們利用一個矩陣稱為Model矩陣。這是圖學常見的MVP矩陣中的第一段，將物體定位於世界的空間中。而Model矩陣可以由上方所提出的旋轉、位移、縮放所組成，但要注意順序是有差別的，正常我們會先縮放，再旋轉、在位移，原因是如果先位移，那旋轉轉的就不是模組本身，而是將模組以旋轉的方式位移。另外先旋轉，後縮放，在位移也是等可以的，如果不是這兩種方式，那就是有其他用途。總之，經過Model矩陣後，物體就會被放到世界場景中該有的位置。

# 視覺座標

世界座標轉到視覺座標(View Space)，這裡使用View矩陣，而這空間也可以說是攝影機空間，將所有世界座標中的物體，經過旋轉位移後，移動到攝影機的面前，也就是世界的長相都取決於攝影機的位置，拍攝角度。跟現實不同的是，現實是攝影機移動拍攝世界，圖學中是世界移動到攝影機面前，或是移出攝影機外。

右下角那個攝影機拍攝畫面就是視覺座標的樣子。其實這裡以圖來表示不是很正確，因為還經過了正交投影，不懂正交投影的話，就先假設圖中就是正確的，因為正交實際上做的事不多。

# 投影座標

最後來到的這個座標叫做(Clip Space)，使用到的矩陣稱為Projection矩陣，原理是透過兩個平面，一個近，一個遠，然後這個範圍內的物體影像(頂點)投射到近平面上，如果是線性投射(透視投影)，就會是仿現實生活的畫面，但也是我們最習慣看到的畫面，如下。

近物

遠物

而如果是經過正交投影，直接將範圍透的物體作投射，那麼就不會有遠近的感覺。不過正交投影自然有它存在的價值，像是做影子就會使用到，初學者需要多多消化理解這部分，因為正交視覺上頗為不直觀。

近物

遠物

# 攝影機

一台攝影機，有拍攝角度跟攝影機的座標位置。這邊就先從簡單的攝影機位置在視覺座標中，與View矩陣到底有什麼關係說起。開始前先說明，畫面是從投影矩陣過後在xyz為-1 ~ 1之間的影像，所以移動到攝影機前這個動作，可能會聯想到，那原本的攝影機在哪? 為何要移動攝影機? 其實預設是有一個假攝影機，他會將那些頂點位於-1 ~ 1之間的描繪出來，所以之前的文章才可以顯示出三角形，而這裡是要給讀者知道，要自訂一台攝影機所需要的知識。

# 攝影機的位置

假設一攝影機位於$(1,2,3)$的三維空間中，那若要以該攝影機為視覺出發點該如何做呢? 簡單來說，就是朝向$(-1,-2,-3)$位移就好了，這裡的疑點應該是，攝影機都在$(1,2,3)$了，為何還要移動$(-1,-2,-3)$呢?原因是假定的這台攝影機，實際上也不存在，所有的視野都只會看到位於$(-1,-1,-1)$到$(1,1,1)$這個正方體(或稱為Normalize Device Coordination)中，也因此正中心是在$(0,0,0)$，也就是說要假裝正中心在$(1,2,3)$的話，那就是這世界的每個物體都要往反方向的$(1,2,3)$移動，也就是$(-1,-2,-3)$。舉個實際的例子，當一台攝影機往右邊平移拍攝的時候，攝影機假設沒再動，那也就是拍攝的物體往左方移動了，讓你誤以為往右平移拍攝，上面的原理就是如此，以為攝影機從原點$(0,0,0)$跑到$(1,2,3)$，實際上是所有物體從世界座標的$(x,y,z)$變成$(x-1,y-2,z-3)$，產生攝影機在動的錯覺。對了，不管哪個矩陣都是對每個物體的世界座標做相乘，而不是對攝影機這個抽象物體。 而攝影機關於位置的位移矩陣如下:

$\begin{bmatrix} 1 & 0 & 0 & -Camera_x \\ 0 & 1 & 0 & -Camera_y \\ 0 & 0 & 1 & -Camera_z \\ 0 & 0 & 0 & 1 \\ \end{bmatrix}$

# 攝影機的拍攝角度

攝影機的拍攝角度，基本上是由三個向量所定義而成的，攝影機的前方$\vec{C}_f$，攝影機的上方$\vec{C}_u$，攝影機的右方$\vec{C}_r$，有了這三個方向的向量，就可以知道，要怎麼旋轉，不過與其說是旋轉，不如說是座標轉換，將原本軸是$(1,0,0)$,$(0,1,0)$,$(0,0,1)$的三個互相垂直的向量，轉換成以$\vec{C}_r$, $\vec{C}_u$, $\vec{C}_f$為xyz軸的空間。 首先要先了解原座標空間在矩陣上是如何表示。

$\begin{bmatrix} 1 & 0 & 0 & 0\\ 0 & 1 & 0 & 0\\ 0 & 0 & 1 & 0\\ 0 & 0 & 0 & 1\\ \end{bmatrix} \begin{bmatrix} x_{old}\\ y_{old}\\ z_{old}\\ 1\\ \end{bmatrix} = \begin{bmatrix} x_{old}\\ y_{old}\\ z_{old}\\ 1\\ \end{bmatrix}$

上方斜對角為一的稱為單位矩陣，撇去名詞，就是一個塞了XYZ三軸單位向量的矩陣，且多了一個不會用到的擴充四維。那麼在攝影機座標空間中是如何看待原座標空間中的點呢? 關係如下:

$\begin{bmatrix} C_r.x & C_r.y & C_r.z & 0\\ C_u.x & C_u.y & C_u.z & 0\\ C_f.x & C_f.y & C_f.z & 0\\ 0 & 0 & 0 & 1\\ \end{bmatrix} \begin{bmatrix} x_{old}\\ y_{old}\\ z_{old}\\ 1\\ \end{bmatrix} = \begin{bmatrix} C_r.x \cdot x_{old} + C_r.y \cdot y_{old} + C_r.z \cdot z_{old} \\ C_u.x \cdot x_{old} + C_u.y \cdot y_{old} + C_u.z \cdot z_{old} \\ C_f.x \cdot x_{old} + C_f.y \cdot y_{old} + C_f.z \cdot z_{old} \\ 1 \\ \end{bmatrix}$

而換算矩陣就是$\vec{C}_r$, $\vec{C}_u$, $\vec{C}_f$所構成的。也就是說如果此時你要在X軸移動一單位，需要$(C_r.x, C_r.y, C_r.z)$個單位才能在畫面上向右移動一格，忘了提到，這裡所使用到的攝影機向量都是單位向量。

而如果要使用攝影機的話，文末提供的GLM有一個名為LookAt(cameraPositon, target, cameraUp)，這個原理就是上方所講的，只是這裡的三個參數，就可以產生出三個向量，像是$\vec{C}_f$ 只要利用 target - cameraPositon之後Normalize就可以達成，而$\vec{C}_u$就是cameraUp，最後的$\vec{C}_r$只要利用$\vec{C}_u \times \vec{C}_f$就可以得到最後的向量了，這裡外積的順序是yz相乘得x，如果是zy就會是-x，若無法理解請拿原本的$(0,1,0) \times (0,0,1)$來做測試。

而要操縱攝影機則要了解攝影機旋轉的概念，主要有三種旋轉方式。一個是Pitch，抬頭與低頭的概念。一個是Yaw，左轉與右轉的概念。一個是Roll，趴睡的時候，你的頭就會轉這種以鼻子為軸的方式旋轉。而概念圖如下:

在座標系統上的概念如下:

Pitch

Yaw

Pitch(抬頭)，即是向量往Y軸移動，若假設向量長度為r，那XYZ三者與Pitch夾角$\theta$關係如下:

其中 plane 代表的是原本X,Z在平面上的分量，而且是常數。不過如果加入Yaw(回頭)的話，就可以改變這個情況，如上圖所示，Yaw代表的是X朝向Z的旋轉關係，所以只要把 plane 改為 $ \alpha $ 就可以完成Pitch與Yaw的攝影機。

至於Roll這個旋轉，較少出現在攝影機的移動中，不管遊戲還是編輯器中，所使用的攝影機多半是Pitch與Yaw的組合，也因此這裡不會有萬向鎖的問題。不過這裡要注意的是這裡的Yaw跟Pitch與歐拉角中的旋轉不相等，因為本文中的Pitch一次就動到了xyz三點的值，算是一種對任意軸的旋轉，而之前所介紹的旋轉公式是對固定軸，

# 透視投影與正交投影

透視投影 近物

透視投影 遠物

正交投影 近物

正交投影 遠物

回顧一下之前看到的兩張圖，透視投影接近現實，越遠的物體就會越小。正交投影屬於理想向量世界，不管物體遠近，都會顯示他原本定義的大小。而不管透視或正交假想上都有一個遠盤(far plane)，跟一個近盤(near plane)，在兩盤之間的物體就會出現在畫面上，超出兩盤的都無法看見。

而這個階段的目的是為了將View階段的$x_{view},y_{view},z_{view},1$，轉換到Projection階段的$x_{clip},y_{clip},z_{clip},w_{clip}$，順道一提，clip space也可以稱為projection space。概念公式如下:

$\begin{pmatrix} x_{ndc} \\ y_{ndc} \\ z_{ndc} \\ 1 \\ \end{pmatrix} = \begin{pmatrix} \frac{x_{clip}}{w_{clip}} \\ \frac{y_{clip}}{w_{clip}} \\ \frac{z_{clip}}{w_{clip}} \\ \frac{w_{clip}}{w_{clip}} \\ \end{pmatrix}$

算出Clip space後，交給OpenGL會自動用透視除法(perspective devision)，來轉成NDC空間的座標，而上方除以$w$的概念就是透視除法，也是齊次座標中所使用到的概念，因為$w_{clip}$，其實是view space的$z_{view}$。

###透視投影### 先從困難的透視投影講起，之後正交就簡單了，在這個階段主要有四個步驟，當然化為程式都是一個數學式，不過要理解透視投影的每個步驟就要一步一步分開詳細探討。

# 第一步:X的線性投影

從上方看透視投影區

從側邊看透視投影區

上圖中，e代表的是View Space中的座標，p代表projection座標，要注意的是，這並不是clip space，就是說這個階段是投影座標。 這個階段要產出的線性轉換如下:

# 第二步:壓縮至-1 ~ 1

為何要壓縮至-1 ~ 1呢?這不是clip space到NDC空間才要由OpenGL轉換的嗎? 沒錯，不過投影階段直接就運算到最終的空間NDC，最後用了齊次座標的技巧，才讓NDC變回clip空間，接下來可以這技巧是如何變的，不過為什麼不直接給NDC給OpenGL，要換成clip space，個人臆測是因為OpenGL對深度有一個叫做Depth test或Stencil test的部分會用到。

首先將投影座標與Normalize後座標(NDC)的關係找出來:

上方轉換成數學關係式如下:

側視圖的公式大同小異:

# 第三步:第一步代入第二步

到這個步驟是view -> proj -> ndc -> clip，第一步找出view -> proj的關係，第二步找出proj -> ndc的關係，這裡當然就是要找出ndc -> clip的關係，以view表示，畢竟要將view轉到clip。那就直接進入數學式吧。

根據以上的NDC與View之間的關係，得到一個新的Clip座標$x_c$，有發現為什麼$-z$會被留在那嗎? 那就是將齊次座標的概念留下，不過只看一個還看不出來，當每個座標都需要$-z$的輔助後，就會理解這樣的用意。不過還是要強調，這個步驟是將NDC的概念退回Clip的步驟，比較不是偏數學的概念，算是程式技巧才有Clip Space的存在。而y的方面就如同上方，讀者可以自行推導，直接進入下一步。

# 第四步:建立矩陣與填補矩陣未知部分

$\begin{bmatrix} x_c \\ y_c \\ z_c \\ w_c \\ \end{bmatrix} = \begin{bmatrix} \frac{2n}{r-l} & 0 & -\frac{r+l}{r-l} & 0\\ 0 & \frac{2n}{t-b} & \frac{t+b}{t-b} & 0\\ 0 & 0 & A & B\\ 0 & 0 & -1 & 0\\ \\ \end{bmatrix} \begin{bmatrix} x_e\\ y_e\\ z_e\\ w_e\\ \end{bmatrix}$

首先前兩行(row)，就是我們第三步所推導的，而第四行只有一個$-1$，是因為已經決定讓$-z_e$，當作最後要做透視除法的參數，也許可以等第三行推完之後，參考本節一開始所說的概念公式，來理解這段。而第三行前兩個值是$0$，因為透視投影主要是將投影空間中依照深度距離不同位置的$x$,$y$，投影到近盤上，既然其他人都依賴$z_e$，$z_e$也就不會依賴回去。因此只剩下兩個未知參數需要處理，而View Space中$w_e$是$1$，因此B成為輔助參數，讓$z_c$與$z_e$建立線性關係，就變成以下的形式。 $z_c = Az_e + B$ 而要轉換回可以逆推導的情形，必須轉回NDC，因為clip space本身並沒有實質意義，這部分對剛接觸的人會有很多困惑，因為前面都是正向工程，到這裡要推$z_c$卻要用逆向工程，返回$z_n$，在回到$z_c$。 $z_n = \frac{z_c}{w_c} = \frac{Az_e + B}{-z_e} = \frac{A z_e + B}{-z_e}$ 其實這段Dowen嘗試過正向推導，不過由於沒有$z_p$與$z_e$的何關係式，所以推不出來。

回到矩陣的形式如下:

$\begin{bmatrix} x_c \\ y_c \\ z_c \\ w_c \\ \end{bmatrix} = \begin{bmatrix} \frac{2n}{r-l} & 0 & -\frac{r+l}{r-l} & 0\\ 0 & \frac{2n}{t-b} & \frac{t+b}{t-b} & 0\\ 0 & 0 & -\frac{f+n}{f-n}& -\frac{2fn}{f-n}\\ 0 & 0 & -1 & 0\\ \\ \end{bmatrix} \begin{bmatrix} x_e\\ y_e\\ z_e\\ w_e\\ \end{bmatrix}$

以上是最終矩陣，將View轉成Clip空間，而通常不會使用以上的矩陣。我們通常使用的是正方形近盤，所以將$t = r = -l = -b$，矩陣會變換如下:

$\begin{bmatrix} \frac{n}{r} & 0 & 0 & 0\\ 0 & \frac{n}{r} & 0 & 0\\ 0 & 0 & -\frac{f+n}{f-n}& -\frac{2fn}{f-n}\\ 0 & 0 & -1 & 0\\ \\ \end{bmatrix} \begin{bmatrix} x_e\\ y_e\\ z_e\\ w_e\\ \end{bmatrix}$

接下來檢視一下OpenGL會用到的GLM函式glm::perspective(fov, aspect, near, far)。其矩陣原理如下:

$\begin{bmatrix} X_{spec} & 0 & 0 & 0\\ 0 & Y_{spec} & 0 & 0\\ 0 & 0 & -\frac{f+n}{f-n}& -\frac{2fn}{f-n}\\ 0 & 0 & -1 & 0\\ \\ \end{bmatrix}$

• fov: field of view，視野的意思，通常視野是45°，根據自定義而有所不同，至於為何是$cot$，看一下上上個矩陣，對邊分之鄰邊，而且視野只有一半。
• aspect: 視窗的比例，若視窗是500x500 這裡只要給1.0即可，若是800x600這裡就要給定800/600，在畫面就會顯示正常，原因是整個畫面要顯示-1 ~ 1的正方體，那x的部分就得多壓縮一點。

# 正交投影

正交投影，直接將點平行投影到投影近盤上，所以不會有$x_p$與$x_e$不同的問題，直接做線性轉換至NDC。

由於$x_e$與 $x_n$ 沒有像透視投影跟深度有關，所以矩正很簡單的如下:

$\begin{bmatrix} \frac{2}{r-l} & 0 & -\frac{r+l}{r-l} & 0\\ 0 & \frac{2}{t-b} & -\frac{t+b}{t-b} & 0\\ 0 & 0 & -\frac{2}{f-n}& -\frac{f+n}{f-n}\\ 0 & 0 & -1 & 0\\ \\ \end{bmatrix}$

# 直線與曲線

# 直線

直線，最常想到的第一個公式是 $ y = ax + b $ ，但是利用向量表示，在電腦繪圖中反而會比較適合做Intepolation。向量表示如下:

上方的公式意義是表示A要往B移動，如果t = 1，表示點P已經從A移動到B。小於1的任何數值都代表還在路途中，這樣的表示法比原本的表示法的移動模式要直觀許多。

####Intepolation(內插)#### 根據現有的資訊進行階段式前進，除了有關線的公式，利用向量步步前進的概念外，OpenGL在顏色上也有這樣的機制。Fragment Shader階段時，若使用者定義三個點各自的顏色，未給定其他像素的意義，OpenGL就會進行顏色的內插。假設有AB兩點，一者紅，一者藍，OpenGL就會自動用內插的方式進行顏色計算，概念如此: $Color_{new} = Color_A + t(Color_B - Color_A) = (1-t)Color_A + tColor_B$。而GLSL語法裡面進行這樣計算的是一個叫mix(a, b, t)的內建函式，專門用來處理以上的動作。

# 曲線

最簡單的直線是利用兩條直線的方式混和移動而成，概念圖如下:

透過兩條線瞬間產生出來的點，在將這兩點做直線移動就是以上的概念，當初Dowen看了許久，到這網站才了解到為何可以這樣混合公式的最初契機。這邊小題外話，有時候數學無法理解，是因為很多網站都沒提到其細部概念，也就是最初觀察到此現象的由來或契機，只說這樣是對的，然後用一堆複雜的數學佐證，所以才導致學習有礙。

剛剛其實就是有名的貝茲曲線，而這裡是介紹三次貝茲曲線，如果看懂的話，不論幾次也能自己推導了。

二次懂，三次問題就不大。這裡就提一個貝茲曲線上的專有名詞Control Point，像是上方二次貝茲的控制點就是ABC，三次是ABCD，藉由更改這些點的位置，就可以改變曲線角度，理解控制點，就可以微調算出想要的曲線角度了。

# GLM

GLM(OpenGL Mathematics)，是一個專門為OpenGL設計的數學函式庫，特別的是，它只需要將標頭檔加入，不需要引入lib，或是dll之類的組態檔，就可以引入環境中，所以不會有環境建置的困擾，首先只需要將標頭檔資料夾放到適當的位置，之後加入Include，就完成基本的載入。

之後加入泛用的程式標頭。

#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>
#include <glm/gtc/type_ptr.hpp>

測試一下矩陣乘法，理解一下概念。

glm::mat4 helloMatrix = glm::mat4(glm::vec4(1.0), glm::vec4(2.0), glm::vec4(3.0), glm::vec4(4.0));
int mlenght = 16;
glm::vec4 helloVector = glm::vec4(1.0f, 0.0f, 1.0f, 0.0f);
int vlenght = helloVector.length();
float *matrix = glm::value_ptr(helloMatrix);
float *vector = glm::value_ptr(helloVector);
glm::vec4 vresult = helloMatrix * helloVector;
float *result = glm::value_ptr(vresult);

std::cout << "Matrix:" << std::endl;
for (int i = 0; i < mlenght; i++)
{
	std::cout << matrix[i] << ",";
	if((i+1)%4 == 0)
		std::cout << std::endl;
}
std::cout << std::endl;
std::cout << "Vector:" << std::endl;
for (int i = 0; i < vlenght; i++)
{
	std::cout << vector[i] << ",";
	if (i % 4 == 0 && i != 0)
		std::cout << std::endl;
}
std::cout << std::endl;
std::cout << "Result:" << std::endl;
for (int i = 0; i < vlenght; i++)
{
	std::cout << result[i] << ",";
	if (i % 4 == 0 && i != 0)
		std::cout << std::endl;
}

這會產生的結果如下:

有發現結果不是正常的矩陣運算嗎?因為OpenGL在定義矩陣的時候都是先定義Column，再來才是Row，用數學來檢視一下結果的原因吧。

$\begin{bmatrix} 1&1&1&1 \\ 2&2&2&2 \\ 3&3&3&3 \\ 4&4&4&4 \\ \end{bmatrix} \begin{bmatrix} 1 \\ 0 \\ 1 \\ 0 \\ \end{bmatrix} = \begin{bmatrix} 2 \\ 4 \\ 6 \\ 8 \\ \end{bmatrix}$

上面如果是想要的結果，但實際上定義的向量是這樣被矩陣擺放的:

$\begin{bmatrix} 1&2&3&4 \\ 1&2&3&4 \\ 1&2&3&4 \\ 1&2&3&4 \\ \end{bmatrix} \begin{bmatrix} 1 \\ 0 \\ 1 \\ 0 \\ \end{bmatrix} = \begin{bmatrix} 4 \\ 4 \\ 4 \\ 4 \\ \end{bmatrix}$

因此，如果要修正的話必須要改成如下形式:

//glm::mat4 helloMatrix = glm::mat4(glm::vec4(1.0), glm::vec4(2.0), glm::vec4(3.0), glm::vec4(4.0));
glm::mat4 helloMatrix = glm::mat4(glm::vec4(1.0,2.0,3.0,4.0), glm::vec4(1.0, 2.0, 3.0, 4.0), 

這樣結果就修改完成了。

而glm::value_ptr這個函式，原始的定義是根據傳入GLM的參數，根據其最原始型態傳回該參數的指標。而本範例是傳入GLM矩陣、向量，使其傳回浮點數指標，或說是一段float陣列。

# 其他

# 四元數

# 不同的曲線

# 攝影機加入Roll旋轉

# 結語

在研究OpenGL上面會碰到很多數學，但是如果找對適當的文章或是解釋，就能打通那任督二脈。而Dowen就是那種需要自己尋找能理解的文章的人。因為有些網站，或是學校的教學方式，就是教學者自己沒咀嚼好，就抽象地教給學習者，所以導致教者不知學者所礙，中間有代溝。Dowen寫的教學文主要是想解決這樣的代溝，所以努力地做圖跟以自己曾經的困惑，自問自答的方式來幫助有同樣困惑的讀者。不過比較差的是以藍寶書的章節為出文的篇幅，如果以後有足夠的經驗與時間，也許會重新製作一份真正的初心者教學吧!

為了讓有興趣的初學者能踏入這個領域，Dowen把以前觀念上不清楚的部分全部在pipeline中補齊許多。縱使如此也是可能有疑點的部分，如果有疑問盡量在文章下方留言，有空一定回覆:D。

# CPU到GPU第一階段 - Vertex Shader的資料傳送

GPU在開始執行Vertex Shader前面，有一個動作稱為Vertex Fetching，這個動作會將我們在程式中寫的一個稱為Vertex Attribute的部分讀出來，而後傳送至GPU處。其中GPU必須由 layout (location = 0) in 來定義輸入要從GPU的哪個位置中取出，而CPU則是藉由 glVertexAttribXXX(0, data) 來將資料填入記憶體等待Vertex Fetching到GPU中layout的部分。

# 動手做 - CPU to GPU

首先在迴圈中加入要傳遞的資料與其對應的function，都是以 glVertexAttrib 開頭的傳遞函式。

glBindVertexArray(vertexArrayObject);

GLfloat data[] = {
	(float)sin(glfwGetTime()) * 0.5f,
	(float)cos(glfwGetTime()) * 0.6f,
	0.0f, 0.0f
};
glVertexAttrib4fv(0, data);
glDrawArrays(GL_TRIANGLES, 0, 3);

glBindVertexArray(0);

double glfwGetTime(void) : 回傳時間參數

void glVertexAttrib[X/fm/vt]()

• X - 有1,2,3,4等數字表達。
• fm - 以i代表整數,f代表浮點數,還有其他d,s...需自行參考Spec。
• v - 代表vector，也就是傳入陣列。

結果:

# 小優化

知道如何傳遞資料給GPU後，我們將三角形的資料提取出來，來從外部傳入三角形Vertex，而不要直接在Shader中寫死。首先將Shader改成以下都從外部傳入的形式。但是這次不用 glVertexAttrib來做連結了，原因稍後解釋。

#version 450 core
layout (location = 0) in vec4 offset;
layout (location = 1) in vec4 vertex;
void main(void)
{
	gl_Position = vertex + offset;
}