火炬之光是用Ogre開(kāi)發(fā)的一款單機(jī)游戲,所以他的資源是可以再度利用的.但是在加載模型時(shí)他的動(dòng)畫(huà)信息沒(méi)有導(dǎo)入進(jìn)來(lái),所以要將他的Skeleton文件動(dòng)下手腳，以火炬之光中 Model/Goust為例,先將Goust.Skeleton文件拖放到OgreXmlConverter.exe工具圖標(biāo)上,然后就會(huì)在Goust.Skeleton目錄上生成一個(gè)Goust.Skeleton.XML文件,該在中間插入<animationlinks>標(biāo)記,然后將所有的動(dòng)畫(huà)Skeleton文件Link進(jìn)來(lái).然后將xml文件拖到OgreXmlConverter.exe工具圖標(biāo)上,便自動(dòng)又生成一個(gè)oust.Skeleton，該文件內(nèi)就會(huì)link動(dòng)畫(huà)文件了
<skeleton>
<bones>
</bones>
<bonehierarchy>
</bonehierarchy>
<animations>
</animations>
<animationlinks>
</animationlinks>
</skeleton
<animationlinks>
<animationlink skeletonName="Attack1.SKELETON" scale="1" />
<animationlink skeletonName="Attack2.SKELETON" scale="1" />
<animationlink skeletonName="Die.SKELETON" scale="1" />
<animationlink skeletonName="Idle.SKELETON" scale="1" />
<animationlink skeletonName="Run.SKELETON" scale="1" />
<animationlink skeletonName="spawn.SKELETON" scale="1" />
<animationlink skeletonName="special_teleport.SKELETON" scale="1" />
<animationlink skeletonName="Special_Gen_AOE.SKELETON" scale="1" />
<animationlink skeletonName="Walk.SKELETON" scale="1" />
<animationlink skeletonName="Special_summon.SKELETON" scale="1" />
</animationlinks>
|
posted @
2010-04-11 22:41 AstaTus 閱讀(1777) |
評(píng)論 (0) |
編輯 收藏
一個(gè)聲源與多個(gè)緩沖綁定時(shí)，這幾個(gè)緩沖中的聲音Format需要一致，否則
alSourceQueueBuffers函數(shù)會(huì)得到 0xA004的錯(cuò)誤，然后在Sourceplay時(shí)聲源狀
態(tài)不會(huì)改變?yōu)锳L_PLAYING而一直都會(huì)在AL_INITAL的狀態(tài)
posted @
2009-09-20 11:17 AstaTus 閱讀(311) |
評(píng)論 (0) |
編輯 收藏
問(wèn)題背景：
很早就覺(jué)得數(shù)學(xué)很重要，但斌沒(méi)有靜下心來(lái)好好看~ 最近重寫(xiě)都D3D框架的結(jié)構(gòu)，打算從基礎(chǔ)類一個(gè)個(gè)寫(xiě)起。。
今天寫(xiě)到射線的相交，在射線與平面相交的判斷上，由于射線的的單方向性，所以可能存在射線的反向延長(zhǎng)線和平
面相交，但是正真的射線沒(méi) 有 和平面相交，所以設(shè)：
平面的單位法向量:N,；
射線的起始點(diǎn)：Origin
射線的方向：Dir
如果Dir，N的點(diǎn)積為正 且Origin在平面的背面，或Origin在平面的正面，且Dir，N的點(diǎn)積為負(fù)，則他們相交
其他情況則不想交
但關(guān)鍵是Origin在平面的哪一面該怎么算呢？下面來(lái)小證一下
證明：
N,Origin,Dir均為矢量，其他為標(biāo)量
平面方程為 N(x, y, z) = D；
射線方程為 P(t) = Origin + Dir*t;
N為平面的單位法向量，
求N與Origin的點(diǎn)積
N•Origin = |N| * |Origin|cos
F 因?yàn)镹為單位向量 則求出來(lái)的值為Origin向量在N上的投影且有方向
(這個(gè)有向長(zhǎng)度相于當(dāng)該平面經(jīng)過(guò)原點(diǎn)時(shí)的有向長(zhǎng)度，既D為0時(shí)),(D的幾何意義是平面到原點(diǎn)的有向距離，
既D為負(fù)則 原點(diǎn)在平面背面，反之在反面)
所以N•Origin + D為最后Origin在正真的有偏移的N上的投影的有向長(zhǎng)度，為負(fù)則在背
面，為正則在正面
貌似講的不怎么清楚 -_- ~~~
posted @
2009-02-25 21:01 AstaTus 閱讀(544) |
評(píng)論 (0) |
編輯 收藏
前些日子 乘著有閑功夫，慢慢的hlsl看了起來(lái)，發(fā)現(xiàn)以前學(xué)的數(shù)學(xué)知識(shí)全用上了，只可惜忘得都差不多了，又要惡補(bǔ)數(shù)學(xué)了。
做了個(gè)比較簡(jiǎn)單的 phong 光照模型。
float4x4 Scal;
float4x4 World;
float4x4 View;
float4x4 projection;
float4x4 WorldViewProjection;
float3 EyePosition;
float3 LightDir;
float4 LightColor;
struct VertexInput
{
float4 Position : POSITION;
float2 Tex : TEXCOORD0;
float3 Normal : NORMAL;
};
struct VertexOutput
{
float4 Position : POSITION;
float2 Tex : TEXCOORD0;
float3 Normal : TEXCOORD1;
float3 View : TEXCOORD2;
};
VertexOutput VertexMain(VertexInput input)
{
VertexOutput output = (VertexOutput)0;
WorldViewProjection = mul(mul(View, World), projection);
output.Position = mul(mul(input.Position, Scal), WorldViewProjection);
output.Tex = input.Tex;
output.Normal = mul(input.Normal, World);
output.View = EyePosition - mul(input.Position, World);
return output;
}
float4 PixelMain(VertexOutput input) : COLOR0
{
float diffsum;
float specularsum;
float4 color;
float sunshinepower;
float4 amibent = float4(0.1f, 0.1f, 0.1f, 1.0f);
sunshinepower = 16.0f;
diffsum = specularsum = 0;
//漫反射
LightDir = normalize(LightDir);
diffsum = saturate(dot(LightDir, input.Normal));
//鏡面反射
float3 L = -LightDir;
float3 R = normalize(reflect(L, input.Normal));
float3 V = normalize(input.View);
specularsum = pow(saturate(dot(R, V)), sunshinepower);
color = specularsum + diffsum * LightColor + amibent;
return color;
}
technique techR
{
pass p0
{
VertexShader = compile vs_2_0 VertexMain();
PixelShader = compile ps_2_0 PixelMain();
}
}
posted @
2009-02-16 10:10 AstaTus 閱讀(2704) |
評(píng)論 (2) |
編輯 收藏
終于把無(wú)限地形調(diào)試好了，但紋理部分還沒(méi)做。那個(gè)惱人的BUG總是把機(jī)器搞成藍(lán)屏，微軟的東西用起來(lái)就是不放心啊。-_-
下一步要做鼠標(biāo)拾取，但發(fā)現(xiàn)擴(kuò)展比較亂，打算重構(gòu)下，具體思路是：
1.把四叉樹(shù)拿出來(lái)單獨(dú)做成一個(gè)類，節(jié)點(diǎn)是node，只標(biāo)管理坐標(biāo)等方位屬性，然后再用entity類attach上去，貌似現(xiàn)在大多數(shù)引擎都是這樣做的。
2.node用composite 模式 可以自己create節(jié)點(diǎn) 四叉樹(shù)的那個(gè)類就是把node 和entity封裝成樹(shù)，以后如果有其他的場(chǎng)景管理模式就不需要改動(dòng)node和entity類了
暫且只想了這些，具體細(xì)節(jié)還有很多的考慮，只能慢慢來(lái)了
.打算以后在編輯器里將場(chǎng)景直接導(dǎo)出成一個(gè)文件，然后在游戲里導(dǎo)入文件就行了~
額，貌似還有很多事情~
紋理沒(méi)做 樣子比較難看 不貼圖了。
posted @
2009-02-16 09:59 AstaTus 閱讀(763) |
評(píng)論 (2) |
編輯 收藏
整合成功已將近1個(gè)星期了，但并不是很開(kāi)心。因?yàn)橄惹暗哪莻€(gè)LOD效率太低 潘永亮的pdf里說(shuō)他有100~200+的幀率，而我的只是在30上下徘徊而且還是512 * 512的高度圖，他說(shuō)他的是1024* 1024的 ，所以無(wú)比的郁悶+ 仇視~后來(lái)感覺(jué)算法的瓶頸可能是在到最后分的節(jié)點(diǎn)太細(xì)了，導(dǎo)致在渲染時(shí) 渲染隊(duì)列里的節(jié)點(diǎn)過(guò)多，（我的筆記cpu是1.66G的，雖然雙核，但單線程的程序最多也不會(huì)超過(guò)1.8G吧）后來(lái)看到ogre里的terrain的那里例子里，LOD變化時(shí)是一大塊一大塊的，一個(gè)節(jié)點(diǎn)代表一大塊的mesh ，后來(lái)看了下是65*65的網(wǎng)格 而我的最細(xì)只有3*3. -.-!
所以這些日子都在弄那個(gè)地形 ，看到tonykee boss的博客里的那個(gè)無(wú)限地形非常的HAPPY，所以依據(jù)他的思路在寫(xiě)，后來(lái)發(fā)現(xiàn)這個(gè)地形代碼非常的龐大，但可以想象，用起來(lái)將是非常的爽啊，因?yàn)閠onykee boss只給了個(gè)大概的思路，細(xì)節(jié)方面有很多要考慮的，尤其是效率方面的(不知道是不是以前寫(xiě)過(guò)單片機(jī)的程序的原因，時(shí)間和空間的開(kāi)銷我都過(guò)分的關(guān)注-。-)，所以導(dǎo)致已將近寫(xiě)了1個(gè)星期，不過(guò)還差點(diǎn)，快的話明天估計(jì)可以展開(kāi)全面的調(diào)試了。。。
明天年三十，希望能1次調(diào)試成功~~
posted @
2009-01-24 22:18 AstaTus 閱讀(940) |
評(píng)論 (1) |
編輯 收藏
參考了潘永亮的lod的資料后，終于將LOD給實(shí)現(xiàn)了
LOD地形的實(shí)現(xiàn)面臨有2個(gè)問(wèn)題
1：網(wǎng)格的裂縫問(wèn)題，我是用取消那條與低分辨塊相鄰的邊來(lái)做的，這樣的話有個(gè)缺點(diǎn)既每相鄰的塊分辨率做多只能相差1；
2：生成網(wǎng)格時(shí)的遍歷次數(shù)，用潘永亮的方法只需遍歷一次
具體參見(jiàn)潘永亮的PDF：
/Files/AstaTus/largeLOD.pdf 我的效果圖：
posted @
2008-12-25 22:54 AstaTus 閱讀(423) |
評(píng)論 (0) |
編輯 收藏
DX學(xué)習(xí)中總是在一些小問(wèn)題上糾纏不清，所以特開(kāi)一篇，記錄下自己的錯(cuò)誤。
1， 內(nèi)存訪問(wèn)異常：
遇到該問(wèn)題時(shí)，可能錯(cuò)誤并非在報(bào)錯(cuò)的那個(gè)語(yǔ)句上，而是在前面的運(yùn)行語(yǔ)句中，數(shù)組越界訪問(wèn)，或其他關(guān)于內(nèi)存的錯(cuò)誤。
我就是在用vector時(shí) 越界訪問(wèn)了（雖然vector可以自動(dòng)開(kāi)辟空間，但[]運(yùn)算符貌似不能訪問(wèn)當(dāng)前所占有的內(nèi)存之后的內(nèi)存，
我是先resiz e的， 這 樣可以提高效率） 導(dǎo)致后面createtexturefromfile的函數(shù)無(wú)法創(chuàng)建紋理 。
2. 創(chuàng)建的實(shí)體渲染后不顯示
這個(gè)問(wèn)題至今遇到了2次，都是因?yàn)樽兞康念愋驮?br> (1).索引的類型默認(rèn)是WORD類型,但是在創(chuàng)建Indexbuffer時(shí)可以將索引的類型設(shè)置為DWORD。
(2).自定義的頂點(diǎn)格式的xyz必定需要float型
3. 換了個(gè)dx的SDK(June 2008) 發(fā)現(xiàn)原來(lái)的shader代碼出了點(diǎn)問(wèn)題，在用到全局變量的代碼處報(bào)
global variables are implicitly constant, enable compatibility mode to allow modification 錯(cuò)誤
也就是說(shuō)全局變量是extern也是常量，在shader里面不能修改，但可以從宿主程序里改。
posted @
2008-12-22 13:06 AstaTus 閱讀(303) |
評(píng)論 (0) |
編輯 收藏
好久沒(méi)寫(xiě)了，前些日子去搞文件系統(tǒng)了，是單片機(jī)的文件系統(tǒng)，完全不能調(diào)試，累啊，現(xiàn)在用起2005 那一個(gè)爽字了得。。哈哈
現(xiàn)在已經(jīng)完成相機(jī)，地形，框架三個(gè)類了，不過(guò)功能還不是很完善，還需待改進(jìn)。。
貼張圖
posted @
2008-11-17 22:21 AstaTus 閱讀(586) |
評(píng)論 (2) |
編輯 收藏