現実を3DCGのバーチャル空間で再現し、産業の世界で活用する「デジタルツイン」。主にゲーム産業で培われてきたリアルタイムCG技術を活用した、遠隔地でのコミュニケーションや計測、そして自動車やロボットの自動運転、さらにはスマートシティの開発など、多彩な目的での活用に注目が集まる。本連載は「言葉はよく耳にするけれど、具体的に何を指すのかちょっとピンと来ない」そんなあなたに送る。

第3回となる今回は、PLATEAUのような3D都市データを活用した日本全国における普遍的な街並みを再現していくための取り組みや、その街並みに必要となる動的アセットづくり、さらに発展させて街中の個別建物の再現にいたるまで、具体的で盛りだくさんな内容でお届けしていく。

プロシージャル的なアプローチで汎用データをクオリティアップ

CGWORLD（以下、CGW）：連載の第1回に続いてシリコンスタジオの神鳥さんにご登場いただき、3D都市データの活用方法とその実践的なソリューションについて、お話しいただきます。これ、いきなりすごいクオリティの動画ですね（笑）。

神鳥泰章氏（以下、神鳥）：ありがとうございます。この動画は自動車の走行シミュレーション用として街を構築したもので、Unreal Engine 5でリアルタイム表示できるシーンデータになっています。自分が走らせるクルマ以外にも、生きている街の表現として、走り回るほかのクルマや人、自転車をゲームのNPCのようにパターン制御しながら動くかたちで配置してあります。見た目のフィーリングとして違和感がないところまでやっときたかな、と感じているところです。

CGW：ではそのあたりは後で詳しくお聞きするとして、まずはここに至るまでの背景として、代表的な3D都市データである「Project PLATEAU」の現状や課題認識からお聞きできればなと思います。


神鳥：はい、PLATEAUはそもそも日本全国において3D都市モデルの整備・活用を目指したオープンデータ化プロジェクトで、国土交通省が主導しているものになります。2022年時で約130都市をカバーしており、LOD（Level of Detail)レベルも1～4までの4段階が定義されています。LOD 2レベルからテクスチャ付きのモデルとなっており、われわれのようなビジュアル的な活用を考える立場においては、実用性が高まるのはこのあたりからかなと思われます。

これらデータの活用法としては、ドローンの配送シミュレーションであったり、気温や風の流れのシミュレーションであったりと、様々な分野で期待されているプロジェクトではありますね。しかしながら現状においては、われわれのようなビジュアライゼーションが主眼のプロジェクトで活用していこう、となるとまだまだ課題が多くあります。

CGW：具体的にはどういった課題があるのでしょうか。

神鳥：まず何より、まだ発展途上のプロジェクトということです。データの精度としてもLOD 2以上のエリアは非常に限定的であり、ほとんどがLOD 1の領域になっています。これはどういう状態かというと、まずテクスチャが存在していません。名古屋市内中心部、渋谷のスクランブル交差点付近といったところはLOD 2なので色付きで表示できますが、それ以外は結構な都市部でもLOD 1で白い建物のモデルのみになっており、街並みの凹凸のみがわかる程度のデータです。それでも風の流れのシミュレーションのような用途であれば問題ないのかもしれませんが、われわれのようなビジュアライゼーションを目的として使うには、明らかにデータが不足しています。

神鳥：では、「テクスチャがあるLOD 2エリアについては、そのままリアルタイムCG空間にポンと置けば使えるのか？」と言われれば、それも難しい。非常に重いデータになっているのでそのままではフレームレートが出ませんし、テクスチャがあったとしてもクルマ目線やドローン目線で街の中に入って見る想定としては、品質的に足りていません。また、街を街たらしめる細部の部品、標識や信号、樹木、街を歩く人やクルマなども存在していないので、プロジェクトの目的に合わせて、LOD 2以上の領域であってもデータの最適化と必要アセットの追加が不可欠と言えます。

CGW：やはり現状、あくまで基礎的というか汎用的なデータであって、デジタルツイン案件への実用にあたっては詳細度が足りないし、処理的にも重いというわけですね。

