Bakinのモデル出力について調査してみる
こんにちは。友だちから貰ったゲームで土いじりを楽しんでるうどんこです。
RPG Developer Bakinのモデル出力の仕様について、気になるところがあったので色々と調べてみることにしてみました。
といっても、私は3D超初心者なので分からないことだらけでしょうが…
でも調べようとしてもそれっぽいのを見つけられないので書いてみます。
個人的な備忘録ぐらいの感覚で見てくれたら助かります。
（用語を覚え間違えてたりしてたらごめんなさい。恥ずかしいね）
現在、2024年5月16日～5月18日。
Bakinのバージョンは「1.9.0.2」です。
出力後のモデルはBlender4.1にて作業してます。
マップのモデル出力をしようとすると、こんなエラーが出ることがあります。
下記手順で表示を正しい状態に戻すことが可能です。
・このマップで使用している地形の種類を減らしてプロジェクトを開き直す
・マップ設定→テクスチャ設定→解像度の数値を小さくして「テクスチャ設定とマップのサイズ変更を適用」ボタンを押す
つまり、描き出せる地形の種類に上限があるってこと！？
ということで限界を探りたくなりました。
稚拙な調査、検証、ご容赦くださいまし
出力可能な地形の最大数を探りたい
ところで、先ほどのエラーメッセージには、
”地形の数が最大を超えている”問題に対し、地形の種類を減らす他
「解像度を小さくする」解決策を提案していましたね。
ってことはよぉ？解像度を小さくして何とかなるならテクスチャのサイズに上限があるってことなんじゃない！？
理想の解像度は16×16なので、それを中心に見てみたいと思います。
色んな地面並べたいからね。
1.出力先のモデルに含まれるテクスチャの調査（側面）
Bakinの地形は、こんな形で構成されてます。
引用元
上のテクスチャでは、「TOP」「1」「2～9」の3つのコマが
用意されていますね。
1ブロック分の段差しかない地形は、マップでは上画像での
「TOP」「1」のコマしか存在しないので、
「2～9」に当たる2段目のコマは使われていないはずです！！
この状態で出力してみると…
2コマ分のテクスチャしかないので、
使われているコマのみがテクスチャに含まれるようですね！
出力エラーは「マップを平らにすると改善される可能性があります。」
っていう線もあることを頭の片隅に入れておこうカナ…
マップ内に使われていないコマは、モデル出力先のテクスチャに含まれない。2.出力先のモデルに含まれるテクスチャの調査（同じ絵、別地形）
同じ絵を別地形としてBakin上にインポートした場合、
それを使ったマップを出力したら、テクスチャはまとめられているのか！？
これは自作の２つの地形スタンプですが
平面は違う絵
側面は全く同じ絵を使っています。
これで側面用の絵を纏めてくれたら結構テクスチャサイズ浮きそうだけど
いけるかなぁ～？
（まとめてくれたら3コマで済むはず）
4コマ分のテクスチャ…
つまり別地形の同じ絵を自動でまとめてくれるわけではないみたいです。
地形の種類分、シンプルに使える絵の数が減っちゃいましたね。残念。
別地形スタンプで同じ画像を使用していても、モデル出力先のテクスチャでは別コマとして扱われる。3.出力先のモデルに含まれるテクスチャ（階段）
地形スタンプの設定では、階段用のテクスチャを設定することができます。
この草原の地形では、天面が土になっている
階段用テクスチャを別途用意してます。
階段用のテクスチャは天面、前面、側面の3コマが必要です。
ここの階段用テクスチャを用意していなかった場合は
無理やり階段にするみたいです。
このときは、Bakin側としても階段テクスチャを用意していないから
出力するときも階段は同じコマを参照しているのでは！？
って言われてもよくわかんないですよね。
テクスチャが紐づいている面を確認してみると
このテクスチャは下のようになってました。
↖：草原の天面 ↑：草原の側面 ↗：草原階段の天面
←：草原階段の前面 □：草原階段の側面 →：道端の天面
↙：道端階段の前面 ↓：道端階段の側面
（※ここではモデル左側を”草原”、右側を”道端”と記載します）
”草原”のテクスチャは、
「1.出力先のモデルに含まれるテクスチャの調査（側面）」より、
今回は１ブロック分の段差しかないので、
天面、側面の2コマが含まれていますね。
（Bakin側には天面、側面2コマの”計3コマ”が設定されています。）
”草原階段”のテクスチャは、先ほどBakinWikiから拝借した画像のように
天面、前面、側面の3コマ分が含まれています。
これは今回用意している階段テクスチャです。
”道端”に対しては今回階段テクスチャを用意していません。
そして”草原”と同じく、
Bakin側には”計3コマ”のテクスチャを設定しています。
”道端”のテクスチャから階段を生成している様子なので、
天面、側面1、側面2、の3コマが、
天面、階段前面、階段側面、として扱われているようです。
そしてこれは出力先でも同じコマを割り当てられています。
結果として”道端”のテクスチャは、
1ブロック分の段差しかないが、2つ目の側面コマが階段側面として扱われ、
天面、側面1（階段前面）、側面2（階段側面）の3コマが含まれています。
合計8コマ！ぴったし！
階段用テクスチャが用意されている地形スタンプでは、階段をマップに含めてモデル出力すると、
階段3コマ分がモデル出力先のテクスチャに含まれる。階段用テクスチャが用意されていない地形スタンプでは、階段をマップに含めてモデル出力すると、
元地形の3コマ分が階段として扱われる。（同じコマを参照する。）4.テクスチャの塗り足し部(?)のサイズ
これって何て呼べばいいんですかね？
正方形のコマの周りに付いてるやつです。
なんか印刷物の断ち切り線の外側みたいやつ。
とりあえず「塗り足し部」って呼ぶことにしてみます。
マップ解像度128だとこんな感じじゃないので、
おそらく共通でこの塗り足し部のサイズが作られているのではないか？
って予想してます。しらべてみよう！
まずはマップ解像度16で出力したテクスチャから…
実際に使われているテクスチャの面に対して、片側32pxずつ。
縦横64px分の塗り足し部があるってことですね！
1コマあたり80×80px使っているようです。
続いて、マップ解像度128のテクスチャをば…
あっ！これやっぱおんなじだ！！
ってことは1コマあたり192×192px使ってるってことか…
(192*192)/(80*80)=5.76
テクスチャサイズに上限があると仮定すれば、
マップ解像度128に対して、
解像度16は5.76倍のコマ数を使えることになりますね…？
（大体5.76倍の地形スタンプの種類を使ってもモデル出力に成功する計算）…途中まで計算間違えててクッソ恥ずかしかった
テクスチャ解像度にかかわらず塗り足し部は縦横64px分追加される。
たとえば、
解像度16の場合のテクスチャサイズは、1コマあたり80×80px使用される。
解像度128の場合のテクスチャサイズは、1コマあたり192×192px使用される。5.出力可能な地形の最大数を試す
さて本題。
ここまでの調査で解かったことをまとめると・・・
マップ上で使われていない側面のコマはテクスチャには含まれない。
別地形の同じ絵でも、別のコマとしてテクスチャに含まれる。
階段用テクスチャが用意されている階段では、3コマ分テクスチャに含まれる。
階段用テクスチャが用意されていない階段では、元の地形3コマ分を参照する。
1コマあたり、解像度16なら80×80px、解像度128なら192×192pxのサイズになる。
ということになる。
まずは今持っている情報とイメージで予測してみよう。
見た感じテクスチャの最大サイズは1024×1024pxの雰囲気があるので、
解像度16の場合、1024÷80=12 …余り64
縦12×横12で144コマ分。
解像度16では、144コマ分のテクスチャを貼れそう。
例えば、側面3コマ分用意した柱を限界まで設置しようとすると、
天面合わせて4コマ消費するから144÷4=36で、
36種類の柱を最後まで立てれる。という仮定になる。
自然物は大体側面2コマ分使っている様子なので、
144÷3=48種類
階段を使わない場合は48種類。
それぞれに用意された階段を使う場合は24種類になりそう。
それじゃあ、実際に試してみよう！！！
…
階段用テクスチャが用意されている側面2コマの地形を使って、
予想通り行けるか見てみたいと思います。
側面2コマ分用意されている標準の地形スタンプが思いのほか
少なかったので、複製して貼ってみることにします。
そしてこの地形スタンプには階段用テクスチャが用意されている！”
これで24地形にそれぞれ階段合わせて実質48地形！
それぞれに3コマのテクスチャが設定されているはずだから
48×3=144コマ！
いけるかな…
だめでした。
ちなみに地形の最大数を超えるとこうなります。
テクスチャの画像サイズは1024×1024だったのですが
なんかダメみたいですね
こんな具合にUV展開図がズレて潰れちゃいます。
つぎは階段消して試してみます
24地形、各3コマで72コマ分使用しています。
あっ、ちなみに一回出力エラーが出たらBakin開き直してから
試したほうが良さそうです。
次に出力したら、エラーメッセージ出ずにテクスチャ乱れちゃいました。
・・・ここから限界を探ってみたところ
・・・探ってみたのだが…
126コマ使用(24×3+18×3)でエラー
でも、再度試したら、いけた。
もしかしてさ…
ねェ、もっかい最初の、やってみる？？
って、できるじゃねぇか！！！！！！
なんだったんだよ今の！！！！
ちなみにテクスチャサイズは1024×1024です。
2048×2048の壁を超えることはできるのか！？
こいつは話が変わってくるぜ！！！！
さぁ…オレを楽しませてみろ…
出力！
6.地形のモデル出力：まとめ
ここまでに調べた内容をまとめてみましょう。
出力先のモデルに含まれるテクスチャ
マップ出力範囲内に含まれているコマ
（ex:段差がない場合、天面のコマのみが含まれる）
別地形スタンプで同じ画像を使用していても、別コマとして扱われる。
階段用テクスチャが用意されている地形スタンプでは、階段を使うと、 階段3コマ分がテクスチャに含まれる。
階段用テクスチャが用意されていない地形スタンプでは、階段を使うと、 元地形の3コマ分が階段として扱われる。（同じコマを参照する。）
モデル出力先のテクスチャサイズ
現状でのテクスチャサイズの限界は1024×1024pxと思われる。
1コマにつき、縦横64pxずつの塗り足し部が追加される。
マップ解像度16の場合、1コマあたり80×80px使う
マップ解像度128の場合、1コマあたり192×192px使う
出力可能な地形の最大数
地形スタンプや、マップの段差によって使用するコマ数が
異なってくるため、あくまでも目安程度。
また、出力できる場合とできない場合があるので、
モデル出力前にBakinを再起動したりして整えてあげると、
きっとあなたにより良い未来が待っているだろう。
マップ解像度16の場合・・・144コマ
（ex:階段なし・側面2コマの地形48種類分）
（ex:階段有り・側面2コマの地形24種類分）
マップ解像度128の場合・・・25コマ
（ex:階段なし・側面2コマの地形8種類分）
（ex:階段あり・側面2コマの地形4種類分）
解像度128だとあまり色んな地形を出力できなさそうですね…
ちなみに、参考程度に
マップ解像度32の場合・・・100コマ
マップ解像度64の場合・・・64コマ
多分これが地形出力の最大量だと思います。
出力エラーを回避したいならなるべく、
地形種類は節約したほうが良いですね。
以上、第一部：地形編 完───。
物体のモデル出力の仕様を探ろう
まずは、物体を含めてモデル出力してみよう！
モデル出力の際に、物体（マップオブジェクト）を含めることができます。
マップオブジェクトを含む
チェックを入れると選択中の地形の上に載っている物体を含んでエクスポートします。
物体については下記の制限があります。
・コリジョンは完全には再現されません。
・モーションは再現されません。
・マテリアルはfbxのデフォルトのものになります。
出力後のFBXには、地形のメッシュと、
マップオブジェクトが分かれて入っていて、
マップオブジェクトは「十字のエンプティ」を親に
メッシュ等が親子関係になっています。
複数のマップオブジェクトを出力した場合は、
それぞれの「エンプティ」「メッシュ等」親子がFBX内に含まれるみたい
上の画像だと正常に出力できていますね。
ですが…
どうやらBakinで設定した位置から、マップオブジェクトがズレて
モデル出力されることがあるらしいです。
これが一番気になるので調べてみたいと思います。
1.どんなマップオブジェクトがなぜ位置ズレを起こすのか
聞いた話によると、家が空に浮いた状態で出力されたとのこと。
試しに家を置いて出力してみます。
1-1.出力後モデルの調査
確かに、窓の部分が家から外れているように見える…。
というよりも家が全体的に前のめりになっている。
あとで気付きましたが、窓のテクスチャが何故か上手く読み込めてなかったです。（テクスチャ自体は出力されているので再度紐づけました。）
シーンの構成はこう。
上から、
「家（メイン）のエンプティ」
→「家のアーマチュア」
→（根本のボーン）
（ドアのボーン）
→「ドアのメッシュ」
→「家全体のメッシュ」
「家（窓）のエンプティ」
→「家（窓）のメッシュ」
「木箱のエンプティ」
→「木箱のメッシュ」
「地形のメッシュ」
となっていました。
木箱の時とまるで違う…
色々と見てみることにします。
余談ですが、出力のとき地形種類エラーをやたらと吐かれたので、
モデル出力範囲外でも地形をたくさん使っているとエラー率が
高まるのかもしれないですね…
さて、この木箱と家は、Bakin上でどんな扱いの差があるのだろうか。
木箱はシンプルな構成なので何も言えそうにない…
それでは次はさっきのおうちを見てみる。
特筆すべきは、サブグラフィックとして窓が設定されていること。
そして、モーションが設定されていることだろうか。
先ほどの出力結果から、モデル出力時には
このサブグラフィックは、メインのオブジェクトに対して、
オブジェクトが分離するようだ。
そしてこのサブグラフィックの相対座標、
Bakin上のYが1.8。Zが-1.49となっている。
これを出力後のモデルのエンプティ同士で測定してみると…
Bakinでのマップ1マスは0.01mとなっているから
サブグラフィックのエンプティ同士の距離は正しく出力されている結果なのが分かる。
（多分小さすぎて0.0149は潰されたのかな？）
もしかして、なんらかの理由で
この距離分おうちが動いちゃったのではないか？
・・・ｺﾚｶﾞﾜｶﾗﾅｲ
オブジェクトの原点も、Bakinと出力後モデルで
それぞれ確認してみよう。
まずはBakin。
多分、ドアを中心にして設置できるようになっているのだ。
次はモデルのほうを見てみよう。
これはドアの原点。
ドアの中心は、親であるエンプティと同じ位置のようですね。
次に家の原点。
なんかすごい位置にある…（上手く測れない）
なんでぇ…
そもそもこの家の親であるエンプティの位置は合っているのか？
まず、Bakinの原点を調べる。
見づらいので、家の表示を消してみる。
左から4マス。下から2マスの位置に原点。
次に、出力モデル。
左から4マス、下から2マス…
エンプティの位置は同じだ！
つまり、このエンプティの位置に、ドアが中心になるように
動いてくれてれば完璧な出力になるってことだな！！！
メインのエンプティ位置と、サブグラフィックのエンプティ位置との距離感は正常に出力される。
エンプティの位置は、正常に出力される。1-2.位置ズレの解決法
・・・モデルを触ってみるとよく分からないことが起きた。
先ほどまでのモデル出力後の画像は、オブジェクトモードでの表示だった。
これを、編集モードへ変更すると…
これ！欲しいやつ！！！どうして！？
もしかしてポーズ的な、なんかそんなやつが影響してる気がしないか？
これは想像なんだけど、編集モードでの表示が正で、
なんらかの設定が作用してオブジェクトモードでの表示が乱れている
…みたいなさァ！？
・・・
・・・。
ということで、色々触ってみたところ
オブジェクトモードで正規の位置へ戻せました。
じゃあ、何をやったのかというと
ボーンの影響による変形なのでは、と考えまして。
こちらのボーンプロパティの☑変形を外すと…
これをrootと、doorの2つのボーンに対して行っただけです！
最初に引用したように、モデル出力ではモーションは再現されない。
ってことは、静止物前提で動かなくなっても大丈夫だよね、ってね。
ちなみに、ボーン選択状態で、ポーズモードに移り、
上部のポーズメニューから、トランスフォームをクリアでも治せました！
こっちのほうだと、ボーンプロパティの☑変形はそのままで、
表示が直ります。
多分だけどこのやり方のほうが確実な気がしますね。多分だけど。
メッシュがエンプティ位置とズレている場合、以下のいずれかの方法で修正できる。
1.ボーンプロパティ内の変形を無効にする。
2.ボーンをポーズモードで編集し、トランスフォームをクリアする。1-3.結局なにが悪かったの？
もう大体察しがつきそうですが、
今回の位置ズレの原因はボーンによる謎のトランスフォームでしょう。
（原因の根本までは流石にわからなかったです…有識者ｷﾎﾞﾝﾇ）
つまり、どんなマップオブジェクトがズレるのか…
それはボーンによるモーション設定がされているマップオブジェクト、
なのではないかと考えられます。
ということで、アセットから色々見てみましょう。
エントリーNo.1 レンガの家-A
見どころ：
サブグラフィックあり。
モーション設定あり。
さっきまで調査対象だったやつ。今もだけど。
エントリーNo.2 窓05
見どころ：
サブグラフィックあり。
モーション設定なし。
モーションがどこにも設定されていないはずなので、
正常に出力されてくれそう！
エントリーNo.3 噴水
見どころ：
サブグラフィックあり。（パーティクル！）
モーション設定なし。
この画面を開くと噴水が爆音で流れて困る。
サブグラフィック原点はきっと0.007mズレているはずです。
パーティクルが付いているとどうなるのだろうか！？
エントリーNo.4 荷馬車
見どころ：
サブグラフィックなし。
モーションあり。（車輪がころころ回ってる！）
本当にボーンが入っているだけで位置ずれが起こるのか気になるところ。
エントリーNo.5 レンガの家03
見どころ：
サブグラフィックあり。（座標オフセット値0）
モーション設定なし。（サブグラフィックには付いてる）
果たして同じ家でもモーションの有無でズレないのか！？
サブグラフィックに付いていたらもうズレちゃうのか！？
1-4.検証開始
以上、５体のオブジェクトで検証してみたいと思います。
出力！
あぁ…こりゃ大惨事だ…
なんか窓の類はテクスチャはがれやすいの何だろうね。
まずはエントリーNo.1の家から見ていきます。
前回出力したズレ方とはまた違うズレ方をしていますね。
窓のサブグラフィックも、同じようにテクスチャが剥がれちゃってます。
お次は、エントリーNo.2の窓くん。
この窓は、サブグラフィックあり。モーション設定なしでしたね。
サブグラフィックとの距離感も良さげでした。
次、エントリーNo.3噴水くん。
サブグラフィックあり。（パーティクル）モーション設定なし。
テクスチャやば！！！なんで？
モデルの位置自体は正常でした。
多分水面のマテリアルがどっかに行っちゃってるのかなぁ
ちょっと、これは…わかんないです。
パーティクルのサブグラフィックはどこにも見当たらなかったです。
次、エントリーNo.4の荷馬車！
サブグラフィックなし。モーションあり。
やはり、モーション付きのものは位置がずれる運命なのか…
ってか回転方向でも狂ってるね！？
とりあえずボーンの変形を切ってみます。
これで元通り──。
ちなみに、ボーンひとつひとつのトランスフォームをクリアしていくと
ボーンの位置が変わります。
そうこうしていると、「いや、もうアニメーションできないんだったら
ボーン消したほうがよくね？」ってなりました。
しかし、ボーンが親になっているので、
出力後、そのままボーンを消すとメッシュも一緒に消えてしまいます。
試しに、出力後そのまま親子関係を切ってみました。
クソデカくなります。
なので、ボーンの変形を切った後、親子関係を
トランスフォームを維持してクリアしましょう。
次で最後！エントリーNo.5 でっかいハウス！
サブグラフィックあり。モーション設定なし。
（サブグラフィックのドアにはモーション設定あり。）
おおむね良好ですね。
唯一、モーションが付いているドアのみズレちゃってます。
（家の内側にいます。ひきこもりめ。）
1-5.まとめ
マップオブジェクトの位置ズレについて
マップオブジェクトを含めたモデル出力における
マップオブジェクトのズレは、
モーションが含まれているマップオブジェクトに起こる。
位置ズレは、モデル出力後の以下のいずれかの方法で解消できる。
ボーンプロパティ内の変形を無効にする。
ボーンをポーズモードで編集し、トランスフォームをクリアする。
ボーンごと消す場合は、位置ズレを解消したのちに、
親子関係をトランスフォームを維持してクリアしてから
ボーンを削除しましょう。
マップオブジェクトの出力についてのあれこれ
サブグラフィックは、別のオブジェクトとして出力される。
サブグラフィックと、メインのグラフィックの距離感は正常に出力される。
パーティクルのサブグラフィックは出力されない。
未解決問題
テクスチャの参照が上手くいかない物体がある。
2.イベント化したマップオブジェクトは出力されるのか
Bakinでは、物体（マップオブジェクト）にイベントに変換することが
できるが、これもモデル出力できるのだろうか。
右下の木箱を喋る木箱にした。
これでこの木箱は「イベント」というものになっているらしい。
これで出力すると…！
いけました！！！！
結論：イベント化したマップオブジェクトもモデル出力できる
3.まとめ
ほとんど「1-5.まとめ」に書いちゃったのでご参照ください
…段取り下手くそかな。
以上、RPG Developer Bakinのモデル出力の仕様について色々調べてみました
全然小さい範囲をマップ出力しようとしてもエラーを吐くことがあるので
まずはパソコンと仲良くするところから、
みなさんも初めてみてはいかがでしょうか！
冗長な記事でしたが、閲覧ありがとうございました！！
あと「実際は違うんじゃない？」ってことがあればぜひコメントください
システム上返信はできないと思いますが！
この記事が気に入ったらサポートをしてみませんか？