プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
GamefestJapan2008XNADemo
Gamefest Japan 2008 デモプログラム
4種類のデモがあり、各種技法による効果のほどを自分のPCで実感できる。TimeRuler等のコードも含まれている。



◎シェーダーインスタンスとは?

前回冒頭で紹介した資料には「同一の3Dモデルを大量に描画すると遅くなる問題」を回避する手法として、モデルインスタンスが挙げられています。シェーダーインスタンスは、モデルインスタンスの手法の1つです。

目的:
・DrawPrimitiveの呼び出し回数を削減し、高速化を図る

手順(資料抜粋):
・頂点とインデックスデータを最大インスタンス分だけ
 コピーし、各頂点にインスタンス番号を追加する
・インスタンス情報は定数レジスターへ格納する

注意点:
・カスタム頂点を利用するので、通常はHLSLを使う



◎命題

地形モデルは1つだけなので、単純に考えれば、地形モデルへのシェーダーインスタンス適用は不可能(意味がない)です。

ここでは、あくまで「シェーダーインスタンス技術を応用して地形モデル描画を高速化できるか?」という命題と解釈してください。

・地形モデルへの適用は可能か?
・どれ程の効果が期待できるか?
・適用にあたり何をすれば良いか?

こういった根本的な疑問から探っていきましょう。



◎地形モデルへの適用は可能か?

適用可否を判断するため、手順の実現可否を検証します。

・頂点とインデックスデータを最大インスタンス分だけ
 コピーし、各頂点にインスタンス番号を追加する

 →頂点とインデックスデータは既に展開済であるため、
  コピーは不要
  (最大インスタンス量は描画プリミティブ数に相当する)

 →「各頂点にパターン番号を追加する」は実施済
  (インスタンス番号はパターン番号に相当する)


・インスタンス情報は定数レジスターへ格納する

 →定数レジスタに格納すべき情報は存在しない
  (position、Scale、Rotation等は不要)
  (パターン番号は頂点データから取得する)


・上記以外に想定される懸案事項

 →HLSLによる大量のパターンテクスチャの管理、描画


よって、上記懸案が解決できれば適用可能と思われます。



◎どれ程の効果が期待できるか?

地表モデル(DrawIndexedPrimitives呼び出し回数:1回)の前回計測実績は、48~60fpsでした。

よって、地形モデル全体のDrawIndexedPrimitives呼び出し回数を1回にすると、上記に近い描画速度が期待できます。

また、副作用として、地形作成処理が若干高速化します。(インデックスデータの分割処理が不要になるため)



◎適用にあたり何をすれば良いか?

・カスタムエフェクト(HLSL)描画に切り替える
 →頂点からパターン番号を取得し、テクスチャを描画する
 →HLSLでBasicEffectと同等の効果を実装する



◎おや?

皆さんはお気付きになりましたか?
地形モデルにシェーダーインスタンスを適用するはずが、図らずも、前々回のB案と同じになってしまいました。

これって、偶然?それともどこか間違えた?
ちょっと自信無いです。う~ん…。


シェーダーインスタンスもB案も(たまたまですが)目的は一緒です(DrawIndexedPrimitives呼び出し回数を減らすこと)。目的を達成するための手段を検討したら、手段も同じ結論に至っただけのことかもしれません。

B案の考え方って、一般的にアリ(実装しても良い)だったのか…。



◎次回予告

A案をやってるのかB案をやってるのか解らなくなってきましたが、とにかく実装に入りましょう。

スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
ゲームパフォーマンスの実践的な改善方法
XNA Game Studioゲームパフォーマンスの実践的な改善方法
「Gamefest Japan 2008」で使用された資料。音声付き。
ゲーム速度を向上させるヒントが多数記述されている。



◎ピンポイント!

遅延対策を実施すべく、前回A案の「DrawIndexedPrimitivesの描画速度が向上するよう調査」を開始したら、いきなりヒットしました。

ひにけにXNAの「GPUはいつ描画するのか?

いや~、私の疑問がピンポイントで解説されているなんて…しかも、この記事は今月書かれたばかりじゃないですか!
ちょっとタイミングがずれていれば、A案は速攻で諦めていたかもしれません。あまりのタイミングの良さにビックリです。
Itoさん、ありがと~!!

しかも、この記事によると、前回書いた「もしかしたら垂直同期などの同期待ちかもしれません」という推測が、意外と(?)当たってたみたいです。
この推測は、追加計測をまとめた際に初めて気付いたことなので、時間を惜しまずやった甲斐がありました!(^^)



◎skinning sampleの高速化について

前述の記事によると「マテリアルバッチ」が現状を打開するキーワードになりそうです。

このキーワードからこちらのQ&Aを探し当てましたが、このQ&Aには「skinning sample」の高速化のポイントが書かれているので、「skinning sample」ベースのアニメーションを実装しているXNAユーザは、かなり参考になるのではないでしょうか?

それにしても…Itoさんが測定もせずにボトルネックを指摘できるプログラムを、公式サンプルとしないでほしいですね。
大勢のXNAユーザが「skinning sample」ベースのアニメーションを実装している現状を思うと、ちょっと悲しくなります。



◎モデルインスタンス

Q&A内のURLから、冒頭の「XNA Game Studioゲームパフォーマンスの実践的な改善方法」という資料の「モデルインスタンス」に辿り付くと、ポリゴン数の少ないモデルを沢山描画する手法が3つ挙げられていました。

・マテリアルバッチ
・シェーダーインスタンス
・HW インスタンス

ひにけにXNAではマテリアルバッチが紹介されていたので、まずこれからやってみて、効果が無ければ他の手法も試すつもりです。

ちなみに、モデルインスタンスについては、こちらの記事の「Mesh Instancing」の説明が参考になると思います。
このサンプルの存在も、ちょっと気になりますね。キリが無いので今はやりませんが、いずれ解析することになるかも。



◎ループの改善

というわけで、前述の資料のマテリアルバッチのコードと現状コードを比較したら…あれ?殆ど一緒??
いや待て、よく見ると、ループのネスティング(入れ子)が違いますね。

現状コードは、(パターンテクスチャ用の)forループの中で、エフェクトパスを開始~終了してました。これだと、ループの中でpass.Endを何度も呼び出すことになります。だから、同期待ちが発生していたのですね。

逆に、エフェクトパスを開始してから、(パターンテクスチャ用の)forループを記述し、DrawIndexedPrimitivesの発行処理が全て終了してから、最後にpass.Endするように変更しました。テクスチャ変更を反映させるために、basicEffect.CommitChangesも挿入しました。

ループ改善のポイントは以下の通り。
改修前:pass.Endが複数回呼び出されていた
改修後:pass.End呼び出し回数を1回とした

改修前と改修後の計測結果は以下の通り。
・地表モデル:30~38fps → 48~60fps
・地形種別モデル:1fps → 1fps

