English version

当時からＳＣＡＳＭは有名で多くの方が使っておられましたが、個人的にはシラッティ・コマンダーを買ったためにそれに付属しているシーナリー・メイカーをいじり始めました。当時のFS, SceneryMAKER, SCASM の状況をまとめると次の表のようになります。

1997年	ユーザー変数	ダイナミック・シーナリー
FS5.1, FS95	-	テクスチャーの無い数種類の飛行機
Scenery MAKER	あり	非対応
SCASM	なし	対応

ここでユーザー変数とはＦＳの内部変数のことではなく、あくまでもプログラミング時にユーザーが勝手に定義して使える変数という意味です。当時初めて首都高などを作る際にいろいろ試行錯誤をする中で、ユーザー変数が使えることはとても自由度が大きく大事なことでした。一方、当時からダイナミック・シーナリーはありましたが、単にテクスチャーの無い飛行機が動くというだけで、山手線の電車を動かす観点からは何ら興味が沸く対象ではありませんでした。従って、自分の目的に対するScenery MAKERの優位性は明らかで、その後ずっとScenery MAKERを使って工事を進めることとなりました。

時は流れて1999年、結構最新情報には疎いのでしばらく知りませんでしたが、ふと気がつくと次のような状況になっていました。

1999年	ユーザー変数	ダイナミック・シーナリー
FS98	-	テクスチャーのある数種類の飛行機
DynKit	-	任意の３Ｄオブジェクトをダイナミック・シーナリーに割り当て可能。
Scenery MAKER	あり	非対応
SCASM	あり	対応

このように、Scenery MAKER は全く変化が無いのに対し、SCASM はバージョンが上がってユーザー変数が可能になっています。ここでまず、SCASM に対する Scenery MAKER の優位性は特になくなったわけです。そしてＦＳ自体も進歩し、ダイナミック・シーナリーの飛行機にテクスチャーを貼ることが可能となりました。そしてさらに DynKit です。ついに任意の物体をダイナミック・シーナリーとして作ることが可能となりました。この DynKit の登場により、ダイナミック・シーナリーで動く山手線を作ることが現実味を帯びてきました。

ここで大問題です。昔から Scenery MAKER を使って作成していたのでそのままではダイナミック・シーナリーに対応できません。そこで、今回ついに、ダイナミック・シーナリーに対応したシーナリー作成の際には SCASM に乗り換えることにしました。 SCASM は今や世界標準と言えるシーナリー作成言語で、これまでも頻繁な改良がなされ、今後もバージョンアップが期待できます。多くのＧＵＩ化されたシーナリー作成ツールにも採用されています。さらに未確認情報によれば、シラッティ・コマンダーの後継ソフトとして Schiratti Control Center が発売になるようですが、なんとこれでも SCASM と Airportマクロの APIファイルが採用されるようです。Scenery MAKER のホームグラウンドですらこのようですから、Scenery MAKER は今後どうなるのでしょうか。もしかしたらなくなってしまうのかもしれません。ただ、従来からの Scenery MAKER のソースの莫大な資産があり、かつ使い慣れた便利なツールでもあるので、１００％ SCASM に移行するのではなく暫くはバイリンガルで使い分けていこうと思います。

というわけで、SCASM と DynKit によりダイナミック・シーナリーを作成してみました。さて、作成してはみたものの、それはそれで特有の問題がありました。ダイナミック・シーナリーは動く飛行機を作るためのものですが、それを無理やり電車に応用するという観点から、長所と短所を見てみたいと思います。

長所

飛行機のように単独で物体が存在する場合にはそこそこいいのですが、山手線のように狭いところに１１個も物体を詰めると、Windowモードではダイナミック・シーナリーの動きがカクカクになります。ちょうどダイナミック・シーナリーを使わないで動かした山手線と同じような動きです。しかし、３Ｄモード( Alt + Enter )にすると全然違います。全ての動きが滑らかで、動きを表す品質はとてもよいです。（これは百聞は一見にしかずです。実際に見ると一目瞭然です。）

さらに、今まで問題になっていたオブジェクト数の限界が緩そうです。従来の方法では全ての座標を指定してやるのに対し、ダイナミック・シーナリーでは物体の移動方向や移動量などをベクトル的に指定します。ちょうどＭＰＥＧのようなデジタル画像に例えると、従来の方法では全ての I ピクチャーを送っていたのに対し、ダイナミック・シーナリーでは動きベクトルだけを伝送しているのと同じです。もっとも、ダイナミック・シーナリーに割り当てられているＦＳ内のメモリ空間の問題もあるでしょうから一概には言えませんが、データ−量が大幅に減っていることは原理的に明らかです。

短所

これも飛行機なら問題にならないのに電車なら大問題というものですが、物体相互の遠近関係が保存されないことです。抽象的でわかりにくい表現ですが、技術的にいうと、section 9 の object と　section 15 の object とを PerspectiveCall ルーチン内に入れることが出来ないということです。（文系の人にはかえってわかりにくいかも？？）もちろん、ダイナミック・シーナリー（section 15 の object）にもスタティックのシーナリー（section 9 の object）にも 基準点 (SetPos, RefPoint) があり、ある程度離れていればそこの位置の遠近により表示順序が制御されるのですが、物体同士が近接している場合には描画順序を PerspectiveCall で制御してやらなければいけません。具体的には、飛行機と管制塔の距離ならば問題にならないのに、電車と線路の距離ならば問題になるということです。これは、section 9 側のオブジェクトの処理で軽減することは可能で Tko_tm2.bgl でもそれは行っているものの、完全になくすことは出来ません。（これが、Tko_tm1.bgl では停車時の山手線のドアが開いたものを作ったのに Tko_tm2.bgl ではこの辺りを作成しなかった理由です。）

