2004/02/27

ひとつ前の雑文はこちら

第一期着工部完成記念

VRMへの改善提言

お蔭様で、第一期着工部を無事完成させることができました。当初半年と見積もっていた工期を事実上1ヶ月で終えることができたのも、偏に読者の皆様からの励ましのメールとVRMの性能に拠るところだと、改めて厚く御礼申し上げる次第です。

で、読者の皆様への御礼は、まぁ、今後いろいろなコンテンツをご提供しておこなうとして、本日は今回のプロジェクトを通して考えた「VRMへの改善提案」を公開してみよう、という趣向です。

なお、事前にお断り申し上げますが、本稿はかなりの量がある上に、一般的な読者には読解困難な内容が含まれていますので、VRM開発者筋の方を除いては、よっぽどお暇なときに読まれることをお奨めします。

 

ghostはやや躁っぽく、かつ健忘症気味で、しかもケチです。

次から次へとしょーもないコトを思いついては忘れていきますが、脳を使ってるってことは糖質を消費しているワケで、それを忘れるのはもったいない、というコトで、こうして駄文を書き連ねて外部記憶し、それを勢いで臆面もなく公開してしまうワケです。

俗にこういう人間を「電波系」と呼ぶみたいです。

部品配置不可能領域の設定

これはghostの個人的な印象かも知れませんが、今回のプロジェクトで、VRMによる設計から実際の施工に着手した時点で非常に強く感じたのは、レイアウターやビュワー画面で見るレイアウトよりも、実際のNゲージレイアウトの方が一回り膨張して見える、ということです。

より具体的に申し上げますと、実は一番最初に設計に着手した時点では、第二期着工部を含めて当初計画ではR280による楕円ループの外側にもう一本退避側線を引くことが可能だと考えていました。このプランにはいささか不安があったため、とりあえず現行プランに合わせた部材を購入してレイアウトボード上に一旦レールを敷いてみました。この時点で当初計画に無理があったことを悟り、同時に前述したような「一回り膨張して見える」印象を抱いた次第です。しかし、レイアウター上で試行する限りにおいては、R280ループ外側のもう一本の側線は、確かに可能に思えるのです。

ちなみに、このような無謀なプランを考えたキッカケは、TOMIXカタログ2003年度版のレイアウトボードの頁に写真掲載されているサンプルレイアウトなのですが、後でよくよく見てみると、どうもR280ではなくR243のループの外側に側線がある構成のようです。あぁ、部材購入前に気づいて良かった(溜息)。

VRMレイアウターでは、レイアウトサイズの指定はもちろんできます。が、各部品はレイアウトサイズを食み出して配置することができます。さらにウィンドウインターフェイスの挙動の癖から、VRM上のレイアウトサイズを実際のレイアウトのサイズと同じにすると、特に右上端へのフォーカスに妙な印象を覚えるため、VRMにおけるレイアウトサイズは実際のそれよりも100〜200mm大きく指定した方が実作業上は便利です。この二つの仕様上の特徴に、前述した見た目の印象の問題が合わさると、実際にはレイアウトベースから食み出してしまうプランに施工まで気づかないという問題が起こり得ます。

この奇妙な印象は、XZ軸共に正方向にはレイアウトサイズを超えて(強引に)画面遷移できるのに、負方向にはそれが出来ないことに起因しているように思われます。

この問題への対処として提言したいのが「部品配置不可能領域の設定」機能です。具体的には、レイアウター上で長方形(可能であれば任意の多角形)の領域を指定し、そこに一部でも入ってしまう部品の配置を妨げるような機能を想定しています。このようなチェック機能を常時働かすと当然のことながらレイアウターの速度低下が予想されますから、現行レイアウターの「製品リスト出力」のように、あるメニューをトリガすると評価がおこなわれ、問題があれば当該の部品について(3.0.2.7からサポートされた車輌を含まない編成の検知のように)レポートする、という機能でも十分と思われます。

このような機能があれば、レイアウター上では可能に見えて実は施工上問題があるプランを警告することができます。また、非長方形のモジュールレイアウトの設計にVRMが利用できるだけでなく、お座敷レイアウトの設計に家具を含む部屋の間取りへの配慮をおこなうことも可能になると考えられます。

 

