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

上次用boost.python的時(shí)候boost還是1.33的時(shí)候。

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

看來(lái)人都是在慢慢進(jìn)步的。。。哈哈。

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

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

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

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

源代碼在此下載。

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

截圖：

 

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

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

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

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

mail： wuye9036   _AAAAATTTTT_ google _dotdotdotdotdot_com

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

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

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

圖1-3

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

圖1-4

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

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

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

下面的例子很好的說(shuō)明了這一點(diǎn)。
我們以case 193為例。193總共有3個(gè)三角形，那么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在查找了這兩張表的信息之后，并計(jì)算出頂點(diǎn)在邊上的具體位置，便會(huì)返回3個(gè)多邊形列表所需要的9個(gè)頂點(diǎn)。由于創(chuàng)建Marching Cubes查找表需要很多的計(jì)算量，因此建議預(yù)先計(jì)算好并在運(yùn)行前載入。該表在光盤上可以找到。

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

這個(gè)設(shè)計(jì)主要是拿來(lái)保證跨組件的時(shí)候能盡可能的保護(hù)型別安全.

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

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

mingw + gcc 4.2.1下通過(guò)

2月22日更新：
修改了項(xiàng)目設(shè)置（大換血。。。）。昨天下過(guò)的最好重新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

由于目前的渲染器離成品還很遙遠(yuǎn)，所以就沒(méi)有以Release的形式放出。Version 6 中，CartoonDemo大家可以自行從solution里面移除；EFLIB需要項(xiàng)目地址上下載Release，然后在VC環(huán)境中另行設(shè)置，給大家?guī)?lái)的不便深表歉意。

2005 SP1 下通過(guò)（有點(diǎn)bug）

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

該軟件渲染器名字就叫SoftArt，本來(lái)準(zhǔn)備叫做ColorfulSnail（哈，因?yàn)镈ebug的時(shí)候它的運(yùn)行速度是在是太慢了），但是無(wú)奈Snail已經(jīng)被人注冊(cè)過(guò)了，所以就還是叫這個(gè)名字了。
每個(gè)開(kāi)發(fā)階段我都會(huì)有一個(gè)項(xiàng)目代號(hào)，目前的這個(gè)還是prealpha階段，所以就叫prealpha好了。

今天放上去的是支持庫(kù)Essential Functions Library，大家可以去我的項(xiàng)目地址下載。

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

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

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

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

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

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

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

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

一開(kāi)始實(shí)現(xiàn)的時(shí)候沒(méi)考慮GS，所以也就沒(méi)有ps40可言。
不過(guò)對(duì)于軟件渲染器來(lái)說(shuō)，沒(méi)有GS，以及沒(méi)有DX11的TS也算不得什么硬傷。

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

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

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

光擺圖我也不敢放首頁(yè)啊……
主要是征詢一下，這段時(shí)間我做什么Demo比較好（如果有太復(fù)雜場(chǎng)景的就算了，因?yàn)檐浖秩酒魉俣扔邢蓿强梢杂斜容^復(fù)雜的效果）
還有個(gè)就是，征詢一下SF上project的名字。。。