歲月流轉(zhuǎn)，往昔空明

上次用boost.python的時候boost還是1.33的時候。

那個時候剛剛開始看shader的東西，就用boost.python做了用python做shader語言的演示。
其實當時看boost.python完全是半懂不懂的。
這段時間找了個C的數(shù)值庫，要Python的接口，Python For C的Interface又懶得使用，還是用boost.python把一些我要的功能給封裝出來好了。
結(jié)果一看才發(fā)現(xiàn)對Boost.Python的理解好了不好。

看來人都是在慢慢進步的。。。哈哈。

以前看D3D的時候，就發(fā)現(xiàn)骨骼動畫是個有點難以掌握的東西。
但是也可以說，骨骼動畫是3D齊次空間變換的集大成者，掌握了骨骼動畫，差不多3D空間變換你也就掌握了。
其他所有的層級變換，基本上都不會脫離骨骼動畫需要你了解的東西。

網(wǎng)上骨骼動畫的demo多如牛毛，我空間想象能力不行，看過無數(shù)資料都不大明白骨骼怎么轉(zhuǎn)，皮膚怎么蒙。況且那些基于DX、基于GL的代碼都長的不行，難看的明白。

前兩天vczh搞了個C#的弱智版的2D物理Engine，我今天就搞個C#和GDIPlus的低能版骨骼變換。雖然是2D的，但是原理和實現(xiàn)基本和3D的完全一樣。希望這已經(jīng)簡單到不能再簡單的代碼能幫助大家搞明白骨骼動畫是咋回事。

代碼框架上都有注釋了，矩陣使用的是Sharp3D的數(shù)學庫，已經(jīng)在包中了。不過也就用了矩陣乘法和矩陣-矢量乘法，還有一些矢量加減法。

源代碼在此下載。

2樓的回帖給了一個地址，是關于骨骼運動變換的數(shù)學推理和理論解釋，還討論了左右手系的問題。理論上有問題的親們可以參照此篇文章。

截圖：

 

Blend Shapes 放在一個固定的數(shù)組bsVertices中,
按照

S0V0, S0V1 ... S0VN, S1V0 ... SMVN
的形式存放.

numBS說明了有多少個BS被混合，也就是slots的大小;
bsPitch為SxV0 - SxVN的長度;
bsOffsets[i] 代表第i個slot使用了哪個BS.

最近開始抽空在看GPU Gems 3了。本來想挑幾篇全文翻譯，但是無奈自己英語水平薄弱，同時最近老板逼得緊，也沒有那么多時間，于是便準備以導讀的形式，將文章的主干部分翻譯出來,幫助英文不好的筒子們。
導讀也是我自己讀書的總結(jié)。文章的核心內(nèi)容一定會提及.圖和源碼，通常我會標注上對應的圖書上的figure和list，各位自行參考。基本維持原文的篇章段落，但是一般不會逐字句的考究。
至于能有多少篇，我倒是不能保證。不過我所用的電子版是那個26M的chm，我讀的時候會把它翻成PDF并加注，如果有筒子需要我注釋后的pdf，可以與我聯(lián)系：

mail： wuye9036   _AAAAATTTTT_ google _dotdotdotdotdot_com

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

Chapter I 運用GPU構(gòu)造復雜的過程化地形
1.1 Introduction
過程化地形的應用已經(jīng)有不少的歷史了，Game Programming Gems 2上就已經(jīng)有了不少成熟的過程化地形的方法，比方說隨機斷層、基于噪聲的、基于分形理論的、中點分割加擾動的。
不過這些算法在現(xiàn)代硬件上都時有缺陷的，特別是針對規(guī)模很大的地形，要么只能在CPU上實時生成，要么就得預存儲起來，但是不管怎么說都面臨著很大的資源開銷；其次這些算法都是只能生成有些起伏的平面，沒辦法表現(xiàn)山洞、巖石凸角一類的3D特征。本文運用DX10的Geometry Shader與Stream Output，彌補了上述兩個缺陷。