お座敷レイアウトでの部屋間取りへの配慮については、VRM会議室でのなかもずさんの指摘をはじめ、TOMIXホームページの談話室(惜しまれつつ2004年2月末休館)でもしばしば話題になっていました。

相対座標系のサポート

おそらくこれも実際にレイアウトボードを前にして製作作業をしてみないと実感できない話とは思うのですが、現行VRMのレイアウター画面左上端を基準点とする座標系は、コンピュータープログラムの実装としては至極まっとうながら、実際のレイアウト製作から考えるとナンセンス極まりない、と思います。と言うのも、まずレイアウトボードの左上端を基準に寸法を測る、ということ自体が想像できない話ですし、そもそもレイアウトボードを自作するケースも含めて考えた場合、レイアウト周縁のラインは座標軸とするに足る精度を持っていないと考えるのが妥当でしょう。

多くの場合、鉄道模型のレールプランはレイアウトボードをいっぱいに使った楕円形となります。ここから考えた場合、座標軸の基準はレイアウトボードの端ではなく、中心にあった方が良いと言えます。また、ドッグボーン状のレールプランの場合は、基準点をある時は右側のカーブの半径の中心、ある時は逆に採って作業をするのが普通ではないでしょうか。であれば、座標軸の基準点は移動できるべきです。

ドッグボーンとはオーバル(楕円)ループについで鉄道模型でよく用いられるレールプランで、2つの円をつないだひょうたんのような形状が、犬が好む骨に似ていることからこう呼ばれます。

思うにこの実装はさほど難しくないように思えます。従来通り、VRM内部での部品の位置には絶対座標を用い、レイアウターインターフェイス上での表示に限りユーザーが指定した基準点に対する相対座標を表示するようにすれば、ユーザーはレイアウト製作の場々面々で最も適した基準点を選びながら作業を進めることができるでしょう。

 

バリアブルカーブレール

レール部品のバリエーションにフレキシブルレールが欲しい、という要望は、これまでもI.MAGiC HOBBY WORLDのVRM会議室をはじめ、各所で聞かれたものです。本稿では、従来と少し異なった観点からの考察を加え、現実的な実装方法も含めて妄想して・・・もとい、論じてみようと思います。

フレキシブルレールとは、固定式レールとも呼ばれる鉄道模型レール部品。ある程度の柔軟性を持ち、任意の曲線に合わせて曲げてレイアウトボード上に釘で固定して使用する。

つらつら思いみるに、「フレキシブルレールが欲しい」と言ってもそこには大きく分けて異なる二つの意図が隠れているものと思われます。1つは文字通り、実際の固定式レール同様に任意の曲線をレイアウター上でも描きたい、というものでしょう。もう1つは、VRMで提供されていない曲率のカーブレールが欲しい、というものと思われます。この両者は同じことのように見えて微妙に違います。なぜなら、実装もさることながらインターフェイスの設計についても困難が予想される前者に対し、後者はバリアブルレールのように、と言っても長さではなく曲率を変化できる角度固定レール(おそらく15度が適当)があれば解決するからです。そして、後者の要望の背景には、TOMIX以外の道床式レール(KATOのユニトラック、かな?)をサポートして欲しい、という思いが隠れていることは疑いありません。

かく言う ghost も、第二期着工部には KATO ユニトラックのR216の導入を検討しているので・・・

以下は ghost の個人的な邪推なのですが、I.MAGiC社とトミーテック社の間ではVRMについて、何らかの契約なり覚書なりが交わされていると考えるのが妥当でしょう。おそらくはその中に、「VRMはTOMIX規格以外の製品を将来に渡って正式にサポートすることはない」というものが含まれているのではないか、と思います。仮にそうだとして、その良し悪しはともかく(ビジネス的には当然だと思います)これがフレキシブルレールの導入の壁になっているのではないか、と思ってみたりするワケです。技術的な問題ではなく、政治的な問題、と言うヤツですね。それは捨て置き、こういう実装なら可能ではないか、ということを提言してみたいと思います。

