ラベル OGRE3D の投稿を表示しています。 すべての投稿を表示
ラベル OGRE3D の投稿を表示しています。 すべての投稿を表示

2010年6月30日水曜日

OGRE - CMake でエラー

Visual Studio 2010 Express をインストールしてみたので、Ogre 関連をすべてこれで再コンパイルしてみました。boost 及び OgreDependencies は問題なくコンパイル終了。で、Ogre 本体をコンパイルするために cmake_gui を起動してソースとバイナリのディレクトリを指定して、Dependencies のパスは OGRE_DEPENDENCIES_DIR にセット、そして Configure するとエラーが発生しました。

Detecting C compiler ABI info
CMake Error: Could not COPY_FILE.
OutputFile: ''
copyFile: 'C:/.../projects/ogre/CMakeFiles/CMakeDetermineCompilerABI_C.bin'

Unable to find executable for try_compile: tried

以下同様のエラーが延々と。Visual Studio 2008 の時はこんなエラー出なかったはず…。とりあえずググってみたところ、Ogre のフォーラムで解決策があったのでメモ:

Ogre のソースのルートにある CMakeLists.txt というファイルをテキストエディタで開き、「# determine system endianess」と書いてある行を探します。 ogre_src_v1-7-1 の場合 138 行目あたりにあります。
で、そこにある次のような行を
# determine system endianess
include(TestBigEndian)
test_big_endian(OGRE_TEST_BIG_ENDIAN)
次のように変更します。
# determine system endianess
#include(TestBigEndian)
#test_big_endian(OGRE_TEST_BIG_ENDIAN)
set(OGRE_TEST_BIG_ENDIAN FALSE)
これで問題なく CMake が通りました。

2010年6月29日火曜日

OGRE - 再コンパイル

先日、Ogre を static リンクライブラリとしてコンパイルすることに成功したので、それを組み込んでテストプロジェクトを作成してみました。
しかし、Ogre 自体は static ライブラリになっていても VC のランタイムを DLL 参照しており、static の意味ねーって感じで即座に Ogre を再度 VC ランタイムを DLL 参照しないようにして再コンパイル。すると今度は Ogre の参照する外部ライブラリも外部 VC ランタイムを参照していて、さらに外部ライブラリも再コンパイル。そうして何もかも再コンパイルして、リンクしたところ今度は Ogre の設定ダイアログを開くところでリソースが足りないとかで停止。仕方ないのでリソースもいろいろコピーしたつもりなのですが結局うまく動かず、全部元に戻して DLL のまま使用することにしました orz
DLL って嫌いなのですよねー。再配布も面倒だし、他の OS は知らないのですが Windows では同名の別バージョンの DLL なんかがインストールされてたりするとハングアップして原因特定するのに時間かかるしで、非常に使い勝手悪いイメージしかないのですが…。特にこういう不具合は自分のマシンでは何も起こらず誰かのマシンにインストールすると起こるので、もう無くしてしまいたいのです…。

2010年6月24日木曜日

OGRE - マニュアル翻訳

今日は少しがんばって数ページ訳しました。長い文の翻訳は難しいですね。とりあえず、ほぼ直訳で書いてしまってますが、後で読み返してみるとやっぱりわけわかめ。全部訳したら全体を再度添削しないとだめだなぁ。

現在進行度 ... 10%

2010年6月21日月曜日

OGRE - マニュアル

…どこかで公開できればいいなと思い、少しずつ OGRE マニュアルの翻訳作業などしてます。まあ、私は英語しゃべれる人ではないので、辞書めくりながらのかなりの意訳を含みつつの翻訳ですが。
しかし、英語しゃべれない人なのではっきりとは言えませんが、この OGRE の説明って一文一文がやたら長ったらしく回りくどいわかりにくい文じゃないですか?直訳的に書いていくと本当に意味不明な文章になりそうで、このためかなり意訳してしまっています。
量も結構あるし、完成はいつになるかな。。。

現在進行度 ... 5%

OGRE - 本体のコンパイル

デバッグするのに SDK の DLL だけだとステップインしてトレースできないため不便。Ogre 自体がバグるってことはほぼないと思いますが、自分で組んだものがバグったとき何が悪かったのか調べる際に Ogre 内部までトレースできると問題を見つけやすいので、ソースを取ってきて自分でコンパイルしてみました。
最初、大量に外部ライブラリをいちいち取ってこなければならないと知り、絶望しました orz。しかし、OgreMain のコンパイルに必要な分は Dependencies パッケージをダウンロードしてくればいいとわかったため、とりあえずやってみました。…結局いくつかは、自分で取ってくることになりましたが。

1.Ogre 本家の Source から「OGRE 1.7.1 Source For Windows」と「Microsoft Visual C++ Dependencies Package」をダウンロードします。
2.Dependencies の方を解凍すると src フォルダに VisualStudio のプロジェクトファイルがあるのでそれを開いてすべてコンパイルします。
3.cmake と 7z と Graphviz、それに boost が必要らしいので、Windows 用インストーラ付きのものをダウンロードしてきてインストールします。cmake は環境変数 Path に設定するのがインストーラでオプションになっているので忘れずに設定します。7z はインストール後に自分で環境変数 Path にパスを追加してやります。boost は環境変数 BOOST_ROOT にパスを設定します。
cmake http://www.cmake.org/cmake/resources/software.html
7z http://sevenzip.sourceforge.jp/
Graphviz http://www.graphviz.org/Download..php
boosthttp://www.boost.org/