地表モデルは、DrawIndexedPrimitives呼び出し回数が1回であるため、描画速度が向上しました。
地形種別モデルは、DrawIndexedPrimitives呼び出し回数が多いので、そちらがボトルネックとなり、描画速度は変わりませんでした。



◎マテリアルバッチの補足説明

地形モデルに対するマテリアルバッチ改修は以上ですが、これだけだと「マテリアルバッチ=ループ改善??」と誤解されそうなので補足します。

通常のXNAプログラムでは、複数の3Dモデルを描画する際に、mesh.Drawを複数回呼び出します。これはGPU側ではpass.Endを複数回呼び出すのと同様の動きになるので、同期待ちが発生します。

これを回避するために、mesh.DrawからDrawIndexedPrimitivesに変更したり、ループを変えたりして、pass.Endの呼び出し回数を1回にするのがマテリアルバッチの目的です。たぶん…。

pass.Endの同期待ち要素は影響力が大きいので、通常の描画方式と比べれば、これだけでもかなり描画速度が向上する可能性があります。地表モデルの描画速度は1.5~2倍ほど向上しましたが、資料によると、3~5倍くらい速くなることもあるそうです。

但し、同期待ち要素は他にもあるので、他の要素がボトルネックとなっている場合、そちらを解消しないと効果は現れません。

資料では、マテリアルバッチの短所の1つに「DrawIndexPrimitive の呼び出し回数は多いまま」を挙げています。つまり、マテリアルバッチだけでは、地形種別モデルの描画速度は向上しない、ということですね。



◎次回予告

資料の内容は3割程度しか理解できませんでした。
でもまぁ、3割でも理解できるようになっただけマシかも?

これを足掛かりに、さらなる技術力向上に励みます。
頑張るぞ~!

次回は「シェーダーインスタンス」にチャレンジします。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
私釈三国志
私釈三国志
三国志関連サイト。相方との会話形式で、独自解釈の三国志をコミカルに語っている。筆者は袁紹と禰衡のファン?



◎まとめました

「計測作業は中止」と書きましたが、「簡単にできて後々参考になりそうなこと」がありましたので、若干の追加計測を実施し、前回の計測と合わせてHPにまとめました。

XNAの3Dモデル描画速度に関心がある方はどうぞ。

立体地形モデルの描画速度に関する計測と考察



◎対策案

遅延原因は「DrawIndexedPrimitives呼び出し回数が多すぎるため」ということが判明しました。
私が考えた対策案を列挙します。

A案
DrawIndexedPrimitivesの描画速度が向上するよう調査改修する。

B案
頂点データフォーマットにパターンテクスチャ番号を追加し、
表示時はその情報を参照しながらHLSLでパターンテクスチャを描画する。

C1案
現状の地形モデルをmodelクラスに格納し、mesh.DrawかACLで描画する。

C2案
コンテントプロセッサで地形モデルを生成し、modelクラスに格納してmesh.DrawかACLで描画する。

D案
パターンテクスチャを廃止し、テクスチャは地形種別の数と同数だけ用意することとする。
1マスあたり現状2ポリゴン→8ポリゴンに変更する。

E案
メタセコイアで地形モデルを作成し、modelクラスに格納してmesh.DrawかACLで描画する。
メタセコイアで作成した地形モデルを読み込んで、カラーマップを生成するツールを作成する。



◎対策案のポイント解説

A案は、案というよりも願望です(笑)具体的な手法はまだ何もありません。計測結果の中に気になる数値があったので、一応調べてみよう、というものです。

気になる数値とは「DrawIndexedPrimitives呼び出し回数:1回=30~38fpsと、15回=15fps」です。ちょっと差がありすぎる気がするので、もしかしたら垂直同期などの同期待ちかもしれません。その場合は、同期待ちしないようにすると、速くなるかもしれません。


B案は、2009/2/28~2009/3/2の記事で「B案」として試した手法です。

この手法なら、DrawIndexedPrimitivesの呼び出し回数は1回で済むので、高速化できそうです。但し、この手法で何百種ものテクスチャを描画できるのか?という懸念はあります。


C1案C2案は「DrawIndexedPrimitivesがダメなら別の方法で描画しよう」という発想ですが、現状より早くなる根拠は全くありません。下手すると現状より遅くなります。なので、この案を採用する前に、どれだけ早くなりそうか予測テストを実施すべきです。

尚、C1案は技術的に難しそうです。また、C2案は二か月前に私が断念した方法ですが、今なら実装できる自信があります。但し、ゲーム中の地形種別変更はできなくなります。


D案は、パターンの模様を、テクスチャではなくポリゴンで再現しよう、という発想です。速度的にはかなり期待できそうですが、見た目は大幅に劣化します(一目で「ポリゴンの境界線だ!」とわかるようになります)。


E案は、現状の「カラーマップから地形を作成する」機能を逆転し、「地形からカラーマップを作成しよう」という発想です。パターンの概念が無くなり、見た目と描画速度のバランスは、メタセコイアで手作業で調整します。

尚、地形の正確な高さが取得できなくなります(大雑把な高さは取得できます)。また、ゲーム中の地形種別変更もできなくなります。



◎優先順位の検討

対策案の優先順位は以下の通りです。この順番で着手し、目標の20fpsを達成するまでやるつもりです。

A > B > E > C1 > C2 > D


最優先はA案。願望ですから、当然ですね。

お次はB案。実現性が高く、描画速度が早くなる可能性も高いので期待大です。

続いてE案。見た目と描画速度のバランスが自由に調整できるのが魅力です。但し、ユニットが多少地形にめり込んだり宙に浮いたりするかもしれません。
ちなみに、この案を採用すると、ここ数カ月やってきたことの大半が無駄になります(笑)

C1案C2案は、どれだけ速くなるか疑問です。あまり期待していません。

D案は、見た目が大幅に劣化するので、できれば避けたいですね。



◎次回予告

対策案と優先順位が決まったので、次回から遅延対策を実施します。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
FRAPS
FRAPS
キャプチャーソフトとして有名だが、フレームレートの計測も可能。無料体験版はキャプチャ機能が制限される。



◎目的

自作地形は、当初目指した機能を一通り実装しました。後はひたすらパターンテクスチャを描き込んでいけば、いくらでも綺麗にできます。

しかし、描画速度が非常に遅く、このままではゲームになりません。遅延原因を特定し、対策を講じて描画速度を向上させる必要があります。



◎計測ツール

描画速度と言えば、フレームレート(単位はfps、1秒間に何回画面を書き換えることができるかを表す)が基準となりますので、先にfps計測ツールを導入しておくべきでしょう。検索すると、冒頭のFRAPSが一番メジャーっぽいので、こちらを導入しました。

しかしfps関連の設定を行い実行しても、フレームレート数値は画面上に表示されないし、ログも出力されません。おかしいな、無料体験版でもfps計測は可能なはずだけど…。