ghost はI.MAGiCの関係者ではもちろんないですし、スーパーバイザーとやらでもないので、左記はあくまでも邪推です。誤解のないように。

まず前述したように、レールで自由な曲線を描くというフレキシブルレール本来の姿は一旦忘れます。これは、ghostが主張する「鉄道模型の実際の製作プロセスに合わせる」という主張と一見矛盾するように思われるかも知れませんが、さにあらず。実際にレイアウトボード上にフレキシブルレールを固定する作業を想定した場合、まずボード上に罫書きをし、それにあわせてレールを敷き釘打ちするのが普通でしょう。この「罫書き」を考えた場合、それは多くの場合は決して自由な曲線ではなく、エンドレスループを完結させるために道床式レールに似た計算を経た曲線のはずです。であれば、重要なのはVRM上で自由な曲線を描くことではなく、ループ完結が約束された曲線の正確な型紙を印刷することが、結果的に「実際の製作プロセスに合わせる」ことになるのではないか、と考える次第です。

これを前提に実装形態を考えた場合、前述したような「半径可変の15度カーブレール」というのが実用上も技術的にも固いのではないか、と思われます。言うまでもなく、サイズが可変する部品はバリアブルレールで実績があります。もちろん、それとは異なり「バリアブルカーブレール」では引き伸ばし方向が二次元になるという問題があります。そのまま拡大・縮小したのではレール幅が変わってしまいますね。これについては外側レールと内側レールを別にデータとして、両者の間隔を保ったままサイズを変更するという戦略で何とかなるのではないかと思うのですが、いかがでしょう。通過時の計算がそうはいかないですかね?。

 

ライケン・フォーリッジクラスタのサポート

引き続き「部品くれくれ」な話題をもう1つ。

VRMと異なり、実際の鉄道模型レイアウトを製作するにあたっては、部品数の増加が製作コストの高騰に直結しています。VRMは、レイアウト上の隙間を埋めるのに、パフォーマンスが許す範囲で無限にストラクチャを配置することが出来ますが、実際のレイアウトでこれをやったら、ghost でなくとも奥様(あるいは親御さん?)に顔向けできなくなることでしょう。閑話休題。とは言え、レイアウト上に何もない隙間が多く残るのは見目麗しくありません。そこで登場するのが、単価が安くかつ大量に配置しても美観を損なわない部材である、ライケンやフォーリッジクラスタ等の「茂み系」の素材です。

個人的にはVRM会議室にしばしば見られる「部品くれくれ」な話題はあまり好きではありません。既存部品の組み合わせでなんとかなるじゃん、工夫しろよ、みたいな。一方でこんな風に「ライケンくれくれ、フォーリッジクラスタくれくれ」みたいに書いてもみたりと、完全なダブルスタンダード。所詮、人間って自分の都合からしかモノが見れないのよね。

念のために補足しておきます。「ライケン」は天然のコケを特殊な薬品で防腐処理したジオラマ素材です。元が天然なのでとても自然に植物の感じを出すことができ、背の低い木々や茂みを表現するのに好適です。「フォーリッジクラスタ」は着色したスポンジが数珠つなぎになっている素材で、ライケンほどかさはないがパウダーで表現するには大きい、ふわっとした下草や森の地肌などを表現するのに使われる素材です。

実のところ、ghost 自身は今回のプロジェクトに着手するまで「茂み系」の素材をあまり重要視していませんでした。が、実際に自分でやってみると、その存在の有難いこと一入。好みの問題もあると思いますが、ghost としては樹木を大量に配置するよりも、少量の樹木をアクセントとして配置しその周囲を茂み系素材でデコレートする方が、より実感ある風景を作ることができると痛感しました。事実、今回のプロジェクトで使用した樹木部品は色違いの同種(TOMIX製落葉樹)が僅か8本だったりします。単にケチなだけですか?。

