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

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

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

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

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

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

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

源代碼在此下載。

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

截圖：

 

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

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

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

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

mail： wuye9036   _AAAAATTTTT_ google _dotdotdotdotdot_com

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

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

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

圖1-3

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

圖1-4

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

1.2.2 查找表
上文已經提到了如何通過體素角點的密度值，就會知道會生成哪些多邊形；這些多邊形的頂點落在哪些邊上。
接下來，我們將用討論這些理論如何在GPU上實現。
首先我們建立一張查找表
int case_to_numpolys[256];
其中每種情況能產生多少個三角形。
第二張查找表，
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][]返回這樣的結果：

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個頂點。由于創建Marching Cubes查找表需要很多的計算量，因此建議預先計算好并在運行前載入。該表在光盤上可以找到。

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

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

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

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

mingw + gcc 4.2.1下通過

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

2月21日更新：

已經將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環境中另行設置，給大家帶來的不便深表歉意。

2005 SP1 下通過（有點bug）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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