画像をクリックすると当該マニュアルのページに移動します

サンプルはdaeと実機用のfmdl、Sofitmageでの設定画面スクリーンショットが同梱されています。背景制作の際は参考にしてください。

画像をクリックすると当該のマニュアルページに移動します

グリッドにアルファつきのテクスチャを貼っただけの最もシンプルなデータなので内容の確認も容易になるかと思います。髪の毛など半透明のオブジェクトを作る際の参考にしてください。サンプルはdaeと実機用のfmdl、Sofitmageでの設定画面スクリーンショットが同梱されています。

[A]
これは答えるのがとても難しい質問の一つです。なぜかというと「2D格闘」と言った時に頭の中にあるイメージに非常に幅があるからです。

最もラフなイメージであれば「奥手前への移動が出来なければOK」ですし、最も厳密なイメージだと「めくりやリバーサルやヒットストップやその他主要な2Dのゲームシステム全装備でステージは完全1軸で壁があり、2P側のキャラは左右反転できてキャラはＵＩより上に描画しないとダメ、キャラと背景に画角がつくのもダメ」である場合もあると思います。

結論から言うとEF-12は2.5Dを念頭には設計していません。3D格闘と2.5D格闘は似て非なるもので両方とも完全なものをメイク可能な仕組みというのは非常に難しいのです。

これを踏まえて以下が可能/不可能リストです（追加質問があれば追記していきます）

・軸移動がない、という基本操作を作ることは可能
・キャラをUIより手前に描画するのは不可能
・背景を絵にするのは不可能
・全ての行動（ダメージ及び攻撃モーション）を2Dの軸線上に固定するのは可能
・ステージに壁を作る（≒リングアウト出来ない仕組みにする）のはウィッシュリストに入っている
・ヒットストップの設定は可能
・アシストキャラは一時的な登場なら可能、常に出し続けることは不可能
・カットイン演出は可能
・1P2Pでキャラを反転するのは不可能
・トゥーンシェーダーは可能
・背景の動くギミックなどはウィッシュリストに入っている
・人型でないキャラを作成することは可能
・敵が背後に回った時自動で振り向かせるのは可能
・カメラを平行投影にしてパースのない絵にするのは不可能

上記をもとにイメージする2D(2.5D)格闘に近いものが製作出来るかどうかをご判断ください。

[Q]
Can I make 2D(2.5D)Fighting system？

[A]
Someone might say “Well, okay, just remove side step,” But other peeps may require all kinds of popular game systems be in place: reverse pose for right side of screen,zero Angle view, draw character in front of UI and more… It’s impossible to say “This is 2.5D”

As a result, EF-12 is built as a pure 3D fighting game engine. As a result, it’s not appropriate for a 2.5D system. However, if you’re okay with the specifications listed below, feel free to use EF-12 as a 2.5D engine.

Fit or not list

Remove side step:possible
Draw characters in front of UI:impossible
2D arena:impossible
Pin all move on only XY plane:possible but hard
Stage limitation:On our To-do list
hit stop efect: possible
Assist character:Possible for momentary appearance, but sustained and controllable assist characters are not supported.
Cut in effect possible
reverse draw when character stand 2P side:impossible
cell shading:possible
Animation object in stage:On our To-do list
Animal or unusually shaped non-human characters: Possible
Auto-turn when opponent move behind character:possible
zero angle camera view:impossible

Check the list and see if this meets your 2.5D fighting game needs.

Aeroが利用できる環境のユーザー様でパフォーマンスが悪い場合はAeroオフをお試しください。

※バージョン1.6x以降は自動判別してAeroを一時オフにする機能が搭載されました。

ただし、それが社会的に許されないものである場合はしかるべきところからさまざまな形でのストップがかかることでしょうし、それについてはEF-12では一切の責任を持ちません。社会的ボーダーラインに近い作品を作るときは製作者自身が責任を持つ覚悟をしてください。

このグラフから以下のことがわかります。
・ポリゴン数に比例して時間がかかる
・ウエイトを適用しているデフォーマ数に比例して時間がかかる
→ポリゴン数×デフォーマ数でさらに時間がかかる（正比例でない）
・シェーダー（テクスチャ）はほとんど関係ない

骨の数は指や顔を除くと削減の余地があまりありません。そうなると必然的に
・ポリゴン数を減らす
・ポリゴン数を減らしたことがわからないテクスチャの使い方をする
この2点が重要であるという結論が導きだされます。

②ゲーム中のパフォーマンスを多少犠牲にして高速化する方法
①の高速化方法は作業にそれなりの時間がかかります。またそもそも2万オーバーのポリゴン数であった場合、効果はどうしても薄くなります。手早く成果が得られるのが②の方法です。

以下は「ほぼ同じポリゴン数で構造の異なる状態でのコンバート時間比較」です。

daeからfmdlにコンバートする際は「オブジェクト内の各頂点を総当たりでチェック」していきます。ゆえに1オブジェクト内のポリゴン数が多いほどネズミ算式にコンバート時間がかかります。
逆に言えば「1オブジェクトあたりのポリゴン数が少なければコンバート時間は著しく短縮」されます。モデルを分割しましょう。ゲームパフォーマンス的にはマテリアル数が増えるのでCPU負荷が増大しますが、そもそも格闘ゲームは画面内のオブジェクト数がそれほど多くないこと、EF-12はCPUよりもGPUの負荷が高いことを考えると、多少パフォーマンスを犠牲にしてもコンバート時間が半分以下になる方法を選択するのは一考の価値があります。

この図のように、デフォーマ数が均等になるように、かつ切り分けやすい部分でオブジェクトを分割するといいでしょう。

（なおキャラ1体のfpsで比較も出来ますが、FPSの測定基準がバラバラだと互いの情報交換の際に困るので上記方法を推奨しています）

概念としては「Rで光らせたものをGのマスクでコントロール」するような使い方になります。したがって光り具合のコントロールにはGが強く影響します。

↓画像をクリックするとフルサイズの画像を確認できます

1.
ウエイトが5つ以上のデフォーマに割り当てられている・・・1“ポリゴン（頂点ではありません）”に割り当てできる最大ウエイト（インフルエンス）数は4です※最大割り当てウエイト制限が“頂点あたり”でなく“ポリゴンあたり”になっている点がよく間違えられるのでご注意ください

2.
意図しないデフォーマにウエイトが割り当てられている・・・たとえば右足の頂点を左足のデフォーマにも割り当てたりすると頂点が引っ張られ、結果裏返って見えなくなる場合があります。

【重要】原因が1の場合はコンバータ側で意図して当該ポリゴンを消しています。なぜかというと「微妙な誤差で少しだけポリゴンの境目が割れていると気が付かない」からです。少しでもウエイトに不正があった場合は視認できるようにポリゴン自体を非表示としています。CGツールでは「表示上の値」と「実際に内部で保持している値」が違うということが頻繁に起こるのでご注意ください。例えばMAYAやSoftimageでは表示桁数を増やすようなオプションがありますのでそれらの機能も利用してデータのチェックをしてください。

またコンバータは5つ目以上のウエイトを自動的に小さい値から切っていき、4つに収めるように動作しています。上記の誤差との両方の理由で「合計値が100にならず、足りない分がおかしなウエイトになる」という症状もよく発生します。その場合は手動できっちり100になるように数値を入れなおしてください。

まずはテクスチャをモデルと一緒にビューアにいれたかどうかをご確認ください。