この経験を踏まえてあらためてVRMビュワーの画面を見てみると、これまでは茂みを表現したい場合や遠目の山肌の処理は樹木部品を対地高度マイナスに指定して埋めて使っていたのですが、どうもこれでは物足りないように感じました。ghost はVRM3・5号を持っていませんので、5号で追加された遠景用樹木は未評価なのですが、他項目でも取り上げる「VRMのレイアウト製作を実際のレイアウトのそれに近づける」という観点からも、ライケンやフォーリッジクラスタの感じを再現する部品の実装を強く希望する次第です。

 

とりあえず5号所収の遠景樹木をマイナス高度で埋めればなんとかなるような気もするんですけどね。

任意長方形の描画

レイアウター上に任意の長方形(欲を言えば任意の多角形)を、サイズの数値入力も可能な上で、描画出来ると便利かと思われます。

第一に、Nゲージレイアウト上に配置されるストラクチャは、ユーザー自作のものも含めると無限の可能性があり得ます。メーカー製のものに限定したとしても、これをVRMがパーツとしてサポートすることは不可能でしょう。今回のプロジェクトでは、VRMが提供している部品を重ねて配置することで擬似的に大きさを近似させましたが、これとて各パーツの正確なサイズ(位置は絶対座標で把握可能)が表示されないため、近似に過ぎません。幸いにして大抵のメーカー製ストラクチャはその床面積がカタログや箱等に記載されていますから、これを元に正確なストラクチャ配置の縄張りをおこなうことが可能となります。

ストラクチャ系の部品について、レイアウター上で床形状の正確な寸法が表示される、というだけでもかなり便利になるとは思います。

第二に、後述する「選択オブジェクトの実寸印刷」とも関係しますが、今回のプロジェクトで最も難儀したのは道路等のシーナリーの型紙を作ることでした。もちろん、作業中のレイアウトベースに紙を押し当てて実採寸することは不可能ではありませんが、起伏造成やストラクチャ配置が進むに従って、事実上困難です。これをVRMレイアウター上でバーチャルにおこなうことが出来れば、レイアウト製作の作業効率の向上につながるとともに、精度の高い製図によるクオリティアップにも資すると考えられます。

前提として、別項で述べた「部品系と地形系の座標軸のズレの解消」が必須かとは思いますが。

これらの任意図形をビュワー上にまで展開する必要があるか、は議論の余地のあるところでしょう。VRMビュワーが「既成部品の表示に特化する」ことで速度向上を実現しているのは周知の事実ですし、おそらくそこには、我々一般ユーザーには認知されない制限事項が内包されており、一見して自由に設計されているように思える各部品の構造が、VRMビュワー固有の仕様に制約を受けている可能性も考えられます。

単色の平面ポリゴン程度ならなんとかなるのではないか、と勝手に考えてみたりするワケですが、これがビュワーの恒常的な速度低下を招いてしまうのであれば、せめて環境設定で表示/非表示を選択できる実装は期待したいところです。あわよくば「高さ」要素も含めて「半透明」の立方体として表示されたりすると、ビュワー画像をレイアウト完成像を事前に知るという観点からも有用と思われます。

 

選択オブジェクトの実寸印刷

VRMには原寸大でレイアウト設計を印刷する機能が実装されていますが、実際にこの機能を利用しているユーザーはどのくらいおられるのでしょうか。今回のプロジェクトでは、ghost は結局この機能を一度も使わず、型紙の必要性が生じた場合は実際のレイアウトから採寸して作成をおこないました。理由は明らかで、レイアウト製作において実寸の図面が必要とされる場面は限られており、必ずしも全体を印刷する必要がないからだと思われます。

実はプリントアウトしてたら、もっと楽だったのかも。単に紙をケチっただけ。

一方で、今回のプロジェクトに限って言えば、道路用のシナリーペーパーを切り出す場面や水田地帯の区画を切る場面で型紙を作成した際、「これがVRMで出来れば便利なのに」と思うことが多々ありました。また、前述のバリアブルカーブレールが実装されるのであれば、これを印刷してレイアウトボードに転写することにより、フレキシブルレールの敷設に頭を悩ますNゲージャーの大きな助けになることは間違いありません。

