lablab.jp （日本語版）

私は不注意なバグで２日間苦しみました。恐らく、あなたは私の不注意な問題を笑いとばすでしょう。もしくは、それは私とあなたにとって、良い教訓になるかもしれません。

私はある法線ベクトルから、別の法線ベクトルへの回転を計算する数学関数を開発しました。 これにより、オブジェクトは指定されたポイントに向かって向きを変えることができます。猛獣がプレイヤーをロック・オンして、彼を攻撃するようなことに、この一般的な関数は役に立ちます。 この私の作業において、私はこれら２つの法線ベクトル間の角度を必要としない新しい方法を試しました。この方法では、クォータニオンはアークコサイン等なしで内積と外積のみによって計算されます。 この方法は有名ですが、それは実装は初めてでした。

実装が終わり、私と仕事仲間は改造されたメソッド'Look At'に満足していました。 しかし、しばらくして、私たちは、このメソッドで回転されたオブジェクトが目標ポイントに背中を向けていることに気付きました。 別のプログラマーは前方方向を示す基本的なベクトルを逆にしました。 彼は、この最初の問題を解決して、諸点を調整しました。 私は、彼の修正をしらずに、すぐに別の問題に遭遇しました。私が'前進'をオブジェクトに与えたとき、オブジェクトは後退を始めたのでした。

私たちは、ミーティングを持って、このバグの原因が異なる座標系の混在だと推測しました。私たちは右手座標系を使用していました。ですから、私たちは左手座標系の計算コードを含むバギーなコードを見つけさえすればよかったのです。しかし、私たちはバグポイントを得ることができませんでした。

翌日、デザイナーは、アプリケーションのメッシュ・データ・エクウポータのオプション項目が切り替わっていたことに気づきました。エクスポータは左手座標系のデータとして、メッシュ・データを変換していたのでした。私たちはデータが私たちのテストに正しいかどうかを検証していませんでした。私が、私たちが完全に理解していなかった異質のコードを書いたので、私たちは、原因がプログラミングバグであると思いこんでいたのでした。。。

An old XNA Extras had used System.XML, but it becomes unable to use because XNA Framework doesn't allow to reference System.XML. But, we can use great solution using Content-Pipeline. I found it in this thread.

In this thread, new XNAExtras Aaron Leiby have posted is a very good solution. This may be the quickest bitmap font solution I have seen. This converted XNAExtras makes it possible to load XML files generated by bmfontgen with content-pipeline.

1. Build XNABaseWin or Xbox.
2. Modify the reference of XNAImport and build it.
3. Double-click the property of your game project and add XNAImport.dll to your content-pipeline.
4. Add XNABase.dll as the reference of your project.
5. Change properties of your XML files generated by bmfontgen. XNA Content Pipeline is true, Content Importer is BitmapFontImporter, Content Font Processor is BitmapFontProcessor.

Now, you can load your bitmap font as the following:

BitmapFont bitmapFont = content.Load<BitmapFont>(asset_name);

I had heard that XNA Framework RTM tries to enable to use fonts for drawing text on the screen. I have expected it, because most of game frameworks doesn't have such feature. But, according to this thread, it seems impossible to use fonts for drawing text. We will have to keep the solution using bitmap font textures.

XNA Game Studio and XNA Framework have been released. We can build the game for Xbox 360. It's just cross-compile. But, it's impossible to share one project for PC and Xbox. That's a barrier for all developers.

現代において、大部分のゲーム開発者は、 C++ もしくは C （と若干のマシン語およびシェーダ）を使わなくてはいけません。これらの言語は、非常に強力であり、 C++ は、十分に生産的ですから、特に問題はありません。

しかし、私は、休日用に、他の言語を求めてきました。あらゆるゲーム開発者は、自身のゲームを開発することを望みます。しかし、それは、不可能なように思われます。ゲーム開発は、多くの時間を必要とするからです。大部分の開発者は、自身のゲーム開発より休暇をとって眠ることを望みます。

その目的のために、私は、最小のアーケードゲームを開発するのにいくらかのライト級のプログラミング言語を必要としました。それらは、休暇用の迅速なゲーム開発用の言語です。私は、 HSP 、 Python 、 Ruby 、 Java 、及び、ゲームエンジンのいくらかのスクリプトを試みました。（私は、一度だけ会社の仕事で Java を使ったことがありますが、二度とゲーム開発には使いたくありません）

そのようにして、私は、多くの言語を試みました。しかし、私は、いつも同じ結果を得ました。C++ がゲーム開発においては世界上で最も生産的な言語であるということです。そこで、私は、 boost ライブラリと OGRE をチェックし始めました。

