Home > こだわり のコーナー > コーヒー の席
ブログ更新情報
ブログを見る

携帯電話用QRコード

VRM5 《ばんぶ~ の ぺえじ》モバイル

携帯のバーコードリーダーでQRコードを読み取ることで、携帯版ホームページへアクセスできます。

コーヒー の席

本文の掲載です 

※ #10 以前は 喫茶コーナー です 
※ 目次は コチラ をご参照ください
* * * * * * * * * * * * * * * * * * *   
※最近の記事 ⇒  左欄『ブログ更新情報』をご参照ください。
* * * * * * * * * * * * * * * * * * *

〔H25.06.11〕 #11・Tehachapi Loop への思い入れ

●全長1.2kmを超えるダブルスタックカー〔二段コンテナ車〕編成を 5重連以上ものディーゼル機関車《補機も多重連》が牽引して喘ぎながら登坂する様子は 多くの鉄道愛好家を魅了しています。
・この様子の映像が数限りなく投稿されていることは その事実を明しているものと思います。
●VRMで この情景を模倣してみたくなり 必要とされる資料〔数値データ・地図・地形図から始まって全行程の線路敷設状態の判明する上空写真・全行程の前後左右からの車窓風景・推奨特定サイトでの情景〕を収集して 動画作成の基礎となる素材映像のためのレイアウトを作成しました。
・この準備期間に3ヶ月を要しました。
●いざ 作成画面を確認してみると 内容が貧弱であることが否めないのです。
・それもそのはずで 国内でよくみかけるコンテナ車を使用しているからです。
・これでは ダブルスタックトレインによる重厚なシーン を映出することが不可能であると認識しました。
●それでは ダブルスタックカーを作ればよいではないか ということになります。
・ここで障壁に突き当るのです。
・ダブルスタックカーを作成したとしても いざ映像化ということになれば 連結数100を超える車輌のポリゴン処理には 〔ポリゴンについては #4 をご参照ください〕 当方のPCでは負担超過となります。
・この結果 コマ落ちが甚だしく見るに耐えられない状態となります。 
●以上のことから 作成画像の投稿を断念している次第です。
~下掲一部修正~〔2016/07/17〕
●既にご存知の各位もおられることと思いますが TehacapiLoopに関連する数多くのYouTube投稿動画のなかに邦人の投稿したものがあります。 そのうちの一つをご紹介します。
こちら からご視聴ください。
・タイトルは 『8重連牽引・全長2キロ!アメリカの貨物列車』 です。


〔H25.06.16〕 #12・当方PCのVRAM と VRM

・レイアウトサイズ と 使用部品〔パーツ〕に付随するポリゴン処理量 がメモリーに影響することは既に #4 で言及しました。
 《VRMシステムをご使用の各位には  ご存知のことであります。》
・RYOMA氏の提案されました方法で作成した R3000曲線を使用すると どうしても高速で走行させたくなります。
●しかし 高速走行となると 別事象での障壁を生じます。
・300km/h 〔 1/150 スケールでは 画面上約555mm/sec の移行速度〕で走行させた場合 当方PCのVRAM 〔ビデオ・ラム〕では 映出時間は約6分が限界となります。
 《 ただし 複数編成での走行としています。》
・この時間を超過すると 肝心なセンサー〔諸々の作動を規定するプログラムを格納している部品〕 の指示が不安定となるのです。
・PCの機能限界に近い状態という過酷な稼働 を強いているものですから ファイルサイズの数KBの違い が上記の不安定な現象の惹起に加担することにもなります。
・したがって 修景用部品の使用と追加に戦々恐々としている次第です。

●上述のことから
・現段階では 地形クスチャーを多彩にすることにより修景用部品使用の代替とするか 走行速度を低下させるか の二者択一の状況です。
・当方としては 少々のコマ落ちは覚悟の上で 走行速度を低下させるという方策は採りたくない というのが本心です。
 

〔H25.08.30〕#19・レイアウトサイズ と ファイルサイズ

・ご承知の各位にはご笑止ください。

●タイトルの内容の概略については #04〔喫茶コーナー〕  で触れているところですが 当方PCに関しての言及をいたします。
・ただし 以下は VRM  ONLIN に関する内容です。
・ VRM5 に関しては未試行です。  ご承知おきください。

●レイアウトの最大 サイズ〔20000mm×20000mm〕 から1/8〔10000mm×5000mm〕への縮小の場合 配置部品数に依存するものではありますが ファイルサイズは3MB前後の減少となります。
・ ただし この減少には下掲『条件』が伴います。
・『条件』とは 当初の最大サイズ全面に部品の配置をしていない場合 のことです。
・当初の最大サイズ全面に部品配置をしていた場合は 縮小サイズに合わせての配置部品の削除をしても ファイルサイズの減少は ほんの僅かです。
・裏付けとなる数値データが存在するものではありませんが この僅かな減少は部品の削除に伴うものと判断されます。
・上記 『ファイルサイズの僅かな減少』  の状況下で 部品を追加配置しての改作を重ねた場合 部品数は当初の最大サイズのときよりも少ないものの部品ID数値は増加の一途を辿りますし ファイルサイズは逐次増加する結果となります。
・この影響で 部品のID数値が 39000 を超えると 一部品の『コピ・ぺ』に数秒を要するようになります。
・センサーや他の複数部品の『コピ→貼り付け』には その都度40秒以上を必要とします。
●したがって 改作をあきらめないのであれば 所要時間に耐えてのコピペとするか 手数をかけての新規配置とするか の二者択一の状態となります。