ただ、少し言い分けすると、結局地形形状の精度が低いので、現行VRMレイアウターから印刷した図面が製作中のレイアウトと一致するとは思えなかった、というのが本音なんですけどね。

このようなニーズに応えるには、レイアウト全体ではなく、むしろ製作の場々面々で必要な部分だけを印刷する機能の方が適切ではないか、と思われます。また、実装面から考えた場合、レイアウター画面上で範囲を指定して印刷する機能の方が実装はし易いと思われますが、前述したような実際の利用の場面を想定した場合、むしろ選択された部品を印刷する機能の方が、よりユーザーのニーズに適うように思われます。

 

地形表面処理・地形造成プロセスの改善

これについては既に別項でも述べました。簡単に要約しますと、VRMの地形表面処理(地面テクスチャの貼り付け、地形高度の設定)は実際のレイアウト製作のそれとはまったく異なり、VRM側を後者に近づけるためには地面テクスチャを動的に生成・最適化するプロセスや、地形の部品化が考えられる、という内容です。ここでは、別の観点からこの話題について3つ書いてみたいと思います。

この節はむやみに長いです。

1つは「シミュレーター」という言葉の二義性です。シミュレーターは和訳すれば「真似るモノ」ですから、そういう意味でまさしくVRMは「鉄道模型シミュレーター」なワケですが、厳密な意味ではシミュレートしていない要素があると思います。そもそもシミュレーターはどのような目的で使われるのか考えてみると、要するに「本物ではできないから真似る」ためなんですね。この「できない」に二義性があって、鉄道模型に限って言うと「レイアウトを設置する場所がないからできない」と「一旦製作を始めると取り返しがつかないからできない」があると思うワケです。

VRMは前者は見事に達成していると思います。つまり、Nゲージレイアウトを擬似的に再現する点においては、満点とは言えないまでも「場所がないからできない」と思っておられる方々の不満の解消は出来ていると言って良いでしょう。一方で、後者については、これは実際にVRMで設計してNゲージレイアウトを製作した実体験をベースに、まだまだだな、と言わざるを得ません。つまりVRMでレイアウトを作っても、結局のところ実際にレイアウト製作をしてみないとわからないことが多いと言うことです。

少し脱線しますが、トム=ハンクスが主演した「アポロ13」という映画がありました。作中、想定外の事故が発生し、その窮地を脱する方法を模索するべく、地上スタッフはアポロ13号のシミュレーターで試行錯誤を繰り返します。もし、このシミュレーターを使って問題解決の手順が検討できないとすれば、それはシミュレーターとは言えません。少なくとも「取り返しがつかないから本物ではできない」ことを試行するべく「真似る」という意味においてのシミュレーターではなく、単に全て正常な状態のアポロ13号の「姿形を真似ただけ」のもの、と言うことになります。私の言わんとすることがご理解いただけたでしょうか。

2つ目はインターフェイスの問題です。本質的には前段と同じことになりますが、作業プロセスが本物に近ければ近いほど、シミュレーターとしては優秀である、言い換えるとシミュレーター本来の目的を達成している、と言うことができるでしょう。このような意味において、現行VRM3の地形表面処理・地形造成のプロセスは、とても実際のレイアウト製作を踏襲しているとは言えません。では、どのようなインターフェイスが考えられるでしょうか。無茶を承知で、理想像を考えてみます。

VRMは最初のバージョン以来、製作作業をおこなうレイアウターとレイアウトを視覚的に再現するビュワーとが別プログラム・別インターフェイスによって担当されるというスタイルを採っています。これは確実にパフォーマンス(処理速度)の向上に貢献しています。一方で、このスタイルがここまで述べてきた地形表面処理・地形造成のプロセスと実際の鉄道模型のそれとの間に隔絶を作る遠因になっているようにも思われます。地形造成については製図的な要素を含むので止む無しとしても、地形表面処理のプロセスは、ビュワー上で行えるようにしても良いのではないか、むしろその方が、実際のレイアウト製作のプロセスと比較して自然ではないか、と思います。

