ココログでもMarkdown機能を使ってブログを書くことができるらしいので，それのテストです。

Markdownとは

簡略な記号などを使って，見出しや*emphasize*，strongなどを簡単に記述できます。HTMLを直打ちするよりはるかに簡単です。

見出しの付け方

見出しとなる行のすぐ次の行に，===== を入れるとH1見出しに，-----を入れるとH2見出しになります。#を使う書き方もあります。

プログラム

```Python import this

The Zen of Python.

```

以上がMarkdownでの本来のコードの貼り方ですが，ココログはこれに対応していないらしい。

import this
# The Zen of Python.

ハイライトまでされたら天才的なのですが・・・

ちなみに，現在は`<pre class="vrmscript">'でコードを貼っています。これはHTML直打ちが必要なのと，ココログが改行を処理するときにバグがあり修正に非常に手間がかかる場合があります。

import this
# The Zen of Python.

はてなブログなど別のブログサービスへの引っ越しも検討中です。

実はそんな人いない説

はともかく。

まずはバージョン5以前の時間系イベントとVRMNXpyの時間系イベントの仕様の相違について，Afterイベントを例に見てみましょう。

バージョン5以前のイベントは，

//イベントを設定
SetEventAfter Target Method EventID Interval
// Target: 対象オブジェクト
// Method: 対象オブジェクトのメソッド
// EventID: イベントIDを受け取るグローバル変数（のポインタ）
// Interval: 時間間隔(ms)

BeginFunc Method
    // Intervalミリ秒後に実行する制御の中身
EndFunc

という仕様でした。一方でVRMNXpyでは

#イベントを設定
evid = target.SetEventAfter(Interval)
# target: 対象オブジェクト
# interval: 時間間隔(s)
# (返り値) evid: イベントID

#指定時間経過すると対象オブジェクトのイベントハンドラが呼び出される
def vrmevent_xx(obj,ev,param):
    if ev=='after':
        # Afterイベントが起きたときの制御の中身

聡明な読者諸兄には自明なことかと思いますが，VRMNXpyのイベントは，どのイベントIDであってもとりあえず同じコードを走らせてしまうという仕様になっています。イベントハンドラの中に様々な処理をベタ書きしているといつかバグの温床となるでしょう。

VRMアンケート分析シリーズ第2弾です。

第1弾の最後に，「アンケートにヘビーユーザーばかり集まってしまった」と書きました。もちろん，ビョーキヘビーユーザーのみなさんがオフ会やこういうアンケートみたいなキャンペーンに参加してくれるのは嬉しいことです。が，ビギナーからビョーキまでを含むVRMユーザーの全体像をVRMアンケートでサンプルすることにはどうやら失敗したのだ，という結論に（自分の中では）なりました。

本稿では，アンケートが結果的にヘビーユーザーホイホイとなってしまった実体を説明します。その後稿を改めて，その原因系についても考察したいと思います。

NX世代の新製品が続々…でもありませんが，徐々に出ている今日このごろです。

しかしラインナップを見ると200系新幹線（国鉄），205系山手線（国鉄），キハ58系（国鉄），クモヤ（国鉄），113系（国鉄）…と，
やたら国鉄が続いている状況です。

アイマジックの向かっている方向は国鉄…？

しかしアンケートを見ると，この傾向もあながち間違ってはおらず，VRM購買層の趣向に沿っているのではないか，と言うことができそうです。

（※オフ会参加の方へ：　集計のミスとかを修正したバージョンでお送りします）

九州オフの開催から１週間が経ちました。

会の最中での感想。

みんな，電車好きだなぁ～

自分も相当かと思いますが笑

超がつくヘビーユーザーが集まってしまいましたが，みなさんそれぞれ，個性あるコダワリというか，他の人にはなかなかマネできないVRMでの得意分野をお持ちだったのが印象的です。2015オフのときよりも，自作車両や，バージョン5システムの使い倒し方のノウハウが成長・成熟していると思いました。

こういうオフ会の場で技術交換といいますか，マネするきっかけが生まれるのはいいことですね。実際，今週のVRM界隈はTwitterを中心に盛り上がっていました。

このブログでも，VRMアンケートのまとめを順次発信していきます。

サンライズ，予約取れず。

発売日当日に買わなかった自分が悪いけど（笑）つーことで，Plan Bはこれから考えます。

VRMアンケートは，33名のかたにご回答いただきました。ありがとうございます。

細かい内容は，オフ会当日に報告いたしますが，「VRMで遊ぶ頻度」と「使っているVRMのバージョン」の集計だけ載せておきます。

3時の方向から時計回りに見る円グラフになっています。ごらんのように，VRMで遊ぶのが月に1～2回未満の方からも25％の回答をいただきました。

9月頭に締め切った時点では，VRM NXのシェアはまだまだ低く，第5世代が根強く使われていることが分かります。なお非VRMユーザーからの回答は，ちょっとは期待していたのですがありませんでした。

自作車両の第2弾にむけて，札幌圏で旅行を兼ねて取材をしてきました。

今回は，形式図やネットの写真で施工可能な場所をできるだけ進めたうえで，よくわからない部分を調べに行くという感じでした。

遠方なので，できる限り効率的に。あらかじめGoogleの航空写真などで屋上や左右サイドを撮れそうなポイントを把握しておき，数が少ないキハ201系の運用と突き合わせて撮影ポイントを転々とします。止まっていてくれた方がさまざまな角度でゆっくり撮れるので駅が中心ですが陸橋なども重要です。

床下機器や屋上機器がよく見える写真はネット上では得にくいので，自分の足で撮りに行くしかありません。

107系に続き，VRM自作車両の第2弾に着手しました。電車＆気動車のセットで仕上げるつもりです。

107系よりもかなり造形が複雑です。かなりいいデザインなのですが，衝撃に強いという機能的にも優れているらしいです。

先日リリースした自作車両の107系であるが，足掛けX年の歳月がかかったものの，さまざまな自作車両製作上のノウハウが得られたという点では時間を掛けた甲斐があったかなと，今となっては思っている。

対象車両の選定について

この自作車両の初回作のプロジェクトは，VRM Cloudのかなり初期から自分の中では存在していた。当初，複数の候補があったのだ（701系や，新潟トランシス製の気動車など）が，直流電車であること，クハとクモハの2車種だけであること，比較的地元の近くを走っていることから107系に決定した。

自作車両で作ってみたいなと思う車両は当然いくつもあるのだが，やはり圧倒的に電車がそのなかで多いことを考えるとパンタグラフ工程をいつかは克服せねばならないので，はじめから甘んじずに，気動車ではなく電車を選ぶこととなった。701系は残念ながら交流電車＝パンタまわりが直流車より相当複雑なので候補から外れることになった。また，701系は製造時期による形態差がどうやら107系より多い（のではないか）ということでも敬遠の原因になった。

製作上のテーマや制約について

モデルの仕様は，はじめから「車内なし　ライト・パンタは動作あり」で考えていた。またポリゴン数のおおまかな目標として，1両5000ポリゴンを目標とした。VRM2最後期のEF58 (1号編成)が1両2000ポリゴンレベルのモデルであったことをベースに，PC性能の進化と，色の塗り分けをテクスチャリングではなくポリゴンの分割でやることを前提に2倍強に盛った。が，公式よりも少ないであろう水準に抑えた。（公式の車両は1両あたりだいたい1万～2万じゃないかと想像している。肌感覚的に。）

おそらく，I.MAGICの中の人は，製品の品質保証という意味で，本格的なゲーミングマシンじゃなくてもまあまあ動いてくれるように腐心されている。ビュワーのプログラム本体もそうだが，当然モデルもローポリゴンなモデルを相当意識されていて，ビュワーの高速動作を実現している（のだと私は感じている）。

そういうI.MAGICの，良く言えばLEAN（無駄のない），悪く言えばケチな，そういう設計思想を尊敬している部分があるので，このプロジェクトの絶対的な制約として「I.MAGICを超えるものは作らない」ということを，内心に標榜した。そういう5000ポリゴン縛りである。（で，結果的にだいたいそのくらいのポリゴン数に収まった。ちょっと溢れたけど1万にはいっていない。）

使用できるテクスチャサイズに512x256というかなりシビアな制約が課されていて，これだけはどうにも動かすことができない。対して，フリーの3D鉄道ゲームで，車両の自作が可能なものがいくつかあって，見目麗しくて羨ましくなることもあるのだが，そういうものはローポリゴンを標榜していても，使用するUVテクスチャがものすごい大きさだったりして，ビデオメモリを圧迫するのが目に見えているようなものもある。

大きなレイアウトサイズと高速な動作というVRMの長所を脅かさないよう，ローテクスチャだからといってポリゴン化に甘んじない，そういうライバル心むき出しの実装方針を打ち立てたのである。

みんな気づいてるとは思うけど，誰も取り上げてくれないVRMNXの画期的な仕様が2点あるので，ここに書き留めておこうと思う。

ひとつめは，ビュワー起動時に車両のない「空の編成」がエラーとならなくなったこと。

ふたつめは，Pythonが元来持っている，（ときに過剰とも言われる）エラーチェックの数々である。

この絶妙なエラー処理のバランスによって，部品欠損に対する頑健性がかなりアップしている。もちろん「なんの不都合も起き得ない」わけではないだろうが，他人のレイアウトファイルをダウンロードして入手したときにかなり深刻な部品不足があっても，なんとかビュワーを起動してレイアウトの雰囲気を味わうところまでは多くのユーザーがたどり着くことができるだろう，という話だ。