川合

FBXとOBJ、CityGMLを、それぞれ使っています。地域によっては、CityGMLしかないところもあるので。

川合

そのまま使っているケースもあれば、自分で変換しているケースもあります。CityGMLからの変換については、PLATEAUのマニュアルにも載っていますし、有志が作った、「突っ込んだらOBJになる」というすごく便利なツールもあります。Blenderのパーサーを作っている人もいます。いろいろあって、うまく動かないときもあるんですけれども。

川合

そのときの論文は、PLATEAUではなく地理院地図を使っていたころです。OpenStreetMapと組み合わせていたのですが、重複する頂点がたくさんあるのです。同じ座標にポリゴンがいくつも重なっているとか、ディテールがきちんと作られているんだけども、見えないだろうというところもありました。そこでBlender上で、ある距離よりも短い間にある2点は、一緒のものだとして考えて合わせる手法をとりました。

こうした考え方は、PLATEAUでも使います。とはいえPLATEAUのデータは、同じ頂点がほとんどありません。大きい範囲内でも4点ぐらいしか重複しておらず、本当にきれいなデータを作っていると感動しました。

ただ逆に、建物のごちゃごちゃした部分は、省略しようと思ったら省略してよいわけなので、遠景で見るような、たとえば、可視化ビジュアライゼーションするような場合は、ポリゴン数を削減することがあります。

川合

これまで使ってきたのは、建物と道路と地形と橋です。立体的な構造物は、かなり使います。今後は、土地利用や災害想定などのレイヤーもうまく活用できそうだと考えています。

建物については、LOD1、LOD2のそれぞれがあって、整備されている範囲もそれぞれ違います。LOD2が提供されている地域では、LOD2を使うと、みなさんテンションが上がるので使いたいところですが、広域になると重たいので、広い範囲で作る場合は、あえてLOD1を使います。

川合

基本的には、手作りです。もともとは写真をもとに手作業で作っていましたが、最近は点群データが取れますし、フォトグラメトリもあります。特に樹木では、比較的昔から、フォトグラメトリモデルを使っていました。とはいえ点群データは、やはり重たいので、それをどう軽量化させていくのかが課題です。

たとえば、過去の景観を作るシミュレーションの例では、立木については、実際にお寺さんに生えている木をフォトグラメトリで撮って、本物を加工しています。逆に人工物、街灯や電柱や電線は、手作業で作ってしまったほうが早いです。ケースバイケースで、メーカーさんによっては図面を公開しているところもありますし、実際にある交差点であれば、そこに行って測定しています。

またUnityの中にも、アセットが多少あります。日本の景観や交通標識などのアセットを使うこともありますし、3Dモデルを販売しているところでも、土地構造物は比較的共通利用できるものでもあるので、そういったものも利用することもあります。

川合

PLATEAUを使う場合は、PLATEAUのデータだけを使ったほうが安全といえば安全です。国土地理院やOpenStreetMapなどの、さまざまなデータを組み合わせると、大変になることがあります。

これまでは、さまざまなデータを組み合わせざるを得ない状況でした。地理院地図だけでは完結できないので、ほかのデータを組み合わせるわけですが、その調整が大変でした。PLATEAUのように、ひとつの標準化された規格に則って、こうした3Dデータを集約していく事業は、とても助かります。

川合

地図屋さんからすると怒られる話で、実際、GISなどの専門家や学会などで、じつはものすごく怒られたことがあります。「そんなものはおかしい。地球は丸い」「お前らは地球を平面だと思っているんだ」と（笑）。そのあたりも難しい部分です。

川合

用途によると思います。少し広範囲で見せようとすれば、球面であることを考慮する必要があります。しかしたとえば、ある交差点１個の範囲であれば、地球は別に平面であっても問題ないので、むしろ、そこでの交通事故をどう再現するかというところに注力すべきだと思います。

川合

相変わらず、地理院地図はよく使います。OpenStreetMapも参考にしています。

人流データや津波の浸水データなどは、地方自治体が公開しているデータを使っています。それぞれが、自治体都市計画図や用途地域などを持っているので、それらを組み合わせていきます。昔からやっていたことですが、それらをPLATEAUに乗せていけると思います。

組み合わせるデータは、プロジェクトによって、さまざまです。過去の景観シミュレーターであれば、古地図や古写真、浮世絵も参考にします。ドライブシミュレーターであれば、たとえば、交通事故マップなどで、警視庁がオープンデータにしているものがあります。渋谷駅周辺の実際の交通事故がヒートマップになっていて、拡大していくと、実際の事故のデータセットがあります。警視庁だけでなく、県警のデータなども見ながら、実際の地図に落としていくだけではなく、ここで歩行者が本当に飛び出してきたというところを使っていきます。

PLATEAUの活用という意味では、「地理空間情報以外のどういったデータと組み合わるのか」という部分も問われます。そのセンスのようなものがこれからは必要になってくると思います。

川合

警視庁のデータは、ダウンロードできません。警察との共同研究というかたちで入手しました。交通事故だけではなく、たとえば、犯罪系のマップなどもあるので、さまざまな用途に使えると考えています。

ただ難しいところは、こうしたデータを地図と結び付けることを嫌がる事業者の方も多いことです。ヒートマップが真っ赤になっている犯罪地域のデータを見て、その地域で賃貸などをやられている業者にやめてくれと言われるという話もあります。

それこそ東日本大震災後に、津波のハザードマップが一回り大きくなって、一番問題になったのは地権者さんです。市議会に、その新しいハザードマップはちょっとおかしいのではないかという陳情もありました。地方自治体さんも、だいぶ苦労されたようです。

