3D都市モデルは処理負荷軽減が重要。頂点数やLODを扱う工夫

モデルの中心点設定は難易度を下げるポイント

――スケールの調整はしましたか？

林：スケールは、ほぼ調整していません。TouchDesigner上で制御できるので、データの時点では、そこまで厳密に詰めなくてもよいかと思います。ただ中心の合わせはしています。今回は、このオフィスのビルの場所にカメラがぐいっと寄るのが決まっていたので、ここを原点に設定して、取り回ししやすいようにしています。

　PLATEAUのデータで最初にやるのは、位置合わせかもしれません。PLATEAUのデータは複数の区域を組み合わせられるようにできているので、必ずしも開いたデータが中央あるとは限りません。ですからまずはBlenderで中央だけ合わせると、それだけで難易度がだいぶ下がるのではないかという気がします。

――このOPEN HUB VisualizerのSmarty Cityの案件では、完成するまでに、どのぐらいかかりましたか？

林：3ヶ月弱ぐらいでしょうか。ご相談いただいたのが11月ぐらいです。最初はプロトタイプを作ったりして、ビジュアライザーが現地で稼働したのが2月頭ぐらいでした。

PLATEAUは簡単。表示だけなら1日でできた

――続いては、AMCIの案件についてお尋ねします。この案件が、PLATEAUの初経験だったと聞きましたが、そのとき使ってみていかかでしたか？

林：とても重いと聞いていたので、どうしようとか思っていました。実際、最初にLOD2のデータを開いたときは重くて、まずいなと思ったのですが、メッシュを結合したらだいぶ軽くなりました。さらに頂点数の削減など軽くする手法もあるなと感じて調べていき、その検証が済んだ後は、比較的気が楽に進められました。

――地図を画面に表示できるまでにどのくらいかかりましたか。

林：触った初日には表示できていたと思います。とはいっても、少しはまったんですよ。Three.jsでLOD1のファイルを直接開いたら何も出なくて。

　わからないなと思ってBlenderで開いて確認したら、オブジェクトがとても遠くの座標にありました。そこでBlenderで座標を調整して、それを読み込んだら、うまく表示されました。ここにだけ注意すれば、使いやすいなと思いました。

［補足］　PLATEAUのデータを3Dソフトで扱う場合は、一般に、平面直角座標系に変換する。平面直角座標系では全国19の原点が定義されており、地域によっては原点と対象オブジェクトが遠く離れていることがある（https://www.gsi.go.jp/sokuchikijun/jpc.html）。

――AMCIは、どのぐらいの期間で完成しましたか？

林：スケジュール自体は、3カ月ぐらいで作ったような気がします。ただ、最初の1カ月で動かすところぐらいまでできて、それからあとは、それぞれのコンテンツや、まちの活動量として表示する参加者の総歩数や獲得ポイントをどうやって合わせかという話を、関係者と進めて作り上げました。

――ACMIでは、PLATEAUをどのようなデータ形式で扱っているのでしょうか？

林：glTF形式です。テクスチャなどの画像を内部で持ってくれるので、取り回しがすごくしやすいですね。OBJ形式なども検証しましたが、glTFが一番軽かったです。Blenderには、glTF Exporterがあり、それを使えば、一発で書き出せます。

Blenderで、1つ1つのオブジェクトを個別に扱えるようにタグ付け

――ACMIの案件でも、処理を軽くするために、LOD1とLOD2を効果的に混ぜて使っているのでしょうか。

林：大丸有エリアのみがLOD2です。PLATEAUのLOD2データと大丸有エリアマップをBlender上に重ねて、重なったところだけを残すように削ることで、大丸有エリアのみのLOD2のモデルを、まず作りました。

　そこにLOD1のモデルを重ねました。そうすると、大丸有エリアはLOD2とLOD1が重なるので、その重なった部分のLOD1を削ることで、大丸有エリアはLOD2、それ以外はLOD1というモデルを作りました。

　今回は演出上、ビルごとに色を変えたり、動かしたりする必要があり、Trree.jsでは、ビルを個別に読み込む必要がありました。そこでBlender上でビルごとにメッシュをまとめて、全部名前を付けていきました。

――ビルがそれぞれ一個ずつのオブジェクトになっているというわけでしょうか？

林：そうです。PLATEAUのデータは、そういうふうにはなっていなかったと思うので、今回はそれを手動でまとめました。結構な量がありますが、大丸有エリアに関しては、せいぜい数十個なので、手作業でもできたという感じです。

［補足］　FME Desktopなどの変換ツールを使うと、条件に合致するものだけをPLATEAUのデータから抜き出したり統合したりすることもできる。特定の部分だけをLOD2、それ以外をLOD1というようなマージしたデータの生成も可能。数が多い場合は、こうしたツールを使って自動化するとよい（https://github.com/Project-PLATEAU/Data-Conversion-Manual-for-3D-City-Model）。

　エリアごとの色分けなどもしないといけないので、そうした区分もモデル内で持っていなければなりません。今回は、メッシュ毎に名前を付けてそれらをJSONというデータ形式で管理することで、どのビルがどのエリアに属するかを区別できる構造にしてあります。そういう意味では、先のOPEN HUBの案件よりも、細かいデータ構造になっています。

　制作途中に、PLATEAUには存在しないビルが建ったというのもあり、それは手動で作りました。さすがに屋根の形状とかはわからなかったので、LOD1的な感じになっていましたけれども。

CPUとGPUをバランスよく使う

――Three.jsなどのWebでの表現において、処理を軽くして取り回ししやすくするコツを教えてください。

林：GPUをいかに効率よく使えるかです。街のglTFデータを読み込んで、パーティクルなどを動かして、ビルもアニメーションをさせて……とやっていくと、あっと言う間にCPUが高負荷な状態になってしまいます。ですので、パーティクルを動かす計算処理などGPUで行えることはGPUで行って、CPUだけに負荷が偏らないようにするのが良いと思います。

――それはThree.jsの中で制御するのですか？

林：そうです。ここはGPU側で、ここはCPU側というように、そこまできれいに分かれてはいませんが、こういう書き方をするとGPUで処理されるというのがあります。

　GPUはかなり使っています。たとえば、少し込み入った話になりますが、全部の座標計算をCPUでやってしまうと、CPUは一個一個処理するんですよ。なので、100個あったら、1、2、3、4、5、6、7、8、9、10と直列で処理される。それに対してGPUの場合は、0～100が並列で処理されるので、大量のものを動かすような処理は、GPUでやったほうがエコです。Three.jsを使ううえでの処理負荷のポイントかと思います。