海外ゲーム技術勉強会#1 OGRE3D

OGRE 3D海外ゲーム技術勉強会#1 資料 @minahito

本日のお話

OGREを使う

OGREの拡張性

OGREのレンダリング

Plugin アーキテクチャ/Reference App Layer

OGRE 3DObject-oriented Graphics Rendering Engine

シーングラフベースの描画システム

抽象化によりDirectX/OpenGLに両対応

MITライセンス

ちょっとだけ紹介してます↑

OGRE 3D2001-2002年頃開発開始、2005年リリース

当時まだそれほどジャスティスではなかった STL を多用、主要なジャンプはほぼvtable経由、なにこれ重い！(2001年)→PCの発展で超余裕に

個人ではなくチームでメンバーを刷新しながら開発、コミュニティも充実

OGRE 3D2001-2002年頃開発開始、2005年リリース

当時まだそれほどジャスティスではなかった STL を多用、主要なジャンプはほぼvtable経由、なにこれ重い！(2001年)→PCの発展で超余裕に

個人ではなくチームでメンバーを刷新しながら開発、コミュニティも充実

最近のバージョンでは、毎フレーム解放再確保するようなコンテナは自前の効率の良いアロケータを使うようになっている

OGRE 3D

オープンソースプロジェクトなので特定タイトル向けの設計傾向を極力排除できる

設計＞速度（製品作ってご飯食べるわけじゃないから）

Game Engine Architecture などでも紹介

お話ししたいことオブジェクト指向でエンジンを提供すると、なにができて、コード面はどうなっちゃうのか

OGRE はOOの利点をゲームタイトルにおける部分的改造と追加、そしてそのre-useに利用

タイトル非特化フレームワークやエンジンの開発ミッションを背負ってる方の参考情報のひとつに




描画エンジン的観点では見るべき点は少ないです！




描画エンジン的観点では見るべき点は少ないです！

得られるものもありますが、今の時期を考えると、 OGRE をじっくり見るより、まずなにより

DX11 を触っておくべき時期だと思います！

OGREを使う本題じゃないのでさらっと

ExampleApplicationExampleApplication は即OGREアプリを作るための簡易フレームワーク

下位ライブラリと明確に分けられている

使わなくても良い

ExampleApplicationExampleApplication は即OGREアプリを作るための簡易フレームワーク

下位ライブラリと明確に分けられている

使わなくても良い導入開始時のMAINが短いのは使う側にはありがたい

シーングラフの構築

シーングラフの構築

UnityのTransformコンポーネントみたいなもの

MovableObject

エンティティ、ライト、カメラ等はシーンノードの継承クラスではない→ノードにアタッチして使う

アタッチ可能IF : MovableObject を継承

シーングラフノードとMovableObjectを別系統で拡張可能

MovableObject

エンティティ、ライト、カメラ等はシーンノードの継承クラスではない→ノードにアタッチして使う

アタッチ可能IF : MovableObject を継承

シーングラフノードとMovableObjectを別系統で拡張可能

ゲームオブジェクトは自前で定義することになる。これら MovableObject を継承拡張してゲームオブジェクトを定義するというより、コンポーネント扱いして、コンポジットして作るのが一般的。

フレーム前後の処理

FrameEvent の中に⊿時間なども入っている

フレーム前後の処理

FrameEvent の中に⊿時間なども入っている

クラスを書き換えなくて済むし、インスタンス単位で別の処理ができるし、拡張されたクラスに対しても共通のリスナーを食わせられる。

OGREはかなり多くのクラスが専用のリスナーを備えており、前後処理のフックや特定イベントの通知を受け取れる。

OGREの拡張性

OGREの拡張性既存のクラスを継承拡張する

→RenderSystem

→SceneManagerでよくやる

OGREが持っていない機能を単に追加

特定役割のオブジェクトを差し替える（後述）


→RenderSystem




RenderSystem

起動時に環境にあわせてひとつ選択する

+ getSceneManager(name)+ getRenderSystem()+ getRenderManager()+ getMeshManager()

Ogre::Root

Ogre::RenderSystem

Ogre::RenderSystem_GL Ogre::RenderSystem_Direct3D9


→RenderSystem




ゲームによって空間管理やカリングが異なる

標準、BSP、ページベース、四分木、八分木などのシーンマネージャを入手可能

ディアブロタイプフライトゲーム

SceneManager

レベルに合わせて変更するためにスイッチ可能

+ getSceneManager(name)+ getRenderSystem()+ getRenderManager()+ getMeshManager()

Ogre::Root

Ogre::SceneManager

Ogre::OctreeSceneManager Ogre::BSPSceneManager

Observer/Visitor 再びOGRE全般に行き渡っているポリシー

例) 標準シーンマネージャとOctTreeシーンマネージャでは、異なる型のシーンノードを生成する

SceneNode::Listener を使えばどちらのノードにもフックできる

Visitorも同様の貢献をする（詳しくは後述）


→RenderSystem