しばらくして、私は、 Managed DirectX と C# 2.0 に出会いました。 Managed DirectX は、 DirectX のマネージドライブラリ版です。C# 2.0 は、 Generics 機能を持つ C# の拡張です。私は、これらが現在最も良い答えである、と思いました。そして今、マイクロソフトはゲーム開発のために調律された .NET 製品である XNA フレームワークと XNA スタジオを提供します。

C# は、低パフォーマンスです。C# や Java のような、 GC 機能を持つ言語は、リアルタイム処理に対する適性を持っていません。私が XNA との最初の接触を持っていたとき、私は、 XNA と C# はなんらかの方法で GC の問題を克服したのだと考えました。しかし、 XNA は、やっぱりひどいパフォーマンスです。

しかしながら、私も他の開発者も、それに関して同じ結論にたどり着いています。その結論は、我々が GPU 至上主義者であるべきであることです。GPU 処理では、 C++ と C# に、パフォーマンスの違いはありません。GPU が物理学等々を計算し得るというアイデアは、いくらかの本にあります。しかし、それは、生産的な方法ではないかもしれませんが...

XNA express edition を楽しみにしています。これは、ゲーム開発を楽しむことを忘れたディベロッパーのためのWonder WitchおよびSaturn Basic以来のビッグニュースです。そして、これは C# の簡易ゲームエンジン Buddha プロジェクトのための新しい目的となるでしょう。私たちは、'Easy to Use' 3D シーングラフエンジンとして Buddha を開発し続けました。Buddha は PICOPICO3D ゲームを容易に開発することを可能にします。私たちはXNAとXBOX360のために Buddha をリメイクするでしょう。

なお、 PICOPICO 3Dゲームは古典的なアーケードのような簡単な3Dショート・ゲームを意味します。

私は長い間 BRYCE3 のユーザーでした。先月、私は BRYCE の最新版を家で使うために欲しくなりました。しかし、アップデートコストが高かったので、私は別のソフトウェアを試すことにしました。そして、私はVue5 Espritを買いました。それは良い選択肢でした。多くのお金をブライス5.0に支払っていたら、私は今頃このニュースによって泣かされていたかもしれません。ブライス5.0 は最新版ではありませんが、私たちが無料でそれをダウンロードすることができることはビッグニュースです。しかし、それは無期限ではありません。BRYCE 5.0 が欲しいなら、9月6日までにダウンロードしなければいけません。

• Download Windows version
  
• Download Man version

なお、私は、cubson GUI ForceのためにビルボードをレンダリングするのにVue5を使用しました。 私は長い間CGプログラミングに関するブログを書いていませんが、再開したいと思います。

（私はウェブプログラマーではないのに、このブログウェブプログラマのブログに見えます）

XTC2006の準備に忙しかったため、ブログを書くことができませんでした。また、私は私がチェックしなければならないソフトウェアたちをチェックすることができなくなっています。（私にとって）重要で興味深いいくつかのソフトウェアが、リリースされているのですが……

Geist3D

http://www.geist3d.org/
これは、興味深いGUIツールを持つスクリプト駆動のグラフィックス・エンジンです。私は、そのようなエンジンがオープン・ソースによって開発されたことに驚いています。プロプラエタリのミドルウェアでは、初めからGUIを持つエンジンは珍しくありません。多くのミドルウェアは、GUIツールの設計と共に開発されています。しかし、オープン・ソース・ソフトウェアでは、GUIツールは、オプションです。多くのエンジンは、グラフィックス・エンジンとしての機能を実装するようリクエストされます。しかし、エンジンがエンドユーザーによって使われるならば、エンジンが初めからツールのために設計されていることが重要です。同様に、XOOPS Cube の重要な事柄は、プログラマーのためのAPIでなくRADツールのための規則であると言えます。

OGRE 1.2.2

http://www.ogre3d.org/
私は、1.2.0 から OGRE のチェックができていません。さらに、私は先月以来 OGRE のフォーラムを読めていません。私は、来月までこれらの投稿をチェックすることができないでしょう。私は、テストを通してレポートを OGRE にコントリビュートしたいです。（しかし、その前に XOOPS Cube を完了させなければなりません）

私はこれらのタスクを自分のGTDに加えるべきなのでしょう！