しばらく設定変更、画面解像度変更、市販ゲーム起動などを繰り返したら、ログが出力され、fpsも画面表示されるようになりました。何だったんだ、一体?まぁ動いたからいいや。

で、現状のプログラムを計測したら、0~1fpsでした。(爆)
ちなみに、シヴィライゼーション4は約20fps、コーエー三国志10は2Dのためか計測できませんでした。

当面の目標は20fpsですね。今後のことを考えると、30fps以上にしたいです。



◎計測計画

どの要素がどのくらい負担になっているのか計測し、一番ネックとなっている要因を特定しましょう。

・テクスチャの模様の複雑さ
 →現状(ノーマルパターンテクスチャ)
 →パターンテクスチャの模様を全部赤色にする
 →パターンテクスチャの模様を全部単色(色違い)にする

・表示モデル数
 →現状(地形モデルを全て統合)
 →地表と地形種別を分割
 →地形種別毎に分割

・表示プリミティブ数
 →現状
 →表示プリミティブ数を半分に減らす

・テクスチャの解像度
 →現状(512×512)
 →256×256
 →128×128



◎計測開始

まず、テクスチャの模様の複雑さが、速度にどの程度影響するかを計測しましょう。現状(ノーマルパターンテクスチャ)と、全て赤色に差し替えた場合でそれぞれ比較します。

飛行テストプログラムを改修し、A地点からB地点まで1分間飛行させてフレームレートを計測しました。

・現状(ノーマルパターンテクスチャ):0~1
・全て赤色テクスチャに差し替え:0~1

あれ?全て赤色にしても0~1ですか?見た目は少し早くなったようでしたが、ドングリの背比べってことですね…。
これだと比較する意味がないので、ユニットや城など地形以外のモデルを全て削除してやり直します。

う…それでも2以上にならない。こーなったら、地形を分割してそれぞれ計測してみましょう。

地表のみテクスチャ赤   地形種別のみテクスチャ赤
赤テクスチャ地表モデル(左図)と地形種別モデル(右図)

・赤テクスチャ地表モデル:30
・赤テクスチャ地形種別モデル:1

あら?地表のみが30で、地形種別のみが1ですか?面積は地形種別のみの方が小さいのに…。

原因を調べてみましょう。



◎遅い原因判明?

地表モデルと地形種別モデルを比較調査したら、遅い原因らしきものが掴めてきました。

・地表モデル
 →フレームレート:30
 →描画プリミティブ数:84652
 →DrawIndexedPrimitives呼び出し回数:1回

・地形種別モデル
 →フレームレート:1
 →描画プリミティブ数:42356
 →DrawIndexedPrimitives呼び出し回数:446回

テクスチャは全部真赤で、プリミティブ数(=ポリゴン数)は地表モデルの方が多い。にもかかわらず、地形種別モデルの方が重いのは、DrawIndexedPrimitivesの呼び出し回数が多いからでしょう。

恐らく「何百や何千のマテリアルを持つ3Dモデルなど想定していない」ということだと思います。



◎確認

前述の推測が正しいか確認するために、カラーマップを置換して、速度差が生じるか確認しました。

カラーマップ青で置換

 →フレームレート:15
 →描画プリミティブ数:42356
 →DrawIndexedPrimitives呼び出し回数:15回

間違いありませんね。同一形状&同一テクスチャですが、DrawIndexedPrimitives呼び出し回数を減らすと、フレームレートが向上しました。

遅延原因が特定できたので、計測作業はここで中止します。他の計測項目についても興味はありますが、今は遅延対策が優先ですからね。



◎次回予告

遅延原因が意外に早く特定できたのは良いのですが、対策案を考えるのはちょっと難しそうですね。でも、何とかしないと、今のままでは、ゲームになりません。

というわけで、次回は遅延対策案を検討します。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
ブログが作りたい!
ブログが作りたい!
FC2ブログ作成手順などを、初心者向けに優しく解説している。GIMP2やInkscapeの使い方などの記事もある。



◎作業目的

荊州は水郷地帯なので、「湿地or河原」と「水田」の地形を追加します。(本当は「森」も追加したいのですが、理由があって、今回は保留にします)

同時に、以下の3項目について確認します。

・地形が確実に追加できることの確認
・地形を追加する手順の確認
・地形追加後の実行速度(マシン負荷)の確認



◎作業手順

作業は、多分こんな流れになると思います。
(この手順が正しいか確認するのも目的の1つです)

1 カラーマップ修正
2 テクスチャ準備(収集&修正)
3 パターンテクスチャ作成&登録
4 プログラム修正



◎カラーマップ修正

カラーマップを修正しました。難しいことは何も無いんですけど、春先にピクセル単位で修正してると、もう眠くて眠くてw

カラーマップ

色は下記の地形を表しています。

青 → 川、湖
紫 → 田畑
水色 → 湿地 or 河原
黄色 → 道
白 → 平原



◎テクスチャ準備