4.Ogre 本体ソースを解凍後 VisualStudio Tools のコマンドプロンプトを起動し、ogre_src_v1-7-1\SDK\Win32 へ移動します。
5.環境変数 OGRE_DEPENDENCIES_DIR に上でコンパイルした Dependencies のパスを設定しておきます。
>set OGRE_DEPENDENCIES_DIR=C:\Dependencies
6.buildsdk.bat を使用して VisualStudio 用プロジェクトファイルを作成します。その際、コンパイラのバージョンを指定する必要があります。例えばうちは VisualStudio2008 でしたので
>buildsdk vc9
と入力します。64bits 環境な場合は vc9_x64 のように指定するみたいです。
実行すると何か見つからないというパッケージがまだたくさんありますが、OgreMain のためには必要ないと思われるので無視しますw 各種プラグインが必要なら Could not found と表示されるすべてのパッケージを取ってくる必要があると思います。
7.buildsdk.bat のあるフォルダの下に vc9 フォルダが作成され、その下にプロジェクトファイルができているので、VisualStudio で開いて OgreMain をコンパイルします。

…と、これでとりあえずコンパイルは通りましたが、6.の段階で BuildType dynamic とか出てるというのは、なんらかのオプションで、この段階で static にできたりするのだろうか…?だとしたらそれはどこで指定するんだろう?うーん、ま、これで使えるみたいだし、とりあえずはいいかな。


2010年6月18日金曜日

OGRE - Singleton

Singleton というのが何かをあらかじめ説明しておくと、C++ のようなオブジェクト指向設計ではしばしば作成したクラスがアプリケーション内で1つだけしかインスタンスを作れないようにしたい場合があり、このとき意図的にインスタンスを1つだけしか作れないように仕込みをしておくテクニックのことです。これはたいてい、誰かが誤って外部から2つ以上のインスタンスを作ろうとするとコンパイルエラーが発生するようになっており、これによって1つしかインスタンスを作成できないはずのクラスのインスタンスが複数存在してしまうというバグをあらかじめ回避しておくことができます。

さて、OGRE に含まれるクラスでも、「Root」やいくつかの「~Manager 」等が Singleton 設計になっているようです。しかし、通常の Singleton とは違っていて、「Root」のインスタンスは自分で作成するようになっており、その他の Signleton クラスのインスタンスは自動的に作られるようですがコンストラクタは public になっているため、インスタンスを複数作ることができてしまいます(複数作ってしまうとこれは当然思わしくない結果になります)。
どうやらこれは DLL のための措置のようです。Singleton の仕組みはクラスの定義内に書くことになりますが、これが OGRE ライブラリのように DLL とその他のアプリケーションの各コンパイル時に参照されるヘッダファイルだったらどうなるか?普通の Singleton 設計されたクラスでこのようなことをすれば、DLL リンク時にインスタンスが組み込まれ、その他のアプリケーション内でもリンク時にインスタンスが組み込まれ、結果として2つのインスタンスが存在することになってしまいます。
これを回避するため OGRE では、Singleton としてはあまりよくない方法ですが、基本的にインスタンスは手動でつくれるような構造になっているけど、実際には勝手にインスタンスを作らないよう気をつけてね、的な構造になっているようです。まあ、実際には Root 以外のほとんどのクラスは自動的にインスタンスが作成されているか Root のメンバ関数を通して作成するかのどちらかなので、失敗することはあまりないと思いますが。うっかりやってしまわないように気をつけないといけないですね。

2010年6月17日木曜日

OGRE - 影の描画

OGRE で影を描画する方法についての自分メモ。

1.モデリングソフトでモデルをエクスポートする際に、「Mesh」の「Build edges list (for Shadows)」にチェックを入れてエクスポートする。(影を落とす地面側のモデルは別に必要ない)

2.シーン初期化に次のようなものを追加する(パラメータはそれぞれ必要に応じて変更)。

this->sceneMain->setShadowTechnique( Ogre::SHADOWTYPE_STENCIL_MODULATIVE );
this->sceneMain->setShadowColour( Ogre::ColourValue(0.4f, 0.4f, 0.4f) );
this->sceneMain->setShadowTextureCasterMaterial( Ogre::StringUtil::BLANK );
this->sceneMain->setShadowTextureReceiverMaterial( Ogre::StringUtil::BLANK );
this->sceneMain->setShadowTextureSettings( 512, 2, Ogre::PF_X8R8G8B8 );
this->sceneMain->setShadowTextureSelfShadow( false );
this->sceneMain->setAmbientLight( Ogre::ColourValue(0.6f, 0.6f, 0.6f) );

3.ライトを作成し、影を有効にする(ここでは平行光源)。

Ogre::Light* light = this->sceneMain->createLight( "SunLight" );
light->setType( Ogre::Light::LT_DIRECTIONAL );
Ogre::Vector3 dir( -0.5f, -1.0f, -0.5f );
dir.normalise();
light->setDirection( dir );
light->setDiffuseColour( 0.95f, 0.95f, 0.95f );
light->setSpecularColour( 0.95f, 0.95f, 0.95f );
light->setCastShadows( true );

4.後は普通に描画すれば自動的に影を描画してくれる。影を落としたくない Entity は、Entity のメンバsetCastShadows() で false を渡せば描画されなくなるはず。(デフォルトではすべて true になっている)

2010年6月16日水曜日

OGRE

仕事でちょっとしたデモを作ることになって、フリーの 3D エンジンを使うことになった。で、いくつか見てみたところ、この OGRE という 3D エンジンを使ってみることにした。本まででているようなので、結構有名なものなのだろう。
専用の Exportor で出力して、そのまま読み込んで、ぽんと表示できる。プログラムもかなり簡単に組めるので、いい感じ。