神鳥：おっしゃるとおりです。現状においてはこうしたPLATEAUのような汎用的なデータを実用化するために、過不足を補完する様々なしくみが必要となってきます。これが、「データがあるならとりあえずデジタルツイン始めてみようかな？」というとき、まず「おや？」となってしまうポイントと言えるでしょう。

そこでまずわれわれが行なっている取り組みの一例を紹介しますと、プロシージャル的にLOD 1モデルしかない領域をよりリッチなビジュアルにアップデートする、というものがあります。PLATEAUに存在する白い建物が並んだ状態をもとに、それぞれのエリアや高さ、幅などの基礎情報から「扉」や「窓」を自動生成した上で、航空写真を参照して地図上の色を取得し、色テーブルで当てはめる。メッシュをいじるのではなくテクスチャとして自動生成して追加しているので、これならLOD 2領域との親和性も高い状態を維持できます。

• 

• 

• 

• 

• 

• 

CGW：これだけでも、視覚的に訴えるものはまるで変わりますね。しかも人手を介さずシステマティックに処理できていると。

神鳥：これで足りるかどうかは用途によりますが、例えば街を飛び回るドローンのデモといった、地面の情報があまり必要なく、近景も不要という場合にはこれだけで必要十分となることもあります。プロシージャルの扱いとしては、Blenderのジオメトリノードでロジックを組んでいます。

CGW：PLATEAUのような汎用データは基本的に“重い”という話もありました。そのあたりの対処はどうされているのでしょうか。


神鳥：もちろん重い・軽いの感覚は用途によるので、あくまで「リアルタイム処理に使うとしては重い」ということです。この場合はLOD 2領域についてなのですが、特にそのままではテクスチャの容量が大きくて非常に不向きなんですね。快適なフレームレートで動かすには、処理を最適化する必要があります。メッシュや画像の最適化、描画エリアの分割読み込み、LOD処理、メモリ解放……etc。3Dゲームのリアルタイム表現と同じアプローチが必要になる、と言えばわかりやすいのではないでしょうか。

より具体的には、Cesium等を使って建物データの読込・表示を軽くする、白飛びしているテクスチャを色補正する、といった処理も必要になります。また、ビジュアルの品質以前の問題として、座標系も合わせなければいけません。“地球は丸い”ので、平面座標系であるゲームエンジンで現実世界のデータを活用するには、位置合わせのためのスクリプトを用意する必要があります。

CGW：それは確かに！　結構ズレてしまうんですか？

神鳥：数キロメートル進むとすると、道路が宙に浮くくらいにはズレますね。こうした細かなことにも対応しつつ、まずシステマティックに自動生成できるところから見た目を整えて、情報を足していっています。ここまでが、PLATEAUのような汎用データを基にしたビジュアルアップデートの第一段階といったところでしょうか。ただここまでの品質だけでは、人の目線位置から見たときにはまだまだ情報が足りません。次のステップを踏んで、より実写に近づけていくことになります。

複数の情報ソースを組み合わせて、より高品質なビジュアルを自動生成

CGW：汎用の3D都市データを人の目線から見た場合の品質として向上させるということですが、これはどのような用途を想定したものになるのでしょう？

神鳥：われわれが実際に行なっているのが「自動車の走行シミュレーション」への活用です。当社ではエンジニアのほか3Dデザイナーも在籍しているので、当然こうした案件では都度新規でアセット制作を行うことも多いのですが、それにしても工数的にも時間的にも、毎回すべて手作業でつくり込むというわけにはいきません。

そのため、街の構築に必要なアセットは一定量事前準備を進めておく、ロジックで自動配置したり品質調整したりできるしくみを構築する、といったことを進めてきています。これによって、お客さんに相談されてすぐ「こういうことですか？」とビジュアルで返せるようになりますし、当社としても案件ごとの制作負担も下がります。

