ひとつ前の関連記事↓
まぁ必ずやらなきゃいけないことでもないんだよな…
この内容を書いているときにだいぶ身も蓋もないことに気づいてしまったんですが、「BVE6に対応できて低性能PCを切り捨てる覚悟があるなら、べつに好きなだけメモリを使って作ればよい」んだよな……と。メモリ上限があったBVE5以前の時代ならまだしも、64bitPCの普及も進んでBVE6への移行の選択もできる。そんなわけで対策をしないという選択もありっちゃありかもしれない。
実際シナリオを読んだ時にBVEのメモリ消費が3GBに達していないのであれば、特に対策の必要はないかと思います。（2GBPCに対応したい場合はがんばれ）
とはいえ対策ゼロでひたすらメモリを食いまくっているとやがて自分ですらプレイできないデータになってしまいます。BVE6の限界はPCの限界なわけで、せっかく作ったデータがまともに動かない、それ以前にまともに製作が続けられないデータになってしまってはどうしようもありません。てなわけで、まぁやるかどうかは別にしてせっかく書いたので見るだけ見てってくれ。
軽量化の実際
「軽量化」というとストラクチャの頂点を減らしたり、テクスチャを縮小したり…と、せっかく作った物のダウングレードをする（質を下げる）作業であるといったイメージがあるかもしれませんが、そうした見た目を一切いじらないでも軽量化できる項目もあります。（とはいえ主原因がストラクチャにある場合も多く効果も大きいのでいじらざるを得ないことも多いですが）まずは見た目に影響がない非破壊の軽量化を紹介します。
●風景描画距離（DrawDistance.Change）を活用する
BVEの構文には風景描画距離を路線側から設定する構文があります。路線の状況によって描画距離を調整することにより処理の軽減が図れます。草原が広がるような区間であれば描画距離はある程度長くしても大丈夫ですが、線路が多くなったり建物が建て込んでいたり、また遠距離描画を必要としない地下鉄のような場所では、描画距離を短くすることで全体的な処理を軽くすることができます。
長い方がいいだろうと不必要に長く設定している人も多いようなので、最初に適切な値に設定するだけでも意味はあるかと思います。
ちなみにこの設定はフレームレートの低下には効果がありますが、メモリの削減には特に効果はありません。
●リストから読み込むストラクチャを減らす
BVEはシナリオ読み込み時にリストファイルにある「すべてのXファイル」を読みに行きます。要するにマップ内で使っていないけどリストに指定しているストラクチャがあるなら、それを外すことによって若干の軽量化をすることができます。
また、同じストラクチャを別のストラクチャキーを付けて登録した場合も別のストラクチャとして認識されるため、キーを統合することで軽量化できます。
共通系のストラクチャパックなどを使っていて、利用していないストラクチャファイルが多くある場合軽量化効果は大きくなります。しかしもともとちゃんと使う分だけ登録している場合は既に対応済みということになります。
●サウンドバッファを出来るだけ最小に見直す
サウンドリストファイルで指定するサウンドバッファは「その音声を同時に鳴らせる数」です。要するに一度だけ流れるようなアナウンス、もしくは周辺で必ず一つしか鳴らないとわかっている音声のバッファは「1」で問題ありません。前に書いた通りBVEは「すべてのデータをメモリに読み込む」ので、サウンドバッファの数だけその音声がメモリに読み込まれることになります。
対向列車用の音声ファイルのバッファはある程度余裕を持っておいた方がよいかもしれませんが、同時再生されそうな数を予想して、できるだけ小さくしておくことが望ましいでしょう。
●ストラクチャのテクスチャ定義を見直す
BVEはストラクチャに定義してあるテクスチャ（材質）について、Xファイルに定義してある分をすべて個別に読み込んでしまいます。そのため使用していないものは外して、統合できるものは統合した方がメモリ消費は軽くなります。特にBVE2/4のCSVから変換しているストラクチャは面ごとにテクスチャを張っていることが多いので、予想以上にテクスチャメモリを食っていたりします。また3Dソフトで作ったものでも、ソフトによっては使用しないテクスチャが残ったままなことがあります。特にRepeaterに設定しているものは影響が強いので調査しておくとよいでしょう。
PMXEditorを使用すればXファイルのテクスチャの使用状況を確認したり、同一のテクスチャを統合したりすることができます。（使用状況を見るだけであればteXviewでも可能）
ここから下は見た目に多少なり影響が出る対策となります。とはいえテクスチャの縮小以外はそんなに気にしなくてよいとは思います。
●テクスチャのDDS化
DDSとは何ぞや＆適用の仕方については上の別記事に譲るのでそちらを参照ください。要するにテクスチャを3Dゲームで扱うのに適した形式に変更するものです。ストラクチャによく使われているPNGファイルは基本的にはインターネット上での表示に適した圧縮画像フォーマット（JPGやPNGの仲間）であり、3Dゲームで扱うには一度その圧縮を解くという処理が入ってしまいます。その辺の処理を省略できるのがDDSファイル形式で、メモリの使用も大きく抑えることができます。ひとまずDDSに変換するだけでも大きな効果があります。
なおPNG/BMPからDDSへ変換するのはNvcompressFrontEndを使用すれば簡単なのですが、そこからXファイルへの適用はちょっとひと手間掛かります。もっとサクッとできるようにしたいですね……ッッッ！
※PNG＝Portable "Network" Graphicsの略でれっきとしたネットワーク利用想定の画像フォーマット
●テクスチャの縮小
3Dゲームにおける画像の重さはそのファイルサイズではなく、画像のピクセル数が基準となります。要するに単純に画像サイズを大きくするとめちゃめちゃ重くなります。下の画像を見ていただければわかりやすいと思います。
ちなみに画像サイズは大きければいいというものでもなく、ある程度周辺に合わせて調整しないとストラクチャごとに解像度が異なって変に浮いてしまうことがあります。使用箇所に応じて適当に調整することが望ましいでしょう。
ちなみに自分が2017年まで使用していたPCは1024px以上のテクスチャを使った路線がまともに動きませんでした。（該当ストラクチャが現れるとFPSが一桁近くまで落ちた）
●ストラクチャ形状や置き方の見直し
駅構内など大量にストラクチャを置いているところでは明らかにフレームレートが落ちることがあります。ストラクチャが多くなれば当たり前のことではあるのですが、表示するテクスチャや頂点数が増えてPCの処理が追い付かない状態になるためです。主に重くなりがちなのはRepeatで回すストラクチャと車輛ストラクチャなので、できるだけ軽いものに置き換えるなど工夫が必要となります。
BVEは模型と違って全体を作りこむ必要はないわけなので、運転台目線から見てよく見えないものはバッサリと削ってしまうのも手でしょう。
またレールも意外と重いストラクチャです。直線ではレール自体を1本の長いストラクチャに取り換えるのも効果がありますし（5mレールを25ｍレールに置き換えれば単純に1/5になる）、遠くの描画がつぶれてしまうようなところにあるレールストラクチャはレール自体を外しても意外と気づかなかったりします。
古いデーターで車両の右／左半分がバッサリと切られたような車両が出てくることもありますが、このくらい削減しないとカクカクして（フレームレートが落ちて）まともに運転できなかった時代の名残です。
（ベースが拙作の梅田駅、見えないところはバッサリ削っている）
●サウンドファイルの最適化
サウンドファイル（WAV）を録音したそのままの音質で使用している場合、サウンドファイルの音質を下げることによってメモリ消費を減らすことができます。例えば音質設定は48kHz/24bitや44kHz/16bit ※1/2 あたりが基本だと思いますが、実は22kHz/16bitでも十分な場面も多くあります。またステレオではなくモノラルでも問題ないこともあるでしょう。音質を44kHzから22kHzに落とすと容量もメモリ消費も半分になります。ステレオからモノラルに変換しても同じく半分になります。
※1 48kHz/44kHz/22kHz：サンプリング周波数：数字が高いほど高い周波数の音が録音できる。音楽CDは44kHzであり、一般的にはこの程度あれば十分とされる。参考サイト
※2 24bit/16bit/8bit：量子化bit数：基本は16bitでよい。8bitに落とすとノイズが出ることがあるので注意。
そんなわけで、自分が思い出した限りの軽量化対策を書き出してみました。冒頭にも書いた通り、今ではPCのパワーもある程度あるので昔のように必死こいて軽量化対策をする必要性はなくなりつつはあります。すみません日豊線もだいぶDDS化サボってます。とはいえ軽いなら軽いに越したことはありませんので、できれば作者側で積極的にやっていくべきかなと思っています。