次に問題なのは、時間的空間的分解能が低いことです。具体的には動きを制御するのに１秒ごとにしか制御できず、制御量も東西南北に１ｍとなっています。これもやはり飛行機なら問題にならないのに電車なら大問題で、特に１１両編成を加速しながらカーブさせたりすると、もううんざりです。細かい動きの制御が難しく、どうしてもカクカクになってしまいます。さらに分解能だけでなく精度も低く、例えば Heading を変えただけで少々遅延があったりもします。

また、絶対時刻指定も不可能です。これは近づいたら動き始めるので逆にエンターテイメント性は良いのでしょうが、凝ったことはやりにくいです。visibility 指定も不可能で、具体的には山手線１１両を全車両全て見ようとしても端が消えてしまいます。また、絶対高度指定なので、synth tileをまたぐとオブジェクトが宙に浮いてしまいます。相対高度指定は不可能です。あとは、当たり前ですが、２以上のダイナミック・シーナリーがあるとその片方または両方が表示されません。東京のような過密都市ではこれは非現実的で、沢山のアドオン・ダイナミック・シーナリーをいれて楽しむことは現状不可能です。

現在のＦＳのダイナミック・シーナリーの仕様に対する希望として、次のように考えます。

section 15 命令の section 9 化

これはいろいろな意味を含みます。まず上記の PerspectiveCall 内に入れるというのが最大の懸案事項で、section 15 の命令が section 9 で使えるようになればそれが可能になることを期待しています。そうすれば、現状の制限事項である、section 15 のオブジェクトが section 9 のＦＳ内部変数を使えないことがなくなり、またメインの Textureフォルダにテクスチャを入れなくてはいけないということもなくなることを期待します。また、上記の欠点に書いたような visibility 指定や高度指定の問題も解決されることを望みます。

この他にも上記の欠点が１つでも多く解決されることを望むものです。

電車を動かすという観点から見てダイナミック・シーナリーは実用になるかという命題に対する結論は、現時点ではまだまだ・・・・だと思います。確かに長所に書いたとおり素性は良いのですが実用性がいまいちです。まあ道路工事もなかなか完成しないので人のことは言えませんが、ＦＳのシステムもまだ未完という印象です。ＦＳ２０００はどうなのか・・・また気になることが増えたという実感です。

FS2000が出ました。そしていろいろいじった結果、やっと2000年12月にダイナミック・シーナリーを使った山手線を公開することになりました。このときに実験した結果を書こうと思います。
まず、良い点が沢山あります。上に書いた事のうち、かなり改善されたところがあります。整理すると、

section 9 のシーナリーとの遠近関係が正常に表示されるようになりました。これで山手線を細かく表現する意味が出てきまして山手線の詳細化を行い、さらに昔ダイナミック・シーナリーを使わない動く山手線で実現した「ドア開き」も復活しました。

ダイナミック・シーナリーの動きの制御が細かく可能になりました。さらに位置の精度が飛躍的に向上しています。時間分解能は１秒のままですが位置の細かい制御が可能になったので、これで存分に電車が作れます。今回作った山手線のように、11両がカーブを通過したり少しづつ上り坂の線路を登ったりしても大丈夫です。（ただ、作るのはとても面倒ですが・・・・）

しかし、まだ良くない点もあります。

相変わらず１つのBGLファイルしか一度には見ることができません。複数のダイナミック・シーナリー・ファイルを同時に楽しむことは今までと同じく不可能です。また、動く時間や動く個数にも制限があり不完全です。SDKによれば、時間は２５５秒、XYZ相対システムコマンドでの同時実行数は３４個ということです。幸い今回の山手線は大丈夫でしたが、ちょっともう１編成増やしたり、次の駅まで電車を伸ばしたりすれば、多分ダメです。

これも困ったことですが、ダイナミック・シーナリーにはヒステリシス効果があるようです。まず、領域の重なるダイナミック・シーナリーを入れると見えないのは当然ですが、領域の重ならない複数のダイナミック・シーナリーをインストールしても勿論同時には見えません。しかし、同時でなければ見えるかというとそれもダメです。重ならない２つの領域間を移動しても、一方が表示された後他方の領域に入った場合にはすぐには他方のオブジェクトが見えてこないという現象があり、これはまさにヒステリシス効果です。

結局これらの問題の全てがなくならないとやはり自由な設計は困難で、今後はこのあたりの改善を期待するものです。

山手線をダイナミック・シーナリーで動かすという話の発端は、まさに DynKit があったからに他なりません。このような素晴らしいソフトウェアを作成された Konstantin Kukushkin さんは、毎度ながら尊敬に値します。そして深く感謝いたします。尚、FS2000用のシーナリーではDynKitは使用していません。こちらではＤＯＤは使用していませんが、ダイナミック・シーナリーに関する助言をＤＯＤの作者の Rafael Garcia Sanchez さんから頂きました。ここに感謝いたします。FS2000でのダイナミック・シーナリーについては、SCASM作者の Manfred Moldenhauer さんに大変有効な助言を頂きました。ここに感謝いたします。