神鳥：今までもやってきていることですが、これらはあくまで“仮想の街”として構築しているものでした。それが昨今では、現実世界の「この街でやりたい」というニーズが高まってきているため、3D都市データを参照しつつ自動生成を行いながら、自動車の走行シミュレーションに足るビジュアル品質まで上げる必要があります。

CGW：それを突き詰めていって、現状ここまでできますよ、というのが冒頭のこの動画になるわけですね。

神鳥：はい。しかも街の再現規模としても、200メートル四方程度ではなく、1キロメートル四方のエリアというようにスケールが大きくなってきました。こうなってくると、手動でアセットを並べていくのは現実的ではありません。システムとして、どうやってデザイナーの制作負荷を下げていくのかが重要になってきます。ただ、最終的にデザイナーの感覚を頼りにする、手をかける、ということは絶対に必要だとも考えており、しくみとアートのバランスをとりながらクオリティを上げていけるのが当社の強みなのかなと思っています。


CGW：確かにデジタルツインとしてこの動画レベルの品質を担保するには、システマティックな処理だけでは難しいでしょうし、デザイナーの手作業だけでは物理的に不可能なことは理解できます。こうした自動車走行シミュレーション案件の場合には、具体的にはどのような作業が行われていくのでしょうか。


神鳥：まず前提として、それに必須となる道路網の情報がPLATEAUには存在していない、というところから話がスタートします（笑）。3D都市データは、あくまで建物や地形の立体情報であって、信号や標識、車線情報といったものは含まれていないんです。管理の枠組みはあるのですが、実際にデータが入っていません。そのため、ナビのような情報をもっている会社さんと協力して、そういったものの緯度経度などの情報を補完していきます。また国土地理院から出ているデータや航空写真を参照することもあります。

そうしてLOD 2のテクスチャ情報だけでは埋めきれない、樹木の場所や歩道のエリア、標識、道路標示等の情報を取得し、3Dアセットやテクスチャを自動配置できるしくみを構築していきます。以下が、その追加だけを行なった比較映像になります。

CGW：これだけでも実在感というか、見せられている世界の納得度に大きな差がありますね。

神鳥：単純に情報を参照するだけでは、例えば信号などは宙に浮いた状態になったりしますし、道路のゼブラゾーンなどでも、どの向きにどう描かれているかまでは、いただいた情報だけでは参照できなかったりします。そういった不明瞭な点については、すごく正確ではないけれども見た目には違和感がなくなるように、というロジックをわれわれの方で構築して、例えば信号なら近接位置にポールがない場合は建てる、ゼブラゾーンなら場所に応じてこの向きならこの模様で描く、といった自動処理が行われるようになっています。

街路樹なども、複数種からランダムで配置してリピート感をなくす工夫をしています。こうしたロジックの積み重ねだけでも、〇〇に活用できそう、とイメージできる程度には、都市空間の再現ができるかと思います。

CGW：なるほど、こうしたしくみを構築しておくことで、「どの都市のどの場所でやりたい」と相談されたとき、スピード感をもってまずビジュアルを出せるようになるわけですね。

神鳥：もちろん、この動画の場合だと参照しているのがPLATEAUのLOD 2なので、よく見ると建物のテクスチャが粗い、といった課題はあります。参照元の建物データが粗い場合にどういうロジックを組めば納得感がある品質に上げられるか、といったことはまだ研究の余地があります。

また、都市に関しては入力するデータ情報、当社の用意するアセットとも比較的揃ってきていますが、これが地方都市や郊外となると、再現するアセットがまだ足りません。同じ店舗にしても広い駐車場付きで、都市にあるものとは別物であったり、バリエーション豊かな一軒家や広大な工場、田畑など、郊外の景観は都市部とはまったく異なってきますので、合わせてアセットを拡充制作していく必要性は感じています。

あとは、それを地図情報等と重ね合わせて、そこに何が建っているのか、学校なのか工場なのか店舗なのか判別し、それをもとにアセットを並べたり、またその幅や広さ、高さに応じてバリエーションを出したりするようなロジックも必要になるかなと思います。これらをニーズがあるエリアから進めていって、日本の3D都市データの入力さえ存在すれば、どこでもある程度の品質で街並みを再現できる、という技術をもっておくところまでは進めたいと考えています。

