BVEのメモリ不足を実験検証してみた
みなさん、BVE遊んでますか。
楽しいですよね。
でもちょくちょくメモリ不足とか言って遊べないことありますよね。
楽しくないですよね。
メモリのエラーとBVE5のメモリ使用制限
古くからBVE界隈で活躍されていらっしゃいますNT/fiv様より、重いデータはメモリを食うぜという話題の記事が出されました。確かにグラボ性能が向上しfpsは金である程度解決できるようになった昨今(そうでもない)、
ツヨツヨPCを組んでいるはずなのにロード画面でクラッシュしてしまうという事案をたまによく見る気がします。これはユーザーが遊ぶだけでなく、作者としてF5連打しているときにも顔馴染みのエラーです。
BVEは、シナリオ読み込み時に「すべてのデータを（BVEの）メモリ上に読み込みます」
ロード中にシナリオデータが読み込みしきれず、メモリを食いつぶしてもなおデータが溢れるためにエラーを吐いたりBVEが落ちたりするんですね。なるほど。
リンク先の表にある通り、現行のBVE6では使用するメモリに制限はありません。メモリエラーの症状はBVE6で起動すればわりと解決します。ですが、各種コミュニティでの不具合報告を様子見するとユーザーの多くは、
メモリ制限のある旧来のBVE5を使用していることが見て取れます。
なんでみんなBVE6を使わないのか？
車両データに付属している(ATS)プラグインの64bit版を別途用意しないといけないため、作者間で強い連携が取れていない場合プラグインを調達できず、BVE5専用でリリースされている(過去に公開したままアップデートされていない)データが大量にあります。たくさんある車両たち、遊びたくても無加工でBVE6ではプレイできない……だからいっそBVE6対応データもろとも、BVE5のままアップグレードしない選択をしたのかなと感じます。
車両を設定しないとシナリオ画面に出てこないのでBVE5.7から更新しないんだという意見を見たこともありますが、それはさすがに更新してほしい。
さて、先日BVE5.8だと起動しない(=メモリ不足になる)路線データがあるとXで話題になりました。話を脇目で見つつ当方でも検証したところ一部のストラクチャがメモリを食いまくっていることが分かりました。そこで、
メモリを食うとは？～ストラクチャを例に比較検証～
をしてきたので、発表会とします。
虚無の路線データとストラクチャで実験
BveTs Map 2.02:shift_jis
Structure.Load('structures.csv');
Station.Load('station.csv');
0;
Station['sta1'].Put(-1,-5,5);こんな感じの虚無の路線データを制作し、プレイ中ではなくシナリオロード時の重さ(メモリ使用量)を比較しようと考えました。
こないだ話題になった路線データでは、ハイポリ車両ストラクチャがメモリを食いつぶす原因でした。
シナリオロード時の重さはストラクチャに相関があるのではと仮説を立て、いくつかの条件で比較することにしました。
ストラクチャの頂点数(≒面数)
テクスチャの解像度
テクスチャの枚数
テクスチャの保存形式
この4点を混ぜながら比較してみたいと思います。
なおこの検証ではユーザーが多くいるということから不本意ながら、
原則BVE5.8.7554.391にて起動します。車両データは内房線で指定されているE217系、裏にBVE以外のソフトも起動しているためあくまで参考値として考えてください。
メモリ使用量は原則、シナリオ読み込み直後のBVE Memory Monitorの値を取っています。以下、～～MBと書いてある値は、この時のメモリ使用量のことを指します。
ストラクチャとテクスチャの影響比較
★頂点数
まずストラクチャが重たい原因としてすぐ思いつくものと言えば、頂点数でしょう。
・先ほどの4頂点205系(めっちゃ軽いストラクチャ)
・それを20枚重ねた80頂点205系(ちょっと軽いストラクチャ)
・ぼくのPCから拾ってきた65050頂点205系(激しく重いストラクチャ)
の三種類を読み込んで比較します。
テクスチャの枚数は1枚だけで、解像度は256px × 256pxです(後述)。
1つだけ読み込んでも変化が分かりづらいので、以下の表では
・1つだけストラクチャを読み込んだもの
・101つ同じストラクチャを読み込んだもの
を掲載します。
さすがに頂点数が重いとメモリ量も増えますが、激しく重たいストラクチャを大量に読み込んだところでメモリが食いつくされるほどの負荷ではないことがわかります。ということは路線データがロード時落ちるとき、
頂点数ではなくテクスチャの方が怪しい気がしてきました。
★解像度
使用テクスチャ1枚、解像度変更で検証してみましょう。
解像度はそれぞれ
・256px × 256px png形式(55KB)
・512px × 512px png形式(171KB)
・1024px × 1024px png形式(434KB)
・2048px × 2048px png形式(1128KB)
です。2048x2048は路線に配置するストラクチャとしてはあまり見ない、
超高画質テクスチャでしょう。
解像度が高くなるほど単調増加でメモリが食われまくることが分かりました。元々頂点数が多いストラクチャに高画質のテクスチャを貼ることで、ついにメモリ不足のエラーとご対面です。このことから、
平均的にテクスチャの解像度(テクスチャデータの重さ)は
軽くした方がよさそうという推測が立ちます。
★テクスチャ枚数
検証すべきは解像度だけではありません。
1つのストラクチャに使用するテクスチャの枚数も考慮すべきです。先日のメモリ不足が話題になった路線のストラクチャでは、1モデルで40枚以上テクスチャを使用していることが影響しているのではと考察していました。
80頂点のモデルで、
・使用テクスチャ1枚
・使用テクスチャ20枚
とテクスチャ枚数を変更した検証を、それぞれの解像度で試してみました。
明らかにテクスチャ枚数の増加でメモリが食われまくっていることが分かります。
ここで注目すべきは、「256pxを20枚よりも1024pxを1枚のほうが軽い」という部分です。テクスチャを1枚にまとめる作業(UV展開など)が有効打になりうることが推測できます。
★保存形式(dds化)
巷ではよく「ddsで保存するとメモリ食わない」と言われています。これも検証しましょう。
ddsには様々な圧縮形式があります。例えば、
・DXT1 RGB 4 bpp | no alpha
一番軽い圧縮。透明部分は塗りつぶされる。jpgのように画像が荒れる。
・DXT5 ARGB 8 bpp | interpolated alpha
そこそこ軽い圧縮。透明部分は保持される。jpgのように画像が荒れる。
・8.8.8.8 ARGB 32 bpp | unsigned
がっつり重い圧縮。透明部分含めpngのように画像が荒れない。綺麗。
このあたりを選べばまず間違いないと思います。ぼくもいつもここら辺しか使ってません。
(参考にしたサイト)
ここで重要なことは、
必ずしもデータサイズがpngより軽くなるわけでもない
ということです。サイズは軽くなる時もあれば、重くなる時もある。そんなもんです。これを見てdds化を諦めちゃう作者さんも見たことあります。
でも諦めないで！dds化の何が軽いのか、
BVEでデータを読み込むときに、メモリ負荷が下がるのです。
先ほどエラーが出てしまった2つの環境をdds化しました。メモリ使用量を下げる効果があることがわかるかと思います。つまり、高画質のテクスチャは諦めたくない時には有効打になりそうです。
★重いものが混ざって読み込む
先日問題になった路線データでは、一部ストラクチャを置換するとメモリ不足が解消されました。通常プレイできる路線データなのに、読み込むストラクチャ次第でヘビーになってしまうことも検証しましょう。
高画質テクスチャを使用したストラクチャを少しずつ混ぜた結果、やはりメモリ不足でエラーが出ました。少しくらいなら耐えますが、大量に読み込むことは得策ではなさそうです。
検証まとめ
頂点数は盛ってもメモリ負荷は意外と耐える
テクスチャは解像度低くしたほうが良い
1モデルのテクスチャ枚数は少ないほうが良い
dds化すると高解像度でも耐えやすい
それでもテクスチャが重たいストラクチャはせめて控えめ量で
くりかえしますが今回はBVE5.8.7554.391にて検証を行いました。先述の通り、BVE6ではメモリ制限が撤廃されたため理論上はこのことを考慮する必要はありません。しかし、ロード時間があまりに長くなりますし、今回エラーが出た条件で試しにBVE6にてメモリ使用量をチェックしたところ10GBを超える組み合わせもあったことから、軽量化した方が気持ちよくプレイはできる気がします。
今回はあくまでシナリオロード時の重さを比較しました。こんなに読み込んだストラクチャたちも結局線路には配置してません。ストラクチャを配置してプレイするときの負荷(=fpsへの影響)はまた別問題になります。
メモリエラーを出さないためにできること
ここから記述することはあくまで
「メモリエラーが出てプレイ画面にたどり着かない現象を阻止」するために有効そうなことの列挙です。快適なプレイ環境のご案内とはちょっと意味が違います。
★路線作者
軽いストラクチャ→軽いテクスチャを目指すことが近道でしょう。
テクスチャについてはいくつか工夫できる兆しが見えます。
1.解像度を落とす
最もシンプルなやり方です。運転して1秒も目に留まらないような部分、本当に高画質である必要があるのか？小さい部品も解像度上げなきゃいけないのか？考える余地はありそうです。
2.dds化する
これまたやりやすい手法です。dds化の保存形式については上記のページで多少紹介されていますので、やったことない人はぜひ挑戦してみてください。
3.ストラクチャ読み込み数を減らす
重複しているパーツがある、そもそも使用してないストラクチャがある。そんなときはバシバシ消してやれば、メモリエラーの可能性から遠ざかります。
4.テクスチャ枚数を減らす
最悪の場合ストラクチャ作り直しになります。ですが、一枚のテクスチャでギュっと完結できるのであれば、何枚も使うよりも経済的になるでしょう。頂点数削減よりもテクスチャ数削減のほうが効果的そうなのは検証で見えてきたことです。ただ作風とか趣味嗜好の話に触れそうなので、たまに意識するくらいでいい気がします。
なお、BVEではすべてのデータを最初にメモリに読み込むという話題があります。つまり、今回はテクスチャを題材にしましたが、その他の要因でメモリ不足になる可能性も当然あります。例えば
Sounds.txtやSounds3D.txtで読み込むwavデータがメモリを食いそうです。
実体験としては、対向車両の音声を車種ごとに全部変えてやろうとSounds3Dにwavを入れまくった結果、だれも開けないデータが完成したことがあります。バッファー数も関係する話題ですが。
急にメモリを食うのはなぜ？と感じたとき、立ち止まって一つ一つ検証するとリリース後に問い合わせが減るかもしれません。
★車両作者
車両データのパネルの話題です。
メモリエラーの文面見たら車両の場所で結構エラー吐いてたり、無理やり続行したらパネル崩壊したりするじゃないですか。ここもテクスチャの話題の応用。パネルデータの解像度をそこそこに抑えれば、改善の余地は見えてきそうです。
ですが家庭用PCでも4Kモニタの時代が到来、路線データ以上にじっくり見られる車両のパネルはどうしても高画質化をしたくなります。しかし高画質化のせいでメモリエラーが出てしまうかも。ストラクチャと違いテキスト記述で座標指定する都合、ある程度出来上がってからおいそれと解像度変えるのも骨が折れる作業。
高画質と軽量化、どちらを取るか難しい天秤になるかも。。。
そもそもBVE6ならメモリエラー問題も改善されるため、プラグイン系作者の皆様には64bit版プラグインをリリースしてほしい願いもあります。
★ユーザー
NT/fiv様の文章に被る内容なのですが。。。
☆BVE5.7(以前)を使用でメモリ不足
今すぐBVE5.8/BVE6にアップグレードしましょう。
そして自分のPCのメモリをせめて4GB搭載しましょう。
割とこれだけで解決する場面はたくさんあります。作者さんにお問い合わせする前に、そもそも自分の環境を調べて解決できるなら時間短縮でラクチンです。
☆BVE5.8を使用でメモリ不足
もし車両データが対応しているのなら、BVE6でプレイしましょう。メモリエラーに起因するプレイ不可能の事態だけは免れます。BVE5.8では使用できるメモリ量に制限があるため、いくらメモリがん積みPCであってもBVE5.8でメモリが不足するときは不足します。また、作者がBVE6でいつも製作しているせいでエラーに気づかない、なんて例もあります。
ちなみにBVE5.8ではダウンロード時点で所謂4GBパッチがすでに適応されています。検索するとやり方とか出てきますが、古い情報なので操作する必要はありません。気にする必要もありません。NT/fiv様のXのポストによれば、
ユーザー側で4GB Patchを別途適応は絶対にしないでとのこと。
☆BVE6を使用/BVE5.8専用データでメモリ不足
激ヤバデータということになってしまいます……。正直自分も思い当たる節がありごめんなさいしかないです。激ヤバデータ世に出してごめんなさい。
こうなるとやはり作者サイドから軽量化データの提供を待つことになります。メモリ使用制限がさらに厳しかった過去には、dds化データを別個に用意したり、解像度や色情報を落としてテクスチャの軽量化を図ったりした例があります。
打倒メモリ不足
実験を通して、BVE5のシナリオロード時に発生するメモリ不足の原因や対策が見えてきたような気がします。実験していない項目もいっぱいあるので、実は見えてないような気もします。
エラーが発生すると、プレイヤーでも作者でもそれなりに凹むものです。PCスペックがどんどん加速する昨今、案外見落としがちな独特のエラー。潰せるものなら潰していきたいですね。
(もちろんBVE6専用として、メモリ不足のエラーをサポート対象外とする手法だってあるのです……！)
この記事が気に入ったらサポートをしてみませんか？