其他

前天洗澡的時候突然想到一個想法似乎我總是在洗澡的時候才有靈感我給部隊做到虛擬戰場的項目由於涉及到一個室外情境的漫遊所以技術的主要痛點就在terrain上面了由於要求顯示彈坑，並且最小直徑為1米，所以最開始的解決方案我想都沒想做了一塊3000*3000個網格的地形用八叉樹+基於patch 剔除的Geomipmap

2個星期時間我就在這5個物理引擎中死去活來不敢說都很瞭解了也算有個簡單的認識我最想說的就是，文檔化真的很重要。。。。這5個裡面Novodex的文檔化最好十分詳細，包括引擎實現的思想，每個類的每個成員都是幹嘛的都有清楚的交代其他4個的話就越來越差最差的要數tokamak和Bullet其中Tokamak是差中之差連官方論壇都荒的不行，並且居然還有交友貼。。。。ODE也很差，這3個都使用doxygen自動產生，除了每個類有1句話介紹以外，再沒過多地說明只能從函數字面意思猜用法了，有時候也會碰到要命的事

試用了一下Novodex2.6.2的布料系統，感覺相當不錯，簡單易用，功能強大，速度也很不錯，布料系統不僅可以用來類比布料，同樣可以用來描述毛髮，以及很多可變性的物體，例如空的汽油桶的表面等等。公司就是打算用這個製作頭髮的效果不多說了，以下是總結：圖以及demo懶得放出了，實在不好意思拿出手 

 從簡單開始 邂逅GeometryDownload幾何體的匯出是相當容易的，有了上次獲得Node的基礎，獲得幾何體的資訊就顯得順其自然了。幾何體關心的主要資訊就是頂點和三角面，自然還有紋理座標，法線，頂點顏色，切線，BinNormal等等，不過這些都是後話，首先我們只關心頂點和面。同時另外一個重要的資訊就是矩陣資訊，需要注意的是，在不同的Frame中矩陣資訊很可能會發生變化，這點需要注意下。在第一個例子的基礎上

一、摘要　　Altera軟體NIOS II高版本（7.2版本以上，本常式中使用的是9.0版本）中實現TCP/IP所用的協議棧為NicheStack，常用的常式有2個，web_server和simple_socket_server，這篇文章只敘述simple_socket_server常式實現的過程。這裡DM9000A的驅動和上篇博文中基於LWIP的驅動不同。 二、實驗平台軟體平台：Quartus II 9.0 + Nios II

一直很想用用Max的 Script其實Max的Script相比他本身的SDK還是有些優勢的首先是不用每次都重啟Max調試再有就是不用擔心記憶體流失的危險，最後Script的封裝更加方便。但是， 對於長期試用強型別程式設計語言的人來說 要適應指令碼開發還是需要些時間的指令碼調試也不方便，缺乏強有力的異常處理手段

材質和紋理的資訊都位於node 中材質的資訊通過類Mtl獲得紋理的資訊位於node中的mesh

古人云：君子生非異也，善假於物也資料匯出是一個繁瑣的工作，於是，有了IGame這個解脫程式員的東西：   關於IGame IGame是Max提供給遊戲開發的一個用於匯入匯出的介面。在Max的help裡面這個東西叫做3ds Max Data Exchange Interface。有了這個介面，可以大大的簡化匯入匯出工作的工作量。如果有經曆過用MAX

1、Warning (10227): Verilog HDL Port Declaration warning at PRESS_MODELE.v(29): data type declaration for "iR" declares packed dimensions but the port declaration declaration does not.解釋：2、Warning: PLL

1、當你在 maxscript中的rollout中注釋掉一個控制項的時候，那麼當你再運行指令碼，與該控制項有關的事件的代碼將消失！ 2、如何使用dotnet 的ListView?  聲明： dotNetControl lv_objects "System.Windows.Forms.ListView" pos:listBoxPos width:485 height:459 添加項：            local li = dotNetObject "System.Windows.Forms.

準備傾盡自己全部所學寫一款FPS遊戲選擇FPS的原因是自己一直研究的是室外繪製其次，是FPS相對其它遊戲來說遊戲性方面比較簡單，也就是邏輯方面簡單室內繪製看過一些，且如果選擇室內的話會對美工的依賴更大，或者說編寫室內地圖編輯器方面我比較無知。先說一下預期的遊戲的工作量，使用OpenGLTeam

一、摘要       該博文主要將視頻採集、壓縮技術、匯流排切換技術和UDP資料轉送結合在一起，完成了基於UDP的網路攝影機的開發。以下闡述了具體開發過程，一些關鍵問題的調試過程見下篇博文。 二、實驗平台硬體平台：DIY_DE2軟體平台：Quartus II 9.0 + Nios II 9.0 + Visual Studio 2008 三、實驗原理1、系統整體框圖 圖1 系統整體框圖2、系統的工作流程　　首先，視頻採集部分一直工作並進行VGA顯示，當NIOS

