Support Function

看了這篇文章，很好奇為什麼

Support(v,-B) = (-1) * Support(-v,B)

於是就打開Geogebra玩看看

上圖的黃色區域叫CSO 

把刷子「水藍B」的每個頂點*(-1) 

可以得到刷子「草綠C」

C = -B

把「草綠C」的local原點(刷子柄)平移到M點

那麼「草綠C」就會平移到上圖的位置

把「草綠C」的local原點(刷子柄)在「粉紅A」區域移動

就可以製造出黃色的CSO了 像這樣

影片裡「草綠C」還是「黃色」的

如果你也想自己刷刷看的話 Link

Support(v,A) 幾何意義是：

找出A在v方向的最遠的點

所以

Support(v,A) + Support(v,-B) 就是：

找出CSO在v方向的最遠的點

當你拿著「草綠C」的刷子柄

在「粉紅A」區域移動(不能轉動刷柄)

Support(v,A)：

在「粉紅A」區域沿著v方向最遠的點是M

Support(v,-B)：

刷子「草綠C」沿著v方向最遠的點是F'

C = -B

點F' 對映到的點是F

F是刷子「水藍B」沿著-v方向最遠的點

但點F乘上(-1)才會變成「草綠C」上的點F'

所以

Support(v,-B) = (-1) * Support(-v,B)

//////////////

用「點」對人眼比較直觀

但上面的Support function其實是用「向量」在計算

比如說，把向量F和向量-v做內積

(如果是圓的Support function

只要從圓心延著射線方向走半徑距離就可以了)

四元數轉旋轉矩陣

如果你有1個正規化的4元數

q=(cos(θ/2),sin(θ/2) U)

q=(w,x,y,z)

這是它的共軛 

q*=(cos(θ/2),-sin(θ/2) U)

q*=(w,-x,-y,-z)

要怎麼得到等效的旋轉矩陣呢？

如果是左乘的話 vM

那旋轉矩陣M就是 

Xx Xy Xz

Yx Yy Yz

Zx Zy Zz

用四元數旋轉一個向量v