具体的には、ビュワー画面に一般的に地面表現に用いられる塗料やパウダー・バラストのパレットがあり、これを選択してビュワーでレイアウト内を移動しながら地面に色をつける、というインターフェイスが考えられます。インターフェイス部のみならば速度的に耐えれそうですが、拙案ではこのインターフェイスを回しながらリアルタイムに地面テクスチャを動的に生成する必要がありますから、少しきついかも知れませんね。

極論すると、ヘッドマウントディスプレイとデータグローブを着用して仮想空間で模型作りってところに行きつくワケですが。これってSF?

3つ目は現行バージョンとの親和性の問題です。あらゆるシステムが共有する問題ですが、何らかの仕様変更をおこなう場合、たとえそれがシステムの利便性を飛躍的に向上させ本来の目的の達成に資するものであったとしても、現行の仕様に慣れ親しんだ現実の利用者の意向を無視してこれを強行すれば、その仕様変更は「改悪」と呼ばれます。VRMについても同様で、仮に拙案が鉄道模型のシミュレーターとして理想的であったとしても、「VRM3ではこれが出来たのに、出来なくなるなんてひどい!!」と言われてしまうようでは、それは愚案と言わなければなりません。

とは言え、それがすべてだとすると、あらゆる仕様変更は否定されてしまいます。仕様変更の是非を検討するには、変更しようとする仕様が現行の利用者にどのくらい活用されているのか、どのように評価されているのか、を分析する必要があります。慣れ親しんだ仕組みであったとしても、利用頻度が低かったり以前から不満を持っていたものが変更される分については、利用者はこれを「改善」と受け取るものなのですから。

個人的な愚痴ですが、最近、左記のような当たり前の事実を認識してないITアーキテクトが多過ぎる、と思ってます。

オマエらの給料が何処から沸いて出るのか一度でも考えたコトがあるのか!!、と・・・(以下略)

このような観点にたってVRMの地面表面処理・地形造成のプロセスを考えた場合、あくまでも私見なのですが、インターネットで公開されているレイアウト、またそのスクリーンショットを見る限りでは、意外に活用度が低いのではないか、と考えています。もちろん、中には ghost の敬愛するVRMレイアウト作家の一人であるしおじ氏のように、地形造成・地面テクスチャを120%活用して、おそらく開発者も想像できなかったであろう奇想天外(誉め言葉です、念のため)な作品を生み出す猛者もおられるワケですが、どうもこれは例外的な事例のように思えます。

私も、しおじ氏の手法に学び、それを取り入れた動画作品をいくつか公開していますが、特に地面テクスチャの応用的な活用は非常に好印象な視覚効果を得ることが出来ることを実感しています。にも関わらず、応用事例が他にあまり見当たらないところを見ると、大多数のユーザーにとって、現行VRMの地面表面処理・地形造成のプロセスは受け入れがたい、拒絶しないまでも活用し切れない仕様になっているのではないか、と分析する次第です。これが、ghost が地形表面処理・地形造成プロセスの改善に拘る遠因にもなっているワケでして。

 

とか言いながら、現行の地形テクスチャの機能も、コンピュータに慣れた人間としては捨てがたいんですけどね。

クリアランスの評価

キハ40事件があったから言うワケではありませんが、VRMレイアウターにレールプランのクリアランスを評価する機能があれば良いのではないか、と考えてみました。とは言え、ghost の実例でも書いたように、規格化されたNゲージ車輌と言えども実際のサイズは千差万別であり、それらすべてについてのクリアランス評価をVRMに求めることは不可能ですし、そもそも不毛です。現実的な実装とその有用性を考えた場合、VRMに求めるべきは「クリアランスの保証」ではなく「クリアランスに影響を与えるリスクの警告」ではないか、と思うワケです。

ここでは「クリアランス」を「列車通過性能」の意味で使っています、念のため。