川合

Unityの「ナビメッシュ」という機能を使っています。この機能は、昔から使っていました。

本来の用途としては、ゲームのキャラクターがおかしなところへ行かないように移動範囲を限定するものですが、CADデータや3D都市モデルのデータに対してもナビメッシュを貼ることができます。 エージェントが道路上を動くようにするには、まず、都市モデルの道路に対してナビメッシュを貼ります。それからエージェントが最初にいる場所とゴールを作り、その上を自由に歩けて、ランダムで動くように設定します。そうするとエージェントは、最短経路でゴールに向かいます。移動できる範囲を面で指定し、初期の位置とゴールを指定すれば、人でも車でも何でも動きます。

津波シミュレーションのときは、都市の中にこうしたエージェントをランダムにばらまいて、そこから一番近い津波避難ビルに向かって、道路のメッシュの上を最短距離で動けというコードを書いています。

また追加のルールとして、収容定員を避難対象のビルに設定しました。実際の避難もそうなのですが、これ以上入れないということもありますし、小中学校が津波避難指定場所となっていても、開校時間中であれば生徒がいるため、外の人は入れてはいけないということもあります。

シミュレーションでは、1つの避難ビルに行って入れなかった場合、どういう判断をするのかも見てみました。そうすると、このエリアに津波避難ビルがあるから大丈夫という計画を立てていても、満杯になってしまうと、次の避難場所が近くになく危険という場所もありました。

川合

まったく、その通りです。このシステムとわりと近い研究を、いま学生がやっています。横浜の建物を全部作って、駅を指定して、駅から最短経路でエージェントを動かして、駅からの距離に応じて、地価がどう変わるのかという研究です。ナビメッシュを使うと、いろいろなことができると思います。

川合

昔からのシミュレーション業界や地理業界の方などから見ると、ゲームエンジンは、「なんちゃってシミュレーションではないのか」ということは、言われます。

その一方で最近、建築学会などの分野では、基礎のシミュレーションモデルと同等のものをゲームエンジンで計算して比較し、これくらいは同等の精度であるとか、逆にこの部分はおかしいとか、そういう違いを調査し、調整のパラメータをゲームエンジンの中にフィードバックしていくことも盛んです。

シミュレーターでは、いろんなことを言われます。たとえば、津波避難シミュレーターでは、エージェントによって、歩く速度が違うだろうと言われました。そこで、児童や高齢者などで分ける、あるいは住民と観光客とで分けるようにしました。さらには、エージェント同士で会話して、「あそこの避難所はいっぱいだ」という情報も広がっていくでしょう。さまざまな想定がありますから、こうしたことは、ゲームエンジンでやっていけばよいと思います。

さらに、道路についても、地震が起きて津波が来るときに、道路が通れるとは限らない。建物が倒壊したり、車が通行止めになったりもします。何パーセントの確率で通れなくなりますといったところもシミュレーションできると面白いですね。

川合

そうです。理論的な部分はシミュレーション業界の方が、いろいろとやっているので、それをトライアンドエラーで可視化できていくようなことを目指しています。

自治体さんと話をして「具体的にわが街はどうすればいいのか」という話になったとき、理論的なシミュレーションでは、それをすぐに確認するのもなかなか難しい。コンサルタントに頼むのもお金がかかってしまうので、こうしたオープンデータを使って「ある程度粗いけれども、こういう雰囲気になるのではないか」というものを可視化して見せるというのは、役に立つのではないでしょうか。

まさに防災教育などもそうでしょう。厳密なシミュレーションとはちょっと違ってくる世界ではありますが、需要はあると思います。

川合

ドライブシミュレーターですと、3人です。学生を含めて3人1チームで、1年間で作りました。1年目は、地理院地図を使いました。2年目はOpenStreetMapと組み合わせて作りました。今やっているのが、PLATEAUで完結できるシステムで、まさに作っているところです。

津波避難シミュレーションに関しては、基盤システムは私ともう一人の学生で最初に作りました。そこからは毎年恒例のプロジェクトになっていて、3人が1年くらいかけて地域を増やしていったり、エージェントのパラメータを、どんどん増やしていったり、ほかのことにも使えないかを考えたりしています。一度、水害のシミュレーションもやりましたが、うまくいきませんでした。

津波自体のシミュレーションもいろいろあります。津波が押し寄せてくるのは、それっぽく見せているだけで、実際には流体とか格子法とか、いろんな世界がそこにあって、そんなふうに津波は来ないぞとか、そのあたりも検証しています。

いずれにしても、水のような流体は、計算量がものすごく大きくなってしまいます。ですからゲームエンジンの中で、しかも都市モデルと一緒にリアルタイムに計算しようとすると大変なので、事前にほかの測定案の中で計算したものを、ゲームエンジンでは可視化するのみというアプローチになります。

人流可視化のほうは、いまOpenCVを使ったシミュレーターが面白いという話になっています。コロナ対策から始まったのですが、たとえば海水浴場で、今はこっちは混んでいるとか空いているとか、観光情報にも使えないかということで考えています。

OpenCVでひとつひとつ算出しているものを、Yoloを使うことで、もう少し密度を高くして取得できないかというところも含めて、もっと大規模にもっとリアルタイムにという形で監視できないかを模索しています。

基本的には、ゼミの学生が担当するので、制作期間は、1年という単位が基本です。プログラムが得意な学生、モデルが得意な学生などが、何人かでチームを組んで、それぞれの得意分野を活かして進めていきます。