---
title: 『モンスターハンター ブリッジ』を支える技術～未踏の映像環境を実現したマルチモニターレンダリングの実装 [RE:2026 2026年10月2日登壇]
tags:  #capcom #カプコン #カプコン技研 #re engine #re2026capcom #ゲーム開発 #ゲームエンジン #モンスターハンター ブリッジ #マルチgpu  
author: [カプコン技研](https://www.docswell.com/user/CAPCOM_RandD)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LJL8ZZ13ER.jpg?width=480
description: 2026年10月にカプコンが開催した「CAPCOM オープンカンファレンス RE:2026」の講演資料です。  ■ 講演映像(再生リスト) https://www.youtube.com/watch?v=f-EHRhMMPIY&list=PLD_N6X6tKlCM
published: November 13, 26
canonical: https://www.docswell.com/s/CAPCOM_RandD/5L3PWG-RE2026-EAST-5
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LJL8ZZ13ER.jpg)

『モンスターハンター ブリッジ』を
支える技術
～未踏の映像環境を実現した
マルチモニターレンダリングの実装
和田 功
塚越 優治
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/47M6VVWMJW.jpg)

『モンスターハンター ブリッジ』を
⽀える技術
〜未踏の映像環境を実現した
マルチモニターレンダリングの実装
和⽥ 功
塚越 優治
1
それでは、『モンスターハンター ブリッジ』を⽀える技術〜未踏の映像環境を実現したマルチモニターレンダリングの実装 の講演を開始します。よろしくお願い致します。
1


# Page. 3

![Page Image](https://bcdn.docswell.com/page/P7RP22YLJ9.jpg)

22
早速ですが、まずはこちらの動画をご覧ください。
2


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PJX3DD467X.jpg)

『モンスターハンター ブリッジ』紹介動画
33
※ 映像についてはDocswell「スライド概要」へ記載のYouTube講演映像からご確認ください。
3


# Page. 5