1.2 移動立方體與密度函數(shù)
要解決3D的地形特征，首先要解決3D地形特征的表達問題。文中將空間劃分為多個Blocks，每個Block代表了世界坐標系中1*1*1大小的空間。每個Block由一個3D紋理來表達。由于使用了過程化的方法，每個Block可以在運行的時候動態(tài)生成，這樣只需要保留那些能看得見的blocks，從而解決了存儲問題。
概念上，一個3D的地形可以由一個密度函數(shù)來表達。對于每個空間中的點(x, y, z)，都有唯一對應的密度值。我們假設，對于任意一個空間中的點，如果點在地形內(nèi)部/巖石內(nèi)部當且僅當點上的密度值大于0。那么小于0的點，自然就在地形之外，如在空氣中，水中等等。而巖石表面上的點密度剛好等于0。
那么自然，這些巖石表面上密度值等于0的點，就是我們要繪制的“表面”。
在將空間劃分為Block后，還要將每個block進一步細分為多個voxel（體素）。我們假定體素內(nèi)密度變化時連續(xù)的。那么很顯然，如果一個體素的頂點上密度有正有負，那么必然里面會有一個（也有可能是多個）0值面。問題就轉(zhuǎn)化為，如何根據(jù)體素各個頂點的密度值，求出這個體素內(nèi)的0值面。如果再把這個假設限定的嚴格一點，如果體素內(nèi)密度變化是線性的，那么這些面可以由0-5個三角形來表示；求得這些三角形的方法，被稱為Marching Cube算法。
很顯然，有多少個三角形，每個三角形的頂點落在哪條邊上，是由八個頂點的密度的正負值所決定的，而值的相對大小則決定了三角形的頂點在邊上靠近那個頂點。那么也就是說，一個體素內(nèi)0值面的分布共有2^8中情況。如果頂點密度為負，那么標記為0，頂點密度為正則標記為1，則八個頂點的情況可以由一個Byte來表示。

圖1-3

如果這個字節(jié)的值為0或者為255，那么說明所有的頂點都為正或為負，那么說明體素中并沒有地表面。Martin Frank為剩下的254中情況建立了一個查找表。其中基本的情形有14種，其余的均可由這些基本情況的對稱或旋轉(zhuǎn)求得。

圖1-4

當確定了三角形的三個頂點分布于哪些邊上后，便可用插值的方法求出所在位置。頂點將位于0值點處。例如，一條邊AB上有一個0值點P，如果A的密度0.3，B的密度-0.1，那么PB的長度是PA長度的三倍。

1.2.2 查找表
上文已經(jīng)提到了如何通過體素角點的密度值，就會知道會生成哪些多邊形；這些多邊形的頂點落在哪些邊上。
接下來，我們將用討論這些理論如何在GPU上實現(xiàn)。
首先我們建立一張查找表
int case_to_numpolys[256];
其中每種情況能產(chǎn)生多少個三角形。
第二張查找表，
int3 edge_connect_list[256][5];
這張表保存了每種情況對應的5個三角形。并且我們將一個體素中的12條邊按照0-11編號（圖 1-5），則查找返回的返回的int3指出了，每個三角形的三個頂點分別落在哪條邊上。

圖 1-5 Case 193 的0值多邊形情況

下面的例子很好的說明了這一點。
我們以case 193為例。193總共有3個三角形，那么case_to_numploys[193] = 3，其次，edge_connect_list[193][]返回這樣的結(jié)果：

int3 edge_connect_list[193][0]: 11 5 10
int3 edge_connect_list[193][1]: 11 7 5
int3 edge_connect_list[193][2]: 8 3 0
int3 edge_connect_list[193][3]: -1 -1 -1
int3 edge_connect_list[193][4]: -1 -1 -1

Geometry Shader在查找了這兩張表的信息之后，并計算出頂點在邊上的具體位置，便會返回3個多邊形列表所需要的9個頂點。由于創(chuàng)建Marching Cubes查找表需要很多的計算量，因此建議預先計算好并在運行前載入。該表在光盤上可以找到。

     摘要:
討論腳本編程與靜態(tài)語言的異同點，
總結(jié)一下近期腳本編程的心得，
吸取教訓，
并歡迎大家探討、指點。  閱讀全文

這個設計主要是拿來保證跨組件的時候能盡可能的保護型別安全.

我今天晚上早些時候也往SoftArt里面提交了一個type to id的實現(xiàn),使用宏和特化機制
但是這個版本的一個很大的問題就在于用起來不是很方便,每注冊一個類需要2行代碼,而且都是
#define PARAM float
#include REGTYPE()
這樣的非常規(guī)的宏用法.
但是由于它是分類實現(xiàn)的,所以可以在里面補充一些額外的功能,比如自動的具名常量的生成.

所以晚上回來的時候又用boost的mpl寫了一個原形,基本上是純模板的.注冊類只需要一行,但是宏實現(xiàn)版本中一些半自動化的特點也損失的差不多了.
回頭還是要考慮用preprocessor結(jié)合MPL,看看能不能做到兩個特點兼?zhèn)?

mingw + gcc 4.2.1下通過