→RenderSystem



特定役割のオブジェクトを差し替える（後述）モジュール的に追加するならプラグインがよい

この情報に従ってDLLをロードする

起動したサブシステムは Ogre::Root からアクセス可能

plugin.cfg

pluginとRefAppLayer

pluginはOgre::Rootからアプローチ可能なシステムを追加する共通の段取り

Reference Application Layer ... OGREと3rd Libを強烈に関係させる例（物理エンジンなど）

本日は割愛！（超重要）すみませんすみません...

換装できないものもあるResourceManager はそれ単体の拡張性はあるが、 MyResourceManager 等と取り替えることは不可

TextureManager、MeshManagerなども同様

ただしOGRE内部で依存性の低いサブシステムは「標準のものは使わずに追加したプラグインのものを使う」ことができる

OGREのレンダリング

シーングラフ中の MovableObject から Renderable を収集して描画する

MovableObject ≠ Renderable ... ボリューム、音源、ライト、カメラ、etc...

MovableObject、Renderableはタイトル側で拡張されていることが多いが、インターフェイスを通じて Renderable を集めることができる

抽象化の下でのレンダリング

シーングラフ中の MovableObject から Renderable を収集して描画する

MovableObject ≠ Renderable ... ボリューム、音源、ライト、カメラ、etc...

MovableObject、Renderableはタイトル側で拡張されていることが多いが、インターフェイスを通じて Renderable を集めることができる

抽象化の下でのレンダリング

MovableObject は複数の Renderable を持つことができる（そして持つことになる）。キューの受け入れは１回だが、受け入れ時に複数積むことができる。ソートはお任せ。

Root::renderOneFrame() がキックされて描画開始

+ renderOneFrame()Ogre::Root

Rootは１つ以上のプライオリティ付け済みのレンダーターゲットを抱えてる。

順番に更新


+ update()Ogre::RenderTarget

1...*

レンダーターゲット更新にあたり、ビューポートを１つ以上持ってるので、すべて更新する



+update()Ogre::Viewport1...*

1...*

レンダーターゲット更新にあたり、ビューポートを１つ以上持ってるので、すべて更新する




1...*

このレンダーターゲットとビューポートのアプローチだけを見ても、DX11の特性を生かした対応はこのままでは難しいでしょう。

ビューポートにはカメラが割り振られているので、レンダリングを依頼




1...*

+ renderScene(Viewport*)Ogre::Camera？

ビューポートにはカメラが割り振られているので、レンダリングを依頼




1...*

+ renderScene(Viewport*)Ogre::Camera？

このカメラはシーンマネージャによって型が異なる可能性がある。

カメラは自身のクリエイターであるシーンマネージャと協働でレンダリングを開始する

？




1...*

+ renderScene(Viewport*)Ogre::Camera

+ renderScene(Camera*, Viewport*)Ogre::SceneManager？

シーングラフ中の MovableObject から、 SceneManager のポリシーでカメラから見えている Renderable を収集

空の RenderQueue が、 Renderable をエンキューしてもらう旅に旅立つ（始発駅: ルートノード）

カスタム RenderQueue を作って差し替え可

RenderQueue




RenderQueue

RENDERQUEUEはエンキュー時にソートを行う




RenderQueue

RENDERQUEUEはエンキュー時にソートを行う

この話です

QueueへのVisitor（おまけ）

Ogre::QueuedRenderableVisitorOgre::RenderQueue

系

+ acceptVisitor()Ogre::QueuedRenderableCollectionxxxVisitor

↑やっぱこれも差し替え可能

VisitorにRenderableが渡された先からカメラが割り振られているので、レンダリングを依頼

？

？

最後に

まとめExampleApplication のようなフレームワークは任意導入なのであると嬉しい

Observer と Visitor で各クラスの責任範囲をシンプルにしたまま、その方向性で拡張できる

DX11の威力発揮が難しい設計とはいえ、描画シーケンスは基底クラスに手出しすることなく、短いコードで深いカスタマイズができる

Reference Application Layer

アニメーションシステム

描画上の”レイヤー”とその制御方法

リソースマネージャ

ゲームエンジンアーキテクチャにちょい情報有

今日やらなかった重要話

Reference Application Layer

アニメーションシステム

描画上の”レイヤー”とその制御方法

リソースマネージャ

ゲームエンジンアーキテクチャにちょい情報有

今日やらなかった重要話

また機会があれば！

問題点

抽象化のベースモデルが Direct X8 の時代からさして進んでない

メニーコアや GPU オフロード

描画トリック

例) Deferred + Forward, ベロシティマップ, etc...

おまけ話DX11 への（効果的な）対応策を打ってくると信じており、設計を楽しみにしています

Ogreはアプリ側やプラグイン側でも計算コードが畳み込まれるようにインライン関数が非常に多くなっています

のけぞらないように……

ご静聴ありがとうございました

Twitter: @minahito

Technology

海外ゲーム技術勉強会#1 OGRE3D