English version

マイクロソフト・フライトシミュレータでは、その仕様で、所定の領域内に表示可能なオブジェクト数には限界があります。この限界を越えると、シーナリーの一部または全部が突然表示されなくなります。よく、単独ではとても良くできているシーナリーが他のシーナリーと組み合わされると消えてしまうという話を聞きますが、この原因のほとんどはこの限界に達したからと考えてよいでしょう。細部までよくできたシーナリーほど極小領域内に多数のオブジェクトをもつのが普通です。

まず、オブジェクトが消えてしまうことがあげられます。どんな場合にも現れなかったり、現れるときもあれば現れないときもある場合もあります。特にこの現象は、ヒステリシス効果として知られています。これはあるオブジェクトが他のオブジェクトの影響を受けるもので、現れたり現れなかったりする場合の主な原因です。　ところで、SceneryMaker においては、Area()　コマンド内で visibility を設定することができます（SCASM等の他のコンパイラでも同様です。）。　ＦＳ上ではオブジェクト数の少ない田舎では、この visibility の値より遠距離から眺めると見えなくなり、近いと見えるという動作がなされます。ところが、オブジェクト数の多い都心ではそうはいきません。たとえ visibility の値より近くから見たとしても、見えなくなる場合があります。

ヒステリシス効果
	これから行くところ は見える。
	真下と先は見える。
	後ろしか見えない。

上の絵を見てください。一番上の絵は、羽田空港上空に相当する条件で、これから都心部へ向かっていく場合です。羽田近郊のオブジェクトは正常に見えています。
真ん中の絵は、新橋・浜崎橋近郊に相当する条件で、銀座や大手町のビルがこの辺から見え始めます。
下の絵は、銀座のビルを過ぎて有楽町駅上空に相当する条件で、首都高速シーナリー(Tko_hw1.bgl)と山手線シーナリー(Tko_tr1.bgl)の両方を入れた状態では東京駅が表示されないことがあります。ただし、これは羽田から直線コースで来た場合であって、東京湾から回り込んできたり一旦隅田川に出て西にアプローチして東京駅に行けばちゃんと表示されます。
このように、各オブジェクトは visibility で規定される値のみならず、他のシーナリーの影響を受け相互の位置関係によって定まるヒステリシス効果により、表示状態がかなり変わってしまいます。

残念ながらこの限界はＦＳの仕様によるものなので、本質的な解決方法は今のところありません。将来のバージョンアップに期待するしかありません。
ただし、この現象を軽減することはできます。

-1-　visibility 設定
まずはやはり visibility を低めに設定することです。こうすることでオブジェクト同士の自己主張が弱まり、遠くのオブジェクトによって近くのオブジェクトが影響を受ける可能性が低くなります。ただし、もし遠慮しすぎて自分のオブジェクトの visibility を低くしすぎると、他のオブジェクトに殺されて自分のが全く表示されなくなります。多数回の実験の結果、首都高速では visibility を 36 km に設定していますが、もちろん上記の現象によって 36 kmより近くてもすぐには現れません。もし 10 km 位にすると、ヒステリシス効果により都心から羽田に戻るときに大井埠頭の湾岸線が表示されなくなります。さらにそれ以下にすると、マイクロソフトの純正シーナリーに殺されて、全く非表示になります。この辺の具体的数値は実験するしかないのですが、定性的には「自己主張しすぎても遠慮しすぎてもダメ」という状況は、毎日家畜以下の扱いで圧死通勤している東京の通勤電車と全く同じで、シーナリーを作ってまでこんな思いをするとはかなり悲しいことです。是非ともマイクロソフト社（と鉄道会社と日本国政府）には本質的解決（新線建設・遷都・「真の」民主主義の実現・・・etc.)をお願いしたいところです。