2月22日更新：
修改了項目設置（大換血。。。）。昨天下過的最好重新check out。

2月21日更新：

已經(jīng)將SoftArt整體放置到SF的SVN上了。

SVN地址： https://softart.svn.sourceforge/svnroot/softart/prealpha
svn co https://softart.svn.sourceforge/svnroot/softart/prealpha softart

由于目前的渲染器離成品還很遙遠，所以就沒有以Release的形式放出。Version 6 中，CartoonDemo大家可以自行從solution里面移除；EFLIB需要項目地址上下載Release，然后在VC環(huán)境中另行設置，給大家?guī)淼牟槐闵畋砬敢狻?br>
2005 SP1 下通過（有點bug）

感謝亨德列克和叛逆者兩位前輩的無私指點（不管哪一方面都是，從技術(shù)到態(tài)度到Fix Defects到New Ideas），非常感謝～～～拜～～～

該軟件渲染器名字就叫SoftArt，本來準備叫做ColorfulSnail（哈，因為Debug的時候它的運行速度是在是太慢了），但是無奈Snail已經(jīng)被人注冊過了，所以就還是叫這個名字了。
每個開發(fā)階段我都會有一個項目代號，目前的這個還是prealpha階段，所以就叫prealpha好了。

今天放上去的是支持庫Essential Functions Library，大家可以去我的項目地址下載。

https://sourceforge.net/projects/softart/

也叫Efl Functions Library，提供了一些基本的數(shù)學工具（比方說基本的向量和矩陣的運算）。項目的主體代碼我需要將接口整理完畢以后再行發(fā)布。目前僅https://softart.svn.sourceforge.net/svnroot/softart/prealpha 支持VS2005編譯器，很快會考慮2008和GCC 4.2 or later。

希望大家有什么意見和建議盡管提出，我一定會盡可能將大家的想法加入到我的TODO LIST中。

     摘要: 總結(jié)了我在以往項目中使用設計模式的經(jīng)驗；
我閱讀《設計模式》的心得；
討論一些在閱讀時產(chǎn)生，實踐中解決的困惑，為設計模式新手提供一條可以參考的學習路線；
并希望與老手們一同探討、交換：
設計模式在實際中使用中的經(jīng)驗與教訓；關于拓展現(xiàn)有設計模式、聯(lián)合使用多個設計模式的案例和思路。  閱讀全文

我也不知道這個能不能算是2005的bug吧，反正我是想不太明白。
今天在對我的pool使用policy的設計的時候發(fā)現(xiàn)的。

看起來這段代碼是完全能正常工作的，是吧。可是很不幸的是這代碼在2005上沒法正常通過。
解決的方法很簡單：
typedef ThreadingModel TM;
typedef TM::thread_safe_type<size_t>::result index_t;
就可以大功告成了。不知道是不是typename的問題。但是從編譯器的出錯提示來看并不能和簡單的typename的問題混為一談。另外，如果這個thread_safe_type不是模板而只是一個普通的struct或者typedef的話，也是沒有這個問題的。

如果有知道這個問題出現(xiàn)的根本原因的，請指教。

今天把軟渲器前后跑了一下，排掉了z buffer的一個很惡心的bug后，終于順暢了。
雖然前前后后的球啊、方盒子啊、平面啊測試了不少，但是差不多像Demo的這還是頭一個。
由于不支持復雜的ddx、ddy（ps僅僅支持求輸入寄存器的ddx ddy），因此ps30的很多東西就沒法做了。

一開始實現(xiàn)的時候沒考慮GS，所以也就沒有ps40可言。
不過對于軟件渲染器來說，沒有GS，以及沒有DX11的TS也算不得什么硬傷。

博客的文章上，這之前還缺設計模式的最后一個話題沒講完。
等結(jié)束了尾巴話題以后，就簡單的說一下軟件渲染器的問題。
其實沒有什么太大的難度，代碼量也不大，核心庫也就8K行代碼。

源代碼由于還比較混亂（主要是很多地方都是雙向），所以還沒有放出來。準備在我放假前放到sourceforge上，這也是我答應了叛兄的。
然后可能要在他的幫助下把SR規(guī)范一下后作為KlayGE的software renderer plug-in用。

這是一個勾邊的Demo。原理很簡單，先正面渲染一次，再沿法線拉伸一下模型，背面渲染一次。
效果圖。

光擺圖我也不敢放首頁啊……
主要是征詢一下，這段時間我做什么Demo比較好（如果有太復雜場景的就算了，因為軟件渲染器速度有限，但是可以有比較復雜的效果）
還有個就是，征詢一下SF上project的名字。。。