CGW：なるほど。そこを出発点として、まずプロジェクト起ち上げ時点ですぐ一定水準のビジュアルが出せるようにしておき、案件ごとの目的や用途に応じて、必要なら「ゲームエンジン3D地図アセット｜車両走行＆群集シミュレーション」のようなクオリティまで、3Dデザイナーも立てながら進めていく、ということですね。

動的アセットを配置してリアリティと実在感を生み出す

CGW：ところでこの走行動画においては、当然ですが街並みだけでなく人や自転車、ほかのクルマなども出てきていますよね。このあたりの動的なアセットについては、どのように組み込まれているのでしょうか？

神鳥：クルマというのは大前提として「人や自転車、ほかの動いているものと密接な関係にあり、かつ決して接触しない」というものなので、これらの存在は走行シミュレーションには必須です。かつ、人やクルマが動いていない街並みは廃墟に感じられますので、世界のリアリティを上げるためにも重要になります。ゲームの世界で言うところのNPCのような存在と思ってもらえばわかりやすいかもしれません。

具体的な挙動としては、例えばクルマの場合はChaos Vehicleというものを定義してあって、アクセルとブレーキとステアリングのパラメータを用意しておき、ドライバーは普通はアクセルを踏んで道路の左車線をこのように走る、信号が変わるとブレーキを踏んで止まる、右折ではステアリングを切って右折レーンに入り一時停止して対向車を見つつ曲がる、障害物が出てくれば急停止、といったようなロジックを組んでおいて、その法則にしたがって、道路上に設定されたスプライン上を動いています。なのでこれらについてはまさにゲーム的な動きというか、あえて厳密な再現までは行なっていません。

神鳥：厳密なカーシミュレータとして、エンジンの挙動や車体の制御まで求められる案件もなくはないですが、その場合はクライアントさん側のもつシステムと連動させて再現することになり、まったく別物の制御になります。いずれにしても、ベースのNPC制御としては、“それらしさ”が出ていればOKという、シンプルで処理の軽いものに抑えておいた方が取り回しが良いのです。なお、これらはUnreal Engineのブループリント制御になっています。

神鳥：人についてもクルマと同じようなロジックで動いていて、設定したパスに沿って進んだりしています。もちろん信号もきちんと見ていて、横断歩道を渡ったり止まったりもします。PLATEAUのデータには地形の高さの概念もあるので、歩行者もちゃんと地形に沿って動くようにもなっています。

CGW：こうした動的な要素が加わると、よりいっそう街らしさが増してきますね。

神鳥：もちろん単なるにぎやかしだけでなくて、ちゃんと当たり判定も取っていますし、大人や子ども、老人など属性ごとの挙動などバリエーションがあり、自動運転の機械学習のような用途になれば、こうした動的アセットはよりいっそう重要な役割を担うことになります。

神鳥：こうした動的アセット開発も最初は案件ベースで始まるものですが、こうやって普遍化できるところをきちんと進めて技術としてもっておき、必要なときにすぐ出せる、ということがこれからのデジタルツインには重要だと思っています。

またこれ以降の開発としては、都度スプラインを引いて人流をつくるのでは手がかかりすぎることもあり、エリア指定がなされればその範囲を人が動く、というようなロジックを構築していければと考えています。地図情報と道路網の情報が入力されると、人がいるべきエリアがある程度判明しますので、そこから人の手を介さなくても、ある程度自動でクルマや人の動きが構築できる、そういうところまではもっていくつもりです。

CGW：お話を聞いていると、NPCの存在などオープンワールドのゲーム開発に近いところがあるように思います。想定としては、どれくらいこうした動的アセットをシーン上に追加できるのでしょうか？

