VRMレイアウトサイズは実際問題どこまでOKなのかの考察
（注：この記事はTwitterでつぶやいたことをリライトしたものです）
ビューわかしお氏が「VRMで日本を再現できるか検証してみた！」という記事をUPされています。とても興味深いです。
たしかに、日本列島並み（あるいは、地球並み）の広大なレイアウトを作りたいというのは一つのVRM愛好家の夢といえますね。（実際には、そんなデカいレイアウトを作る手間がイヤですけどｗ）
ところで、コンピューター上の「数」の扱いは
- 数は10進法ではなく2進法で取り扱われる
- 整数と小数（実数）は厳密に区別される
- 整数は「整数型」、小数は「浮動小数点数型」という型の中で表記され、てきとうな有限の値しか取ることが出来ない
という事情があるので、「桁が増えて処理が出来なくなった」という予想は正しいですが、レイアウター上に置いてあるもの（部品や細かいポリゴンも含め）の座標を整数で取り扱うのはムリなので、「整数で10桁くらいの計算ができた」からといって、「幅が1010ミリくらいまでのレイアウトは作れる」わけではないのです。
（惜しいところでしたが、数理的アプローチで検証しようという視点は、感情論・理想論のみの議論よりもはるかに価値があります。）
では、現実問題として、VRMレイアウトの幅の上限はなんぼのもんなのでしょうか。いま現状の5万ミリという数字の周辺を考察してみます。
（人によってはつまらない話題が始まるので、画像の出て来るあたりまで読み飛ばすべし。）
さきほど申し上げたように、部品やポリゴンの座標は浮動小数点数で扱われています。VRMでは、32bitの浮動小数点数のようです。32bitということは、0か1を32個並べて表現できる程度の種類の数しか表すことが出来ません。
変数の型の話はここでは踏み込みません。Wikipediaの記事でも参照して頂くことにして、ざっくばらんに言うと、コンピューターにはどんな数でも上から何桁かしか表現できない（ある程度以下は切り捨てかよくて四捨五入される）という現実があります。
どんなスーパーコンピューターでも、上の方から高々有限の桁しか認識することが出来ません。
ちなみに上から何桁、というのは有効数字の話と同じで、
12345
も5桁ですし、
123.45
も
0.12345
も5桁、というふうにここでは言っています。
32bit浮動小数点数は、仮数部が23ビットということで、
2進数にして上から23桁
10進数にして高々7桁の途中までしか扱うことができないのです。
6桁の999999は確実に扱えますが、7桁の9999999は怪しくなります。つまり、9999.995と9999.996の差はコンピューターには分からないのです。
Nゲージレイアウト上のものの座標を扱っている以上、0.01ミリくらいの精度をなんとか保証したいとすると、整数部分4桁+小数部分2桁ならOK、整数部分5桁+小数部分2桁だとちょっと精度が怪しい、というお話になってきます。
ということで、MAX=50,000ミリというのは、まあまあ妥当なところではないか、という風に言うことができると思います。
万のオーダーでも、計算のたびに誤差が蓄積される可能性があるので、小数第2位はまあ怪しい、と思っていただいていいでしょう。
さて、この「計算精度」や「計算誤差」を体感する方法があります。
画像のようなテストコースを引いてみてください。これを、めいいっぱい横に長い(50,000 x 8,000mm)のレイアウトのx=0付近とx=50,000付近に2つ設置し、車両を走行させて比べてみてください。車両は、できるだけ精密なやつをおすすめします。
そうすると、x=50,000付近のコースでは、ナナメになっている直線区間で、画面がわずかながらブルブル震えるのが観察できると思います。このブルブルが「精度が落ちている」「誤差が乗っている」部分になります。
大した手間にはならないと思うので、ぜひご自身のお手元でご確認ください。
例えば、幅の上限値を5万の2倍の10万にしたとすると、2進数にしてもう一桁精度が落ちることになります。見てみないことには分かりませんが、実用上あまり見るに堪えられる感じではない（3D酔いを引き起こす？）のではないか、というのが私の考えです。
・‥…━━━☆・‥…━━━☆・‥…━━━☆
精度の問題で「幅5万ミリが妥当なところ」と申しましたが、コレ、実物に換算すると7.5kmです。山手線も入らないっちゅーところがなかなか悲しいところです。
ちなみに。
「フレキシブルレールをコピペすると、アームがわずかにズレる」という症状を聞いたことがあります。
おそらく、座標のオーダーの大きいところへコピーしたりしたため、アーム座標の精度が落っこちた、ということなのではないかと推測します。基本的に落っこちた精度を復元するのはムリなので、レイアウターやビュワーの高速動作やなんかの兼ね合いを考えると、仕方のない仕様かなと思います。
| 固定リンク
「VRM:研究」カテゴリの記事
- VRMNXの時間系イベントが使いにくいなあと思っているアナタへ(2019.12.24)
- [VRMNX] フレーム同期の話(2019.07.18)
- [Python] リスト型をベクトルに見立てて計算したい(2019.06.16)
- VRMNXのレイヤーベース地形を使ってみよう（前編）(2019.05.18)
- [VRMNX]自動踏切モジュール(2019.01.25)
この記事へのコメントは終了しました。
コメント
double(64bit浮動小数点数)型にしてもらえば、倍以上に範囲が伸びますよｗ
（floatで8,388,608がdoubleなら4,503,599,627,370,496ですから、少数点下2桁とっても13桁は確実にとれます）
SSE2命令を使って、なんとかならないものですかね(^^;
ただ、CPUに演算回路が組み込まれてる浮動小数点は、符号が必ずついてるはずなので、
X=50,000がいけるなら、X=-50,000もいけるのでは？
それなら、倍の幅がとれます（面積なら4倍）
VRMは4までしかやったことないので、最近のVRMは知らないですが、-の値は取れないですか？
ただ、そうは言っても実は2進数なので、浮動小数点だと10進数の0.1が表せれないんですけどねｗ
（どうやっても誤差が入る）
どうせ、オブジェクトの位置は固定小数点しか取らないので、
小数点2桁なら100倍して、
32bitか64bitの整数値(int32やint64）で取れないものですかね？（いわゆる固定小数点の様に）
そうすれば、31bitや63bit分すべて有効桁数で使えます
実際にレンダリングする際に、車両の各部品の座標をそのまま演算したいから浮動小数点といっても、
X=50,000の位置の車両の各部品の座標は取れない
（レイアウト座標X=0なら、
車両のポリゴン位置X=0.0001の所にライトして表示されますが
レイアウト座標X=50,000の位置の車両だと
X=0.0001の所のライトは、レイアウト座標X=50,000.0001だなと思っても、この値は50,000.01に丸められて正しい位置にライトを表示出来ない）
のですから、
実際にレンダリングでポリゴン表示する際には、
カメラから見える相対位置で車両とかのオブジェクトの位置を計算した後、
その値を元に各ポリゴンの座標を計算しているはずですので、
レイアウトに配置する部品（オブジェクトの座標）は浮動小数点である必要性は全くないと思うのですが(^^;
（実際、金融関係のお金の計算では、誤差が発生する浮動小数点は使わない）
投稿: ku- | 2016年10月26日 (水) 21時51分
ku-さんこんばんは。
＞CPUに演算回路が組み込まれてる浮動小数点は、符号が必ずついてるはずなので、
X=50,000がいけるなら、X=-50,000もいけるのでは？
それなら、倍の幅がとれます（面積なら4倍）
たしかにそのとおりですね！部品自体もマイナスの座標は取れるので、やってできないことはなさそうです。
面積の話をするとここはメモリ制約との兼ね合いになってくると考えています。
（MAX20,000時代でも、例外的ですが「内海市」のような激重レイアウトが存在したので・・・）
http://www.imagic.co.jp/devblog/2014/08/07/%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%82%BF5-1-0-157%E5%85%AC%E9%96%8B/
I.MAGIC Blogのこの記事
「走行情報を従来のn倍精度に引き上げました。（モバイル版は単精度です。）」
あたりから察することもできるように、一部演算は64bitになっている模様です。（たぶん、CPUがやっている）
ぜんぶが倍精度になったら（メモリ制約を忘れれば）レイアウトサイズは格段に大きく出来るようになるでしょうが、まだまだふつうのGPUのことを考えると、（64bitにはすこぶる弱いらしい）難しいのかなあなんて思います。
固定小数点のお話も魅力的です。やるとしたらCPUになるのでしょうかね？
（コンピュータアーキテクチャと実装上の実際の話になると、私じゃよくわかりません（汗）
投稿: AKAGI | 2016年10月27日 (木) 00時42分