就是對向量v做三明治運算

 q (0,v) q* = (0,v')

這樣得到的v'

就是v繞著U軸轉θ的結果

這是單位旋轉矩陣

X軸：1 0 0

Y軸：0 1 0

Z軸：0 0 1

分別對這3軸做1次三明治運算

 q (0,X軸) q* = (0,X軸') 

 q (0,Y軸) q* = (0,Y軸')

 q (0,Z軸) q* = (0,Z軸')

X軸'、Y軸'、Z軸'分別是

X軸、Y軸、Z軸繞U軸轉θ的結果

現在，你可以拿這個旋轉矩陣

X軸'：? ? ?

Y軸'：? ? ?

Z軸'：? ? ?

來旋轉向量v了

Texture2D Bilinear

我當時用比較搞工的觀點

方法1

後來想過，其實可以用更簡單的觀點

方法2
需要把邊界也包含進來(上圖沒畫出來)

我發現TinySoftRendwrer

定義uv值(0,0)、(1,0)、(0,1)、(1,1)

位在貼圖最邊緣的像素上

(我是定義在黑色框框上)

所以他只要

把u mapping到0~(w-1)之間

把v mapping到0~(h-1)之間

uv mapping to u'v'

對 u'、v'取整數值，就能知道

雙線性內插左下角的像素索引了

6參數版本的Projection Matrix

一直以來都是Fov派

突然有點好奇 6參數的版本

他推導的這1步 我覺得不是很直覺

所以想了一下，還是換成自己好理解的版本

Oblique Matrix 推導的疑惑

為什麼Eric先生 (Thank U

要用(sgn(C'.x),sgn(C'.y),1,1)

而不是F * (sgn(C'.x),sgn(C'.y),1,1)呢？

Oblique Matrix矩陣推導 (Thank U

--------------

在projectin space

right平面和top平面會相交在1條線b

在b上的點，只有(F,F,F,F)是4個值相等的

而(F,F,F,F)/w之後

會得到 (1,1,1,1)

--------------

P是projection matrix (OpenGL Right Hand Fov version 

P的逆矩陣是 P^-1

P^-1 (F,F,F,F)=( Ratio F tan(θ), F tan(θ),-F,1 )=QF

P^-1 (1,1,1,1)=( Ratio tan(θ), tan(θ), -1,1/F )=Q

Matrix (Thank U

calculate

在view space ， w =1

Q = Q/Q.w =QF

Q和QF其實是同1個點

用Q和QF算出來的 a 也是同1個東西

(因為上下都有1/F，最後就互相消掉了

--------------

3D平面 vs 4D平面

平面在3D的定義是

(X-P)。N=0

X、P、N都是3維的向量

。是內積；P是位在平面上的1點

X。N-P。N=0

X。N+d=0

展開來就是

(x,y,z,1)。(Nx,Ny,Nz,d)=0

Eric文章裡C指的是(Nx,Ny,Nz,d)

把平面當成了1個4D向量

view space C變換到Projection space的結果是C'

fov=2θ(half fov=θ)

Right裁切平面的情況為(以下為右手座標)

C'  = (-1,0,0,1)

C  = (-1/(R*tan(θ)),0,-1,0)

在view space是

(x,y,z,1)。(-1/(R*tan(θ)),0,-1,0) =0

-x/(R*tan(θ))+z=0

在projection space(4D)是

(x',y',z',w)。(-1,0,0,1) =0

-x'+w =0

為什麼要在4D space裁切三角形

原本我覺得要在camera space作裁切

(用視錐的6個平面)

可再想想

我們使用數學庫生成projection Matrix時

zFar和zNear(in camera space)

其實是被編碼在Matrix的2個component上面的。

而傳給Verext Shader 的，可以有下面2種情況

第1種：MVP分開

第2種：MVP乘在一起

第1種情況

如果OpenGL知道你傳的是那一種Projection Matrix

可以用Projection的2個component

重新解出zNear和zFar(但這也是Camera Space的)

但OpenGL其實不知道你傳那一種

第2種情況

我猜不行

由上可知

它不需要知道zNear和zFar

projection space ( or clip space)

乘上projection Matrix之後，視椎體的fov變成了一定是90度角

(原來在camera space 時不一定是90度，但除tanHalfFov項之後就一定是90度了)

這樣一來裁切平面就變成有4個是固定的

(和y軸夾45度角的2個平面，和x軸夾45度角的2個平面)

備註：

線段和這4個平面的交點

平面方程式是 dot( (P-C),N )= 0

和y軸夾45度角的2個平面，其中1個是

N=(1,0,-1),C=(0,0,0)所以該平面是 x=z

三角形 Vo、V1、V2

其中的一邊所在的射線為

Vo+t(V1-Vo)

代入 x=z 平面

解出t就能算出交點了

 

能不能6個平面都在NDC裡作裁切？

4個平面不能在NDC裡裁切，原因是：

如果A點和B點構成線段L

而L和其中一個裁切平面的交點為S

在projection space空間裡，A、B、S三點共線

但在NDC space，這3點不能保證共線

(這一段是在OpenGPU論壇看到的，我只是把前人說的話，畫成圖)

✖️是和y軸夾45度角的2個平面

(x , y , z , w)是Projection space的點

(1)畫的是(x , y , w)

(2)畫的是(x/w , y/w , 1)

(3)畫的是(x/w , y/w , z/w)

這張圖的NDC z是位在0~1之間

你會發現B的位置跑掉了

projection space ( or clip space)

仔細看clipping裡的條件

它說6個平面都可以在

projection space判定是否需要clip

為什麼？

以Directx為例

model view projection 全部使用左手座標

view space的頂點為V_v =(x_v , y_v , z_v)

projection space的頂點為V_p = (x_p , y_p , z_p , w_p)

z_p = a z_v + b

w_p = z_v

NDC space z_n = z_p / w_p

當V_p在近平面和遠平面之間

z_n會落在0和1之間

0 ≤ z_n ≤ 1

0 ≤ z_p / w_p ≤ 1

0 ≤ z_p ≤ w_p 式A

當V_p在遠平面外面

z_n > 1 

z_p / w_p > 1 

z_p > w_p 

當V_p在近平面外面

z_n < 0

z_p / w_p < 0

z_{p <} w_p

所以用式A就可以判定是否需要clip

完全不需要知道近遠平面是什麼！

(OpenGL也是類似的道理)

當三角形的2個頂點V₀和V₁需要被裁切

對線段做插值就可以得出裁切平面(遠平面)上的點

(視錐的其他5個平面也可以套用類似的方法)

NDC之後還有1次z的remapping

glDepthRange

 

參考資料

• 虎書某一小節好像有提到
• 雖說只挑了重點看 Scratchapixel 2.0 - clipping

寫完軟光柵後

圖 Screen Space

先解出t,s找到點hit，就能算出α

發現其實不必在Clip space裁切左、右、上、下

因為在Screen Space 光柵化三角形前

會找出包圍三角形的矩形

而這個矩形又會受限於Screen Space的大小

效果等於在Clip space裁切左、右、上、下

Code

但是不裁切的話

矩形超出Screen外面的部分

也會在loop裡

雖然沒做任何事

實作中發現的有趣效果

Demo

透視校正

假設三角形的3個頂點

在modle space是A_m、B_m、C_m

頂點乘上Model View Projection Matrix(MVP)後

變換到Projection space
MVP(A_m) = A、MVP(B_m) = B、MVP(C_m) = C

A(x)代表存取頂點A的屬性x，以推類推

B(w)代表存取頂點B的屬性w

找出P(w)

透視校正就是
透過P(w)反推出「在黃色三角形上內插的結果」

用ASM實現Navigator效果

用Unity的ASM硬幹Navigator

ASM(Animation State Machines)

stacknavigator和tabnavigator

其實就是在處理狀態的轉移

所以用ASM就可以搞出一樣的效果

下面的狀態機是參考自這個頁面的UI配置

• murobox

當時在練習使用Unity的UI ( 還不是為了 😍 錢錢

區塊代表的意義

• 深橘色是大狀態，用來達到tabnavigator的劃分功能。
• 淺橘色是子狀態，用來達到stacknavigator的回朔和記憶(memory)功能。

線段代表的意義

• 淺藍、深藍線代表由上而下，比如說「Selector」到「音樂庫(1)」；
• 或是「memory」到「全部樂曲」；只要從「memory」出發的就會是深藍線。
• 紅線代表由下而上，比如說「全部樂曲」返回「音樂庫」。

舉個例子

• User正在「全部樂曲」Panel。此時他點擊分頁按鈕「我的清單」，會產生goTop訊息給State Machine，「Any」子狀態收到goTop後會轉移到「Selector」狀態；「Selctor」狀態依據target會前往「我的清單(2)」狀態，並進入「memory」子狀態；假設之前已經進入過我的清單，而且是停在「清單樂曲」，就會由「memory」直接轉移到「清單樂曲」。
• User正在「清單樂曲」Panel，這時他點擊其中一首曲子播放，於是「播放曲目」Panel會更新正在播放的曲目資訊。接著他點擊「播放曲目」Panel上的編輯按鈕，會產生goTop訊息，「Any」子狀態收到goTop後會轉移到「Selector」狀態；「Selector」跟據target會前往「編曲(3)」狀態。當他編曲結束後按某個按鈕會產生goTop，然後轉移到「Selector」。由於from有記錄他之前是在「我的清單(2)」狀態，「Selector」會把他導向那裡。進入「memory」後因為有過去的記錄，接著又導向「清單樂曲」狀態。
• User正在「清單樂曲」Panel，此時他點擊分頁按鈕「編曲」，會產生goTop訊息，「Any」子狀態收到goTop後會轉移到「Selector」狀態；以下的Flow就不再重述，但是這個動作會產生新的編曲，而不是編輯舊的曲目。

DB的部分

那時傻傻的，沒想過可以直接用json做假資料

結果就把db的部分也硬幹出來了

UI長這樣

果然還是需要專業的配色呢

想了一下ig可能怎麼實作

UDP VS TCP

 如果1個程式是1個隨身碟；那usb插槽就是1個port

假設現在有隨身碟Server(S)、隨身碟Client(C)

UDP：

當要從S傳檔案A.txt到C，就要自己從S剪下，找到隨身碟C之後再貼上

(使用UDP，必須要提供另一端的ip和port)

TCP：

當C和S連線之後，會在S裡建立一個資料夾捷徑L(指到C裡的F資料夾)

當要從S傳檔案A.txt到C，只要剪下A.txt直接貼到L，這樣F裡就有A.txt了

(TCP在連線之後，已經記下了對方的ip和port)

TCP Sample Code

http://cs0.wikidot.com/chatbox

上面的程式碼

newsock.Bind(ipep);

newsock.Listen(10);

Socket client = newsock.Accept();

Socket client會設定2個port

localPort就是newsock使用的port (=20)

remotPort則是連進來的遠端程式使用的port

所以Accept得到的Socket並沒有佔用新的port

http://blog.csdn.net/tanyjin/article/details/69403220

WebSocket?

https://blog.zengrong.net/post/2199.html

Port

之前不懂

Server和Client程式為什麼可以在跑在同一台電腦上?

原來是因為:Server和Client是使用不同的port

比如說當程式和port 5555綁定

就可以透過5555來接收和傳送訊息；

但沒有限制一個程式只能和一個port綁定

https://zhidao.baidu.com/question

LinkA http://cs0.wikidot.com/udp

上面的程式碼

sender.Port

可以把sender的Port印出來，會發現它不是5555(而是發送端的port)

Console.WriteLine("Port:"+sender.Port);

在bind時使用Any的原因

(為了讓內網和外網的ip都可以被連到)

http://blog.csdn.net/farmer_worker

如何改成可以雙向傳送訊息?

Client-> Server

Server-> Client

Client也必須在1個port上綁定

這樣Server就知道要傳訊到那個port

發現比起用Socket，有個更方便的UDPClient

system.net.sockets.udpclient

非同步版本的接收/發送

zh-tw/library/h0kz38kh

半球積分與面光源積分 🐞

➡️ 目錄

開端

故事的開端是，我看了網上的LearnOpenGL CN 光照
在讀程式碼的時候，嗅到了1些不對勁

程式碼片段，來自LearnOpenGl CN 光照

於是我開始展開調查
這麼說來，我小時候的夢想，就是想做個警探呢...
(有點像Jacky的電影那樣，不是像現在這種版本)

如果你覺的這隻馬很面熟
對他叫熱鬥小馬，不是我原創的

後來我漸漸明白，「L的定義」再加上「BRDF的定義」，
從這2個地方出發，可以得到渲染方程

L是什麼？

我們從L的定義出發，真實世界只有面光源
但遊戲世界充滿了點光點，所以先看點光源

• 點光源的L 👩‍🔬

再來是面光源

• 面光源的L 
• L_c  = dE / ( dω cos(θ_o) )

除以cos(θ_o)，是為了讓每個方向的L都是定值
計算光照時，會再考慮cos(θ_o)的影響

入射光源的Cos(θ_i)項

ΔA_s 是 shading point的微小面積

能全部擊中shading point dA_s的是dE_i

Integrals over Area 式(5.6)

Integrals over Area
E = ∫ dE
出處

dω_i = cos(θ_o) dA / r ² 
dE⊥ = L dω_i
dE = cos(θ_i) L dω_i

使用L_o = L_c * cos(θ_o) 
dE_i =cos(θ_i) L_o dω
dω = dA / R_i ² 
也能推導出同樣的結果

渲染方程半球積分的dω

當初被點光源帶偏了

怎麼都想不通為什麼dω要從ΔA_s的視角出發

於是我認為半球積分裡需要 (1 / R_i ²) 項

半球積分裡多了 (1 / R_i ²) 項 🐞

修正 🐞：

• 半球積分的1/(R*R)？ ⭐⑤
• 半球積分的Li dωi ⭐⑥

現在，讓我們回到故事的開端

重新檢視LearnOpenGL CN 光照的程式碼
橘色圈起來的那個
其實應該叫irradiance (會隨距離衰減的E⊥_i)

• 點光源的謎團 ⭐

程式碼片段，來自LearnOpenGl CN 光照

面光源的L (Radiance的cos項？)

➡️ 目錄

面光源的L

上圖來自advanced global illumination

魔改一下會變成

L_c cos(θ) = dE / dω 式①

會發現面光源的radiance在每個射出方向並非定值

• L_c 為定值
• L = L_c * cos(θo)

上面的式子畫起來就像這樣

利用半球面積投影到法向量平面 = 圓面積

可知 ∫ cos(θ) dω_o = π

如果把式①移項

L_c  = dE / ( dω cos(θ_o) )

我們就能讓radiance在每個射出方向為定值

這樣日後再使用的時候會比較方便

舉例

現在給你1個面光源Φ

面光源的面積A 

Φ在表面上均勻分佈

就可以算出 L = Φ / A / π

對函數進行旋轉

 

用座標變換 對函數進行旋轉

轉45度也可以 只是GeoGebra不能畫

要用別的軟體畫

Diffuse BRDF推導過程的疑惑

➡️ 目錄

CG 魚書ch 13.8裡Perfect Diffuse BRDF的 推導過程

reflectance即albedo(texture color)
(13.9)就是render equation裡的半球積分 只考慮RGB其中1個component (且值為1) 有Diffuse BRDF為 F= 1 / π

有個地方讓我困惑

第1個黃色

告訴我們
往不同方向出去的L_o有個cos(θ_o)修正

第2個黃色

卻告訴我們進入dA 的E 會平均分到半球的各個方向 (各方向出去的L_o為定值)

實際來算算看

假設所有L_i都相等

當F = 1 / π

跑1次 式13.11

E = ∫ cos(θ_i) L_i dω

會得到 E = Li * π 式B

跑1次 式13.9

L_o = ∫ F cos(θ_i) L_i dω

會得到 L_o = Li * F * π

使用F = 1 / π

會得到

L_o = L_i 式C

(代表E在任1個方向o會產生L_o)

那所有方向o 就是跑1次 式 13.12

E = ∫ cos(θ_o) L_o dω

E = L_o * π 式A

因為式C 所以

式B = 式A

E = E

能量守恆

如果跑式13.12 時忽略cos(θ_o)項

E = ∫ L_o dω

E_o = L_o * 2π

就沒有能量守恆了

當F = cos(θ_o) (1 / π)

跑1次 式13.9

L_o = ∫ F cos(θ_i) L_i dω_i

會得到

L_o = F L_i ∫ cos(θ_i) dω_i

L_o = cos(θ_o) (1 / π) L_i π

L_o = cos(θ_o) L_i 式D

再跑1次 式13.12 (不使用cos(θo) )

E = ∫ L_o dω

會得到

E_o = ∫ L_o dω_o

E_o = ∫ cos(θ_o) L_i dω_o

E_o = L_i ∫ cos(θ_o) dω_o

E_o = L_i π

實際來畫畫看

光用猜的也知道

用F = cos(θ_o) * (1 / π) 的結果會很奇怪

現實生活中沒看過球的輪廓是黑黑的一圈

F = 1 / (π)

F = cos(θo) * 1 / (π)

到底那出了問題？

看起來像是

迷團(1)

面光源進行直接光照的計算

L_o要乘上cos(θo)

迷團(2)

從diffuse物體直接到達眼睛的L_o不用

為什麼有(1)和(2)的區別？

迷團(3)

如果直目(直接目視)面光源

面光源對眼睛來說是L_o 還是 L_o * cos(θ_o) ？

解開迷團？

我感覺迷團(2)的答案和透視有關

透視不只是近大遠小

還包括dA的朝向

• L的cos(θo)