最もポピュラーなオープンソースエンジンの1つである OGRE は、多くのツールキットを持っています。ダウンロードページを参照してください。 メジャーアプリケーションのためのツールキットが十分にあります。そして、そのページはOGREにおけるポピュラーなアプリケーションのランキングを示しています。それは興味深いです!

OGREで最もポピュラーなアプリケーションは3ds maxのようです。ただ、max のためのツールキットはOGREで最初のツールです。ですから、それの新しいバージョンがリリースされる度に、max のツールキットはダウンロードされます。しかし、3ds max の知名度には誰もが同意するところでしょう。

私たちはsoftimage XSIのランクに注目すべきです。Blenderが2つのアイテムを登録していますから、XSIはワーストということになります。しかし、ゲーム開発には、XISは本当に素晴らしいです。 それには、プラグインとプログラマブルシェーダのためのベスト環境が備わっており、また、リーズナブルです。なぜ XIS はマイナーですか？ Wikipedia(日本語版)の記事は、その理由について語ります:

3Dソフトが全般的に高価で、ユーザーは一度覚えたソフトから気軽に乗り換えたがらないことが要因にある。

XSIのシェーダパイプラインのためのダイアログはエクセレントです。また、TDEはおもしろい環境です。XSIは、よりポピュラーになるべきです。

私は、マイクロソフトが DirectPhysics を DirectX に加えようとしているというニュースに驚かされました。そのニュースに関して、DirectX が AGEIA PhysX をサポートするという噂があります。これらの計画が実現するならば、 DirectX はホビープログラミングだけでなく、ビジネス・プログラミングのためにもよりエクセレントなものになるでしょう。

DirectX は、マルチメディア用の複合的なライブラリで、 OpenGL より遙かに大型です。それは、Windows Vista の描画技術として知られています。だからといって、マイクロソフトがゲーム・ライブラリとしての DirectX の開発をやめたわけではありません。多くの開発者は、 OpenGL が次世代ゲーム・グラフィックスAPIの勝者であるとみなしました。理由は、以下です：

• OpenGL 2.0 の登場 -- OpenGL 2.0 は、最新のグラフィック・テクノロジーを取り戻しています。
• PS3 が、グラフィックスAPIとして OpenGL/ES 2.0 を使用。

DirectX は、リッチではありますが、制限された用途です。それは、 Windows ファミリ専用です。そのため、大多数のゲーム開発者は、プラットフォーム依存であるライブラリを学びたくないと考えるでしょう。彼らは DirectX に対して冷ややかであると思われます。DirectX は、すでに DirectInput、DirectSound、DirectShowとDirectPlay(P2P) を含んでいます。しかし、これらのライブラリが、必ずしも使われてきたというわけではありませんでした。私も、ガイドブックの外で、これらのライブラリが実際に使われるところを見たことがありません。

しかし、マイクロソフトは強力なテレビゲーム・ライブラリを開発することに関して完全に真剣です。DirectPhysics は驚きです。そして、それは我々を興奮させます。

私は、大多数の開発者は、やはり次のバージョンも使わないだろうと思います。多くの開発者は、巨大なライブラリがプラットフォーム依存であることに容赦がありません。たとえライブラリが非常に役に立つとしても、距離を置きたいところでしょう。しかし、これらのライブラリは、ホビー・プログラミングには非常によいです。

その点、OpenGLはグラフィックスAPI以外を含む予定はありません。OpenGLは、グラフィック開発のためにシンプルです。そして、DirectX はゲーム開発のためにリッチなのです。

法線マッピングは、以前からある技術です。多くのDirectXガイダンスブックはそれを取り上げます。しかしながら、それは、現在のゲームコンソール上で実装しにくいものでした。次世代の製品ではその実装にあたっての問題はありません。

おもしろいことに、法線マッピングに求められたコンセプトは、変遷の途にあります。私は、そのように感じます。昔、法線マッピングは、 GPU のための省力技術であると紹介されました。しかし、次世代環境において、非常に複雑なポリゴンモデルを扱うことが容易になりました。私は、法線マッピングが GPU ではなく、人間のための省力技術として重視されるのではないかと考えます。

私が思うに、大部分の開発者は、背景モデルのために多くの時間を費やすことを望みません。れんが壁の表現のために、開発者は、法線マッピングを使うでしょう。そして、壁のモデルは昔同様プリミティブであり続けるでしょう。

法線マップはもはや人間の仕事ではありません。そこで、優秀なツールが必須です。多くのソフトウェアメーカーは法線マップのソリューションを市場へ投入しています。Zbrushはこのレースにおける先頭ランナーの一人です。加えて、ZBrushはテクスチャのカテゴリにおいても同様に優れていると考えているかもしれません。それは、３Ｄペインティングのための興味深いフィーチャーと、モデリングのための癖のあるフィーチャーを備えています。