昨天進行TerrainEditor的編碼工作，在動態修改Terrain的高度的時候死活都會出錯錯誤總是訪問違規，應該就是數組越界了測試了一個晚上後依然如此。本以為修改一下動態修改高度的功能會很快完成真是出師不利阿。到今天依然不死心，一步一步的跟發現一個讓我打死也想不明白的事情那就是似乎我發現了VC7.0的一個編譯器的問題是不是bug我不敢說在程式中我定義了一個宏#define MAP_W

一、摘要　　該篇博文主要對“基於UDP協議的網路攝影機的設計與實現”調試過程遇到的問題進行說明，並闡述其解決過程。 二、實驗平台硬體平台：DIY_DE2軟體平台：Quartus II 9.0 + Nios II 9.0 + Visual Studio 2008 三、實驗內容　　以VGA顯示作為參照，綜合調試，使C#端的視頻顯示正常。C#端的控制項顯示解析度為320*240。1、初始映像圖1 初始圖片     

 情境檔案格式說明一、說明情境檔案由地圖編輯器編輯，可由程式載入。本情境檔案使用簡單的文字檔，為了簡單起見沒有進行chunk的處理。也沒有節的概念。本說明並不是最終說明，如果需要的話，有可能進行大的修改。二、情境檔案組成情境檔案由以下幾部分組成：1、 Terrain的邊長。在本遊戲中Terrain的長寬必須一樣。並且每個網個大小是1*1。2、 Terrain的每個頂點的高度。由於地形在X-Z平面是規則的，所以只需要儲存Y座標即可。3、 天空盒位置4、 天空盒貼圖5、 地面的貼圖6、 細節貼圖7、

一、摘要　　對之前幾篇博文涉及到的網路通訊協定進行分析，概述出TCP/IP的協議棧模型，最後根據執行個體對各層包頭進行分析。 二、標準TCP/IP協議棧模型　　標準TCP/IP協議是用於電腦通訊的一組協議，通常被稱為TCP/IP協議棧，以它為基礎組建的互連網是目前國際上規模最大的電腦網路。正因為互連網的廣泛應用，使得TCP/IP成為了事實上的網路標準。1、OSI模型和TCP/IP協議模型　　圖1是OSI模型和TCP/IP協議模型的對比。圖1 OSI模型和TCP/IP協議模型2、TCP/IP協議模

 PhysX（1）By sssa2000 今天正式開始接觸PhysX，關於這個東西還是簡單說幾句。這是個很NB的物理引擎，Xbox360和PS3都使用了這個東東。 PhysX這個引擎很好用，上手十分簡單。簡單說句，現在在他的官方首頁上已經無法獲得SDK了 ，必須要先註冊提交申請，通過後才能下載。目前官方的最新版本似乎是2.5版本。我使用了以前下載的2.4.4版。 值得一提的是PhysX的文檔相當的詳細，從路徑設定到Tutorials的代碼解釋都有，大家有空還是看看吧。我這也是照抄文檔而已。 1、

一、摘要　　在博文“DIY_DE2之DM9000A網卡調試系列常式（四）——基於NicheStack協議棧的TCP/IP實現”中提到，通過SOPC搭建NIOS II軟核時候，需要一個Interval Timer核，以供uC/OS II系統所用。Interval Timer核有多種模式，當時隨手選了一個 Simple periodic interrupt模式，資料轉送倒也正常。只是，在完成基於UDP協議的視頻傳輸的基礎上，進行基於TCP協議的視頻傳輸時（二者的硬體設定完全相同），網路傳輸不能工作，

一、摘要　　基於TCP協議的網路攝影機的設計大部分和博文“基於UDP協議的網路攝影機的設計與實現”相同，本篇博文採用的TCP協議棧為NicheStack協議棧（同理，可使用LWIP協議棧實現），協議分析及上位機設計可參考博文“基於NicheStack協議棧的網路常式分析及用戶端程式設計”。 二、實驗平台硬體平台：DIY_DE2軟體平台：Quartus II 9.0 + Nios II 9.0 + Visual Studio

     相比立方體貼圖，球面貼圖的結果雖然不很精確，但是只需要一張貼圖。這個時候球面環境貼圖還是有用武之地的。     隨便用搜尋引擎在網上找了下，基本上沒發現關於球面環境貼圖的內容，本來想找個簡單的shader直接來用的，沒想到的是找了半天也沒找到，於是只能自己動手寫了。以下文章是我參考了一些資料加上我自己的理解寫成的，如果有錯誤的地方還望大家指正。     環境映射是一種近似，它基於這樣的假設：相對於光潔物體的大小而言，環境中的物體離光潔物體很遠，也就是說，將一個很小的光潔物體放在大房間中