テクスチャの収集と修正。私の苦手な分野です(^^;

まず湿地の写真を収集しようとしましたが、これが意外と難しい。アシが生い茂った状態って、一見するとただの草原っぽいんですよね~。現実に足を踏み入れないと、草原か湿地か分からなかったりするからなぁ…。

結局、今回は湿地を諦めて、河原ということにしました。これだけ川が多いなら、河原でもアリじゃないかと。


もう一つの「水田」は、とりあえず秋の稲穂の写真をベースにしました。ゲーム内の季節によって、テクスチャを差し替える必要があるかもしれません。

また、水田の場合、畦(あぜ)で区切った方が日本人のイメージに近そうですが、パターンテクスチャに合うように合成するのはちょっと難しそうです。

そもそも、古代中国の水田が均等に区切られていたか怪しいので、とりあえず今回は全面稲穂イメージを目指すこととし、新たに覚えたGIMP2のスタンプ機能等を使って修正しました。



◎GIMP2のお勉強

テクスチャ収集中に、冒頭のサイトを見つけました。

この中で初心者向けのGIMP2の記事があったので、ついでに勉強させて頂きました。お陰様で、ようやくレイヤーとパスが使えるようになりましたw


記事の中に「GIFアニメ制作」があったので、これを機に、昔2D画像に落としたモーションをGIFアニメにしてみました。とりあえずHPにでも貼っとくかな~。


これでツールボックスの機能は半分ぐらい理解したと思います。でも、メニュー側の機能は殆ど知らないので、まだまだですね。また機会があったら勉強します。



◎パターンテクスチャ作成&登録

テクスチャの元ネタが準備できれば、パターンテクスチャはツールで簡単に作成できます。
XNAの登録も、作業的には問題ありません。

問題があるとすれば、パターンテクスチャの総数が早くも132個に達した点です。大丈夫かな~?



◎実行結果

カラーマップの色の種類を追加変更したので、それに合わせてプログラムをちょっと修正しました。

では、実行しましょう。

自作地形26   自作地形26B

いかがでしょう?カラフルになって一段とゲームっぽくなった気がしませんか?

では、個々に見ていきましょう。


赤テクスチャは未登録です。多分「道路と河原」のパターンです。作成して登録するのは簡単ですが、数が少なさそうなので、別の方法(カラーマップ修正等)で対応できないか後日検討します。

河原テクスチャは灰色です。色の差別化には成功したと言えるでしょう。アップにすると、石がゴロゴロしてます。河原より湿地の方が良いのでは?という未練はまだあるので、後日変更する可能性はあります。

水田テクスチャは黄色です。色合いのバランスとしては悪くないのですが、ぱっと見で水田には見えません。やはり畦による区切りが必要ですかね~。今後の課題です。

今回、地表テクスチャも差し替えてみました。以前の地表テクスチャはアップに弱かったのですが、今回のテクスチャはアップに強いのが特徴です。しかし、遠方から見ると、以前のテクスチャの方が綺麗な気がします。森地形を配置してからまた考えましょう。



◎総評

今回、地形を2種類追加しました。個々のテクスチャの是非については、今後差し替えていくつもりです。


・地形が確実に追加できることの確認
・地形を追加する手順の確認

上記2点は問題無いことを確認しました。但し、

・地形追加後の実行速度(マシン負荷)の確認

この点は大問題でした。ゲキオモです!(哀)



◎次回予告

次回は、ついに地形プログラム最終課題!
地形描画負荷調査&速度向上について取り組みます。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
自作地形25
開発中の自作地形
川や道に段階的な淵が付いた。また、直線的だった淵の形状を改め、自然に近い印象になった。



◎ツールの改修

今回は、パターンテクスチャ自動作成ツールを改修して、パターンテクスチャを綺麗にしよう、という試みです。綺麗なパターンが自動的に生成できるようになれば、今後地形種別を簡単に増やすことができます。

パターンを綺麗にするアイデアは3つありますが、実際に綺麗になるかどうかは、正直やってみないとわかりません。



◎淵を付ける

1つ目のアイデアは「淵を付ける」というものです。地表と川の境い目のように、絵が急激に変わりすぎるとちょっと不自然なので、中間的なテクスチャを間に入れることで、自然な色の変化に近付けよう、という狙いです。

実際に川と地表の中間に「河原」テクスチャを挿入すると、少し良くなりましたが、川の場合はもう1段階あった方が良さそうです。結局2段階挿入可能とし、「浅瀬」テクスチャも挿入しました。

パターンテクスチャ03   パターンテクスチャ03実装地形
新パターンテクスチャ(左図)を実装した地形(右図)

「浅瀬」テクスチャは「川」テクスチャのコントラストを下げただけなんですが、わりと良い感じですね。少なくとも、前回の「淵無し」状態よりは良いと思います。



◎角を丸める

2つ目のアイデアは「角を丸める」というものです。角の部分が極端に角ばっていると不自然なので、これを丸めてより自然な感じにしたい、という狙いです。

パターンテクスチャ04   パターンテクスチャ04実装地形
新パターンテクスチャ(左図)を実装した地形(右図)

あれ?より不自然になってしまいました(汗)
湖や沼はともかく、川は直線的な方が良かったですね。道はちょっと微妙ですが…でもやっぱり直線的な方がいいかな。

というわけで、このアイデアは今回不採用です。折角作ったのに…(泣)

でも、今後地形を追加したら使うかもしれないので、角を丸める機能は残しておきましょう。



◎境界線をブレさせる

3つ目のアイデアは「境界線をブレさせる」というものです。
川や道がひたすら直線状だと人工的な印象を受けるので、ブレさせて自然な感じにしたい、という狙いです。

パターンテクスチャ05   パターンテクスチャ05実装地形
新パターンテクスチャ(左図)を実装した地形(右図)

いかがでしょう?なかなか良い感じになったと思いませんか?



◎パターンテクスチャ作成ツール

先に結果画面をお見せしましたが、今回ツールをどのように改修したか簡単に説明します。

パターンテクスチャ自動作成ツール

画面の右半分が、今回追加した機能です。

・テクスチャC、Dを指定すると、淵を2段階まで挿入可能
・「角を丸める」オプション追加
・ブレ具合の数値を変更すると、境界線がブレる

ブレは乱数で作成していますが、ある程度方向性を付けるために、3つのパラメータを指定するようにしました。

プログラムの中身はだんだん凄いことになってきましたが…まぁ、このツールを今後改修する予定は今の所無いからいいかな?(^^;



◎次回予告

次回は「地形種別の追加」です。
やっと地形が増やせるぞ~!!

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
自作地形24
開発中の自作地形
テクスチャの境界線が解消された。奇数列のテクスチャは反転表示しているが、ぱっと見気付かないだろう。



◎新たな問題

前回は3つの課題をクリアしましたが、これにより新たな懸案が1つ増えました。川と道のテクスチャに境界線が生じてしまったのです。

川道の境界線の問題

この懸案は、見栄えに関するプログラムの最後の課題です。かなり厄介そうですが、何とかしましょう。



◎調査開始

境界線が生じる原因を探るために、テクスチャを差し替えてみました。

川と道を芝テクスチャに差し替え   川と道を赤テクスチャに差し替え
川と道のテクスチャを芝(左図)と赤(右図)に差し替え

上図では、いずれも境界線が存在しません。

テクスチャを差し替えただけで境界線が消えたということは、プログラムの問題ではなく、テクスチャの性質の問題と考えられます。

多分、テクスチャ画像の左端と右端、上端と下端が繋がった模様になっていないために、境界線が生じたのでしょう。



◎試行錯誤

では、テクスチャの左端と右端、上端と下端を合わせてみましょう。このようなテクスチャを用意しました。

Water512A2

このテクスチャは、画像を4分の1に分割して、配置を変えたものです。

AB → DC
CD → BA

この画像は、上下左右に敷き詰めて並べると、画像の継ぎ目が無くて綺麗に見えます。(ペイントソフトで実際に4枚並べて確認しました)
水テクスチャをこの画像に差し替えて確認します。

川道の境界線が消えない

あれ?境界線(赤矢印)が消えないぞ。おかしいな??

黄矢印の色については、テクスチャを描き変えれば直るので良いのですが、赤矢印の境界線は、テクスチャを描き変えても直りません。しかもこの境界線は、飛行モードで視点を僅かに変化させただけで、消えたり出現したりします。

XNAの誤差のレベルっぽいけど…?もしかしてテクスチャ座標の誤差とか?

試しにterrainScale=256として、テクスチャ座標を全て整数にしてみました。

terrainScale=256

ダメですね~境界線が消えません。

果たして原因はプログラム?テクスチャ?どうすれば解消できるのでしょうか?



◎原因判明

そんなこんなで2日間悩みまくってましたが、「犯罪捜査に行き詰ったら現場に戻れ」とはよく言ったものです。画面を何度も見直していると、下記の事実に気付きました。

・真っ青のパターンと真っ青のパターンの境界
 →境界線が存在しない

・真っ青のパターンと他のパターンの境界
 →境界線が存在する

結論から言うと、この現象はTextureAddressModeをWrapにしているために発生しました。

Wrapは、同じパターンを繰り返すことを想定したモードなので、左端ピクセルの色計算に、テクスチャの左端と右端の色が影響していたのです。



◎TextureAddressModeの検討

TextureAddressModeは、Wrapの他にBorder、Clamp、Mirror、MirrorOnceがあります。変更可否を検討しましょう。
(各モードの表示イメージはこちら

まず、境界線を無くしたいのでBorderは論外です。

また、Clampは、現状の頂点データ(=テクスチャ座標)共有方式では、採用不可です。共有方式をやめてテクスチャ座標を4倍増やすという選択肢もありますが、無駄にバッファを喰うと全体のパフォーマンスが低下しそうなので、極力避けたいですね。

残るはMirrorとMirrorOnceです。実際に試してみました。

TextureAddressMode=Mirror   TextureAddressMode=MirrorOnce
Mirror(左図)とMirrorOnce(右図)

Mirrorは、奇数列(または偶数列)のテクスチャを反転します。縦方向の奇数列のテクスチャを上下反転、横方向の奇数列のテクスチャを左右反転すると、本来の地形に戻ります。

MirrorOnceは、Mirrorの回数指定バージョンです。指定回数を超えた部分は、Clampと同様に表示されます。今回は回数を指定しなかったので、Clampと同様の表示になりました。回数を大きく指定すれば、Mirrorと同様の表示になります。


というわけで、単純にTextureAddressModeを変更しただけでは解決できそうにありません。



◎対処方法の検討

上記を踏まえて、私が考えた対処案を記述します。

A案
 頂点フォーマットのテクスチャ座標データを4つに増やす。

B案
 地形作成処理内のパターン判定時に、奇数列の割り当てを反転する。

C案
 カスタムエフェクトにより、テクスチャ座標の左上隅と右下隅を内側にずらして表示する。

前述したように、A案はなるべく避けたい所です。
B案は実現可能と思いますが、今後デバッグが混乱する要因になりそうで心配です。
C案は、実際にテクスチャの右下隅を指定することが可能かどうか不明です。

う~ん…C案だとBasicEffectを全て自力で再現する必要があるので、開発に時間がかかる上にメンテナンス負荷も増大します。そう考えると、消去法でB案ですね。



◎実装

というわけで、TextureAddressModeをMirrorとして、これに合うようにパターン判定を補正しました。(冒頭図参照)

ついに境界線が無くなって、綺麗に表示されましたね!!

奇数列は反転するという制約付きですが、地形テクスチャの性質上あまり問題無さそうなので、境界線の問題はこれで対処完了とします。



◎補足

下記の手法も試してみました。

「TextureAddressMode=Clampとし、テクスチャ座標を偶数列=0.0、奇数列=1.0と反転させ、これに伴いパターン判定を修正する」

画面の見た目はMirrorと同様になりました。まぁ、やってることは一緒ですからね。速度的な違いも無いようなので、とりあえずMirrorに戻しておきました。



◎残課題について

当初想像していた以上に細かく表示されたので、

・メモリ消費を抑えてカラーマップの解像度を上げる
・カラーマップ修正

上記の必要性が感じられなくなりました。課題一覧から削除します。(もし後日必要と感じたら、その時に取り組みます)

というわけで、地形の残課題は下記4点です。

・パターンテクスチャの一括修正
・地形描画負荷調査&速度向上
・地形種別の追加
・パターンテクスチャの手描き修正



◎次回予告

次回は「パターンテクスチャの一括修正」です。
これでさらに綺麗になると予想していますが、果たして??

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
自作地形23
開発中の自作地形
複合パターンの対処が完了し、川や道の輪郭が滑らかになって、かなり綺麗になった。



◎追加登録方式に向けた環境整備

「全パターンのテクスチャ登録はしない」と決めました。パターンテクスチャは、必要に応じて追加登録します。

というわけで、今回最初に行ったのは、追加登録しやすいように環境を整備することです。

具体的には、パターン作成プログラムを改修してテクスチャのファイル名を4次元配列に合わせたり、メインプログラムを改修してテクスチャの存否を確認し、在れば登録、無ければ赤いテクスチャを貼る、といった具合です。



◎川と道のパターン登録

前回、地表と川、地表と道のパターンテクスチャを登録しましたが、まだ赤い地形が沢山あります。いろいろ考えましたが、川と道のパターンは頻度が多いので素直に登録することにしました。

自作地形20

赤い箇所が半分ぐらい減りました。残りの赤い箇所は、地表、川、道が3種類複合している所です。



◎複合パターンの対処

3種類以上複合したパターンを作成して登録することは可能ですが、無条件に登録していくと凄い数になってしまいます。
そこで私が考えたのは「似ているテクスチャで代用する」という方法です。

問題は、似ているテクスチャを選択するロジックですが…登録済のパターンテクスチャの中から最も似たものを選択するのが理想ですよね?

作成前は難しそうに感じましたが、いざ作るとコードは意外とシンプルにまとまりました。その理由を解説すると長くなりそうなので省略しますが、リクエストがあれば解説します。

自作地形21

おお…とりあえず、赤い箇所が無くなりましたね。果たして複合パターンがうまく選択されているか、ですが…確認の前に、2つやることがあります。



◎地形作成速度向上

地形作成部分のコードは、以前のロジックをベースに改修したものなので、かなり冗長なものになっています。具体的には、インデックスデータ作成時に4次元配列ループの中で毎回パターン判定を行っているのですが、これを改善します。

頂点データ作成時にパターン判定を行い、パターン番号を頂点データにセットしておきます。インデックス作成時はその番号を参照してパターン判定を行い、パターン判定速度を向上させました。

これにより、実行開始してから画面標示されるまで、15秒かかっていたのが3秒になりました!「任意ポリゴンのテクスチャ差し替え」も、13秒かかっていたのが2秒になりました!

これで課題ひとつクリアですね!



◎パターン判定の見直し

次に、複合パターン以前の問題として、2種類のパターンの選択がおかしいようなので、そちらの修正を図りました。

しかしパターン判定ロジックをいろいろ変えても、うまくいきません。原因が解らず首を捻っていましたが、以下の画面を見てようやくヒントを掴みました。

textureCoordinateScale

画面中央下の赤い四角形で囲んだテクスチャを見ると、1枚のテクスチャサイズがわかります。ところが、赤い四角形の左側を見ると、かなり細かい模様が表示されています。パターンテクスチャはまだ描き込んでいないので、こんな細かい模様はありません。
自分のプログラムなんですけど、「どうやったらこんな表示が可能なんだ?」としばらく悩んでしまいましたよ(笑)

何故このような表示になったのか、画面を見ただけで推測できた人はいますか?一目で見破ることが出来たら、かなりのXNA経験者だと思います。
  ・
  ・
  ・
答えは「頂点の位置とテクスチャ座標がずれているから」です。
頂点は、赤い四角形1つの中に数十個存在します。
パターンテクスチャは頂点単位に変更しているので、左側のような細かい模様が表示されているわけです。



◎綺麗になった!

というわけで、頂点座標とテクスチャ座標を一致させました。

自作地形22

おお、やった!ついに綺麗になりましたね~!!!
いつかこうなると信じて頑張った甲斐がありましたよ!!

ざっと見た限りでは、2種類のパターンも複合パターンもうまく選択されているようです。でも、地表はテクスチャサイズが細かすぎてマス目がバレバレですね。これはこれでアリかもしれませんが、とりあえず地表は以前の状態に戻しておきましょう。(冒頭図参照)



◎次回予告

前回掲げた課題のうち、

・赤い地形(複合パターン)の対処
・地形作成速度向上
・パターン判定の見直し

上記3つが完了しました。今回はかなり進みましたね~!

次回は新たな課題に取り組みます。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
自作地形17
開発中の自作地形
パターンテクスチャを実装したが、赤い部分(複合パターン)は未対処。パターンを描き込めばもっと綺麗になる。



◎最初の誤算

以前テクスチャのパターン数を計算した時は6枚(3頂点同じパターンを追加すると8枚)でした。
実際には、ポリゴンの半分は逆向きなので、6枚のパターンテクスチャを反転/回転させて対応するつもりでしたが、これが出来ないことに気付きました。

通常は、頂点データのテクスチャ座標を変更すれば反転/回転できますが、今回は、頂点データのテクスチャ座標を複数のポリゴンで共有しているため、テクスチャ座標は変更できません。

メモリ内のテクスチャイメージを反転/回転させるという回避策もできなさそうです。



◎大きな誤算

結局、パターン数を増やして対応することにしました。パターンテクスチャ作成プログラムを改造し、地表、川、道で16パターン×3種類=48枚を作成しました。

パターンテクスチャ修正前

パターンテクスチャをXNAに登録し、メインプログラムを改修しようとしたら、これでは足りないことに気付きました。
今回は地形が3種類ありますが、3種類の地形を複合したパターンが不足しています。

さらに、頂点数が3つから4つに増えたため、今後地形種別を増加すると、パターン数が相当増えることになります。
いくらパターン数の上限が無くなったとは言え、このままではさすがにまずい気がします。



◎パターンを減らせ!

全ての組み合わせを無条件で登録すると、ものすごい枚数になるので、パターンの組み合わせに制限を設けることにしました。

・地表と他の地形1種類の組み合わせのみ登録することを原則とする
・地表以外の地形を複数組み合わせる場合は、個別に管理制御する

問題は、カラーマップを注意深く作らない限り、上記後者のケースは自動的に発生してしまうので、その際にどのテクスチャを選択するか、ですね。
デバッグ用に赤色テクスチャを登録しておき、例外パターンは全て赤色で表示して、目視確認しながら個別に潰していくことにします。



◎4次元配列化

4頂点の色の組み合わせから、テクスチャパターンの種類を判別しないといけないわけですが、従来のやり方だとパターン数が多すぎて扱い切れません。
プログラムも複雑で分かり難くなってきたので、思い切ってテクスチャとインデックスバッファの管理配列をそれぞれ4次元配列化しました。

texturePattern[i1, i2, i3, i4]
vertexIndicesStartIndex[i1, i2, i3, i4]
vertexIndicesPrimitiveCount[i1, i2, i3, i4]

forループ内の注目頂点を基準とした場合、i1=上、i2=右上、i3=(注目頂点)、i4=右、に該当させています。

これによってソースが驚くほどシンプルになりました。以前のソースは凄い状態だったので…(^^;



◎パターンテクスチャの実装

少々苦戦しましたが、何とか表示にこぎつけました!
(冒頭図参照)

赤い部分は川と道が混在した所です。いずれ個別パターン等で対応しますので、今は気にしないでください。

え?全然綺麗じゃない?

それは用意したテクスチャパターンがまだ四角形のままで、かつ地形モデルを1つに統合しているからです。テクスチャパターンをきちんと描き込めば、綺麗になります。

それと、滅茶苦茶重いです。飛行テストすると、過去最悪の遅さです。うわ~CPUが2つとも80%超えてる(汗)

う~ん…速度については後で調べるとして、とりあえず見栄えについて試したいことがあります。



◎地表モデルの分離

以前は地表モデルと地形種別モデルの2種類を想定していました。パターンテクスチャは当時のままなので、試しに当時の状態に戻してみましょう。

地表モデル   地形種別モデル
地表モデル(左図)と地形種別モデル(右図)

自作地形18
上記2つを統合した地形

これが当時目指していた状態ですね。川や道が細くなって繊細な感じになりました。

速度が落ちると思ってましたが、地形種別モデルのポリゴン数が少ないたためか、分離前よりも遅くなった感じがしません。速度的な問題がないなら、とりあえずこの状態で継続しましょう。



◎パターンの修正

これだけだと、パターンテクスチャを実装した効果があまり感じられないので、パターンテクスチャを少し修正することにしました。

パターンテクスチャ修正後   自作地形19
修正後のパターンテクスチャ(左図)と適用した地形(右図)

う~む…矢印のあたりをよく見るとカクカクが少し緩和されたのがわかりますが、全体的な印象はさほど変わらないですね。さらなる改善が必要でしょう。



◎今後の課題

・赤い地形(複合パターン)の対処
・パターン判定の見直し
・パターンテクスチャの一括修正
・地形作成速度向上
・地形描画負荷調査&速度向上
・メモリ消費を抑えてカラーマップの解像度を上げる
・カラーマップ修正
・地形種別の追加
・パターンテクスチャの手描き修正

地形関連だけでもこんなに増えちゃいました(^^;

地形プログラムは今月中に完了させるのが目標なので…
ペース上げるぞ~!



◎次回予告

赤い地形が目立つので、先に複合パターンから対処します。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
自作地形A2案
開発中の自作地形
適用するテクスチャ毎にインデックスデータを分割して作成した。任意ポリゴンのテクスチャ差し替えも可能。



前々回の続きです。

◎B案の懸念と対策案

B案によって性能と機能は目標レベルに達したものの、このままでは、将来問題が生じる可能性があります。想定される懸念と、その対策案を記述します。

懸念a:Color.a(透明度)が利用できない
懸念b:VertexElementUsage.Depthが利用できない
懸念c:テクスチャパターンが数百に及ぶ場合でも、正常に動作するか?

懸念aと懸念bの対策案:
現在TEXCOORDの値は全て30未満である性質を利用して、TEXCOORDにテクスチャ番号情報も含める。具体的なコード例は、C#側で「TEXCOORD += テクスチャ番号 * 1000」とし、HLSL側で「テクスチャ番号 = TEXCOORD / 1000、TEXCOORD = TEXCOORD % 1000」として分解する。

懸念cの対策案:
予め、数百個のサンプラを登録して動作検証する。その際、動作可否だけでなく、実行速度への影響度にも注意する。

上記の対策案を実施して、問題無さそうであれば、このままいけそうな気がします。但し、例外的な仕様であることは間違いないので、必ずしも理想的とは言えないでしょう。



◎2つのA案

一方、A案について考慮すると、2通りの方式が考えられることに気付きました。

A1案(従来のA案):
適用するテクスチャ毎に、頂点データ及びインデックスデータを分割して地形モデルを作成する。表示時は、分割されたインデックスデータ毎にテクスチャを適用する。

A2案:
適用するテクスチャ毎にインデックスデータを分割して地形モデルを作成する(頂点データ作成部は変更しない)。表示時は、分割されたインデックスデータ毎にテクスチャを適用する。

A2案をA1案と比較すると、地形作成速度は劣りますが、比較的シンプルなコードで、改修量は少なくなります。任意ポリゴンのテクスチャ差し替えは、(B案には劣りますが)A1案よりも簡単です。



◎A案は一般的か?

A1案とA2案はインデックスデータを分割する方式です。
ということは、1つのモデルが複数のインデックスデータを持つことになります。それって普通のやり方なんでしょうか?

この記事から推測すると、1つのモデルのインデックスバッファは1つであり、配列の範囲で分割するみたいですね。描画時は、先頭の配列番号を指定して描画するのでしょう。



◎A2案でチャレンジ!

総合的に考えると、任意ポリゴンのテクスチャ差し替えが上手く出来れば、A2案が一番良さそうです。
改修量も少量なので、試しにやってみることにしました。

(冒頭図参照)

おお!うまくいきましたね!
HLSL(カスタムエフェクト)からBasicEffectに戻し、インデックスバッファを分割してテクスチャを変更しながら表示しています。CPU使用率も70%程度でB案と同等です。



◎XNAのマテリアル形状データの格納場所

XNAで3Dモデルを扱う場合、大きく2つの方式があります。
Modelクラスにモデルデータを格納して扱う方式と、
頂点データやインデックスデータを直接扱う方式です。

前者については、マテリアル形状=ModelMeshPartであろうと先日書きましたが、後者については、マテリアル形状=インデックスデータのようですね。

マテリアルが複数存在する場合は、インデックスデータをマテリアル形状毎に分割するA2案が一般的に正しそうです。さらに推測すると、ModelMeshPartは分割したインデックス配列の先頭番号を所持してると思います。



◎テクスチャ差し替え検証

A2案で残る懸念と言えば、「任意ポリゴンのテクスチャ差し替え」です。これについても実際に試してみましょう。

スペースキーを押すと「カラーマップの色情報配列の値を書き換えて地形種別を変更し、インデックスデータの再構築を行う」ように改修しました。

自作地形A2案スペースキー押下前   自作地形A2案スペースキー押下後
スペースキー押下前(左図)と押下後(右図)

…変わりましたね~!1秒弱ぐらいです。
アクションゲームじゃないので、これなら許容範囲内でしょう。A2案に決定!!



◎次回予告

複数のテクスチャシリーズは、今回でめでたく終了です。
次回はテクスチャパターンを作成します。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
3DmodelSNS_cg
3DmodelSNS「cg」
3DCGの製作者が自分の作品を投稿し、他の製作者や一般の閲覧者が投稿作品を見て楽しむためのサイト。



◎予定変更

先日、Karu_gamoさんのブログに「今月の目標」が掲げられているのを見て、私も見習うことにしました。こういうことは、即断実行すべきと思いますので、今回の記事は予定を変更して記載します。

今月の目標は「最終目標を達成するために、今月はここまで達成したい」という観点で設定することが望ましいでしょう。私は年間目標を年度単位で掲げているので、まずそちらから説明します。



◎2008年度 年間目標

私は2008年6月からゲーム制作活動を開始し、下記の年間目標を掲げました。

2008年度 年間目標(PDF)

私はゲーム会社設立を目指しているので、経営目標や営業目標を中心とした目標設定をしています。

この中で最も重視したのは「どのようにして黒字を目指すか?」という点です。「黒字の目途が立てば、会社の体裁はどうにでもなる。しかし黒字にできなければ会社は存続しない」と考えているからです。様々な可能性を探った上で、ベストな経営戦略方針を見出すことが目標です。


また、当時は「初めは2Dゲームから製作し、数年後に頃合いを見計らって3D化する」という構想で、ゲーム企画案も全て2Dでした。

私はかつて同人ゲームの製作販売を行った経験があるので、2Dであれば年内に1本完成させる自信がありました。ゲームを完成販売すれば売上も発生するので、宣伝販売方法の確立を営業目標に掲げました。さらに売上の様子を見て、早ければ2009年に会社設立することも視野に入れていました。

ちなみに、会社設立の主目的は、収支を明確にして税処理を行うことです。一定額以上の収入があれば、例え赤字でも税処理は発生するので、わりと早い時期を想定していました。まぁ、ゲーム会社というか、いわゆる自営業ですね(笑)



◎3Dテストプログラム

6月の構想は、その後2つの要因によって大きく変更することになりました。「3Dテストプログラム」と「金融危機」です。

3Dテストプログラムは、元々「将来3D化を目指すのだから、とりあえず感触だけでも掴んでおきたい」という動機で、モデルを幾つか表示し移動するだけの簡素なものを作るつもりでした。

しかしモーションを付け始めたことを契機に、当初考えもしなかったものを作り上げ、これによって「最初から3D化を目指す」という選択肢が増えました。

2Dのイラスト画像は使い回しできませんが、3Dモデルは使い回しが可能です。3Dの方がコストはかかるものの、ゲームをシリーズ化して使い回すことを考慮すれば、費用対効果は高いのではないか?であれば、最初から3D化を目指した方が良いだろう…というわけで、3Dに方針変更しました。



◎金融危機

昨年9月のリーマンショックに端を発した世界金融危機は、
「どのようにして黒字を目指すか?」の選択肢を一気に減らす要因になりました。

以前は「企業サイト向けのコンテンツとして企業に売り込む」とか「フリーのネットゲーサイトを構築してスポンサーの広告収入を狙う」とか「安価なコストで手頃なゲームを量産する」等の選択肢も考えられましたが、金融危機により「企業やスポンサーはあてにできない」「中途半端なものは通用しない」という時代に突入し、結局「マニアックで品質の高いゲームをシリーズ化して固定ファンを獲得する」という方針に決定しました。


また、金融危機の時代では、購入前から「絶対に面白いゲームに違いない」と確信できるものしか売れません。今回のゲームは「実際にプレイしないと面白いかつまらないか判らない」類のものなので、第一弾はフリーウェアとして配布し、売上回収は第二弾以降としました。

3D化方針や売上回収計画の変更に伴い、年間目標も変更しました。
2008年度 年間目標(12月忠誠版)(PDF)



◎技術力の問題

売上回収時期が2010年12月以降となったため、今年度の営業目標は撤廃し、当分開発に専念することにしました。

しかし開発を進めようとすると、すぐに技術的な壁にぶつかり、進捗が滞ってしまいます。これは、私の技術力があまりにも低すぎるために生じる問題です。

3Dテストプログラムの時は「3Dプログラミングの感触を掴む」という目的でした。これが終われば2Dに戻るつもりだったので、進捗を優先し、技術的によくわからない部分はなるべく避けてきました。
お陰で自分でも驚くほど短期間で完成しましたが、技術力は見掛けほどは上がっていませんでした。

要するに、進捗を優先し基礎技術習得を疎かにしたため、次の開発の進捗が伸び悩んでいる、というわけです。己の技術力の無さを痛感した私は、進捗よりも基礎技術の習得を優先するよう開発方針を変更しました。



◎3月の目標

ここ数カ月は基礎技術の習得を優先してきたので、以前よりも技術力が向上した手応えはあります。その反面、進捗は非常にお粗末で、地形モデルが未だに完成していません。

まだまだ基礎勉強が足りないことは実感しているので、もうしばらく技術力向上を優先するつもりですが、そうかと言って進捗を完全に無視したら「いつ完成するんだ?」ってことになります。

まだKaru_gamoさんのように詳細目標を立てられる段階ではありませんが、せめて月単位で大項目の1つ2つぐらいは立てるべきでしょう。

というわけで、3月の目標です。
・地形モデルを完成させる
・CG担当者を獲得する
・CGの発注条件を詳細化する


4月になったら、2009年度年間目標と年間スケジュールを作成し、年間スケジュールに基づいて月間目標を立てるようにします。



◎CG担当者について

2月からCG担当者を探しているのですが、ネット上の自作3Dモデルは「建築物」「メカもの」「女の子」が9割という状況で、武将モデルを作成してくれそうな人がなかなか見付かりません。オリジナル武将イラストとかは結構見掛けるんですけどね。

cgpixivなどで探していますが、cgはまだ出来たばかりなので作品登録数が少なく、pixivはイラスト中心のため3DCGは不向きなようです。
他に良い場所を知ってる方は、是非教えて下さいね~!



◎次回予告

次回は、前回の続きから再開します。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
複数のテクスチャを貼り付けた自作地形
試行中の自作地形
強引な手法により複数テクスチャを実現。任意ポリゴンのテクスチャ差し替えが容易にできるという特長がある。



◎VertexElementUsage.Sampleの用途

複数のテクスチャを扱うために、頂点データフォーマットを拡張して、頂点データにテクスチャ番号を追加しました。しかしVertexElementUsageにSampleを指定した状態で実行すると、頂点定義データを作成する所で落ちました。


原因を調べると、そもそもVertexElementUsage.Sampleは、テセレーション(曲面を三角形に分割する処理)を行うために、VertexElementMethodやUsageIndexと組み合わせて使用すべきもののようでした。
マニュアルには「UsageIndex = 0 の Sample」の記述しかありませんが、「UsageIndex = 1」としても、同様に落ちました。
要するに、VertexElementUsage.Sampleは、テクスチャ番号の格納用には不適だったのです。


私は、VertexElementUsageは"対人向けの注釈コメント"程度に考えていたのですが、プログラムの動作にも影響するのですね。

VertexElementUsage.Sampleの前例が見当たらない理由もわかりました。自力でテセレーションまで踏み込まない限り、使用しないってことですね。



◎B案断念

VertexElementUsageには、他にテクスチャ番号を追加するようなメンバーが見当たりません。つまり「そんな使用方法は一般的に想定されていない」ってことです。ガーン!
…残念ですが、この段階でB案は諦めることにしました。


VertexElementUsageには、他に"動作に影響しない"メンバー(Depthなど)もあるので、そちらにテクスチャ番号を追加すればまだ可能かもしれません。

でも、独自路線を突っ走るということは、後で様々な問題に直面する、ということです。それを乗り越えるだけのメリットがB案に感じられない以上、固執すべきではありません。



◎でも試してみた

B案は止めると決めましたが、後学のために、B案方式の表示が可能か否か試すことにしました。
…う~ん、やはり一筋縄ではいかないようですね。

一番の問題は、ピクセルシェーダの入力セマンティクスにCOLORとTEXCOORDしか存在しない点です。
ピクセルシェーダ入力用構造体には、頂点シェーダ出力用構造体を流用できますが、その場合、COLORとTEXCOORD以外の宣言は無視され、ピクセルシェーダ内部で使うことはできないようです。

これでは、頂点シェーダからピクセルシェーダにテクスチャ番号を受け渡すことができません。そこで、Color.a(透明度)にテクスチャ番号を無理矢理突っ込むことにしました。

Color.aはfloat型で0~1の範囲なので、テクスチャ番号もそれに合わせましたが、どこかで誤差が生じるらしく(?)、=(イコール)判定では引っかからないので、<(大小比較)判定としました。

それから、ピクセルシェーダのバージョン1.1では、別のサンプラに同一のテクスチャ座標を渡すとエラーになるので、ピクセルシェーダのバージョンを2.0に上げました。

というわけで、何とか冒頭図の状態になりました。

今回のHTML
(問題ありまくりなので、良い子のみんなはマネしないでね!w)



◎テクスチャ差し替え

ここまできたら、是非試したいことがあります。

「頂点データ内のテクスチャ番号を変更すると、見た目に反映されるのか?」

というわけで、Update()にコードを追加し、プログラム実行中にスペースキーを押してみました。

スペースキー押下前   スペースキー押下後
スペースキー押下前(左図)と押下後(右図)

おお!テクスチャが瞬時に差し替えられました!スゲ~!
他のやり方じゃ、任意ポリゴンのテクスチャを、こんな簡単に差し替えられないですよね?!

地形モデルが1つに統合されて、CPU使用率は約70%。性能も機能も目標通りです。このまま捨てるのは惜しい気がしてきました…。



◎次回予告

決心が揺らいでしまったので、
このまま継続すべきか?
別の方式で作り直すべきか?
もう一度考え直します。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |

copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。