ZBrushによるモデリングは普遍的ではありませんが、十分に興味深いです。しかし、日本の多くのデザイナーはこの普遍的ではないツールをモデリングのために使うことを望みません。ZBrush はそのことをよく理解しています。それゆえ、彼らはZBrushと他のツールを組み合わせることを勧めるのでしょう。

3ds Max v8 が出てしばらくになります。しかし、私はまだそれを一度も試みたことがありません。そこで、私は、今日久しぶりにAudodesk日本サイトを訪問して、いくつかの変化を知りました。まず第一点に、私たちはそのサイトからトライアル版をダウンロードすることができます。バージョン7の頃は、トライアルCD-ROMを申し込まなければなりませんでしたが……次に、バージョン8は本当に素晴らしい新機能をもたらします。 バージョン8はサイトで20に及ぶフィーチャーをリストアップしています。それは、エクステンションのフィーチャーを含んでいます。つまり、Autodeskは、CharactorStudioと同様に、より多くの有償エクステンションの提供を止めたということです。

3ds Max のために、「ｅ解説」と呼ばれる興味深い製品があります。これは初心者のための様々なソフトウェアのビデオチュートリアルです。 私は昔、それには価値がないと思っていました。 しかし、これは時間の節約です。3ds Max のための製品は2種類です。そのうちのひとつは、初心者のためにバージョン7をカバーします。別のひとつは、バージョン8における新機能だけをカバーしています。これはおもしろいアプローチです。この製品は新機能に関する説明のために4,000円を請求します。それはまさに時間の節約のための純粋な対価です。

ところで、3ds Max の新しいバージョンは法線マッピングに関して、より強力な機能を獲得しました。そして、日本のユーザは法線マップのためにZBrushに注目するようになりました。ZBrushは日本で十分ポピュラーとはいえませんでした。しかし、それは最近、法線マップツールとしてポピュラーになり始めています。ZBrushのための学習センターであるZBrushCentralは、3ds MaxをZBrushと共に使用することを勧めています。"ZBrush normal maps and 3dsmax v8"というチュートリアルは法線マップの分野における勝利宣言かもしれません。

私は、OGRE AppWizard を試してみました。これはいいです！　私は、その安定性と素晴らしさに感嘆せざるを得ませんでした。

インストールは、Javascript ファイルを走らせるだけで済みます。それだけで、 OGRE のアプリケーションウィザードが手に入ります。豊富なオプションからいくつかの選択肢をプロジェクトのために選ぶことが出来ます。さらに驚くべき事は、生成されまったく修正されていない状態のプロジェクトをビルドできることです。

もし、 Standard application を選択すれば、いくつかのリソースファイルがプロジェクト内にセットアップされます。また、 Sample Framework を選択すれば、そのフレームワークですぐにアプリケーションの開発にとりかかることができます。

私は、インストーラーが非常に丁寧なアプローチであることに驚かされています。多くの熟練したユーザーがOGREのまわりにいるにも関わらず、それはあまりに使いやすく作られています。熟練したユーザーのためのツールであれば、それが親切でないとしても、普通それは問題にはなりません。しかし、このツールは、そうではないのです。私は、このツールの品質へのこだわりを尊敬します。

また、サンプル枠組みは重要です。 それはOGRE SDKが含んでいるExample Applicationヘッダーファイルを使用します。 私たちは、ゲームのような多くの複合的場面を造るのにそれを使用することができません。 しかし、だれでもフレームワークによるサンプルシーンで学ぶことができます。(フレームワークはすぐに1つの場面を造ります)。 技能プログラマーの中には彼らがサポートなしでかなりのアプリケーションを組立てることができるので、フレームワークが嫌いである人もいます。 しかし、サンプルフレームワークで手早くプログラミング効果を学び始めることは、重要です。あなたが一度も経験したことがない他のカテゴリにおけるアプリケーションを開発しなければならないなら、あなたは先達の開発者が準備したサンプルフレームワークを当てにするかもしれません。

DefColStudioは2005年にSIGGRAPHで発表されました。 これはインタラクティブな変形可能モデルのフレームワークです。 デモアプリケーションで、私たちはモデルをつまみ、振り回して、別のモデルにぶつけることができます。それは非常におもしろいです。