-2-　オブジェクト数の減少
これは山手線シーナリーで多用しました。例えば２本の線路を並行して敷く場合には、１本の線路のオブジェクトを２つ置くのをやめて、２本の線路を現すオブジェクトをひとつ置きます。こうすることによって、例えば有楽町-東京間の線路は山手線・京浜東北線・東海道線・東海道新幹線の４系統が各々複線ですから合計８軌道あることになりますが、これをひとつのオブジェクトにすればオブジェクト数は1/8に減少します。具体的にはテクスチャを多用します。東京駅の南側線路を見てください。いくつもの線路が入り乱れてポイントがあったりカーブがあったりしていますが、オブジェクトはひとつです。線路の絵は全てテクスチャです。もっとも、どこまで細かく書くかによってテクスチャの消費量に響いてきます。

-3-　その他の方法
理論的には条件分岐プログラムによって、近くになったら複雑なオブジェクトを描き、遠くになったら単純なオブジェクトを描くことも考えられます。条件分岐をして、あるルーチンは一回しか実行されないようなプログラムを書いたとしても、実際の実行時はプログラム全体のトータルのオブジェクト数がＦＳ上で消費されるようです。これもオブジェクト数のリミットに達した状態の東京都心で色々やって実験しました。このことは山手線動画シーナリーにも良く当てはまります。動く車両を見て頂ければわかるとおり、動いているのは山手線一編成だけです。しかし、オブジェクト数は非常に多くなってしまいます。これはアニメーションを作るときのセル画のように各時刻毎に別々のオブジェクトを生成するようプログラムする必要があるからです。もし条件分岐してもオブジェクト数が増えないなら、Tko_tr1.bgl と Tko_tm1.bgl はこのシーナリーの非表示現象に対して同じ振る舞いをするはずです。しかし現実は全く異なり、動画シーナリーは他のシーナリーとは併用不可能なほどのオブジェクト数を持っています。
但し、 SetVar を使い、 PerspectiveCall の外側で条件分岐を行う方法はちゃんと動作するという点では良い方法です。（これも下にある Kukushkinさんの文献に書かれています。） しかし、ヒステリシス効果のとても強い東京都心では、残念ながら改善効果は現れませんでした。多分、荒野の中に複雑なオブジェクトがひとつだけあるような状況では効果があるのだろうと思います。
また、 CondRefpoint を使い、３種類の visibility 設定を使い分けるという方法もあります。v1,v2,v3の具体的意味については文献をご参照ください。ただこれも、実際の都心のヒステリシス効果を低減させることはできませんでした。

上記はすべて、３次元オブジェクトの表示限界に関するはなしでした。文献によると、ドットとラインについてはこのオブジェクト数の限界は関係ないとのことでしたので、花火大会のシーナリーではそれに期待してドットとラインのみでシーナリーを構成しました。しかし、やってみると、ドットとラインには３次元オブジェクトとは別の限界が存在します。確かに、オブジェクト数のほぼ限界に達した東京やニューヨークに花火を置いても、ある程度までは正常に表示されますが、花火の数や時間（時間が増えるのは物体が増えるのとほぼ等価です。山手線動画シーナリーのときに体験したことと同じです。）を増やしたりすると、途中で消えてしまいます。いろいろやってみたところ、ドットとライン数の限界は３次元オブジェクトの限界とは独立していると解釈するのが良いように感じます。
なぜならば、東京とニューヨークでは３Ｄオブジェクトは多分東京の方が多い（ただし首都高と山手線をフルにインストールした場合）のに、ドットとライン数の限界はニューヨークの方が厳しいのです。ニューヨークの夜景を見るとわかる通り、マンハッタン島周辺には沢山の橋が架かっており、それらには美しいドットの照明がたくさんついています。東京の首都高やレインボーブリッジにも照明がありますが、ニューヨークほどの表示密度はないと思います。また、逆に花火によって首都高が表示されなくなることもあります。これは一見３次元オブジェクトとドット・ラインの限界には独立性が無いようにも見えますが、なぜか首都高は消えても山手線は消えていませんでした。夜景を見るとわかるように首都高は照明がつきますが、山手線は夜は真っ暗です。首都高のドット命令は PerspectiveCall 内に入っているという違いはありますが、花火シーナリーによるドット･ライン数の限界への到達のために道路ごと消されたのではと思います。
このように花火のドットと首都高のドットが喧嘩した場合には花火の方がどうやら強そうですが、おそらく首都高の方は PerspectiveCall 内に入っていて３次元オブジェクトとしての制約も受けるというハンディキャップがあるからかと思います。（勿論、visibility設定の違いも効いていると思います。）