●それでは ほかに方策はないのか ということになります。
・既にお気付きの各位がおいでのことですが 新規作成として縮小レイアウト全体の コピー & 貼付 の方法があます。
・この場合には 部品ID数値もファイルサイズ も一般通常の値に戻ります。  
・が 『所属『レイヤー』 の修正 をしなければなりません。
・残念なことに この修正には 配置部品数に相応して 上記同様の膨大な時間を必要とします。
・また  地形データ は コピペ されませんから 新たに調整することとなりますので レイアウトサイズ縮小時と同一の画面背景が作出できることにはなりません。

● 結論としては 極端なレイアウトサイズを縮小しての改作は 総合的観点からすると実効性は小さいもの であることを認識した次第です。
《以上  当方のグラ・ボやメモリーに関係した  経験則 の申し述べ です。》  
※なお 頭書で VRM  ONLIN と VRM 5 の差異に言及したのは 動画作成時に同一ソフトの使用であるにも拘らず 制作過程の状況が異なることによるものです。
・ ご了承ください。

〔H25.12.06〕 #20・センサー と 自動センサー と

・昨今の自動センサー仕様は 初期のものとは比較にならないほどの多彩な内容となっております。
・しかしながら 汎用性の観点からすると 万人のユーザーの詳細に亘る要望に応えようとすれば かなりの難題を抱えることになりましょう。
●当方のレイアウト作成においても 現時点での自動センサー仕様では全ての作動設定は無理であるという局面があります。
・それで〔(従前からの)センサー〕との併用としております。
・とはいうものの すべからく併用で処理できるものでもありません。
・当方の経験では 処理できるのは《ポイント》操作のみです。
・そのため 例えば編成の走行制御や信号現示による制御では〔センサー〕のみに頼らざるを得ないため苦労しております。
●〔自動センサー〕は多彩な仕様となっていることから〔センサー〕に比して 若干ではありますがメモリーが増加するように思えます。
・若干とはいうものの 使用数量に比例した増加であるため PC機能の限界に近い稼働状況下では 場合によっては〔自動センサー〕の使用数量を削減せざるを得ないことがあります。
●編成スクリプトで couple については 自動プログラムであることから 特段のセンサー設定についての記述はされておりませんが 当方の現状認識に触れます。
・11月までは マニュアル どおりの自動連結でありましたが 現12月時点では 接近速度に関係なく停車編成の手前で必ず進行を停止します。
・この現象は 追突防止機能の仕様変更によるものではなかろうか と推測しております。
・ただし センサーの追加措置により対応できるので なんらの不都合はないところでありますが この対応検討に時間を要することと相なりました。

~ とりあえず 以上です ~

〔H26.03.09〕#21・編成のアクティブ化 と 列車カメラの変移

・遅れ馳せながら 現時点で当方が認識したことです。
・既に当記事の内容をご承知の各位には ご笑止ください。
●以前は 一の未アクティブ化編成の列車カメラを指定する場合には 当該編成をアクティブ化することにより可能であったことは周知のことと思料します。
・ところがです。 現時点では 非アクティブ化であっても 列車カメラ指定箇所では素直に当該センサーの指示に従う状況となりました。
・このことは 非アクティブ対象編成の列車カメラを作用させたくない場合でも 自動的に作用してしまうことを意味します。
〔当方は 従前からの『センサー』を使用しているのですが 推察するところでは 自動センサーの仕様強化 または 地上カメラの仕様変更 に伴うものではなかろうかと思料しています。〕
●それで 試行錯誤の末に 自動センサーの仕様表記のうちの《 stat 》を『センサー』によって 編成に付与する措置をしてみましたところ やっとのことで事象の解消ができました。
・が 一時は 関わりのあるレイアウトが使用できなくなった と落胆したものです。

~ 以上です ~

〔H26.08.19〕 #22・不確かな裏話

●裏付けとなるデータはないのですが 作成の結果から転車台に関して推測されることです。
●まずは 作品の仕様などです。
・作品名:〔93〕じゅんばんにね《キⅡ》29
・レイアウトサイズ:5500 × 5500 
・ファイルサイズ:2587 KB
・使用車両数:3両(+石炭車) /転車台:1基/走行形態:単機
●制作の概要と結果です。
・当該サイズなどからでは メモリーに負担のかかる規模ではないはずです。
・しかしながら センサーの作動が不全となる現象を生ずる結果となりました。
・この現象とは わずかな車両数であるにも拘わらず 編成の認識と制動/ポイント開閉 を掌るセンサー数が制限されることになったのです。
・なお 上記以外の作動にはセンサー数は制限されません。
・レイアウトの構成上から 走行のシンガリである第3両目を停止させる必要があるのですが 編成の条件分岐が不可能となり停止措置ができない状況に陥ったのです。
・このため 当該編成の停止は 苦肉の策で 追突防止機能を利用することとしたのです。
・『上記以外の・・・』との表記は 当該編成の前照灯消灯などが可能であることからです。
●結論です。
・レイアウトの構成上から転車台作動に少々複雑な設定をしているため VRAM が関与したものではないかと憶測しております。

〔H29.03.11〕 #23・ re. Tehachapi Loop

・第10トンネルバイパス竣工後の状況を模倣してみました。
・画面構成や制作の意図などを別途ご案内しております。
// → PDFを コチラ からご覧ください。
・ご視聴は → YouTube  〔但し タイトルは " (#19) new Tehachapi Loop "  です。〕

お問い合わせはこちら
ご覧いただく皆様に
・動く絵本作りに傾倒しています。
ご関心をお持ち戴いた映像の内容を お子様と一緒に変えてみませんか ! ?
・変えてみたい ご希望の内容 は 〔 お問い合わせはこちら 〕 から お知らせください。
・併せて 即興の詩文などもご案内いただければ幸いです。
・お差し支えありませんでしたら こ希望により改変した画像などを公開させて戴きます。