Three.js Cannon.es 調査資料 - マップ分割（３）３Ｄデータ
この記事のスナップショット
- ビーナスラインーセクション1：大門峠～霧ヶ峰（分割版）(028_venusS1.html)
- シーサイドダブルレーン(028_mfg4.html)
- 芦ノ湖ＧＴ(028_mfg2.html)
シーサイドダブルレーンの折り返し地点から坂を上っての眺望
芦ノ湖の大鳥居を模したもの（ｗ）を眺めて
ソース
動かし方
- ソース一式を WEB サーバ上に配置してください
- 車の操作法
- カーソル上 .. アクセル
- カーソル下 .. バック
- カーソル左、カーソル右 .. ハンドル
- 'b' .. ブレーキ
- 'c' .. カメラ視点の変更
- 'r' .. 姿勢を戻す
- マウス操作 .. カメラ位置の変更
- '1' .. 車変更：FR低出力
- '2' .. 車変更：FR高出力
- '3' .. 車変更：FF低出力
- '4' .. 車変更：FF高出力
- '5' .. 車変更：4WD低出力
- '6' .. 車変更：4WD高出力
概要
どうにか大きなサイズの地図上を走らせたい！という一念で、マップの分割表示にチャレンジします。
今回は最終目標の、国土地理院の3Dデータを分割して表示することになります。
「ビーナスラインーセクション1：大門峠～霧ヶ峰」のマップ分割が上手くいったようなので、「静岡県熱海付近の海岸線」や「芦ノ湖の周回コース」にもチャレンジしました。
やったこと
「ビーナスラインーセクション1：大門峠～霧ヶ峰」の地図（一枚絵）は 7640x7640[pixel]、標高データは 956x956もあります。これを適当なサイズ（画像は 2000x2000[pixel]、標高データは 251x251）をブロックとする単位で分割します。全体で 2行4列のブロックになります。常に表示するブロックは 3x3 とします。足りない分／端での処理は、周期的境界として反対側のブロックを流用します。
一方で、githubに格納するにあたり、テクスチャ（png）と標高データ（csv）のサイズが問題になりました。画像はjpgに（品質60）に落としてサイズを削減してます。標高データは float32のバイナリデータ化してます。（こちらは次の記事で紹介）
実行
前回と比べ、テクスチャと標高データが大きくなったことで、マップの切り替えが重くなってます。
それでも自分のマシンなら一秒かからない感じなので許容範囲かなと思ってます。
ネットワークの状況やマシンスペックによってはつらいものがあるかもしれません。申し訳ないです。
マップ切り替え時以外で、一枚絵の時と比べてもそんなにそん色なく、ひどく劣化した感じはしないので、これならビーナスライン全コースも視野に入りそうです。
ビーナスラインのセクション１のあと調子に乗って、静岡県熱海付近の海岸線（シーサイドダブルレーン）や芦ノ湖の周回コース（芦ノ湖ＧＴ）のコースを作成してみました。
雑感／検討課題は以下のとおり。
- マップ切り替えが重い
- 当初、画像は png 、標高データはテキスト（csv）だったのでやや重かったのですが、jpgとバイナリに変えて少しは軽くなりました。それでも「コマ落ち？」っていうくらい静止してます。
- 一番良いのはメモリ上でキャッシュ化すれば良いのですがそこまでスキルが達しておらず。
- 思い切って、ブロックサイズを小さくすると良いのかも？！
- ブロックサイズの決め方がよくわからない
- ブロックを大きくするとマップの切り替えが少なくなる一方で使用メモリが増え、切り替えも重くなります。
- 逆に小さくすると切り替えは軽くなると期待できますが、頻度が多くなります。
- 正直、ブロックサイズの決め方は適当です。
- ブロックの境界位置が問題
- 芦ノ湖のコースでは境界位置が上手く定まらずに、更新が頻発する区間があります。
- コースとブロックの矩形が交差する回数を少なくなるよう決められたら良いのですが。何なんでしょうね、この最適化問題。
Discussion