もう少し具体的に言いますと、一見自由に接続できるNゲージのレールにも、いろいろと禁忌があります。よく知られているのは、トラス鉄橋のように列車通過域を取り囲むパーツが付属するレールに隣接してカーブを作ることで、列車と鉄橋の接触によるクリアランス低下を招くというもの。大抵のカタログや関連書籍には「トラス鉄橋とカーブの間にはストレート区間を作るべき」旨が警告されています。今回のプロジェクトで ghost が経験したケースも、一般化すれば「カーブレール周辺へのストラクチャ配置に際しての注意」と言うことができるでしょう。この他、車輌毎の通過可能なカーブ半径(これも大抵のカタログでは新幹線系の車輌についてカーブ半径の警告が記載されています)や、ポイントレールの過度の連続による脱線率の増加、なども同じように考えることができます。

車輌製品毎のクリアランス評価は不可能にしても「ココは列車がひっかかるかも」とか「新幹線型車輌の通過にはカーブが急過ぎる」とかの指摘ぐらいはできるんじゃないかと。

これらの禁忌(絶対にやってはいけないワケでもないので「ノウハウ」と言うべきでしょうか)は、一角の鉄道模型愛好家ならば知っていて当たり前、という言い方はできます。しかし、別段でも述べたように「一旦製作を始めると取り返しがつかない」ことを事前に検証できるというシミュレーターの本義から考えれば、まさしくクリアランスの問題は鉄道模型レイアウト製作においては「一旦製作を始めると取り返しがつかない」ことの代表格と言えます。敷設してしまったレイアウト、ストラクチャの移設は大変な作業になる上、苦労して用意したレイアウトベースを破損するリスクを負うことになるのですから。これをVRMが事前に教えてくれる、または、教えてくれないまでも警告してくれるとすれば、VRMはレイアウト製作をおこなうNゲージャーにとって非常に魅力的なサポートツールとなるはずです。

具体的な実装を考えてみましょう。少し話が逸れますが、VRMレイアウターではレイアウト上に配置された部品数がある限度を超えたあたりから急にパフォーマンスが低下する減少が発生します。VRMのソースコードを読んだりリバースエンジニアリングしたワケではないので断言できませんが、おそらくこれは、レールや道路等の「連結」機能を持った部品をドロップする毎に、部品配置データベースに対して近接部品を検索する処理が実行されるからではないか、と推測しています。レイアウト上に配置済みの部品が増えるほど連結可能性を検討する回数も増えますから、これがレイアウターの速度低下を引き起こすのであろう、と考えられるワケです。

確かREはVRMのソフトウェア利用許諾契約で禁止されてますね。ghost がしばしばやっている「見かけの動作から内部設計を考察する」行為も広い意味では「解析」に当たるような気もするんですが、ひょっとしてコレって利用許諾契約違反ですか?

ここで述べたクリアランスの評価も「配置する部品の周囲に禁忌となる既設部品があるか検証する」という意味で「連結」可能な部品を検索する処理と類似していると言えます。従って、仮にレイアウター上に部品をドロップした時点でクリアランス上の問題を指摘するような実装をおこなった場合、急激なパフォーマンス低下の原因となる恐れがあります。この機能の受益者は、今回 ghost が試みたように「VRM設計を元に実際のレイアウト製作をおこなう人」に限られますから、これは得策とは言えません。

むしろ、現行VRMの「製品リスト出力」の機能のように、ユーザーが必要を感じた時点でトリガするとクリアランス評価をおこない、その結果をレポートする形態が望ましいと考えられます。その際には、アップデータ 3.0.2.7 にて好評を博した「車輌が含まれない編成部品を指摘する機能」のように、クリアランスに問題が発生する恐れがある部品の番号と位置を報告してくれると、レイアウト製作の事前の問題判別ツールとしての価値が高まることでしょう。

 

マルチゲージ・メーカー対応

最後にオマケ的な話題をひとつ。

2004年1月に工学社から出版された「VRM3レイアウトコレクション」という本に、ghost は「Vゲージを目指そう」と題した小文を執筆し掲載していただきました。既読の方もおられるやも知れませんが、要約すると、VRMはNゲージ鉄道模型の派生物として誕生したが、必ずしもその地位に留まる必要はなく、HOやZゲージ等のN以外のゲージの鉄道模型同様に独自のゲージ「V(Virtual)ゲージ」を目指す戦略を採っても良いのではないか、というような、一介のユーザーが書くにはいささか大風呂敷な文章でした。