トワイライトエクスプレス社の東京シーナリーは衛星写真を使用したテクスチャをグラウンド･テクスチャとして使用しています。東京シーナリーの説明書にもあるように、これまでと同様な方法で追加のシーナリーを作ってもうまくいきません。この説明書には synthetic scenery に関する記述はあるものの、Scenery MAKER を使いこなさないと駄目とかの抽象的表現しか書いてありません。
具体的対策は２つ考えられ、１つは Priority コマンドを使う方法です。しかしこれは実験しましたがうまくいきませんでした。 _CondRefpoint を使用する方法も試しましたが、今のところうまくいきません。
２つ目の方法は、 sclink を使う方法です。これはうまくいきます。ただ、今までのようにファイルを軽く出し入れして手軽にインストールという使用方法はできなくなってしまいます。 sclink は、下の World Wide Guide のサイトからダウンロードできます。このような素晴らしいプログラムとサイトの存在には頭が下がるばかりです。
それから、このトワイライト東京シーナリーに限っては、メモリーの増設がオブジェクト数の増加に有効なようです。（後述のように、ＭＳ版では内部バッファの容量が効いてきます。） 私のところはＲＡＭが９６ＭＢの環境ですが、知人の３２ＭＢの環境では非表示となってしまうオブジェクトがあることが分かっています。その詳細な理由は不明です。

ＦＳ９８が遂に出ました。さっそく、最大の懸案事項であるオブジェクト数の限界の実験を行いました。
ＦＳ９８それ自体では残念ながら３Ｄオブジェクト数の限界については、前と全く同じで何ら改善されていないようです。首都高・山手線をたくさん入れると、前と同じように消えます。さらに、ドットとライン数の限界については、逆に少々悪くなっています。ＦＳ６の東京のディレクトリをＦＳ９８から指定して全く同じ内容のディレクトリをアクセスした場合、ＦＳ６では花火が正常に出ても、ＦＳ９８では首都高のせいで花火の一部が非表示になります。
しかし、大ニュースがありました！！マイクロソフトのサイトでＦＳ９８コンバータが発表になり、これを使用するとなんとオブジェクト数の限界が緩和されます。これこそ、マイクロソフト社が行った本質的解決であり、高く評価できると思います。次に、私が作りました東京の各種シーナリーについて実験した結果を示します。

インストール状況	FS6	FS98+fsconv98
ＭＳ版首都高山手線詳細版全部	殆ど非表示となる。	Ｇｏｏｄ！ちゃんと表示される。ライトバージョンはほぼ不要と言える。
東京の花火大会を３つとも同時インストール	隅田川はＯＫ。東京湾は途中で消える。神宮は非表示。	Ｇｏｏｄ！完全に全部表示される。
ＭＳ版首都高山手線詳細版全部＋東京の花火大会３つ全部	全く駄目。	さすがに苦しいものの、ヒステリシス効果を我慢すればそこそこ出る。
ＴＷ版首都高山手線(ver0.6)	ヒステリシス強い。FS6では苦しいが、FS98+では実用範囲。

このように、大幅に緩和されていますが、やはり万能ではありません。それから、ＴＷ版ではおそらく sclink の威力のために、ＭＳ版ほどの差は出ません。ただ江戸橋・箱崎ＪＣＴ完成後は、ＦＳ９８＋でないと苦しくなりました。さらに、首都高環状線完成後はさすがにＦＳ９８＋でないと使用不能です。

