projection in vertex shader

一般的perspective projection ：

在 vertex shader 動手腳的 projection：


不知道為什麼下圖有點走樣，不過似乎可以靠vertex shader 讓 z 值變成線性的，這樣的話應該可以避掉z fighting，效能差多少就不清楚了。

deferred lighting

In the beginning, I wanted to know how "light pre-pass" works. But I couldn`t catch that idea easily. Then I started to study defered lighting. Finally, I make a sample after wasting whole GPU powers. (yes, I implement it without any optimazation !) Here is a screenshot, 128 point lights rotate around each balls. It looks like the reflection of wave can be implemented by the same way.

UNORM v.s. UNORM_SRGB

DXGI_FORMAT_R8G8B8A8_UNORM_SRGB :

DXGI_FORMAT_R8G8B8A8_UNORM :

DXGI_FORMAT_R8G8B8A8_UNORM 才是我要的結果！dx 10 DXUT 的back buffer format 預設只選DXGI_FORMAT_R8G8B8A8_UNORM_SRGB！

p.s. 材質是這裡來的。

國三數學課本

國二時在外掃區撿到一本國三的數學課本，課本都寫得淺顯易懂，所以兩三下就翻完了，也覺得幾何題很有趣。不過由於沒有過人的天賦，加上注意力很容易因為其他有趣的事轉移（像是做白日夢），所以「高中聯考」之後就只碰過幾分鐘的幾何學。大一時學校的總圖還沒搬家，悶熱的空氣加上愛打瞌睡的天性，還來不及沉浸在剛找到的幾何學書籍，就結束了短短幾分鐘的邂逅！

中午在麥當勞的白日夢上演了這段往事，記得國三時的一次考式，卷子上的幾何題出得比較特別，寫完證明方法後整個欄位都被填滿了，然而交換卷子後同學卻說他看不懂，那時我還很有自信的請他去問老師對不對，結果是對了，不過老師說：「不知道我是怎麼學的！」事件的經過不怎麼重要，不過這讓我開始意識到自己思考問題的方法，直到現在都是同一個模式。

如果問題是A，答案是Z，可能存在最佳解法M，我的思路常常變成ABCZ或是ADEMZ，B或D是前幾個在腦袋裡浮現的解法，是「邏輯上」可行的做法，然後不斷的往前延伸，直到一連串邏輯上可行的解法達到Z，因為M比其他的路隱晦許多，所以雖然沒找到最佳解，但通常可以很快地找到可用解。壞處是只要問題夠複雜，這個方法就容易走進死胡同。即使是寫程式，整個流程也是這般流泄而出，通常能很快的寫出可行的程式，再花時間最佳化。就算一開始就找到M，也沒人能保證A到Z之間有更好的解法，也許把紙對折，A和Z就自然碰上了。

三年級的數學作業有這麼一題，一段圓弧跟圓弧外的點A，畫一條直線連接A跟圓弧的圓心。問題很簡單，在弧上畫兩段不重疊的弓，它們的中垂線會在圓心相交。不過當時我可不是這們寫的，因為題目的位子畫得太好了，所以只要以A為圓心，畫個弧能夠跟本來的弧線有兩個交點，那可以少做很多事……所以從國中開始，我就有當程式員的徵兆了嗎？

when to SSE ?

Long long ago, when I playing with Jaina, I don`t know why my Jaina can`t act as smooth as Blizzard`s. But there is a rumor about how to make Jaina move more like a really young girl. SSE is the first solution.

I don`t find any document about cost of SSE (ohh...I`m lzay, you know that...). But in my experience, there is a simple rule. The most general usage of SSE is matrix multiplication. And there are many many multiplication in bone skin animation. But you`ll find it cost more CPU power if you only write SSE to do "one" vector multiple "one" matrix.

The simple rule is :
if the number of vector multiplication is more than double of vector IO, SSE will gain higher performance.

For example, the dot value of 2 vectors need 3 IO (2 vectors in, one value out), but there is only 1 vector multiplication. Another example is vector multiple matrix, 6 IO (5 in, 1 out) with 4 vector mul ...... so we still can`t get better performance.

But in the bone animation case, there are less bones with many many point. That means many points will mul the same matrix in each frame. If you have to mul N points, you need :

1. 4 vector reading from matrix.
2. N vector reading from points.
3. N vector writing to points.
4. each point need 4 vector mul.

Ignore the 1`st one, it just meet my simple rule. So there is a chance make my Jaina act more smooth. (Just write a function to mul many vectors to one matrix).

BTW, there are many 0 in normal 3d matrix......that`s another story.

座位上的小丸子

某次公司發了粉筆跟一個杯子，要我們發揮創意在杯子上塗鴨！創意我是沒有的，所以拿起粉筆就在旁邊的牆上描了個小丸子！

WarHammer[3];

中間的棚子有 LOD ……就在這麼近的距離下，玩game 的時候都在注意這些會不會太無趣了 XD

WarHammer[2];

這個世界充滿了泥濘，讓我走起路來像缺了條腿！其也沒這麼誇張，只是不管走到哪，都覺得頓！現在終於讓我抓到凶手了，請看：

抬頭望天，晃晃角色的視野，這時會頓！

低頭撿錢……好順啊！怎麼會這樣？看到第一張圖的紅圈圈了嗎？再來比對這一張：

