)シーンとは世界のようなもので、複数の世界を用意し、それぞれの世界を描画することが可能です。プロパティを切り替えることで、描画する世界の切り替えが可能となっています。ボタンは使い方を示す上で用意されているもので、押した時に実行されるコードは次のとおりです。アクセスして指定シェイプの剛体追加を行なうというものです。距離画像の3D表示を行います。下記の通り、何も書かれていない状態です。ポイントスプライトポイントスプライト用のシェーダコードを作成したいと思います。頂点だけオブジェクトを作成します。ファイルに変換します。...変換に失敗しました。出力先フォルダが作られていないだけでした。出力先フォルダを作成するよう修正、結果コンバートに成功し、変換後のファイルを読み込むことを確認しました。おや?FBXConverterを介すとマテリアルがうまく作れません。出力するとどうも、法線情報が含まれていない様子...どうなっちゃっているのでしょう?詳細を調べます。頂点情報のみの場合は、頂点位置のみで、法線情報は出力されない仕様のようです。してプリミティブを出力します。対応していたので、最初読み込めないだけでした。頂点描画ができるようになりました。ポイントスプライトを作成するため、まずは現在描画しているシェーダコードを見てみましょう。自動生成したシェーダコードです。距離に応じて色を変える作りを入れてみます。Z軸に対し近くが赤、遠くが青となるようにグラデーションをかけます。結果は次のとおりです。後付でシェーダパラメータとプロパティを結び付けたいものです。この発言の意味を具体的に示します。現在の時点でマテリアルカラーがこれに当たります。下記の通りマテリアルカラー変数をシェーダコードに定義し、ピクセルシェーダで直接利用します。マテリアルカラーがあることを示します。シーンに一つ作られており、そこの文字列を参照するID(インデックスですが)がここには打たれています。次のとおりでは、システム側は何をしているのか?自分でも思い出せないので、詳細を追ってみます。ツリーには並んでいます。ノードだけで親から子ノードへ下りながら再帰します。ノード変数の更新は、ノード単位、例えばノードの姿勢行列とかです。ノードがメッシュの場合に描画するのですが、メッシュには複数のプリミティブが存在します。プリミティブの存在単位はマテリアル数と同じと考えることができます。なりここでは6回ループしながら、エフェクト変数を更新しつつ、プリミティブの描画を行います。一つ驚くかもしれませんが、プリミティブインデックスはシーンで一意なIDとして機能します。メッシュからプリミティブを複数参照する場合どのようにアクセスするかですが、上記コードの通り連番でアクセスできます。マテリアルカラーの更新を行っているはずなので、中身を明らかにします。]]>マテリアルがあれば、マテリアルのディフューズテクスチャフラグをチェックなければシーンのマテリアル情報からディフューズカラーを取り、何やら変数IDを指定して設定をシーンにお願いしています。何を行っているのか確認します。プリミティブとエフェクトは一対一で対応付いているので、プリミティブインデックスからシーンのエフェクトを引っ張ってこれます。(注意したいのがインデックスは同一ではないです、エフェクトはマテリアルと読み替えることができます。対して値を設定しています。今のところ、予約変数と2Dテクスチャのセマンティクスにのみ対応しています。これが現在プリミティブが持っているエフェクト変数に対して走査が行われるようになれば、目的を達成できそうです。これらの予約変数を作成している処理が次のとおり。]]>結構このサイトを閲覧している方から、質問メールをもらうのですがとりわけこのエフェクト作成についての質問が多いです。上記コードが回答なのですが、このコードはエフェクト情報からエフェクトとその入力レイアウト、エフェクト変数アクセサ予約変数に関しては現在のパラメータで初期化するという操作を行っています。いうの見ていると色々なことが頭を駆け巡りますが、必要な計算、必要な更新のことを考えるとノードツリーの描画フローでは一度GPU側の変数を更新したら、次にCPU側のパラメータを変更するまでは更新は不要になります。今はマテリアルカラーを必ず更新するフローになっていますので、結構低速となり得るコードです。いったギミックを入れていきます。...脱線してますね。見えてきたところで、この話は次回に行おうと思います。ポイントスプライトに話を戻します。ポイントスプライトを行なうためには、ジオメトリシェーダを使うのが手っ取り早いです。頂点位置を入力に、カメラ姿勢行列からビルボード用の頂点を4つ作り、三角形を2つカメラに向けて作成します。あとはワールド位置のZ座標よりカラーを決定するだけです。上記の考えに沿って書いたシェーダコードを次に示します。このコードを適用すると次の描画結果を得ます。掛けた位置情報、つまりカメラからの距離に比例して、スプライトの辺の長さを調整するようにしました。全てのスプライトは距離に影響されず常に同じ大きさで描画されます。シーンの文字列ブロックを次のとおり編集シェーダコードの予約変数は次のとおりはい、ポイントスプライトについて詳細を示しました。上記シェーダコードを参考に書けば問題ないですね。(今回は詳細を示せました。)3Dセンサ情報表示プラグインあとはセンサからもらった3D位置を入力にポイントスプライトを描画する仕組みを入れてみたいと思います。オーディオプラグインを参考にしたいと思ったので、どのようなインタフェースを用意すれば良いのか確認します。基本的には必要な情報を渡し初期化、終了処理を行なう関数を用意する。入力データを渡してそれを処理する関数を用意する。設計の話になりますが距離画像だけを入力としてもらいたいプラグインもあればカラー画像だけを入力にもらいたいプラグインもあるわけで処理的にはどちらも、または音声までも一緒にもらいたいプラグインもあります。初期化処理に必要な情報はそれぞれ異なるので、どうしたものか...プラグインに種類を作り、これをプラグインに教えてもらう形はどうでしょうか?プラグインを使う側はその宣言を頼りに初期化処理を行うのです。気になる技術を確かめてみます。リフレクションについてです。カスタムアトリビュートでを定義して指定したプロパティを取得できることを確認しました。これを使って、まずはプラグインアセンブリかどうか判断することにします。共通のプラグイン用アトリビュートとプラグイン基底クラスを提供するアセンブリを用意してプラグインはそれぞれのタイプに合った基底クラスを継承して作成することにします。すると結構簡単にプラグインクラスを扱えるのではないでしょうか?設計なのか構想なのか、とにかくイメージしたものを形にしてみようと思います。したい、あーしたいをユースケースにて誰が何をどうするに書き換え登場した単語をオブジェクトとして切り分けるとクラスやその属性が見えてきます。概念設計を行った所、早速実装してみましょう。買ったので、クラス図からソースファイルの作成をやってみたいと思います。先ほどのクラス図のクラス名などを実装仕様にしました。ワンボタンで次のようなクラスコードを構築してくれます。(これは嬉しい!)設計図に書き込んでいたコメントも良い感じで書き込んだ状態でソースコードを構築してくれますしステレオタイプでプロパティであることを設定しておけばプロパティとして属性を書いてくれます。おまけにクラス間の集約について記述すると、そこからメンバも自動生成してくれる優しさ。半日から、一日に相当するめんどくさい実装作業があっという間に完了します。買ってよかったなと思います。実装を埋めて思い通りにプラグインを管理できるのか試してみます。今回の話は長いなぁ...勉強することがいっぱいです。プラグイン機構を実装しました。今までと基本的には何も変わりませんが、任意のプラグインを選択デバイスストリームに対して割り当てることが出来るようになります。距離画像処理用のプラグインを作ってみましょう。3Dデータの取得ここまで距離画像の情報は取得できること、表示できることを確認しています。距離画像データではなく、3D点雲がデータとして欲しい所なので、具体的な取得方法を確認します。前のことになりますが081話で調べていました。カラーカメラの画像座標でした。は?あとで確認します。あ、記述を見つけました。