さらに、ＦＳ９８の特徴としては、
「動作開始時・situationに行く時・シーナリーのデータベース組み替え時にとても時間がかかる。」
「フレームレートが非常に遅い。（Pentium 166MHzではつらい。）」
「こちらで使用する分には、シーナリーの３Ｄ表現は特に変化なし。（Canopus POWER WINDOW 3DV SX 使用）」
「シチュエーション・ファイルはＦＳ６と互換性があるものの、パネルを隠す設定のシチュエーションの場合には、開始後"Ｗ"キーを押す必要あり。」
などがあります。フライト・シミュレータを時空間移動マシンとして Slew モードで使用する分には、是非ＦＳ９８コンバータをご使用ください。ＦＳ９８コンバータなしのＦＳ９８は利用価値なしと言えます。
なお、ＦＳ９８（日本語版）でははじめから限界が緩和されているようですので、ＦＳ９８コンバータを作用させる必要はありません。

あまり詳しく書きませんでしたが、シーナリーの表示限界については上に述べた「３Ｄオブジェクト数の限界」とそれにともなうヒステリシス効果・「ドット・ライン数の限界」の他に、「PerspectiveCall命令内のポリゴン数の限界」もあります。これは、首都高の複雑なＪＣＴと山手線動画シーナリー作成の際に遭遇したもので、例え上記「３Ｄオブジェクト数の限界」 に達していなくとも、PerspectiveCallの中にあまりたくさんポリゴンを置くと、突然消えてしまいます。これについては解決方法は簡単で、多すぎるオブジェクトをPerspectiveCallの外に出してオブジェクト相互の前後関係を犠牲にすれば再び表示されます。大体その限界の個数は道路ユニットで２８個、ポリゴン数に換算して多分１００から１２８個です。なお、上に書いたヒステリシス効果は、「３Ｄオブジェクト数の限界」にのみ関係するもので、「ドット・ライン数の限界」「PerspectiveCall命令内のポリゴン数の限界」については何の前触れもなく突然消えます。

さて、長野オリンピックのジャンプ台のシーナリーを作りました。もうすでに以上の３つの限界がある事が分かっていました。「３Ｄオブジェクト数の限界」については、何といっても白馬の山の中で何も無いところなので、限界ともヒステリシス効果とも無縁であると期待しました。「ドット・ライン数の限界」についても今回ドットとラインはほとんど使わないので関係ありません。「PerspectiveCall命令内のポリゴン数の限界」についても、もし出会ったら少々見栄えは悪くなってもPerspectiveCallの外に出すという作戦があります。そのためかなり楽観的に、ジャンプ団体戦の金メダルジャンプを選手４人分は楽に作れると思っていました。ところが・・・原田選手を作っただけで限界が来たのです。しかも当初の予定よりもコマ数を減らしてやっと表示されるくらいでした。いろいろ実験すると、まずこれは「PerspectiveCall命令内のポリゴン数の限界」ではありません。なぜなら、PerspectiveCallの外に出しても変わらなかったからです。次に、「３Ｄオブジェクト数の限界」でもありませんでした。この場合、ＦＳ６（＝ＦＳ９５）でもＦＳ９８＋でも表示は変わりませんでした。（その後さらに実験したところ、逆にＦＳ６の方が良い結果が出ました。）また、 sclink を使っていろいろやってみましたが、 sclink を使わない方がいい結果が出たのです。これらの事は、「３Ｄオブジェクト数の限界」とは相容れない現象です。
それでは今回に特有の条件は何かというと、何しろ選手が動くアニメーションなので、１〜２メートルの大きさの物体をたくさん詰め込んだのです。一方、首都高や山手線・それ以外のデフォルトの東京のシーナリーの場合、それらは最小でも１０〜２０メートルのオーダーの物体から構成されています。というわけで、この微小物体が高密度に集積された条件で観測される現象であるということで、便宜的に「核力」と命名しました。ちょうど、原子核内の陽子・中性子はニュートン力学でいう重力ではなく核力によって結合しているというのと同じイメージです。そして消える時はただ消えるだけでなくＦＳがエラーで落ちたり固まったりします。先ほど書いた通り、「核力」についてはＦＳ９８＋よりもＦＳ６の方が優秀です。これは皆さんも簡単に実験して頂けます。私の長野オリンピックのシーナリーにはＦＳ９５用とＦＳ９８用がありますが、ＦＳ９５用は Nagano98.bgl 、ＦＳ９８用は Naga98a.bgl という名前になっています。この Nagano98.bgl をＦＳ９８で見てもらうとＦＳが固まって、Windows95ごと再起動しないと駄目になります。このように、「３Ｄオブジェクト数の限界」と「ドット・ライン数の限界」が比較的似ている振る舞いをし、「PerspectiveCall命令内のポリゴン数の限界」と「核力」が比較的似ている振る舞いをします。
つまりちょうど量子力学のように４つの基本的な力（＝限界）が存在するようですが、それを含めて表にまとめると次のようになります。

	FS5.1	FS6	FS98	FS98+fsconv98