このデモアプリケーションは、 Bruno Heidelberger の研究を説明するために、彼によって開発されました。 それは、インタフェースにCEGUI、レンダリングにOpenGLおよびOGREを使用します。 そう、このデモはOGREによって作られてている成果物の1つです。 私たちが注目すべきことは、十分なプログラミング技能を持っている研究者がCG技術を説明するためにOGREを選択したということです。 言い換えれば、OGREには、プロトタイプのための十分なライブラリと十分なツールキットが既にあるということです。

Bruno は、スイス連邦のチューリッヒ工科大学の研究助手であり、AGEIAで働いています。 AGEIAは最近、PhysXでポピュラーになりました。 彼のプロフィールは、彼がAGEIAの次世代ゲーム物理学に取り組むと説明します。 AGEIAによって作られたPhysXは次世代ゲーム物理学を実現する特殊ボードです。 恐らく、彼はPhysX開発チームのメンバーでしょう。

OGRE は、レンダリングエンジンであり、私が常に見ているオープンソースプロジェクトのひとつです。それは、多くのユーザーの支持、良いツールキット、及び、詳細ドキュメントを持っています。私が OGRE を見始めたとき、それは、まだ正式バージョンをリリースしていませんでした。そのため、ユーザーは、 OGRE プロジェクトの進捗を見るために、毎回ソースコードをチェックアウトし、それをコンパイルしなければなりませんでした。

OGRE は、長い間 0.9.x にあり、そして、公式のチーム、及び、サードパーティは、その間に様々なツールキットを開発しました。私は、 OGRE の計画があまりにも壮大だったので、それは完成しないのではないか、と思いました。しかし、 OGRE は、多くのツールキット、及び、オフィシャルドキュメントを伴う正式バージョンとしてリリースされました。

OGRE は、多くの好影響を他のプロジェクトに与え、そして、 OGRE に関するいくらかのプロジェクトもまた、始まりました。CEGUI は、それらのなかでも最も良いプロジェクトです。OGRE 、 CEGUI 、及び、いくらかのツールキットは、容易な３Ｄプログラミングを趣味、もしくは他の分野へもたらします。たとえば、我々は、 SIGGRAPH で OGRE アプリケーションを見ることができます。これらのライブラリは、我々の考えをテストするために便利です。同様に、とあるドイツのゲーム学校は、 3 次元プログラミングを学ぶために OGRE を使います。

しかし、 OGRE は、アジアでポピュラーではありません。その理由は、それが UTF-8 をサポートしないので、アジアのユーザーが OGRE で母言語を用いることができないためです。いくらかのソリューションは、提案されており、そして、 3rd party 製のパッチもあります。しかし、公式のソリューションはまだありません。このことは、今しばらくの間、 OGRE におけるホットトピックであり続けるでしょう。

CG WORLDの最新号で曲面のモデリング方法が特集されていました。その記事の冒頭で、曲面の変遷が簡単に説明されていました:

1. ポリゴンはもっともポピュラーな方法である。しかし、この方法は、複雑な形状を作るときに、膨大なデータ量に悩まされるというウィークポイントがある。
2. 一方、自由曲線のデータサイズは小さくて済む。が、計算負荷が高く、複雑で、取り扱いも難しい。データが軽量で済むため、一時期、ポピュラーな方法だった。
3. ポリゴンは複雑な形状に対する欠点を持っているものの、最近のコンピュータのスペックが上がってきているので、現在では曲面処理にもよく使われている。

そして、Maya、3ds MAX、XSI、そしてLightWaveを使用するチュートリアルが掲載されていました。これらのチュートリアルのすべてが曲面(スプライン等)を使用します。確かに、これらのアプリケーションの曲線ツールはどれも非常に良いものです。しかし、Shadeはどこにいったのでしょうか？　コンピュータのスペックが低かった時代から、Shadeは曲面機能のみを実装してきました。Shadeには多くの弱点がありますが、曲面特集のときくらい、Shadeに対する敬意があってもよいのではないかと思います。Shadeが少し気の毒でした。

私はずっと自由曲面が好きで、リアルタイム処理でそれを扱いたいと思っています。それはまだしばらく難しいでしょう。

ほとんどの次世代ゲーム機は、直接スプライン曲線を使用する機能を持っています。しかし、私は道路のカーブがポリゴンで作られているのを、XBOX360のレースゲームで目撃しました。リアルタイム処理におけるスプライン演算が難し過ぎるので、だれもうまくスプラインを使用することができないかもしれません。 おそらく、リアルタイム処理には、サブディビジョン・サーフェイスのほうがスプラインより向いているでしょう。