神鳥：リアリティラインをどこに置くか、稼働させるハードウェア（PC）の環境は何か、というところにも左右されるかと思いますが、つくる側としては人なら100人くらいが動き回っていても大丈夫なようには考えています。ただ、やみくもに追加してもいいことはなくて、この場合はクルマと同じで人の流れにも正確性は必要ありません。バランスをとりながら、リアルで実用性のあるデジタルツイン環境が構築できるのがベストです。

CGW：リアリティラインの設定という点においては、やはり案件ごとにクライアントさんの要望で決まっていくのでしょうか？　シリコンスタジオ側で決めることもありますか？

神鳥：それは両方で決まる、という回答になるかと思います。われわれの方で、クライアントさんの要望以上のビジュアル品質を目標として設定することもあります。ただ「どこにリアリティを求めるか」については、やはりニーズをもっているクライアント側で決まることが多いです。例えば、工事現場や工場などでの走行シミュレーションといった内容になれば、安全性にも関わるため、ビジュアル以上にそこにいる人の動きの正確性が強く求められたりします。逆にビジュアルの品質については、求められないのであれば一定以上をわれわれの方で担保するというかたちになります。

CGW：クライアントサイドで活用するハードウェア環境についての言及もありました。想定するスペックというのはあるのでしょうか？

神鳥：再生して少なくとも30fps以上は出ないとスムーズとは呼べませんので、中程度以上のGPUが入っているPCを想定しています。具体的にはGeForce RTX 4060程度が搭載された、世の中的には少しスペックが高いデスクトップPCというイメージでしょうか。そんなに特殊な環境が必要なわけではありません。

ただターゲット端末として、スマートフォンでの活用はまだ考えていません。そうなるとアプリ開発から始まって、サーバサイドレンダリングからの動画ストリーミング等までが必要になり、まったく別の開発アプローチが必要になります。とりあえずはローカル環境でのPC活用が主流、と考えています。

CGW：いろいろとありがとうございます。かなり具体的なところまで見えてきましたね。デジタルツインを始めるにあたってどんな準備が必要か、相談する側としてもだいぶイメージしやすくなってきたのではと思います。

自動生成と手動加工を組み合わせた固有ロケーションの再現

CGW：ここまで伺ってきたことは、建物や道路といった構造物にしても動的アセットにしても、街並み全体の再現に関わることでした。デジタルツイン案件としては、もっと個別に、例えばある一部の建物やエリアだけを細かく、建物の中まで再現したいといったこともありますか？

神鳥：はい、もちろんあります。ここまで紹介してきた内容は、主には自動車やドローン、ロボティクスといった製造業における活用イメージになります。デジタルツインは他の分野でも積極的に活用されていますので、例えば街並みの一部を切り取って詳細に再現するといった案件は、不動産業界や建設会社、また行政における都市開発などのサービス産業においてニーズがあります。例えば「この建物のこの場所にデジタルサイネージを置いたらどう見えるか？」とか、「構築物の内部への動線は問題ないか？」といったようなことですね。

CGW：建物レベルでの詳細な再現となると、例えばPLATEAUのような汎用的なデータでは対応できませんよね。

神鳥：ターゲットとなる建物の周囲の環境から再現することもあるので、一部においては使えることもあります。ただおっしゃられるように、特定のディテールの再現には、当然個別の対応が必要になります。具体的には、以下のように複数のプロセスにて撮影を行い、それをもとにフォトグラメトリー作成を行う流れになるかと思います。

[1]　レーザースキャナによる外観の撮影（3D点群データの取得）
点群データを取得することで、詳細な3Dデータを生成する

[2]　一眼レフカメラによる撮影（建物の形状、色情報の取得）
レーザースキャナの色情報だけでは弱い。死角となった部分の形状を補完する、テクスチャとして活用する、等の用途があり写真データは必要となる

[3]　ドローンによる上部からの撮影（建物形状、色情報の取得）
レーザースキャナや一眼レフだけでは上部からの情報が不足するため、ドローン撮影にて補完する

[4]　フォトグラメトリー作成
点群データと写真データを合成することでクオリティを向上させる