![Page Image](https://bcdn.docswell.com/page/3JKYXXZG7D.jpg)

『モンスターハンター ブリッジ』
• ⼤阪・関⻄万博の⼤阪ヘルスケアパビリオン「XD HALL」に出展
• 「ミライのエンターテインメント」がテーマの
「モンスターハンター」シリーズの世界に没⼊できる体験
44
というわけで、改めてコンテンツについてご紹介します。
『モンスターハンター ブリッジ』は、2025年に開催された⼤阪・関⻄万博、⼤阪ヘルスケアパビリオンの⼀⾓に建てられた「XD HALL（エックスディー ホール）」にカ
プコンが出展した、体験型コンテンツです。
「ミライのエンターテインメント」をテーマとしており、参加者は専⽤のARデバイスを装着して360°シアター内に⼊場し、全⽅位に映し出された映像やサウンド、床振
動、ARコンテンツなどを組み合わせて構成した「モンスターハンター」シリーズの世界への没⼊体験を楽しめます。
4


# Page. 6

![Page Image](https://bcdn.docswell.com/page/LE3955D5E5.jpg)

本講演の構成
前半︓『モンスターハンター ブリッジ』とは
後半︓ 未踏の映像環境を実現したマルチレンダリングの実装
55
本セッションは前半と後半の2部構成となっております。
前半では『モンスターハンター ブリッジ』というコンテンツそのものの紹介や体験を向上させる⼯夫についてご紹介し、
後半では特にマルチレンダリング技術にフォーカスしてご紹介します。
5


# Page. 7

![Page Image](https://bcdn.docswell.com/page/8EDGDDPYEG.jpg)

前半
『モンスターハンター ブリッジ』とは
66
では、まず前半はわたくし塚越から、『モンスターハンター ブリッジ』というコンテンツについて、
企画の経緯やコンセプトといったトピックから、徐々に技術的な内容についてもお伝えします。
6


# Page. 8

![Page Image](https://bcdn.docswell.com/page/V7P3XXN2J8.jpg)

77
コンテンツの紹介に先⽴ち、まずは⼤阪・関⻄万博とカプコンのつながりについてご説明します。
7


# Page. 9

![Page Image](https://bcdn.docswell.com/page/2JV4LLKX7Q.jpg)

成り⽴ち
カプコン
企業理念
遊⽂化をクリエイトする
感性開発企業
「モンスターハンター」シリーズ
テーマ
⾃然や⽣物、
⽣命の素晴らしさ
『モンスターハンター ブリッジ』
⼤阪・関⻄万博
テーマ
いのち輝く
未来社会のデザイン
⼤阪ヘルスケアパビリオン
テーマ
REBORN
88
カプコンは「遊⽂化をクリエイトする感性開発企業」という理念に基づき、ゲームという媒体を通じて⼈々を魅了する企業を⽬指しています。
その創業の地・⼤阪で開催されることとなった⼤阪・関⻄万博のテーマは「いのち輝く未来社会のデザイン」、
そこに⼤阪府と⼤阪市が出展した「⼤阪ヘルスケアパビリオン」のメインテーマは「REBORN」でした。
「いのち輝く」、「REBORN」といったワードから着想を得た我々は、「⾃然や⽣物、⽣命の素晴らしさ」を主要なテーマに掲げた「モンスターハンター」シリーズを活⽤し、
体験型コンテンツ『モンスターハンター ブリッジ』を企画するに⾄りました。
8


# Page. 10

![Page Image](https://bcdn.docswell.com/page/5EG1XXQRJL.jpg)

ずばり、そのコンセプトは……
99
ずばり、そのコンセプトは……
9


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4JQD88KY7P.jpg)

夢と現実が、ひとつになる。
10
10
「夢と現実が、ひとつになる。」です。
10


# Page. 12

![Page Image](https://bcdn.docswell.com/page/K74Z22PZE1.jpg)

コンセプト︓夢と現実が、ひとつになる。
多くのゲームは「モニターの前でコントローラーを持って遊ぶ」スタイルが主流
▼
「ゲームの世界やキャラクターと直接触れ合う没⼊体験」の創造に挑戦
万博という⾮⽇常空間で
✓ゲームファンだけでなくより幅広い層に
✓⽇本のユーザーだけでなく世界の⼈々に
楽しんでもらえるようなコンテンツへ
11
11
皆さんもよくご存じの通り、多くのゲームは「モニターの前に座り、コントローラーを⼿に持って遊ぶ」スタイルのものがほとんどです。
しかし、『モンスターハンター ブリッジ』ではそれらの垣根を取り払うことで、ゲームの世界やキャラクターと直接触れ合うことのできるような、特別な没⼊体験を創り出す
ことに挑戦しました。
万博という最先端技術の集まる⾮⽇常空間で、従来から弊社のゲームを遊んでくださっているお客様はもちろん、「モンスターハンター」シリーズに馴染みのないお客
様、さらにはゲームそのものに関⼼のないお客様でも楽しんでもらえるようなコンテンツを。
そして、その特別な体験を⽇本のお客様だけでなく世界の⼈々ともつながって共有してほしい―「夢と現実が、ひとつになる。」のコンセプトと『ブリッジ』というタイトルに
は、そのような想いが込められているのです。
11


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LJ1RMM9DJG.jpg)

12
12
さて、『モンスターハンター ブリッジ』の成り⽴ちや、そこに込めた想いについての紹介はこれまでとして、より具体的に⽤いられている技術について説明します。
12


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GJW133Q8E2.jpg)

技術仕様 – 『モンスターハンター ブリッジ』を構成する4つの要素
360°シアター
ARデバイス
イマーシブサウンド
床振動
13
13
『モンスターハンター ブリッジ』は⼤まかに「360°シアター」「ARデバイス」「イマーシブサウンド」そして「床振動」の4つの要素から構成されます。
冒頭の紹介動画でもお⾒せした通り、ゲストはコンテンツの説明を受けたのち、ARデバイスを装着してシアターに⼊場します。
シアター内では360°映像が映し出され、それと連動したイマーシブサウンドと床振動、そしてARデバイスに投影されるキャラクターとのインタラクションを通じて、我々
の⽬指した没⼊体験を現実にします。
では、これらの主要な要素をひとつずつ紹介していきましょう。
13


# Page. 15

![Page Image](https://bcdn.docswell.com/page/4EZPVVW9J3.jpg)

技術仕様 – 360°シアター
14
14
『モンスターハンター ブリッジ』を構成する要素の中でも最も⼤規模なものが、360°を取り囲む円筒形の「360°シアター」です。
14


# Page. 16

![Page Image](https://bcdn.docswell.com/page/Y76M55GDEV.jpg)

技術仕様 – 360°シアター
床⾯はプロジェクター投影
RE ENGINEによる
全⽅位リアルタイムレンダリング
側⾯と天井⾯はシースルーLED
15
15
床⾯の直径が約12メートル、⾼さが約5mの円筒形状となっており、同時に約20⼈が⼊場できます。
側⾯と天井⾯にシースルーLEDを、床⾯にプロジェクター投影を採⽤しており、天井⾯、側⾯、そして床⾯に4K 計12枚を同時に描画し、それらをつなぎ合わせる
ことで全⽅位の映像を実現しています。
また、映像はRE ENGINEによるリアルタイムレンダリングによって描画されています。プリレンダではなくリアルタイムレンダリングを採⽤することで、ゲストは⾝振り⼿振
りを⽤いて映像とのインタラクションが可能になり、より没⼊度の⾼い体験を楽しむことができます。
15


# Page. 17

![Page Image](https://bcdn.docswell.com/page/G75ZYYV8J4.jpg)

技術仕様 – ARデバイス
16
16
シアターと並び、視覚的な体験を提供するのが「ARデバイス」です。
16


# Page. 18

![Page Image](https://bcdn.docswell.com/page/9J2RGG3V7R.jpg)

技術仕様 – ARデバイス
新規で開発した
専⽤のARデバイス
ハンドトラッキングで
キャラクターとインタラクション
現実世界が⾒える光学シースルー型で
360°シアターとARコンテンツを重ねて表⽰
17
17
没⼊体験の核となる「インタラクション性」の実現には、ARデバイスの存在が⽋かせません。
このARデバイスは「光学シースルー型」というタイプのヘッドマウントディスプレイで、ゲストの視界を完全に覆うようなVRヘッドセットと異なり、⾁眼で周囲の現実世界
を視認しながら、同時にレンズに投影された⽴体コンテンツを楽しむことが可能です。
つまり『モンスターハンター ブリッジ』は、全⽅位のシアター映像に囲まれた中で、ARデバイスに投影されたキャラクターとインタラクションが楽しめる、という作りになって
います。
インタラクションには主にゲストの⼿を⽤います。デバイスに搭載されたカメラによって⼿の位置姿勢をトラッキングしコンテンツに反映することで、例えばオトモアイルーを
⼿で撫でたり、迫りくるモンスターに⽯を投げたり、という体験が可能になるのです。
17


# Page. 19

![Page Image](https://bcdn.docswell.com/page/DEYDVV1QEM.jpg)

技術仕様 – イマーシブサウンド
18
18
続いて、シアターに並んで重要な役割を果たす「イマーシブサウンド」を紹介します。
18


# Page. 20

![Page Image](https://bcdn.docswell.com/page/VJN6MM22J8.jpg)

技術仕様 – イマーシブサウンド
側⾯70台、頭上19台のスピーカー
4台のサブウーファー
シースルーLEDを通じて
360°シアター内にサウンドを届ける
19
19
このイマーシブサウンドシステムは、円筒形のシアターを取り囲む形で構築されています。
図に⽰しました通り、側⾯に⾼さを変えて計70台、頭上には19台、そして4台のサブウーファーが配置されており、そのチャンネル数は89.1chを誇ります。
先ほども軽く触れましたが、シアターの天井⾯と側⾯にはシースルーLEDを採⽤しています。つまりLEDパネルの表⾯に物理的な透過⽳が開いているため、その外
側に配置したスピーカーのサウンドは損なわれることなく、理想的な状態のままゲストに届けられます。
19


# Page. 21

![Page Image](https://bcdn.docswell.com/page/YE9LNN1D73.jpg)

技術仕様 – 床振動
20
20
イマーシブサウンドと関連してお話ししたいのが、4つ⽬の要素である「床振動」です。
20


# Page. 22

![Page Image](https://bcdn.docswell.com/page/GE8XKK45JD.jpg)

技術仕様 – 床振動
演出と連動した振動ユニットを
床下に設置
ゲストの⾝体に直接作⽤し
没⼊度を向上
21
21
床⾯のさらに下に設置された床振動ユニットは、これまでにご紹介したシアターの映像やイマーシブサウンドと協調して動作し、
ゲストの⾝体に直接作⽤するという重要な役割を果たします。
体験型コンテンツでは⼀般に視覚や聴覚提⽰が優先されることが多いですが、本コンテンツでは触覚提⽰もフル活⽤して⼤⾃然の厳しさを表現します。
また、いわゆるハプティックグローブのようにゲストがデバイスを直接装着する必要がないため、振動ユニットの⼤型化も容易であり、
結果としてゲストの快適さと振動のスケールを両⽴することにも成功しました。
21


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LEL8ZZ637R.jpg)

技術仕様 – 『モンスターハンター ブリッジ』を構成する4つの要素（おさらい）
360°シアター
ARデバイス
イマーシブサウンド
床振動
22
22
以上が『モンスターハンター ブリッジ』を構成する4つの主要な要素の紹介でした。
「360°シアター」「ARデバイス」「イマーシブサウンド」そして「床振動」。いずれも本コンテンツのために最新技術を惜しみなく注ぎました。
22


# Page. 24

![Page Image](https://bcdn.docswell.com/page/4JM6VV5MEW.jpg)

23
23
しかし「夢と現実が、ひとつになる。」体験の実現には、これらの要素をただ並べるだけではなく、効果的に組み合わせることが不可⽋です。
本セッションでは、視覚的な体験の質を⼤きく左右する「シアターとARデバイスの組み合わせ」にフォーカスし、具体的にどのような⼯夫を施したのか、その⼀部をご紹
介することにします。
23


# Page. 25

![Page Image](https://bcdn.docswell.com/page/PJRP223LE9.jpg)

最⼤の課題は「境界」を感じさせないこと
360°シアター映像
• 空間全体を包み込む
• ⾼品質でスケールのある表現が得意
ARコンテンツ
• ⽬の前に存在するように⾒える
• インタラクションが可能
課題
• 単に重ねるだけでは両者は別々の映像に⾒えてしまう
24
24
シアター映像は、ゲストの周囲360°を取り囲み、巨⼤なモンスターや⾃然環境のスケール感を表現できます。
⼀⽅でARコンテンツは、ゲストの⽬の前にキャラクターやオブジェクトが存在しているように⾒せられ、⼿を使ったインタラクションも可能です。
しかし、この2つは表⽰される場所も性質も⼤きく異なるため、単にそれらを重ねるだけでは、ゲストには「シアターの映像」と「ARの映像」が別々のものとして⾒えてし
まいます。
「夢と現実が、ひとつになる。」体験の実現のためには、この境界をいかに感じさせないかが⼤きな課題でした。
24


# Page. 26

![Page Image](https://bcdn.docswell.com/page/PEX3DD96JX.jpg)

「境界を消す」ために⾏ったこと
360°シアターとARの境界を消す
• 同じ存在として⾒せる
• ⾏動の結果を世界に返す
• 空間の質感を揃える
• 明るさを設計する
ゲスト間の境界を消す
• 共有体験を提供する
25
25
そこで我々は、シアターとARの境界を感じさせないための様々な⼯夫を施しました。
本セッションではその中から、5つの事例を紹介します。
25


# Page. 27

![Page Image](https://bcdn.docswell.com/page/3EKYXXPGJD.jpg)

360°シアターとARの境界を消す – 同じ存在として⾒せる
例︓⽕⼭エリアのリオレウス
• まずはARで登場
⇒ ゲストが⽯を投げてインタラクション
• 途中で360°シアター表現に移⾏
⇒ ラージャンとの縄張り争いを⼤スケールで表現
ARで登場するリオレウス
ねらい
• 表⽰媒体が変わっても
同じキャラクターとして認識させる
360°シアターで登場するリオレウスとラージャン
26
26
⽕⼭エリアに登場する⼤型モンスター、リオレウスを例にしてひとつ⽬の事例を紹介します。
リオレウスは最初、ARコンテンツとして登場します。
ゲストは⽯を投げて応戦できるため、ここでは「⾃分が関われる存在」としてリオレウスを感じてもらいます。
その後、リオレウスはシアター側の表現に移⾏し、ラージャンとの縄張り争いを展開します。
ここではRE ENGINEによるシアター映像や床振動を活かし、⼤型モンスター同⼠のスケール感を表現しています。
重要なのは、ARとシアターで表⽰媒体が変わっても、ゲストには「同じリオレウスがそこにいる」と感じてもらうことです。
26


# Page. 28

![Page Image](https://bcdn.docswell.com/page/L73955X575.jpg)

360°シアターとARの境界を消す – ⾏動の結果を世界に返す
例︓船上エリアのラージャン
• AR側
⇒ ゲストが砲弾を投げる
• 360°シアター側
⇒ 着弾位置に爆⾵を描画
ねらい
• ⾃分がこの世界に影響を与えたと感じさせる
AR砲弾の爆⾵が多数360°シアターに描画されている
27
27
次の事例は、船上エリアのラージャンです。
このシーンでは、ゲストがARデバイス上に表⽰された砲弾を投げて応戦する遊びを⽤意しました。
砲弾そのものはARで表現していますが、着弾時に⽣じる爆⾵はシアター側に描画しています。
これによって、ゲストの⾏動がARデバイスの中だけで完結せず、シアター全体の世界に影響したように⾒え、
ゲストに対して「⾃分がこの世界に影響を与えた」という感覚を与えています。
27


# Page. 29

![Page Image](https://bcdn.docswell.com/page/87DGDD2Y7G.jpg)

360°シアターとARの境界を消す – 空間の質感を揃える
例︓船上エリア ラギアクルス登場
• 360°シアター側
⇒ ラギアクルスの周りに⽔しぶき
• AR側
⇒ ゲストの近くにも同様の⽔しぶきパーティクルを配置
ねらい
• 360°シアターの質感とARの質感を揃え、空間の境界をぼかす
360°シアター（ラギアクルス＋⽔しぶき）
AR（⽔しぶき）
タイミングを合わせて両⽅を再⽣
28
28
3つ⽬は、より繊細な⼯夫です。
ラギアクルスというモンスターの登場シーンを⾒てみましょう。
シアター側で海中から現れるラギアクルスの周りには⽔しぶきが表現されています。
それに合わせて、AR側にも同様の⾒た⽬をした⽔しぶきのパーティクルを配置しました。
シアターだけに⽔しぶきがあると、それは「スクリーンの向こうの⾵景」に⾒えてしまいます。
しかし、AR側にも⽴体的なパーティクルを配置することで、ゲストの近くまで登場の余波が流れ込んできたように感じられます。
これによって、シアターとARの境界をさらに曖昧にしています。
28


# Page. 30

![Page Image](https://bcdn.docswell.com/page/VJP3XX12E8.jpg)

360°シアターとARの境界を消す – 輝度の壁
ARコンテンツ
• 半透明で表⽰される
シアターLED
• ⾼輝度で空間を包み込む
課題
• 360°シアターが明るすぎると、ARキャラクターが⾒えづらくなる
ARコンテンツ
シアターLED
重ね合わせで⾒えづらく
29
29
実際にシアターとARコンテンツの重ね合わせを成⽴させるうえでは、⼤きな壁がありました。それがARデバイスに搭載されたディスプレイとシアターLEDの輝度差です。
ARデバイスに表⽰されるコンテンツは半透明になるため、⾼輝度のシアター映像と重なると⾒えづらくなってしまいます。
つまり、シアターの表現を強化すればするほど、AR側の体験を損なう可能性がありました。
29


# Page. 31

![Page Image](https://bcdn.docswell.com/page/2EV4LLYXJQ.jpg)

360°シアターとARの境界を消す – 明るさを設計する
例︓草原エリア
• 床付近を少し暗くする
⇒ ARオトモアイルーの視認性を確保
30
30
そこで、シアター側の輝度を演出に合わせてコントロールしました。
例えば草原エリアでは、床に近い部分をわずかに暗くすることで、地⾯に⽴っているARのオトモアイルーが⾒えづらくならないようにしています。
30


# Page. 32

![Page Image](https://bcdn.docswell.com/page/57G1XX9REL.jpg)

360°シアターとARの境界を消す – 明るさを設計する
例︓⽕⼭エリア
• はじめは溶岩も明るく発光している
⇒ 360°シアターの⾵景を重視
• 途中から溶岩の発光がおさまる
⇒ ARリオレウスの視認性を確保
ねらい
• その瞬間に⾒てほしいものを際⽴たせる
31
31
また、⽕⼭エリアでは、序盤は溶岩を明るく⾒せて、まずはシアターの⾵景を印象づけます。
その後、ARリオレウスとのインタラクションが始まるタイミングでは、溶岩の発光を抑えています。
つまり、常にすべてを⽬⽴たせようとするのではなく、その瞬間にゲストに⾒てほしいものが最もよく⾒えるように、シアターとARの明るさのバランスには特に気を配って
体験を設計しました。
31


# Page. 33

![Page Image](https://bcdn.docswell.com/page/4EQD88WYJP.jpg)

ゲスト間の境界を消す – 共有体験を提供する
例︓⽕⼭エリアのリオレウス
• ARリオレウスの位置を同期
⇒ どのゲストから⾒ても同じ場所に存在
• 投げた⽯も同期
⇒ 他のゲストの⾏動も反映される
ねらい
• 360°シアター内の全員が
• 1体の強⼤なモンスターに
• 共に⽴ち向かっているという感覚を届ける
ARで登場するリオレウスと、それに⽴ち向かうゲスト
32
32
ここまでの⼯夫は、シアターとARをひとつの世界として⾒せるためのものでした。
さらに『モンスターハンター ブリッジ』では、その世界をゲスト全員で共有することも重視しました。
例えば⽕⼭エリアのリオレウスは、どのゲストから⾒ても同じ位置にいるように同期しています。
また、あるゲストが投げた⽯は、他のゲストからも⾒えるようにしています。
これによって、各⾃がARデバイスで個別に体験しているのではなく、「シアター内の全員が」「同じ1体の強⼤なモンスターに」共に⽴ち向かっている、という感覚を作っ
ています。
32


# Page. 34

![Page Image](https://bcdn.docswell.com/page/KJ4Z22KZ71.jpg)

技術統合＝体験をひとつにすること
360°シアターとARをつなぐための様々な⼯夫
1. 同じ存在として⾒せる
2. ⾏動の結果を世界に返す
3. 空間の質感を揃える
4. 明るさを設計する
5. 共有体験を提供する
これらの積み重ねで「夢と現実が、ひとつになる。」体験を⽬指した
33
33
シアターとARデバイスの統合とは、単に2つの表⽰装置を同時に動かすことではありませんでした。
キャラクターを同じ存在として⾒せる。
ゲストの⾏動をシアター側の世界に返す。
空間の質感を揃える。
さらに、ARとシアターのどちらも損なわないように、世界の明るさにも気を配って設計する。
そして、その体験をゲスト全員で共有できるようにする。
こうした⼯夫の積み重ねによって、「夢と現実が、ひとつになる。」というコンセプトを体験として成⽴させたのでした。
33


# Page. 35

![Page Image](https://bcdn.docswell.com/page/LE1RMMXDEG.jpg)

前半のまとめ
『モンスターハンター ブリッジ』は4つの要素から構成
360°シアター
ARデバイス
イマーシブサウンド
床振動
それらを統合し「夢と現実が、ひとつになる。」のコンセプトのもと
「ミライのエンターテインメント」を実現
後半では、360°シアターを実現したマルチレンダリング技術にフォーカスして紹介
34
34
さて、前半はここまでとなります。
『モンスターハンター ブリッジ』を構成する4つの要素やそれらの統合に関する⼯夫の紹介を通じ、
「夢と現実が、ひとつになる。」のコンセプトのもと「ミライのエンターテインメント」をいかにして実現したのか、その⼀端でも伝わったのであれば幸いです。
後半では和⽥より、360°シアターの実現を⽀えたマルチレンダリング技術にフォーカスしてご紹介します。
34


# Page. 36

![Page Image](https://bcdn.docswell.com/page/GEW133N872.jpg)

未踏の映像環境を実現した
マルチレンダリングの実装
35
35
塚越さん、コンテンツのご解説ありがとうございました。
ここからは私、和⽥に代わりましてレンダリングについてのお話をさせて頂きます。
35


# Page. 37

![Page Image](https://bcdn.docswell.com/page/47ZPVV39E3.jpg)

はじめに
360°に広がるゲーム世界との境界をなくす没⼊空間
36
36
今回お話をさせて頂く内容は、XD HALL内、360°シアターの話です。
後ろの範囲全般、シームレスに広がるパノラマ空間ですが
壁も床も含めたリアルタイムでのレンダリングを⾏っております。
ARデバイスとの組み合わせでまさに境界が無く、ゲームの世界そのものにいるような
⾼い没⼊体験を提供できているかと思います。
36


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YJ6M55XD7V.jpg)

はじめに
通常のゲーム開発との⽐較
通常のゲーム
『モンスターハンター ブリッジ』
GPU
1つ
4つを同期
出⼒
4K × 1〜2
巨⼤なパネル + プロジェクターの4K × 12
環境
PC1台の中だけ
360°シアター + ARコンテンツ + イマーシブサウンド + 床振動
すべて連動するリアルタイム処理
• モニターの前だけで完結するのではなく、巨⼤な空間の
• 描画負荷12倍を想定 + リアルタイムレンダリング
⇒ 通常のゲームの前提が通⽤しない
37
37
さてこの構成は、通常のゲーム開発と⽐較すると
想定されていない内容とスケールであることがわかります。
使⽤するGPUは4つ
出⼒先は4K × 12
さらに、AR、サウンド、床振動、これらともリアルタイムに連携します。
通常のゲームの前提が通⽤しない、まさに未踏の試みと⾔えます。
37


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GJ5ZYYX8E4.jpg)

はじめに
特異な構成に対して3つの取り組みで実現
① 4つのGPUを並列に⽤いたレンダリング
② GPU間で同期されたリアルタイムキューブマップ
③ 円柱上への12ディスプレイへの出⼒
既存のRE ENGINEには存在しない機能であり
他での前例も少ない
GPU並列レンダリング
GPU間での同期
想定していなかった特有の問題が、様々な観点から発⽣
⇒ レンダリングの設計から実現までの解説
12ディスプレイ出⼒
38
38
そのような特異な構成に対して、我々はレンダリング処理として
4つのGPUを並列に⽤いて
GPU間でのキューブマップの同期
そして円柱上への複数ディスプレイへの出⼒
これらを実装することで実現致しました。
既存のRE ENGINEの機能では存在せず、参考となる前例も少ない内容です。
思いもよらなかった特有の問題も、複数の⾓度から発⽣しました。
今回はそれらについてお話しさせて頂きます。
38


# Page. 40

![Page Image](https://bcdn.docswell.com/page/LE3955XGE5.jpg)

１．360°シアターの構成
360°シアターの詳細な仕様とPC構成など、経緯を追った説明
２．実現に向けたレンダリングの実装
実装されたマルチレンダリングに関する、技術的な解説
３．開発が進むと⾒えてくる問題
RE ENGINE上での開発環境や
マルチレンダリング以外で必要になった機能や改善
４．現地で出てきた問題
XD HALLが出来上がったあと、現地で⽣じた問題と対応
５．まとめ
39
39
本内容につきましては
360°シアターの構成
実現に向けたレンダリングの実装
開発が進むと⾒えてくる問題
現地で出てきた問題
そしてまとめ
このように進めさせて頂きますので、よろしくお願い致します。
39


# Page. 41

![Page Image](https://bcdn.docswell.com/page/8EDGDD2NEG.jpg)

40
40
では、まずは360°シアターの構成
そしてその経緯についてお話致します。
40


# Page. 42

![Page Image](https://bcdn.docswell.com/page/V7P3XX1NJ8.jpg)

360°シアターの構成
XD HALLの構成案と成り⽴ち
• 「ミライのエンターテインメント」として
360°シアター + ARデバイス の没⼊空間体験
• コンテンツ内容と共に360°シアター形状の議論
⽅式 ⇒ プロジェクター投影
形状 ⇒ ボックス
半球
全⾯LED
等
円柱
RE ENGINEはこの検証としても使⽤された
• 結果下記は⾮採⽤
ボックス ⇒ 壁や天井の⾓が⽬⽴つ
半球 ⇒ 壁に近いと空が迫る
41
41
「ミライのエンターテインメント」として
360°シアターの中でARデバイスを使⽤し、没⼊空間への体験を提供する。
このプロジェクトの⽬指すものは、そう定義されていました。
その中で提供されるコンテンツと、それに適したXD HALL⾃体の議論もありました。
⽅式としてはプロジェクター投影や、全⾯LEDなどの案があり、
そして形状として、ボックスや半球という案も出ました。
また、RE ENGINEはXD HALL⾃体の検証としても活⽤されました。
41


# Page. 43

![Page Image](https://bcdn.docswell.com/page/2JV4LLYY7Q.jpg)

360°シアターの検証
42
42
こちらは案があった形状に対して、パノラマ動画をあてはめているものとなります。
ご覧の通り、半球では壁に近づいた時の天井が気になります。
また、ボックスではやはり⾓が⽬⽴ちます。
そして円柱であれば、⼀番違和感の出ない形状として提供できそうに⾒えます。
※ 映像についてはDocswell「スライド概要」へ記載のYouTube講演映像からご確認ください。
42


# Page. 44

![Page Image](https://bcdn.docswell.com/page/5EG1XX9WJL.jpg)

360°シアターの構成
円柱型決定後の構成
• 床⾯
︓天井からのプロジェクター投影 （床振動のため）
• 天井と壁︓シースルーLED（イマーシブサウンド⽤）
最終的な360°シアターの仕様
• 壁⾯︓シースルーLED 4つ
• 天井︓シースルーLED 2つ
• 床⾯︓プロジェクター投影 ６つ
出⼒先4K x 12枚
⇒ 通常のゲームの12倍のレンダリング負荷
43
43
結果としてXD HALLの形状は、円柱に決まりました。
また、床は振動を使⽤するため物理的なディスプレイは使⽤せず
天井からのプロジェクター投影に。
天井と壁はイマーシブサウンドも考慮して
シースルーLEDを使⽤することに決定しました。
XD HALL内は巨⼤な空間です。
そのため解像度も⾼くしなければならず
ディスプレイ出⼒は4Kを基本として構成され、出⼒先は12枚となりました。
単純計算でも通常のゲームの12倍のレンダリング負荷となりそうな規模となったのです。
43


# Page. 45

![Page Image](https://bcdn.docswell.com/page/4JQD88WQ7P.jpg)

360°シアターの構成
構成に対しての問題点
File Stream?
• 単⼀GPUではレンダリングが間に合わない
CubeMap
File?
CubeMap
File?
CubeMap
File?
CubeMap
CubeMapFile?
File?
• キューブマップならリアルタイムレンダリング可能
⇒ ディスプレイごとに直接ではなく
360°を⼀度だけレンダリングして共有可能
それでも2Kが限界で品質不⾜
動画ストリーミングにするしかなくなる︖
• ディスプレイ出⼒を同期させるための仕組みも必要
• 複数台PCを使⽤する構成
⇒ AR + イマーシブサウンド + 床振動の連携
体験時の運営、開発も考えると難しい
PCの構成は1台に集約せざるを得ない
Display A
Display B
Display C
Floor
AR
1App
Sound
Rendering
44
44
もちろん単⼀GPUではレンダリングが間に合わないことが予想されます。
通常のゲームでは最適化しても4Kは1枚か2枚で限界です。
例えば、直接ディスプレイごとにレンダリングするのではなくキューブマップから切り出す⽅法であれば、360°にリアルタイムレンダリングできそうです。
また⼀度のレンダリングで複数ディスプレイに共有もできるため、重複する描画のコストも抑えられそうです。
しかし⾼性能のGPUでも、2Kサイズのキューブマップが限界です。
それ以上の解像度とすると、動画ファイルでのストリーミングにするしかないレンダリング負荷です。
さらに全ディスプレイ同⼠、同期させるための仕組みも必要です。そうすると、複数台のPC構成にて構築することも難しく思えます。
当然ARもイマーシブサウンドも床振動も、すべてを連携させなければならず、もちろん体験型コンテンツである以上、
運営のオペレーションの簡易さも考慮する必要があります。
⼀台に集約せざるを得ません。
44


# Page. 46

![Page Image](https://bcdn.docswell.com/page/K74Z22KYE1.jpg)

360°シアターの構成
専⽤の「モンスターPC」を構築
CPU︓Intel Xeon Gold 5415+（8コア 16スレッド）x 2
GPU︓NVIDIA RTX 6000 Ada × 4
91.1 TFLOPS VRAM48GB MemBW 960 GB/s
PCIe 4.0
NVIDIA Quadro Sync II にて同期
過去タイトルや性能から計算すると
理論上ではRE ENGINE
4Kのキューブマップ + 4Kを12枚出⼒可能
⇒ 必要なのは
マルチGPUとマルチディスプレイへのレンダリング
45
45
そこで専⽤PCが構築されました。
モンスターPCと名付けられた本プロジェクト専⽤の構成です。
CPU２つを搭載しており、Quadro Sync II でのGPUとディスプレイ同期機構もあり、それに対応した⾼性能のGPUが4つも搭載されています。
まさにモンスター級です。
4Kのキューブマップを作成し、そのまま4Kの12枚ディスプレイ出⼒もできると⾒積もられた構成です。
後はマルチGPUとマルチディスプレイへのマルチレンダリング
この実装がなされれば達成となります。
45


# Page. 47

![Page Image](https://bcdn.docswell.com/page/LJ1RMMXNJG.jpg)

360°シアターの構成
360°シアターの構成と要件が決定
レンダリングは
リアルタイムに4Kの
キューブマップ
円柱上に12枚の
ディスプレイへの出⼒
他要素との
リアルタイム連携のため、
1台のモンスターPCに集約
AR
Floor
Sound
Rendering
4つのGPUを使⽤して
マルチレンダリング
⇒ ⼤まかな仕様が決まり、具体的な実装へ
46
46
ここまでが今回の対応が必要となった経緯となります。
12枚のマルチディスプレイへの出⼒。
4Kキューブマップへのリアルタイムレンダリング。
それらを単⼀のPCの単⼀のアプリケーションにて、
4つのGPUを使⽤したマルチレンダリングの実装を⾏うということです。
これで仕様や要件が決まりましたのでここからは具体的な実装に⼊っていきます。
46


# Page. 48

![Page Image](https://bcdn.docswell.com/page/GJW133KME2.jpg)

360°シアターの構成
構成の構築はカプコンだけでは実現できませんでした。
ヒビノ株式会社様
LED及びパネルやプロジェクターのご⽤意、建設を含み
ティフォン株式会社様
モンスターPCの構築や、ディスプレイ転送構築
NVIDIA Corporation様
RTX 6000 Adaの⼿配や、技術サポート
この場でお礼を申し上げます。
47
47
実装の話の前に謝辞を述べさせて頂きます。
この構成はカプコンのみでは構築することはできませんでした。
関連した会社の皆様、改めてお礼を申し上げます。
47


# Page. 49

![Page Image](https://bcdn.docswell.com/page/4EZPVVZMJ3.jpg)

48
48
では、具体的なレンダリング実装をお話していきます。
48


# Page. 50

![Page Image](https://bcdn.docswell.com/page/Y76M55Z5EV.jpg)

実現に向けたレンダリングの実装
設計の基盤
どのように実現していくか︖
通常の12倍負荷のレンダリング構成
4Kキューブマップ + リアルタイムレンダリング
⇒ 4つのGPUに分散することが必要︖
⇒ １つのアプリケーションでマルチレンダリング︖
切り⼝は何か︖
49
49
さて、どのように実現していくかを考えます。
通常の12倍の描画負荷ともなるレンダリング構成です。
4つのGPUに分散させて使⽤させる必要があります。
そのうえ4Kキューブマップをリアルタイムでレンダリング、
それを1つのアプリケーション内で実装する必要があります。
ではその切り⼝はどう考えられるでしょうか︖
49


# Page. 51

![Page Image](https://bcdn.docswell.com/page/G75ZYYWGJ4.jpg)

実現に向けたレンダリングの実装
設計の基盤
考えられる要素と切り⼝
１．キューブマップ各⾯をGPUに分散︖
２．各⾯を送受信してキューブマップとして同期︖
３．各ディスプレイに切り出して出⼒︖
Display × 12
⇒ RE ENGINEは中間描画命令をCPUで作成し、GPU⽤のネイティブ命令に変換 [出典1]
分散や同期の⽅法によっては、GPUもCPUも負荷が増加してしまう
50
50
まずは要素を整理してみます。
1つはキューブマップの各⾯を、各GPUに分散するということです。
そしてそのキューブマップをGPU間で、送受信して同期する必要がありそうです。
最後に各ディスプレイに対しても、GPUが分散して出⼒する必要があります。
RE ENGINEは中間描画命令をCPUで作成し
GPU⽤のネイティブ描画命令に変換して実⾏する、レンダリングパイプラインとなっています。
ここで問題になるのは
キューブマップとディスプレイの分散やGPU間の同期が、
実装⽅法によってはGPUに対してもCPUに対しても負荷の増加の要因となってしまうということです。
50


# Page. 52

![Page Image](https://bcdn.docswell.com/page/9J2RGGQD7R.jpg)

実現に向けたレンダリングの実装
設計の基盤
検討例
Cloud
• 各キューブマップのカメラ範囲だけ
カリングなどで切り分け
Load＆Draw
• ロードや描画も必要なGPUのみ
Monster
Cloud
Ground
Grass
• しかし
途中のレンダリング結果の共有など、GPU間の同期連動が細かく必要
• カメラ毎に異なる中間命令作成となり、CPUの負荷も上昇
⇒ 不採⽤
Monster Motion
Record Draw Command
(CPU)
NG
Temporal Cloud
Sync…
Draw
Monster Motion
Temporal Cloud
Ground
Grass Wind…
51
51
では、分散⽅法を検討してみましょう。
例えば各キューブマップのカメラ範囲だけを切り分け、ロードや描画も必要なGPUに対して振り分ければ効率は良く無駄も無いように思えます。
しかし、空の雲がテンポラルな蓄積で動作していたとしたら︖
モーションや揺れ物はどうなるでしょうか︖
この⽅法ではそれらのレンダリング途中の情報を細かくGPU間で同期する必要が出てしまいます。
また、カメラ毎に異なる中間命令の作成をGPUごとにバラバラに構築するために、CPUの負荷も⾼くなることが予想されます。
そのためこれは採⽤できません。
51


# Page. 53

![Page Image](https://bcdn.docswell.com/page/DEYDVVWMEM.jpg)

実現に向けたレンダリングの実装
設計の基盤
RE ENGINEでの設計
• リソースをすべてのGPUに読み込み
• 中間命令の作成も同⼀のものを使⽤させる
Cloud
Ground
Monster
Grass
Load＆Draw
• 同期はレンダリング済みのキューブマップのみに抑える
OK
Record Draw Command
(CPU)
Monster Motion
Temporal Cloud
Ground
Grass Wind
Draw
GPUの同期も最⼩ + CPUでの中間命令の負荷も１つで済む
52
52
そこで我々は別のアプローチを選択しました。
同⼀のリソースをすべてのGPUに読み込ませ、
中間命令の作成も、同⼀で1つのものを全てのGPUに使⽤させました。
同期はレンダリング済みのキューブマップのみに抑えております。
これによってGPUの同期も最⼩に抑えられ
CPUでの中間命令も、GPUごとにバラバラに作成する必要もありません。
52


# Page. 54

![Page Image](https://bcdn.docswell.com/page/VJN6MM93J8.jpg)

実現に向けたレンダリングの実装
設計の基盤
同⼀のリソースと同じ中間命令の設計にする意味
• GPU計算やシミュレーションが同期不要でズレない
⇒ パーティクルやCloth、フレーム蓄積する雲、⾵など
• １つの中間命令のため、デバッグも容易
デメリット
• VRAM容量は効率的ではない ⇒ しかし48GBと潤沢
• ロード時間は短縮されない
⇒ ただし増加もしない+ 体験⼊れ替え時間もある
カプコンは過去NVIDIA SLI対応やNintendo 3DSでの⽴体視を経験している
基盤はそれらを参考にしつつ、独⾃に実装
53
53
中間命令が同⼀でリソースも同⼀ならば
GPU計算での揺れ物やパーティクルなどのシミュレーション系統や蓄積型の雲なども
同期不要でズレないというメリットも⽣まれます。
そしてデバッグも容易であることも挙げられます。
デメリットはありますが、VRAMは潤沢で
ロード時間についても体験の⼊れ替え時間を考慮すると問題ありません。
過去似たような構成として、カプコンでは
SLIや3DSの⽴体視のための描画を経験しています。
考えの基盤はそれらを参考にしつつ独⾃の実装として考慮致しました。
53


# Page. 55

![Page Image](https://bcdn.docswell.com/page/YE9LNN2P73.jpg)

実現に向けたレンダリングの実装
設計の基盤から具体的な課題へ
①GPUの役割分担をどうするか
分担をどのように⾏わせるのか
⇒
ここが基点
②GPU同期した転送を実現する
実際にキューブマップを同期させる
⇒
⼀番コアとなる難しい実装
③マルチディスプレイへの出⼒
仕上げとした出⼒
⇒
ここまで解決するとシステムが形になったことが⾒える
54
54
さて、設計の基盤はまとまりました。
具体的な課題がこちらとなります。
この3つが実装の⼤きな核となりますので順にお話していきます。
54


# Page. 56

![Page Image](https://bcdn.docswell.com/page/GE8XKK5XJD.jpg)

実現に向けたレンダリングの実装
設計の基盤から具体的な課題へ
①GPUの役割分担をどうするか
分担をどのように⾏わせるのか
⇒
ここが基点
②GPU同期した転送を実現する
実際にキューブマップを同期させる
⇒
⼀番コアとなる難しい実装
③マルチディスプレイへの出⼒
仕上げとした出⼒
⇒
ここまで解決するとシステムが形になったことが⾒える
55
55
まずは、基点となるGPUの役割分担についてです。
55


# Page. 57

![Page Image](https://bcdn.docswell.com/page/LEL8ZZYN7R.jpg)

実現に向けたレンダリングの実装
①GPUの役割分担をどうするか
中間命令はそのまま同⼀ではない、3つの対応
１．GPUごとに番号を振り分け、それぞれをデバイスインスタンスとする
２．ExecMaskを定義し、中間命令に設定
⇒ どのGPUが実⾏するかを切り替え可に
ExecMask : 1101
GPU0︓0001
ExecMaskは実⾏するGPUを
選択するためのBitマスク
GPU Command …
DrawInstance()
ExecMask : 0xD = b1101
GPU Command …
• キューブマップ⾯の担当GPUの振り分けが可能に
GPU1︓0010
GPU2︓0100
GPU3︓1000
• ディスプレイ出⼒に対応した
SwapChainの保持や出⼒もGPU振り分け
56
56
リソースも中間命令もすべてが同⼀と説明しましたが
完全に同⼀ではありません。
まず、GPUごとに番号を振り分けたうえで
それぞれデバイス層の実装のインスタンスとして保有します。
そのうえで、どのGPU番号に実⾏するのかを指定するBitマスクのExecMaskを定義し
中間命令に設定します。
これによるBitマスクの判定によって
どのGPUがキューブマップのどの⾯をレンダリングするのかを振り分けます。
またディスプレイに対応したSwapChainの保持と出⼒のGPU振り分けもできます。
56


# Page. 58

![Page Image](https://bcdn.docswell.com/page/4JM6VVNQEW.jpg)

実現に向けたレンダリングの実装
①GPUの役割分担をどうするか
３．別GPUのデバイスもTextureリソースも１つに抽象化
Texture A : For GPU0
Texture A : For GPU1
• レンダリング機能も既存のコードのまま扱える
CreateTexture()
MultiTexture A : For All GPUs
• 抽象化リソースはそのまま使⽤できない
⇒ デバイスに渡すとき、コピーしながら
各GPUデバイス⽤の実体リソースに差し替える
• 新規実装も少ない
GPU Command …
DrawInstance()
MultiTexture A
Copy & Replace
• 実装期間も短い
• CPU負荷も⼗分に少なく済む
GPU Command …
GPU Command …
DrawInstance()
Texture A : For GPU0
DrawInstance()
Texture A : For GPU1
ExecuteDevice : GPU0
ExecuteDevice : GPU1
57
57
そして、デバイスもTextureリソースも抽象化します。
GPUが別々であっても、1つのインスタンスとしてみなせるため、既存コードへの変更も不要となります。
ただし、抽象化されているリソースはそのまま使⽤できません。
あくまで実体は各独⽴したGPUのデバイスに対して存在し、異なるGPUデバイスからは参照できないためです。
そのため中間命令をGPUデバイスに渡すとき、各GPU向けにコピーしながら、抽象化リソースをGPU⽤の実体へと差し替えております。
結果として実装⾃体も期間も短く、そして、CPU負荷も⼗分に少なく済む⽅法となりました。
57


# Page. 59

![Page Image](https://bcdn.docswell.com/page/PJRP22DKE9.jpg)

実現に向けたレンダリングの実装
①GPUの役割分担をどうするか
分散実装のまとめ
１．GPUに役割⽤の番号を割り当て
２．１つの中間命令を、ExecMaskにてGPU毎に切り替え
３．デバイスやTextureリソースの抽象化
GPU0︓0001
GPU1︓0010
GPU Command …
Texture A : For GPU0
Texture A : For GPU1
DrawInstance()
ExecMask : 0xD = b1101
GPU Command …
MultiTexture A : For All GPUs
58
58
ここまでで
GPU番号とExecMask、デバイスやリソースの抽象化
これらによって役割を割り振ることができました。
58


# Page. 60

![Page Image](https://bcdn.docswell.com/page/PEX3DD15JX.jpg)

実現に向けたレンダリングの実装
設計の基盤から具体的な課題へ
①GPUの役割分担をどうするか
分担をどのように⾏わせるのか
⇒
ここが基点
②GPU同期した転送を実現する
実際にキューブマップを同期させる
⇒
⼀番コアとなる難しい実装
③マルチディスプレイへの出⼒
仕上げとした出⼒
⇒
ここまで解決するとシステムが形になったことが⾒える
59
59
次は同期と転送に取り組んでいきます。
⼀番難しい箇所になります。
59


# Page. 61

![Page Image](https://bcdn.docswell.com/page/3EKYXX2RJD.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
達成したい流れ
GPU間で直接メモリを共有できるHeap
各GPU担当の
レンダリング⾯
Shared Heaps
で共有
実際の対応
Shared Heapsで転送の実装
同期の問題と対処
転送負荷の問題と対処
YUV圧縮で
転送量の削減
SendTexture と
ReceiveTexture を作成
ダブルバッファにして
フレームのズレを防⽌
1⾯のペアとして仮想化
並列処理で
転送待ちの隠ぺい
マルチレンダリングの
リアルタイム
キューブマップの共有︕
60
60
ここは情報も多いため、まずは⼤枠をお⾒せ致します。
やりたいことは各GPUのレンダリング結果を他のGPUに転送同期し
マルチレンダリングでのキューブマップを作製するだけです。
しかし実装は多くの段階があり、そして多くの問題も出てきました。
それでは、それぞれの対応説明を進めさせて頂きます。
60


# Page. 62

![Page Image](https://bcdn.docswell.com/page/L739554G75.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
GPU同期とは︖そして何が必要︖
• 各GPUで分散して4Kテクスチャにレンダリング
• キューブマップの6⾯の１⾯としてテクスチャを使⽤する
• GPUを跨いで１つの4Kキューブマップを完成させる
All GPU Shared 4K Cube Map!!
61
61
同期するとはどのようなことでしょうか。
各GPUが分散してレンダリングしたキューブマップのうちの各⾯、
それらを複数のGPUを跨いで6⾯に結合させること。
これを同期するということと定義し、
これが出来れば共有された4Kのキューブマップが完成することとなります。
61


# Page. 63

![Page Image](https://bcdn.docswell.com/page/87DGDDQN7G.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
具体的な実装とAPI
• Multi-adapter systems [出典2] によって複数のGPUに分担や命令発⾏が可能となる
• Shared Heaps [出典3] は複数のGPU間で直接メモリを共有できるHeap
• GPU間を跨いで、テクスチャの送受信と同期が可能になる
Send
Receive
Shared Heaps
Shared Heaps
62
62
では、具体的な実装を説明していきます。
Multi-adapter systemsというDirectX 12の機能は
複数のGPUに分担や命令発⾏が可能となるものです。
その機能の1つであるShared Heapsを利⽤します。
本来異なるGPU同⼠はメモリの共有は出来ず、CPUを中継した転送は負荷が⾼すぎますが、
こちらは複数のアダプター間、つまりGPU間で直接メモリを共有できるHeapです。
これでGPU間でテクスチャの送受信が可能になりますので設計を進めます。
62


# Page. 64

![Page Image](https://bcdn.docswell.com/page/VJP3XXLNE8.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
送信⽤テクスチャの SendTexture を作成
• Shared Heapsのフラグを指定してHeapとFenceを作成し、共有⽤のハンドルを作成
• Heap内に1つだけコピー先Textureを作成
• ⾯へのレンダリングを担当する、送る側のGPUが保持
レンダリング & 送信するGPU
Copy
Shared Heaps
Heap
Handle
レンダリング後の⾯
SendTexture
CreateSharedHandle()
Handle
Fence
受信先GPUへ送信
受信するGPUで使⽤
63
63
APIを交えた具体的な実装はこの場では控えさせていただきますが、
Shared Heapsのフラグを指定してHeapとFenceを作成し
そこから他のGPUで使⽤する、共有⽤ハンドルを作成しておきます。
そしてHeap内に１つだけコピー先Textureを作成します。
これを送信⽤テクスチャである SendTexture と定義しますが
⾯へのレンダリングを担当する、送る側のGPUだけが保持するTextureです。
63


# Page. 65

![Page Image](https://bcdn.docswell.com/page/2EV4LLQYJQ.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
受信⽤テクスチャの ReceiveTexture を作成
• SendTextureのハンドルから、受信⽤のHeapとFenceを作成
• こちらもHeapに１つだけ、コピー元としてのTextureを作成
• 受け取る側のGPU3つが、レンダリングを担当しない⾯として保持
受信側GPU
送信GPUのHandleから作成
Shared Heaps
Heap
Handle
送信GPUから受信
SendTexture
OpenSharedHandle()
Handle
受け取った
キューブマップの⾯
Fence
Copy
64
64
そしてSendTextureのハンドルを使⽤して、受信⽤のHeapとFenceを作成します。
こちらのHeapにも、同じように１つだけTextureを作成します。
こちらは受信⽤テクスチャとして ReceiveTexture と定義します。
これをレンダリングを担当しない⾯の、受け取る側の他GPU3つにそれぞれ保持させます。
64


# Page. 66

![Page Image](https://bcdn.docswell.com/page/57G1XXWWEL.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
キューブマップの1⾯の構成
• 1⾯毎に仮想化された1つのテクスチャとして扱う、それを6⾯⽤意
• ExecMaskを、SendTextureとReceiveTextureの切り替えにも使⽤
• レンダリング結果のRender Target Texture(RT Texture)から、Copyすると転送される
Render Target Texture
（RT Texture）
MultiTexture FaceN
ExecMask: b0010
CopyTexture
キューブマップの1⾯は
1つのGPUではSendTextureとする
他の3つではReceiveTextureとする
⾯ごとにSendTextureを
担当するGPUは異なる
CubeMap Face N
SendTexture
GPU1:0010
ReceiveTexture
GPU0:0001
ReceiveTexture
GPU2:0100
ReceiveTexture
GPU3:1000
65
65
そして SendTexture と ReceiveTexture の組み合わせを
キューブマップに合わせて6⾯作成します。
ExecMaskをここでも使⽤して、どの⾯がどのGPUに対してSendTextureとなるかを指定します。
送信側GPUではSendTexture
受信側GPUではReceiveTextureと、保持している形態は異なりますが
ここも上位レイヤーからは、抽象化された1つのTextureとして扱わせます。
また、SendTextureに対して、レンダリング結果から CopyTexture を⾏うと
共有のための転送がなされます。
65


# Page. 67

![Page Image](https://bcdn.docswell.com/page/4EQD883QJP.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
GPU0
実際の転送まで
Shared Heapsの特徴
• 直接RT Texture等としては扱えない
• 専⽤のCopyQueueだけで完結
専⽤コマンドで転送実⾏
1. 各⾯ごとにGPUの送受信をセットで実⾏
Render
Draw
ExecMask : 0x1 = b0001
GPU Command …
RT Texture
Draw Complete
Face N
Copy
MemoryTransfer()
MultiTexture Face N
SendTexture
GPU Command …
2. RT TextureをSendTextureにコピー
3. その後ReceiveTextureからキューブマップにコピー
Send/Receive
Copy Queue
GPU1
4. コピー後にレンダリングにて使⽤可能
⇒ キューブマップ1⾯の共有が実現
ReceiveTexture
Copy
Texture
66
66
Shared Heapsは他のGPUとの共有⽤途のみに制限されております。
レンダリング先のRender Target Textureとしても使⽤できませんし、Copy以外の操作やサンプリングもできません。
レンダリング結果をCopyで受け取って送信するか、または受信した結果を別のTextureにCopyするのみです。
中間コマンドも含めた流れを整理しますと、キューブマップの1⾯へのレンダリングまで終えた後、
最後に送信と受信両⽅を意味するメモリ転送のコマンドを実⾏させます。
それで送信側はレンダリングの結果をSendTextureにコピーし、受信側はReceiveTextureから通常Textureに受信した結果をコピーさせることになります。
これで各GPUに同じキューブマップの1⾯が共有されます。
66


# Page. 68

![Page Image](https://bcdn.docswell.com/page/KJ4Z221Y71.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
送受信の実装が完成
• レンダリングを⾏った⾯はSendTextureで送信
• レンダリングしていない⾯はReceiveTextureで受信
• 各GPU内で6⾯結合し共有キューブマップが完成
GPU毎の⾯の割り振り
All GPU Shared 4K Cube Map!!
GPU
SendTexture
ReceiveTexture
ReceiveTexture
SendTexture
SendTexture
ReceiveTexture
GPU0
GPU1
GPU2
GPU3
67
67
これで送受信が実装できました。
各GPU内でレンダリングを⾏った⾯はSendTextureで送信する。
レンダリングしていない⾯はReceiveTextureで受信する。
6⾯分⾏い結合することで4Kのリアルタイムのキューブマップが各GPU内で共有されました。
67


# Page. 69

![Page Image](https://bcdn.docswell.com/page/LE1RMMGNEG.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
しかし、キューブマップ間のフレームのズレが⽣じる
キューブマップの⾯で使われるフレームが異なる
68
68
しかし単純にはいかずズレが発⽣しました。
図の通りキューブマップの境界に対してのずれですが、お分かり頂けますでしょうか。
68


# Page. 70

![Page Image](https://bcdn.docswell.com/page/GEW1335M72.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
各GPUだけのタイミングで送受信するとずれてしまう
⇒ 描画処理のタイミングがバラバラで
送受信のタイミングがズレるため
SendTextureが送信する前に
ReceiveTextureが受け取り処理をしてしまう
⇒ ⾯ごとにフレームがバラバラとなる
GPU0
GPU1
GPU Execute
GPU Execute
Not Yet…
MemoryTransfer()
Receive
Draw Complete
Face N
Rendering
MemoryTransfer()
Send
送信まで待たせるとGPUの待ち時間が問題に
Already…
Wait
Begin Send︖
MemoryTransfer()
Send
NG
MemoryTransfer()
Receive
69
69
原因はGPUごとの実⾏のズレで、送受信のタイミングもズレてしまったためであります。
１つのGPU中で送信する前に
別のGPUが受け取り処理をしてしまうと
⾯ごとにフレームがバラバラとなるために問題は発⽣します。
仮にReceiveTextureを、SendTextureの送信まで待たせることにすると
GPUの待ち時間が多くなりその場合も問題となります。
69


# Page. 71

![Page Image](https://bcdn.docswell.com/page/47ZPVVNME3.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
受信を1フレーム遅らせて
確実に送信完了したデータを使う
ダブルバッファに考え⽅を変える
共有テクスチャを2つ持たせ、受信を遅らせることで安定化
• 今回のフレームのレンダリング結果は送受信のみ、フレームごとに格納先を⼊れ替え
• 次のフレームで⼊れ替わった前回のものを、キューブマップとして使いディスプレイ出⼒
SendTexture GPU
Frame N
RT Texture
Frame N
Frame N+1
RT Texture
Frame N+1
ReceiveTexture GPU
Frame N
Frame N+1
Double Buffer
BufferB Frame N-1
BufferA Frame N
Double Buffer
BufferA Frame N
CubeMap Texture
Frame N
Display
Frame N
Send&Receive
BufferB Frame N-1
BufferA Frame N
Double Buffer
Display
Frame N-1
Swap
BufferB Frame N+1
Double Buffer
CubeMap Texture
Frame N-1
CubeMap Texture
Frame N-1
Display
Frame N-1
Swap
BufferB Frame N+1
BufferA Frame N
CubeMap Texture
Frame N
Display
Frame N
70
70
そこで、正攻法での同期待ちから考え⽅を変え、
共有テクスチャはダブルバッファとすることにしました。
SendTextureもReceiveTextureも、内部的には2つ持たせます。
送信タイミングは今まで通りですが、受信タイミングはフレームの最後にします。
そして両テクスチャともに毎フレーム、送受信⽤とディスプレイ出⼒⽤を⼊れ替えをさせることで
確実に送受信が完了したキューブマップの⾯をディスプレイ出⼒に使⽤できます。
これであればGPUがバラバラに動作した送信であっても
受け取りを遅らせることで安定化させることができます。
70


# Page. 72

![Page Image](https://bcdn.docswell.com/page/YJ6M55857V.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
1フレームレンダリングが遅延する
しかし確実に送信が終わった次のフレームで受信するため安定する
実装も仮想テクスチャ内で完結させている
Output Frame N-1
MultiTexture Face0
Double Buffer
MultiTexture Face1
Double Buffer
MultiTexture Face2
Double Buffer
⇒ 注意点も増えるが、キューブマップのズレの問題は解決
71
71
ただし、これは必ず1フレームの遅延が発⽣する⼿法となります。
あるフレームでレンダリングしたキューブマップが、実際にディスプレイに表⽰されるのは次のフレームとなるということです。
しかし待ち時間などの余計なGPU待ちも⽣じず、確実に安定する⽅法です。
実装⾃体も仮想テクスチャやデバイス内の下位レイヤーのみで完結しております。
サウンドなどのタイミングには注意が必要となりますが
GPUを含めて全体の処理時間が削減できる妥当な⼿段であり、これでズレの問題は解決となりました。
71


# Page. 73

![Page Image](https://bcdn.docswell.com/page/GJ5ZYY9GE4.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
デバッグが⾮常に困難
⇒ PIX on Windowsによるフレームキャプチャーも使⽤できない
NVIDIA Nsight Systemsが唯⼀複数GPUでの確認⼿段
⇒ 確認したことで新たな問題
・転送時のGPU負荷がかかっている
・Shared Heapsの並列化対応の必要性
⇒ さらに⾒つかった問題への対処へ
72
72
このズレの問題は発覚してから解決するまで難航しました。
GPUの数やAPIが特殊であるからか、PIXによるフレームキャプチャーも正しく動作しません。
つまりデバッグを⾏うことすら困難な問題です。
しかしNsight Systemsが唯⼀、複数GPUにまたがって稼働の内訳を時間軸で確認することができ
それによって、原因を特定できたことで解決へとつながりました。
それと同時に、転送時のGPU負荷がかかっていること、
Shared Heaps処理の並列化対応の必要性が明らかになりました。
72


# Page. 74

![Page Image](https://bcdn.docswell.com/page/9E2RGG2DJR.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
GPUの転送待ちがフレーム遅延の要因に
⇒ 32Bitフォーマットの4Kを転送することは重たい
PCIeでの転送にて
10.8ms も待たされる
73
73
⾒つかった問題の1つとして
4Kの32Bitフォーマットを転送することはPCI Expressへの負荷となるということです。
10.8msと⼤きなネックとなっていることが挙げられます。
73


# Page. 75

![Page Image](https://bcdn.docswell.com/page/D7YDVVYM7M.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
転送量と負荷の整理
GPU0
• 各GPUは6⾯分の送受信
• ⼀⾯あたり 4096 × 4096 × 4Byte = 64MiB
⇒ 64MiB × 6⾯ ≒ 384MiB/frame の送受信量︕
Send x1 Face
Receive x5 Faces
GPU1
• GPUに対してのPCIeは4.0 の 双⽅向64GiB/s
Send x2 Faces
Receive x4 Faces
• しかし理論値とはならず10msの待ちに
⇒ このままではリアルタイムとして成り⽴たない
64MiB
64 × 6 = 384MiB!
74
74
各GPU6⾯分の送受信を⾏います。
1⾯あたり64MiBとなるため、毎フレーム384MiBもの送受信となります︕
PCI Expressは4.0、スペック的には間に合いそうにも思えます。
しかし実際には理論性能通りにはならず
何らかのオーバーヘッドが発⽣したことによって10ms程度は待ちとなっていました。
このままではリアルタイムとして成り⽴ちません。
74


# Page. 76

![Page Image](https://bcdn.docswell.com/page/VEN6MMP3E8.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
YUV[出典4] を⽤いて2 x 2のブロックで圧縮
YUV422
YUV420
• リアルタイムで変換可能
• 結果半分の16Bit相当に
• フォーマットはICtCp（⾼輝度も扱える）
⇒ 画質は低下するが
転送にかかるコストを⼤幅に削減できると判断
75
75
そこでYUVにて圧縮することとします。
ピクセルをブロックに分割して、輝度はピクセルごとに残しますが、⾊成分を削減する⼿法です。
BC圧縮などとは異なり、リアルタイムでエンコードとデコードが可能であり
GPU処理としても軽量で削減効果が⾼いものです。
⾼輝度成分も使いたかったため最終的なフォーマットはICtCpとしましたが、
結果として半分の16Bit相当まで下げることができました。
⾊成分が少なくなるため画質は低下しますが、
それでも転送にかかるコストを⼤幅に削減できるとの判断のもと導⼊を致しました。
75


# Page. 77

![Page Image](https://bcdn.docswell.com/page/Y79LNN3PJ3.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
半分の5msに削減成功
⇒ 変換の負荷も低い
圧縮後は
10.8ms > 5.14ms に
圧縮後
圧縮前
転送時間
5.14ms
10.8ms
bpp
16Bit
32Bit
転送量
192MiB/frame
384MiB/frame
76
76
結果10msかかっていた負荷を、予想値と同等の半分の5msまで削減できました。
RGBからYUVへのエンコード、またその逆のデコード
それらも⼤した負荷とならず、直結した削減効果を得ることができました。
76


# Page. 78

![Page Image](https://bcdn.docswell.com/page/G78XKKMXED.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
Shared Heapsの並列化対応
⇒ レンダリング処理の裏で送受信し、PCIeでの転送待ちを⼤きく削減
受け取りの転送が
他GPU処理中にも動作する
レンダリングのためのGPU処理
77
77
そしてさらにShared Heapsの転送をレンダリングの裏で⾏うようにしました。
これにより、PCI Express転送による待ち時間の隠ぺいができ、
全体の処理時間の⼤幅な削減が達成できました。
そしてリアルタイムでの4Kキューブマップレンダリングが現実的になりました。
77


# Page. 79

![Page Image](https://bcdn.docswell.com/page/L7L8ZZ3NJR.jpg)

実現に向けたレンダリングの実装
②GPU同期した転送を実現する
GPU同期の実現までのまとめ
• Shared Heapsでの送受信テクスチャを作成
• レンダリング後のキューブマップをコピーで送受信
• ダブルバッファにて送受信の安定化
• テクスチャの圧縮と並列化で転送効率の改善
4つのGPUを使⽤したリアルタイム + マルチレンダリングまでは完成
78
78
GPU同期のまとめです。
タイミングや転送コストなどの問題も⽣じましたが
Shared Heapsを使⽤したうえで、各対処を⾏うことで形にすることができました。
これで4つのGPUを使⽤したリアルタイムでのマルチレンダリングまでは実装できたと⾔えます。
78


# Page. 80

![Page Image](https://bcdn.docswell.com/page/4EM6VVDQ7W.jpg)

実現に向けたレンダリングの実装
設計の基盤から具体的な課題へ
①GPUの役割分担をどうするか
分担をどのように⾏わせるのか
⇒
ここが基点
②GPU同期した転送を実現する
実際にキューブマップを同期させる
⇒
⼀番コアとなる難しい実装
③マルチディスプレイへの出⼒
仕上げとした出⼒
⇒
ここまで解決するとシステムが形になったことが⾒える
79
79
最後は同期されたキューブマップを各ディスプレイに切り出すのみです。
79


# Page. 81

![Page Image](https://bcdn.docswell.com/page/PERP224K79.jpg)

実現に向けたレンダリングの実装
③マルチディスプレイへの出⼒
マルチディスプレイへの出⼒⽅法
• マルチディスプレイに対しての出⼒はExecMaskにて振り分け可能
GPU Command …
GPU0
Draw CubeMap to Display
ExecMask : 0x1 = b0001
Draw CubeMap to Display
ExecMask : 0x4 = b0100
GPU2
GPU Command …
• ディスプレイへの描画は単純にViewPort切り抜き︖
⇒ 円柱形状に合わせた別の⽅法
NG
80
80
マルチディスプレイに対しての出⼒は「GPUの役割分担」にて説明したように
ExecMaskを⽤いることでどのGPUが⾏うかを振り分け可能です。
そのうえで単純にViewPortとして切り抜くだけで良いのでしょうか︖
そうではありません。
80


# Page. 82

![Page Image](https://bcdn.docswell.com/page/P7X3DD25EX.jpg)

実現に向けたレンダリングの実装
③マルチディスプレイへの出⼒
投影として出⼒する必要がある
• 円柱のどのディスプレイに対してかを指定
• 投影先を計算してキューブマップからのサンプルを⾏う
Projection
CubeMap Sample
Display Output
投影のイメージ
81
81
円柱に対しては単純な切り抜きではありません。
プロジェクションのように投影して出⼒する必要があります。
具体的にお話します。
まずは仮想的に設定した視点の⾼さを基準に
円柱上の物理的なディスプレイやプロジェクターの投影位置を求めます。
そして、その投影位置に対応するキューブマップのサンプル⽅向を計算します。
そうしてキューブマップからサンプルした結果をRender Target Textureに描きだし
それをディスプレイに出⼒させます。
81


# Page. 83

![Page Image](https://bcdn.docswell.com/page/37KYXXMRED.jpg)

実現に向けたレンダリングの実装
③マルチディスプレイへの出⼒
トーンマップも組み込む
• キューブマップはリニアな輝度であるため
• OCIOも使⽤している
Projection
CubeMap Sample
Tonemap
トーンマップ前
トーンマップ後
Display Output
82
82
またキューブマップの時点ではライティング直後の輝度そのものです。
トーンマップも必要になります。
そのため出⼒時にOCIOを使⽤したトーンマップも組み込んでいます。
82


# Page. 84

![Page Image](https://bcdn.docswell.com/page/LJ3955YGJ5.jpg)

12枚ディスプレイへの出⼒
83
83
ここまでの実装の結果をご覧ください。
12枚のディスプレイに対してリアルタイムの4Kキューブマップから投影出⼒されていることが確認できます。
※ 映像についてはDocswell「スライド概要」へ記載のYouTube講演映像からご確認ください。
83


# Page. 85

![Page Image](https://bcdn.docswell.com/page/8JDGDD5NJG.jpg)

実現に向けたレンダリングの実装
ディスプレイの出⼒のまとめ
• ExecMaskで出⼒するGPUを決定
• 円柱上への投影出⼒
• 出⼒時にトーンマップ
⇒ マルチGPUを⽤いたマルチディスプレイへのレンダリングは完成
しかし主要な機能1つだけでは実現には⾜りない
⇒ エンジン側だけでなく
タイトル側も並⾏して開発を進めることで発⽣する別の問題もあった
84
84
ディスプレイ出⼒の処理のまとめです。
ExecMaskで出⼒するGPUを決定し
円柱上への投影出⼒
そして出⼒時のトーンマップ
これでようやく、マルチGPUを⽤いたマルチディスプレイに対してのレンダリング、その機能は実装できました。
しかし機能１つだけでは実現には⾜りません。
エンジン側だけではなく、タイトル側も⼀緒に開発しているからこそ出てくる、別の問題も発⽣します。
84


# Page. 86

![Page Image](https://bcdn.docswell.com/page/VEP3XXGN78.jpg)

85
85
今度はタイトル側、開発環境などを含めてお話していきます。
85


# Page. 87

![Page Image](https://bcdn.docswell.com/page/27V4LL6YEQ.jpg)

開発が進むと⾒えてくる問題
模擬会場について
• エンジン側の実装に先⾏して
RE ENGINEのエディター上で作成された
• 既存のRE ENGINEの機能で作成
• 模擬会場内で実コンテンツの制作が進められた
⇒ ここまでは想定通り
86
86
エンジンチームでのマルチレンダリングが⽤意できるまでの間、
タイトルチームは既存のRE ENGINEの機能を使⽤して
1台のPCでも確認できる、模擬会場を作成しました。
そのうえで実コンテンツの制作も並⾏して進められておりました。
86


# Page. 88

![Page Image](https://bcdn.docswell.com/page/5JG1XXNW7L.jpg)

模擬会場
87
87
この段階になりますとシアターの構造も決まっており、コンテンツの開発も進められています。
しかし、いくつかの問題も⾒えてきます。
何かの境界に対して、切れ⽬が⽣じていたり、ねじれや不⼀致が⽣じていることが分かりますでしょうか。
※ 映像についてはDocswell「スライド概要」へ記載のYouTube講演映像からご確認ください。
87


# Page. 89

![Page Image](https://bcdn.docswell.com/page/47QD88QQEP.jpg)

開発が進むと⾒えてくる問題
通常のゲーム前提では想定しない問題が発⽣
① ビルボードがつながらない
② GUIが意図しない⾒た⽬になる
③ ポストプロセスに切れ⽬が発⽣
⇒ キューブマップをそのまま出⼒に使⽤しているための問題
88
88
輝度のままであるキューブマップを、そのまま出⼒に使⽤しているため
通常のゲームでは想定していない様々な問題が発⽣します。
ビルボード、GUI、ポストプロセスに対して問題が発⽣しました。
それぞれ具体的に⾒ていきます。
88


# Page. 90

![Page Image](https://bcdn.docswell.com/page/KE4Z22NYJ1.jpg)

開発が進むと⾒えてくる問題
①ビルボードがつながらない
キューブマップの境界で、ビルボードに折れやズレが発⽣
折れやズレが発⽣
89
89
⼤きい問題としてVFXなどで使⽤されているビルボードが挙げられました。
画⾯中央がキューブマップごとの⾯同⼠の接合部分です。
折り⽬のようになっていることが分かりますでしょうか︖
89


# Page. 91

![Page Image](https://bcdn.docswell.com/page/L71RMM5N7G.jpg)

開発が進むと⾒えてくる問題
①ビルボードがつながらない
キューブマップに対するビルボードの問題整理
• キューブマップは、⾯ごとにカメラの向きを90°ずつ合わせてレンダリング
• ビルボードはカメラ⾯に正対させてメッシュ構築
• キューブマップ⾯の境⽬、つまり異なるカメラ間で折れやズレにつながる
• Z⽅向の回転や前後関係の順番も問題につながる
ビルボードは各カメラに正対
カメラ毎に
ビルボードの⾓度も変わる
回転の値が同じでも
ズレや折れにつながる
90
90
キューブマップは6⾯それぞれに対して正対した、画⾓90°のカメラでレンダリングします。
ビルボードは通常それらのカメラに正対してメッシュを構築します。
そうすると各⾯の画⾯端を跨ぐビルボードは、
各⾯ごとに向きが変わってしまい、⾯を跨いでズレたり折れ曲がったような⾒た⽬になります。
90


# Page. 92

![Page Image](https://bcdn.docswell.com/page/G7W133WMJ2.jpg)

開発が進むと⾒えてくる問題
①ビルボードがつながらない
ビルボード問題の解決⼿段
• カメラの⾯ではなく、カメラの位置に対して正対させた
• 描画順のソートをスクリーン深度ではなく、キューブマップ中⼼との距離に
カメラの⾯に正対
カメラの位置に正対
つなぎ⽬でも違和感がない
91
91
そこでカメラの⾯ではなく、カメラの位置に対して正対させ、
描画順もスクリーン深度ではなく、キューブマップ中⼼との距離にてソートさせるように変更しました。
これでキューブマップのつなぎ⽬でも違和感なく接合されるビルボードとなります。
91


# Page. 93

![Page Image](https://bcdn.docswell.com/page/4JZPVV5M73.jpg)

開発が進むと⾒えてくる問題
②GUIが意図しない⾒た⽬になる
ロゴ表⽰に対してのGUI問題
• 通常はカメラに紐づいたGUI描画で問題ない
• GUI描画先がキューブマップであるためゆがみが発⽣
• さらにリニア輝度であるため意図しない⾊味や混ざりが⽣じる
意図しない⾊とゆがみ
リニア輝度のキューブマップに描画されるため
92
92
次にGUIの問題となります。
体験内でロゴを表⽰したいという話が出ました。
しかしレンダリングターゲットが輝度そのままであるキューブマップです。
通常のGUI描画を⾏うと、⽩⾶びなどしたり、円柱への投影によってゆがみが⽣じてしまう結果になります。
92


# Page. 94

![Page Image](https://bcdn.docswell.com/page/YE6M5595JV.jpg)

開発が進むと⾒えてくる問題
②GUIが意図しない⾒た⽬になる
GUI問題の解決⼿段
• GUI⽤のテクスチャに描画を⾏う
• 出⼒時のトーンマップ後、円柱への投影として合成
Projection
CubeMap Sample
Tonemap
GUI
最終的な体験中の表⽰
Display Output
93
93
そのためGUI⽤のテクスチャに描画を⾏ったものをディスプレイ出⼒時のトーンマップ後に合成させる、
専⽤処理を追加することで対応致しました。
93


# Page. 95

![Page Image](https://bcdn.docswell.com/page/GE5ZYYNG74.jpg)

開発が進むと⾒えてくる問題
③ポストプロセスに切れ⽬が発⽣
ポストプロセス処理問題
• UVをずらしてサンプルするようなものは控えて頂く
• ブルームのみ対応することに
⾯ごとのポストプロセスは
他の⾯を考慮しないため
つなぎ⽬がおかしくなる
NG
太陽のブルームがキューブの端で崩れる
各⾯にぼかしを加えた、キューブマップの例
94
94
ポストプロセス処理も問題となります。
UVをずらす処理は控えて頂きましたが、全般的な汎⽤性を考慮してブルームのみ対応することにしました。
左側が実際に問題が⽣じた時のものですが
キューブマップのつなぎ⽬に、太陽のブルームが崩れることが確認できるかと思います。
これはキューブマップの各⾯単位でブルームがなされるから⽣じるものです。
右側の例のようにキューブマップを⾯ごとにぼかしてみると確認できます。
94


# Page. 96

![Page Image](https://bcdn.docswell.com/page/972RGG5DER.jpg)

開発が進むと⾒えてくる問題
③ポストプロセスに切れ⽬が発⽣
ブルームの解決⼿段
• キューブマップ上で周辺⽅向複数にサンプルしつつ、ダウンサンプル
• ダウンサンプル後のキューブマップ複数枚をマージさせる（KawaseBloom[出典5]と近い）
ピクセル⽅向 +
⾓度を変えた周辺⽅向で
重みを含めてサンプル
それをダウンサンプルしつつ結合
周辺サンプルとダウンサンプルのイメージ
結合後
95
95
対応の詳細となります。
仕組みとしては KawaseBloom等と考え⽅は近く、よくある軽量な⽅式です。
周辺のピクセルをサンプルしつつ、キューブマップをダウンサンプルしていきます。
最後にそれらを結合することでブルームとするものです。
これであれば、⾯を跨いだピクセルもサンプルされるため切れ⽬は⽣じません。
95


# Page. 97

![Page Image](https://bcdn.docswell.com/page/DJYDVVKMJM.jpg)

開発が進むと⾒えてくる問題
③ポストプロセスに切れ⽬が発⽣
その他ポストプロセスに関連する話
• SSAOはそのまま使⽤
⇒ ⾒た⽬ではキューブマップ境界の違和感は出ていないため
• VFXでもブラーやDistortionなど、画⾯をゆがめる処理は使⽤しない
すべてを完璧に技術的に対応するわけではなく
コストやリスクも考慮して、制約や落としどころを正しく選択する
ゲーム開発者としても重要な考え⽅
96
96
余談ではありますが、実はキューブマップへのレンダリングでもSSAOなどは使⽤されております。
ただ、⾒た⽬ではキューブマップ境界の違和感は出ていないためそのままとしています。
またVFXでも⼀部処理は使⽤しないなどの⽅針を決めております。
すべてを技術で対応するわけではなく、コストやリスクも考えて、制約や落としどころを正しく選択する。
それはゲーム開発者としても重要な考え⽅であると思っております。
96


# Page. 98

![Page Image](https://bcdn.docswell.com/page/V7N6MMR378.jpg)

開発が進むと⾒えてくる問題
これでレンダリング機能の実装はすべて完了︖
⇒ そうではありません。
97
97
さて、これで実装がすべて完了しました。
本当にそう⾔えるのでしょうか︖
97


# Page. 99

![Page Image](https://bcdn.docswell.com/page/YJ9LNNMPE3.jpg)

98
98
「ミライのエンターテインメント」としての未踏の試みは
未踏ならではの不具合を引き起こします。
ここまではカプコン社内、開発PC内のみの話でありました。
ここからはXD HALLが竣⼯し、理論上だけではなく現実空間で発⽣した問題の話となります。
98


# Page. 100

![Page Image](https://bcdn.docswell.com/page/GJ8XKKLX7D.jpg)

現地で出てきた問題
現地で未踏ならではの不具合が確認される
⇒ 主に想定外のディスプレイ出⼒の問題によるもの
① 切り出しが合わない
② シースルーであるため側⾯から天井が透ける
③ カラーシフト問題
④ 同期が合わない
99
99
模擬ではない現地夢洲に、シアターが出来上がり確認が始まりました。
そうすると、切り出しの問題や天井が透ける問題、カラーシフトや同期等、
ディスプレイに関わる想定外の問題が発覚してきました。
99


# Page. 101

![Page Image](https://bcdn.docswell.com/page/LJL8ZZLNER.jpg)

現地で出てきた問題
①切り出しが合わない
ディスプレイへの切り出し設定が想定と合致しない
• 現地でなければ確認できない
• 移動に⽚道1時間はかかる
• ネットワークでのやり取りにも限界がある
切り出しが合わず、天井と壁⾯がズレてしまう
100
100
⼀つはディスプレイへの切り出し設定が、想定と合致しない問題です。
事前に細かくすり合わせをしても、⼤規模になると起こるべくして発⽣します。
調整が必要になります。
しかし修正したのでパッケージを確認してください、という通常の開発フローでは問題があります。
現地にもっていかなければ確認できないということになりますが、
その移動に⽚道1時間はかかります。
そしてネットワークのやり取りでも解決しきれません。
100


# Page. 102

![Page Image](https://bcdn.docswell.com/page/47M6VVMQJW.jpg)

現地で出てきた問題
①切り出しが合わない
現地での調整への対策
１．パッケージだけでなく
協⼒会社様向けのRE ENGINEをSSDに⼊れて持ち込み
２．起動時に調整設定ファイルを読み込む機能を追加
⇒ XD HALL内での調整が可能に
３．ディスプレイチェックのデバッグ機能を多数⽤意
• キューブマップのつながり
• ディスプレイの発⾊チェック
• 同期のためのスキャンライン
⇒ 現地にて調整できる⼟台が整った
101
101
まずはライセンスなどの問題もあるため、協⼒会社様向けのRE ENGINEをSSDに⼊れ
それをポータブルREとして持ち込むようにしました。
そして実装として、起動時に調整が反映されるように設定ファイルを⽤意致しました。
これによって調整後の状態を即時パッケージ反映させることも可能になります。
さらにディスプレイチェック⽤のデバッグ機能を多数⽤意致しました。
何があるかもわからないため、思いつく限り実装した記憶があります。
これで調整できる⼟台は整いました。
101


# Page. 103

![Page Image](https://bcdn.docswell.com/page/P7RP22VKJ9.jpg)

XD HALLでのデバッグ
102
102
こちらが360°シアター内でのデバッグの様⼦です。
機材というよりも、もはや建築物であり、最終的な⾒え⽅は現地でしか確認できません。
実際、私は数回しか⾜を運べておりませんが、現地だからこそ得られた情報や考えもあります。
このプロジェクトだからこそ得られた経験です。
※ 映像についてはDocswell「スライド概要」へ記載のYouTube講演映像からご確認ください。
102


# Page. 104

![Page Image](https://bcdn.docswell.com/page/PJX3DDZ57X.jpg)

現地で出てきた問題
②シースルーであるため側⾯から天井が透ける
シースルーLEDは壁⾯が透過する
• 天井LEDの円の外の領域が、壁⾯から⾒えてしまう
• そのため円状にくりぬいて⿊塗りする処理を、天井のディスプレイ出⼒に追加
LEDから天井が透ける
透過して天井が⾒えるイメージ
出⼒時に塗りつぶし
⇒ 透過して⾒えていた天井部分が⽬⽴たなくなった
103
103
さて、イマーシブサウンドシステムを活⽤するために、壁⾯と天井にはシースルーLEDが採⽤されています。
シースルーLEDで⾯は遮蔽されていません。
したがって、壁⾯を通して天井のLEDが⾒えるもので、そこから円の外の領域も⾒えてしまいました。
そのため、天井は円状にくりぬいて⿊塗りする処理をディスプレイ出⼒に追加しております。
103


# Page. 105

![Page Image](https://bcdn.docswell.com/page/3JKYXX8R7D.jpg)

現地で出てきた問題
③カラーシフト問題
天井の前⽅は⻘い
カラーシフト問題が発⽣
• 同じ⾊で出⼒しても場所ごとに
天井や壁の⾊が変化する
• 通常のゲーム開発では全く
想定されていない聞いたことも無い問題
原因は完全に解明できていない
天井の後⽅は⾚い
壁⾯も⾓度で若⼲変化する
⽩でも前後で⾊が異なるパノラマ写真
⇒ おそらくLED同⼠の発光の⼲渉と
LEDと⽬の⾓度によって⽣じるものと推測
⇒ ⽴ち位置によっても⾒え⽅が変化する
完全な解決は不可能
素⼦のずれや⼲渉は推測
104
104
そして同じ⾊でLEDに出⼒しても、天井や壁の⾊が変化してしまうカラーシフトが⼤きい問題となりました。
通常のゲーム開発では全く想定されていない、聞いたことも無い問題です。
LEDの⼲渉や素⼦のずれなどいくつかの推測は⽴てられましたが、原因は解明できておりません。
また、完全解決は不可能と⾒られます。
104


# Page. 106

![Page Image](https://bcdn.docswell.com/page/LE39552GE5.jpg)

現地で出てきた問題
③カラーシフト問題
カラーシフト問題の解決策
• 壁や天井に対してある程度の傾向が⾒られる
• 技術的な解決から考えを切り替える
• 補正⾊を天井の⽅向や壁の上下に対してかけられるように追加
• 現地にて⽬で⾒て⽬⽴たないように調整
調整中
調整後は⽬⽴たなく
⇒ ⽬⽴たないレベルまで抑えることができた
105
105
しかしながら、壁や天井に対してある程度の傾向が⾒られました。
そのため技術的な解決から考えを切り替えました。
天井の⽅向や壁の上下に対して補正⾊をかけられるように追加し
それを現地にて、⽬⽴たないように調整を頂くことで解決としました。
105


# Page. 107

![Page Image](https://bcdn.docswell.com/page/8EDGDDZNEG.jpg)

現地で出てきた問題
④同期が合わない
LED出⼒の同期がまれにズレる問題
• GPU間やキューブマップ同期のズレではない
• Quadro Sync IIを使⽤しているが発⽣
LED A
LED B
LEDの境⽬が、同期ズレによって⽬⽴つ
106
106
そして最後まで最も問題となったのは
ディスプレイ出⼒の同期がまれにズレることがあるということでした。
GPU間のキューブマップ同期のズレではなく、出⼒先ディスプレイ同⼠の同期ズレです。
Quadro Sync IIを使⽤しているにも関わらず発⽣します。
106


# Page. 108

![Page Image](https://bcdn.docswell.com/page/V7P3XXDNJ8.jpg)

現地で出てきた問題
④同期が合わない
出⼒ズレに対しての考慮や検証
• NVIDIAのMosaic構成
⇒ 機材構成的にも使⽤できなかったため未検証
• 単純な同期チェックアプリではズレは⽣じない
• 最終盤で発覚した問題であり期⽇も迫る
• プログラムのみでは解決⼿段もなく対応不可
• 最後の候補としてNVIDIA社にご協⼒を仰ぎ、NvAPIのPresentBarrier[出典6]を検証
⇒ 本件の要件とは適合しないことが確認された
⇒ 判断を切り替える必要がある
107
107
この問題の対応策はNVIDIAのMosaic構成が考えられますが
モンスターPC構成時に問題があったため使⽤されなかった経緯があります。
そこで、NVIDIA社とも相談させて頂きながらNvAPIのPresentBarrierも検証致しました。
しかし期待するように同期がなされず、こちらも断念せざるを得ませんでした。
単純なディスプレイ同期チェックアプリであればズレは⽣じません。
しかしプログラムのみでは解決⼿段もなく対応不可とも⾒れました。
そして最終盤で発覚した問題であり、期⽇も迫っています。
ここでも判断を切り替える必要がありました。
107


# Page. 109

![Page Image](https://bcdn.docswell.com/page/2JV4LL1Y7Q.jpg)

現地で出てきた問題
④同期が合わない
天井と壁⾯ならズレは気にならない
そのため同じGPUに担当させたほうが良い
出⼒ズレ解決のための施策
• 1つのGPUの出⼒のグループであれば
ズレが発⽣しないことを確認
• 壁⾯や天井⾯同⼠でズレなければ違和感もない
• そこが解決すれば問題ないと判断を切り替え
• ディスプレイ出⼒の
GPU分散の設定を切り替えることで回避
正しい解決への推測
• Quadro Sync IIとHouse Sync Generatorでの
Genlock構成が必要であった︖
GPU0
Wall1 Floor1 Ceiling1
GPU1
Wall2 Floor2 Floor3
GPU2
Wall3 Floor4 Floor5
GPU3
Wall4 Floor6 Ceiling2
GPU0
Floor1 Floor2 Floor3
GPU1
Ceiling1 Ceiling2
GPU2
Floor4 Floor5 Floor6
GPU3
Wall1 Wall2 Wall3 Wall4
• ディスプレイとも直接同期をするようにすることで対応できた︖
• 新規機材も⽤意できるタイミングではなかったため未検証
1つのGPUグループとして
壁⾯全てを設定してズレを防⽌
108
108
1つのGPUからの出⼒のグループであればズレが発⽣しないことは確認できていました。
そのため壁⾯や天井⾯同⼠でズレが無ければ違和感もない、そこだけが解決できていれば問題ないと、判断を切り替えました。
そして、GPU分散のディスプレイ出⼒先設定を切り替えることで回避としました。
もしかしますとQuadro Sync IIに対してHouse Sync Generatorを導⼊すると改善できた可能性はあります。
しかし、すでに新規機材も⽤意できるタイミングではなかったため、こちらも検証することはできておりません。
個⼈的にもこの問題に関して解法がお分かりの⽅がおりましたら、是⾮ともご解説を頂けますと幸いと思っております。
108


# Page. 110

![Page Image](https://bcdn.docswell.com/page/5EG1XX2WJL.jpg)

現地で出てきた問題
現地問題のまとめ
• 現地で⾒つかった問題に対して対応が出来なかったものは反省点
⇒ しかし着地点としての機能を提供できた
• 技術的に挑戦はするが、それ以外の⾯で解決を進めることも重要
• 最終的な調整を頂いたタイトルの⽅々
ご相談に応じて頂けたNVIDIA Corporation様に感謝
109
109
現地で⾒つかった問題に対して正確に対応が出来なかったものは多々あり反省点としたいですが、
何とか着地点としての機能を提供できたことは安⼼しました。
技術的には挑戦はすることは前提としても、問題に対して、それ以外の⾯から⾒て解決を進める。
改めてそれもエンジニアとして重要であることを実感できました。
また実際に現地で最終的な調整を頂いたタイトルの⽅々。
相談に応じて頂いたNVIDIA社にもここで改めて感謝を述べたいと思います。
109


# Page. 111

![Page Image](https://bcdn.docswell.com/page/4JQD88PQ7P.jpg)

110
110
最後にまとめとなります。
110


# Page. 112

![Page Image](https://bcdn.docswell.com/page/K74Z22YYE1.jpg)

まとめ
• 通常のゲームの前提が通じないタイトルだが、仕組みを完成させることができた
⇒ マルチGPU +マルチディスプレイ のレンダリングの実装と
それを前提とした環境も設計も重要であった
• 想定していない問題も多々⽣じるが、多⾓的な視点で解決を考えることは重要
• 改善可能な余地はあるため、機会があればさらに良くしたい
• マルチGPUレンダリング、もしくはマルチディスプレイレンダリング
別の視点や構想で、あるいは未来で応⽤できれば望ましい
• 過去事例も、実践する機会も少ない事例ですが
このような取り組みに挑戦される際のご参考になれば幸いです。
111
111
未踏の構成であり、通常の前提が通じないものではありましたが何とか達成することができました。
やはり技術も⼤切ですが、それ以外の視点も持つことは重要であると感じています。
またこれはあくまで私個⼈の考えですが、
今回の技術は他の分野にも応⽤できる可能性があると感じています。
そのため、本件のみにとどまらず、今後の取り組みにつながっていけば嬉しいと思っていますし
過去事例も、実践する機会も少ない事例ですが、このような取り組みに挑戦される際のご参考になれば幸いです。
111


# Page. 113

![Page Image](https://bcdn.docswell.com/page/LJ1RMM6NJG.jpg)

参考
参考出典 1 / 2
1. GPU駆動レンダリングへの取り組み
https://www.docswell.com/s/CAPCOM_RandD/Z2GP4Z-2022-07-15-121419
2. Multi-adapter systems – Win32 apps
https://learn.microsoft.com/en-us/windows/win32/direct3d12/multi-engine
3. Shared Heaps – Win32 apps
https://learn.microsoft.com/en-us/windows/win32/direct3d12/shared-heaps
112
112
こちら出典元となります。
112


# Page. 114

![Page Image](https://bcdn.docswell.com/page/GJW1334ME2.jpg)

参考
参考出典 2 / 2
4. ITU-R BT.2100
https://www.itu.int/rec/R-REC-BT.2100
5. Masaki Kawase GDC2003
http://www.daionet.gr.jp/~masa/archives/GDC2003_DSTEAL.ppt
6. Synchronizing Present Calls Between Applications on Distributed Systems with DirectX 12
https://developer.nvidia.com/blog/synchronizing-present-calls-between-applications-on-distributedsystems-with-directx-12/
113
113
では、本講演は以上となります。ご清聴ありがとうございました。
113


# Page. 115

![Page Image](https://bcdn.docswell.com/page/4EZPVV2MJ3.jpg)

付録
Shared Heapsの実装
// 送信側の作成実装
// D3D12_HEAP_FLAG_SHARED | D3D12_HEAP_FLAG_SHARED_CROSS_ADAPTER をともに指定する
// Shared Heaps として Heap作成
CD3DX12_HEAP_DESC heapDesc(
total_bytes, D3D12_HEAP_TYPE_DEFAULT, 0,
D3D12_HEAP_FLAG_SHARED | D3D12_HEAP_FLAG_SHARED_CROSS_ADAPTER);
ComPtr<ID3D12Heap>crossAdapter;
device->CreateHeap(&heapDesc, IID_PPV_ARGS(&crossAdapter));
// Shared Heaps として Fence作成
ComPtr<ID3D12Fence>fence;
device->CreateFence(
0, D3D12_FENCE_FLAG_SHARED | D3D12_FENCE_FLAG_SHARED_CROSS_ADAPTER,
IID_PPV_ARGS(&fence));
114
114
114


# Page. 116

![Page Image](https://bcdn.docswell.com/page/Y76M55V5EV.jpg)

付録
Shared Heapsの実装
// Heap内に1つだけコピー受け取り⽤のTextureを作成する。これは操作もサンプリングもできない
// 送信元であるので混乱するが
// コピー先としてCopyTexture() を⾏うことで送信処理が⾏われる
auto crossAdapterDesc = CD3DX12_RESOURCE_DESC::Buffer(total_bytes,
D3D12_RESOURCE_FLAG_ALLOW_CROSS_ADAPTER);
ComPtr<ID3D12Resource>sendTexture;
device->CreatePlacedResource(
crossAdapter.Get(), 0, &crossAdapterDesc,
D3D12_RESOURCE_STATE_COPY_DEST, nullptr, IID_PPV_ARGS(&sendTexture));
115
115
115


# Page. 117

![Page Image](https://bcdn.docswell.com/page/G75ZYYDGJ4.jpg)

付録
Shared Heapsの実装
// 送信側からHandleを作成
HANDLE heapHandle = nullptr;
device->CreateSharedHandle( crossAdapter.Get(), nullptr, GENERIC_ALL, nullptr, &heapHandle);
HANDLE fenceHandle = nullptr;
device->CreateSharedHandle( fence.Get(), nullptr, GENERIC_ALL, nullptr, &fenceHandle);
// 受信側は heapHandle と fenceHandle から OpenSharedHandle()を使⽤してHeap と Fence を⽣成
ComPtr<ID3D12Heap>crossAdapter;
device->OpenSharedHandle(heapHandle, IID_PPV_ARGS(&crossAdapter));
ComPtr<ID3D12Fence>crossFence;
device->OpenSharedHandle(fenceHandle, IID_PPV_ARGS(&crossFence));
116
116
116


# Page. 118

![Page Image](https://bcdn.docswell.com/page/9J2RGG8D7R.jpg)

付録
Shared Heapsの実装
// Heap内に1つだけコピー元としてTextureを作成する
// 受信先ではあるが
// 実際にレンダリングで使⽤するときはCopyTexture()にて別のTextureに取り出すため
auto crossAdapterDesc = CD3DX12_RESOURCE_DESC::Buffer(total_bytes,
D3D12_RESOURCE_FLAG_ALLOW_CROSS_ADAPTER);
ComPtr<ID3D12Resource>receiveTexture;
device->CreatePlacedResource(
crossAdapter.Get(), 0, &crossAdapterDesc,
D3D12_RESOURCE_STATE_COPY_SOURCE, nullptr, IID_PPV_ARGS(&receiveTexture));
117
117
117