内部変数	使用可能な変数が多い。	使用可能な変数が少なく、FS5.1との互換性が無い変数が多い。	FS6と同様。 FS6とは互換性あり。
ヒステリシス 効果	４つとも同等。
.
３Ｄオブジェクト数の限界	３つとも同等の限界あり。			限界があるものの、大幅に緩和されている。
ドット・ライン数の限界	これら２つは同等。		前に比べて少し悪い。	限界があるものの、大幅に緩和されている。
PerspectiveCall命令内のポリゴン数の限界	たぶん４つとも同等。
核力	たぶん同等。		多分ＦＳ９８＋と同等	ＦＳ６より少し悪い。

量子力学といえば、あの有名なハイゼンベルクの不確定性原理があります。位置と運動量は両方確定することはできないというものだったと思いますが、シーナリーにも同じようなことがあります。
長野オリンピックの選手のアニメーションでは、選手はとても速くジャンプします。遠くから見ると、動いているなというのはわかりますが、どこにいるのかは正確にはわかりません。近くで見ると、場所はわかるのですが、一瞬のうちに過ぎてしまって、運動量はよくわかりません。だからどうなのということになりますが、運動量の確定の度合いを０にすれば、位置の確定の度合いは無限大になります。要するに、アニメーションをストップしてすべてのコマを静止画で見られるモードを作りました。各々の絵をごゆっくりお楽しみ下さい。

量子力学では、原子核を回る電子の軌道は不連続で、エネルギー準位に依ります。ＦＳシーナリーでもアニメーションを作っても、なかなか意図したように連続には動いてくれません。こちらの環境では１／４秒に１コマが限界です。滑降するところの後半、ジャンプしてから着地するまでなどでは１／８秒のレートで作成していますが、残念ながらこちらの環境では再生されませんでした。このレートはＦＳの仕様で不変なのか、それともハードウェアの性能により変わるのかは不明です。こちらの環境は無印 Pentium 166MHzですから、今となってはかなり厳しいです。Pentium II 333 MHz あたりではどうなのでしょうか？ビデオカードの性能も効いてくるのかもしれません。

幸いなことにFS2000では、今まで述べた限界は全て根本的に解決されているようです。これは大変素晴らしいことである一方、FS2000になって発生した問題も多々あります。詳しくはこちらからどうぞ。
なお、FS2000のダイナミックシーナリについては、こちらからどうぞ。

このページでとりあげたオブジェクト数の限界についての知識と、山手線動画シーナリーを作成する上で不可欠なＦＳの内部変数についての知識について、Konstantin Kukushkinさんからいろいろと教えていただきました。ここに深く感謝いたします。