神鳥：しかし結局のところ、こうして撮影をして精密にデータを取得しても、そこからフォトグラメトリーでシステマティックに再現が完了するということはまずありえません。建物サイズの大きさがあり、かつ複数素材で構成される物体のフォトグラメトリーになると、いろいろと3D化にあたって不具合が発生するんです。例えば、庭木などの自然物がある場合。点群データを取っても樹木はノイズになるだけです。位置は正確に出ますが、形状の取得はほぼ不可能です。同じように、ガラス部分も素材として難しい。点群では、データが取れたり取れなかったりします。

また、写真撮影においても現実世界の写真は光の情報が付加された、つまりライティングがされた状態の色情報しか取れません。建物の撮影はとくに日光下の屋外で行われますし、それをデジタル空間上で展開するとなるとさらにライティングが施されることになる。これが特に、建物のフォトグラメトリーは相性が悪いと言われる所以だと思います。

CGW：アルベド情報だけがほしいですよね。

神鳥：逆算で光の情報を取り除くことができる、アルベドだけが撮れる360度カメラみたいなものはできないかな、とは思いますね（笑）。

CGW：そうしてフォトグラメトリー生成であっても、形状もテクスチャもデザイナー側での手動による修正や作り直しがかなり発生するわけですね。

神鳥：ただ、それはそういうものなので、仕方がないと思っています。必ず人の手を入れる必要がある。システマティックに全部自動処理をして、上手くいくわけがありません。ビジュアルのクオリティを上げるというのは、そんなに簡単なものではない。

ただし、その作業を楽に行うための構造はつくっていく必要があります。例えば、こうした場合の建物も1つのオブジェクトとして作成してしまうと、のちのち調整が非常に大変になります。手動調整が必要だったり、ノイズになりやすかったりするような怪しい箇所については、別データ管理できる状態のアセットとして構築していく。そうすることで、後で問題が起こったときにも楽に加工、対応できるデータになります。

CGW：基本的にはできる限り自動化しつつも、手動でクオリティを上げるところがあるのを踏まえた上で、それをどう楽にしていくかというアプローチなんですね。

神鳥：われわれはそもそもゲーム開発向けのツール等をつくっている会社ですので、デザイナーが楽になるしくみをつくってクオリティを上げていくという目線の持ち方をしています。実際の例を見てもらうと、これらの建物内部もガラス部分を「このエリアは除く」みたいな処理ができる状態にしておいたりだとか、実はあえて3D形状化せずに板ポリとして配置して、写真をテクスチャで貼り付けているだけの部分があったりします。目的に応じてですが、点群データのまま使うこともあります。

樹木についても、その正確性がそれほど重要視されないのであれば、既存アセットに差し替えて配置する、といったことが現実的な解決策でしょう。その場合、ガラスと同じように、該当箇所を削除する指定ができるような構造にしておく必要があります。

CGW：ありがとうございます。ひとえにデジタルツインといっても、広範囲の街並みから、個別の建物の詳細な再現、またさらにその建物内部の再現にいたるまで、様々なバリエーションが存在することがわかりました。これらはそのクライアントの目的から必要とされる技術にいたるまで、大きく異なる内容になりますよね。シリコンスタジオでは、それらをひととおり網羅できるのが素晴らしいと感じました。

神鳥：求められる再現規模というか、エリアの大きさによって必要な情報も技術も変わってきますが、われわれとしてはそれらを広く取り揃えて、よりリアルで納得感があるようなものを今後も構築をしていきたいです。

一番重要なのが、どんな技術にしてもデザインにしても、それがお客様の課題を解決し、やりたいことを実現しているのか、またそれがその先で社会のためになるのか、という想像力だと思います。われわれの技術を提供することによって、例えば社会においてクルマの事故が減るとか、それにつながる製品が開発できるとか、はたまたお客さんの安全な工事現場の環境が構築できる、といったことにつながる。そのために、われわれは仕事をしているんだという意識を常にもって取り組んでいければと考えています。

CGW：今回もありがとうございました。またぜひ、新たな事例があればご紹介ください！