樹林滿是三角形啊！看起來密密麻麻地貼了好幾層！地上的灌木叢也是：

看來這比wow豐富多了！只可惜在wow的荊棘谷時，我一樣腳步輕盈，從來不覺得自己太胖該減肥，即使控制的角色是隻大笨牛！樹林看起來相對豐富，但似乎是用三角形換來的，難怪控制起來舉步維艱啊！

WarHammer[1];

這個遊戲最最最明顯的問題，就在人物移動的時候常會莫名其妙卡點！玩了兩個星期，常常亂跑亂跳後就以為自己卡點了，還得亂跑亂跳一陣才能脫離！傳說中，戰鎚的特色之一是玩家間的碰撞，人物間的碰撞應該不是難題，大概就是OOBB吧！但是玩起來著實讓我很難過，邊放法術邊移動，不但要看敵方從哪個方向跟來，還得注意前方是不是有身型瘦小的種族擋路，被擋住就完全不能前進，不會因為按著前進就慢慢的滑開。至於怪物就沒有碰撞了，他們打我的角色時，可就經常利用這一點，穿過角色身體，從背後開始攻擊！

上圖，我穿不過一個在火盆與旗子之間的空隙，因為bounding box 卡到火盆了，完全無法前進。

所謂仁政

「追根究底來看，所謂仁政，只不過是創造一個老實人不會吃虧的社會而已。」

塩野七生．《羅馬人的故事 IX》

WarHammer[0];

最近玩戰鎚，不過大概快玩不下去了，bug很多，而且G1S跑起來也不順，3G的RAM加上8600GT還不能順暢的運作，這個game一定有些問題，雖然設定上還有些意思，但我從第一天開始就覺得：無論美術程式，都無法與Blizzard 打對台。今天累了，提一個奇怪的rendering bug就好，其他有空再說。

圖不是很清楚，左上角紅框裡還有個「方框」，喔不！這是個誤會，實際上那是盞燈，週遭則是充滿煙霧（風沙？）的場景，會跑出個這麼突兀的方框是 z check 跟 z write 的問題，燈看起來是張textue (texture animation？maybe）的billboard，屬於半透明物件，整片煙霧也是半透明物件，這兩個東西都會等到整個場景畫得差不多後才會畫上去，為得是半透明的渲染未經排序的話結果會是錯的。我猜問題是這樣發生的：燈影跟煙霧畫的順序不一定，有時燈先畫，有時煙霧先，所以這個問題不是一直存在。接著，畫燈影的時候 z write 是開著的，畫霧的時候 z check 是開著的，結果燈先畫的話，因為 z write（z 值還可能是錯的），導致畫煙霧時 z check 後沒辦法畫那一塊，最後就生出一個方框了。

ZZzzZzZzzzz...快睡著了......

why UnAdvise ?

If you are familier with COM, you would usually work with AdviseFooEventSink / UnAdviseFooEventSink. You have to call UnAdviseFooEventSink explicitly somewhere ...... it`s better not in the scope of this event sink, especially in the destructor of event object. But WHY ?

I try to demo something by directshow recently. When working with filter, I made some mistake in accident today. I did something like UnAdviseFooEventSink in the destrucotr of event object. Let`s check what happen :

1. when the event sink object is created, the reference count should be 1.
2. when Foo Advise the sink object, reference count of sink object increase to 2.
3. when I don`t need the sink object anymore and try to release it, reference count decrease to 1.
4. Now the owner of the sink object is Foo, and I wish sink object to be UnAdvise when being deleted.
5. Since Foo is still the owner of sink object, sink object won`t be deleted if Foo doesn`t do extra work.

Thanks for the debugging function of baseclass of dshow, I got some ugly assert and try to fix it.

BTW, the same isuue would happen in cocoa of Mac, too. If 2 objects are the owner of each other (retain each other), they should be disconnected before release the final reference outside of the scope.

some methods to optimized gui rendering.

I thought about gui rendering today and got some ideas. Here is a brief note (but this should be useless since ui rendering is an old topic).

Sometimes we have to render ui with 3d API such as d3d. For example, it`s hard to rendering ui with video without d3d on windows. The generic method to rendering gui is to render many "rectangle", like buttons, checkbox, combobox, etc. Each rectangle need one draw call. When there are too many controls (include text), it may call draw primitive too much times and start to affect the performance. There are some points we can try :

[1]. Sort entire gui rendering by texture. The first issue make us render rectangle one by one is : all images may not on the same texture. For controls that share the same texture we have a chance to draw many "triangle list" to reduce the draw call.

[2]. Separate gui to dynamic & static part. All controls share the same "dynamic" vertex buffer. For dynamic controls, changing vertex position to move their position. For static controls, their position is fixed. So all vertices in the buffer can sort by their state to 2 part, too. Then there is a chance to minimize the vertex update method.

[3]. All controls share the same "dynamic" index buffer. For those hided control, we can just ignore them by not applying index. Sort the index could get better performance, too.

[4]. If there is alpha controls, separate them to another pass......or everything is gone.

[5]. So now you can :

1. get a single texture with all images of controls.
2. update position of dynamic controls by update vertex buffer.
3. update visibility of controls by update index buffer.
4. collect all characters in the same texture (or less textures)
5. pray.

[6]. I am kidding... please inform me if you tried it.