度々アチコチで書いてますが、あの記事はあくまでも ghost の私見です。I.MAGiC社の方針とかとは無関係です。

どーでもいいですが、かの本で記事毎の文責が明示されていないのは問題があると思う今日この頃。

もちろん、この文章が意図したところは「Nゲージを蹴倒して進め!!」というような、いわゆる下克上ではありませんし、元よりそんなコトは不可能です。本稿でも述べて来たように、VRMは現行バージョンではまだまだ至らぬ点があるにせよ、鉄道模型レイアウトを愛好する人々の強力な支援ツールとなり得る可能性を持ったアプリケーションです。であるならば、何もNゲージという鉄道模型の一分野に拘泥する必要はないのではないか、むしろ現実のゲージ幅を持たない特性をいかして、すべてのゲージの愛好家をサポートする方向性を模索した方がより発展できるのではないか、というのが ghost の本意でありました。

一方的にリアル鉄道模型愛好家を助けろと言っているワケではありません。彼らから支持されるツールになれば、彼らからは長年に渡って蓄積されたリアル鉄道模型ならではのノウハウが作品等を通して必ずフィードバックされ、これがVRMのさらなる発展を加速させることに真の目的があります。

さらに言えば、鉄道模型愛好家は比較的大きな購買力を有している方が多い点もビジネス的に魅力です>I.MAGiC様。

言うまでもなく、ゲージが異なると同じ鉄道模型とは言え考え方が随分異なります。例えばNゲージで半径400mmのカーブと言えば極普通ですが、同じ曲率をGゲージにそのまま当てはめると、とてもではないですが実現不可能なカーブ半径になってしまいます。このように、Nゲージのノウハウをそのまま他ゲージに充当することが適当でないのは百も承知ですが、敢えて言うならば、本稿でも述べた「バリアブルカーブレール」と「相対座標系のサポート」を実装すれば、理屈の上ではVRMは存在するすべての鉄道模型ゲージ、さらには未だ存在しないゲージについてもサポートが可能になるはずです。

相対座標系云々に補足しておくと、要するにVRM内部で部品位置を記録する座標系とレイアウターがプレゼンテーションする座標系を独立させれば、基準軸の移動はもちろん、一律に等倍することで、各鉄道模型ゲージの実寸に合わせて数値を弾き出せますね、という話です。

同じく、ゲージが異なればユーザーが利用する部材も異なってきます。現在のNゲージのみとの連携を考えても(これはトミーテック社との関係もありますから難しい問題とは思いますが)KATOのユニトラックレールやGREENMAXの豊富なストラクチャ群が何らかの形でサポートされれば、NゲージャーのVRMを見る目は変わってくると思われます。マルチゲージ対応を考えれば、Zであればメルクリン、ファーラーはお約束でしょうし、GゲージならLGB・・・ちょっと話が広がり過ぎましたね。

 

おわりに

駄文にここまでお付き合いくださいまして、ありがとうございました。

世に「これから〜をやります、見てね」と書いてあるWebは吐いて捨てるほどあるワケですが、日付を見ると3年前のまんま止まっていたりするケースもまた吐いて捨てるほどあるワケでして。思えば大胆にもかのVRM本の後記に「Nレイアウト作るぞ」と公言し、本当にレイアウトを完成させた上、こんな愚にもつかないことをグダグダかつ大量に書いている自分に「オマエは結局何がしたいんだ?」と問いたいです。問い詰めたいです。

例によって中途半端な知識と個人的な感想をベースに書いておりますので、事実誤認や論理の破綻などが散見されると思われますが、この点は個人が「伊達と酔狂で」やっていることとご寛恕ください。メールにてご意見・ご指摘等をいただければ、適時本稿についても改訂を加える所存です。

 

では、第二期着工部完成の暁にまたお会いしましょう。

まだ、やるんかい!!>オレ

当サイトはマジ半分、ネタ半分です。あまり字面を捉えてお怒りになられぬよう、伏してお願い申し上げます。

 


Webmaster: ghost@nodus.ne.jp