---
title: 『鬼武者 Way of the Sword』『モンスターハンターワイルズ』のVFXに息吹を与える「VORTEXEL」 [RE:2026 2026年10月2日登壇]
tags:  #capcom #カプコン #カプコン技研 #re engine #re2026capcom #ゲーム開発 #ゲームエンジン #vortexel #鬼武者ws #モンスターハンターワイルズ  
author: [カプコン技研](https://image.docswell.com/user/CAPCOM_RandD)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/5JG1G4ZX7L.jpg?width=480
description: 2026年10月にカプコンが開催した「CAPCOM オープンカンファレンス RE:2026」の講演資料です。  ■ 講演映像(再生リスト) https://www.youtube.com/watch?v=sHM9kl1e43E&list=PLD_N6X6tKlCM
published: November 13, 26
canonical: https://image.docswell.com/s/CAPCOM_RandD/KPRPE4-RE2026-EAST-7
---
# Page. 1

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

『⿁武者 Way of the Sword』
『モンスターハンターワイルズ』の
VFXに息吹を与える「VORTEXEL」
米山 哲平
1


# Page. 2

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

『⿁武者 Way of the Sword』
『モンスターハンターワイルズ』の
VFXに息吹を与える「VORTEXEL」
米山 哲平
1
それでは只今よりVORTEXELというシステムについてお話をさせていただきます。
よろしくお願いいたします。
1


# Page. 3

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

• 自己紹介
• VORTEXEL
└ 概要
└ Geometry
└ Turbulence
└ Thermal Conductor
当セッションはCEDEC2025で発表した内容に
その後の拡張と『⿁武者 Way of the Sword』での
活用事例を追加したものとなっています
└ Physics
• Extra Content
22
当セッションではこのような構成で進めさせていただきます。
自己紹介から実装の経緯、各機能の解説と使用例等を順番にご説明します。
なお、当セッションはCEDEC2025で発表した内容をベースとしており、
その後の拡張と『⿁武者 Way of the Sword』での活用事例を追加したものとなっています。
CEDEC2025ではかなり高い評価をたくさん頂きありがとうございました。この場を借りて感謝申し上げます。
2


# Page. 4

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

自己紹介
米山 哲平
• 2013年にカプコンに入社
└ 当初RE ENGINEのエフェクトエンジンユニットに所属
• モンスターハンター:ワールド時代 (2015～2019)
└ MT FRAMEWORKベースのエンジンで専属エフェクトプログラマとして担当
└ アイスボーンも引き続き担当
• RE ENGINEのエフェクトエンジンユニットに合流
└ しばらくはモンスターハンターワイルズを中心にサポート
• 過去の発表
└ MH:W | GPU Particle - モンスターハンター:ワールドにおけるGPU Particleの実装
https://www.docswell.com/s/CAPCOM_RandD/Z7DPJK-2022-07-15-133910
33
まずは簡単な自己紹介をさせてください。
自分は2013年に入社してしばらく、RE ENGINEのエフェクトエンジンユニットに所属していました。
その後、『モンスターハンター:ワールド』チームへ専属のエフェクトエンジンプログラマとして所属することになりました。
そしてRE ENGINEへ再び合流し、エフェクトエンジンユニットのメンバーとしてサポートを行っています。
合流後もしばらくは『モンスターハンターワイルズ』を中心にサポートを行っていました。
で、この自己紹介が結構大事で━━
3


# Page. 5

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

自己紹介
米山 哲平
• 2013年にカプコンに入社
└ 当初RE ENGINEのエフェクトエンジンユニットに所属
• モンスターハンター:ワールド時代 (2015～2019)
└ MT FRAMEWORKベースのエンジンで専属エフェクトプログラマとして担当
└ アイスボーンも引き続き担当
• RE ENGINEのエフェクトエンジンユニットに合流
└ しばらくはモンスターハンターワイルズを中心にサポート
• 過去の発表
└ MH:W | GPU Particle - モンスターハンター:ワールドにおけるGPU Particleの実装
https://www.docswell.com/s/CAPCOM_RandD/Z7DPJK-2022-07-15-133910
44
今回制作したシステムはまさしくこの『モンスターハンター:ワールド』でやりたかったことの集大成なためです。
4


# Page. 6

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

モチベーション
モンスターハンター:ワールドからのフィードバック
• 当時タイトル側に席を置いて密接に連携していた
• 次回作でやってみたい事をVFXアーティストと語り合う
└ 雑談ベースの妄想話がとても大事
└ いろんなインスピレーションを得た
→ VORTEXELの開発へ
55
今回ご紹介する技術は『モンスターハンター:ワールド』を作っていく中で出てきたアイディアが発端となっています。
当時は変則的にアーティスト席と非常に近い場所で制作していました。
それもあってアーティストと雑談しながら「もっとスペックがあったら何がしたいか」、「今回なにがめんどくさかったか」、「欲しかった機能は何か」などの情報を収集してました。
おかげでいろんなインスピレーションを得てVORTEXEL構想が立ち上がりました。
そしてこの度
5


# Page. 7

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

モチベーション
モンスターハンター:ワールドからのフィードバック
• 当時タイトル側に席を置いて密接に連携していた
• 次回作でやってみたい事をVFXアーティストと語り合う
└ 雑談ベースの妄想話がとても大事
└ いろんなインスピレーションを得た
→ VORTEXELの開発へ
+ モンハンワイルズのフィードバックを⿁武者WSに反映・拡張
66
『モンスターハンターワイルズ』からのフィードバックを回収しつつ、『⿁武者WS』に対して反映および拡張を行うまでになりました。
6


# Page. 8

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

77
というわけでここからが本編となります。
ぜひ楽しんでいただければと思います!
7


# Page. 9

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

キャッチコピー
88
VORTEXELにはキャッチコピーがあります。
それが
8


# Page. 10

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

キャッチコピー
次世代の
風
を感じよう
※ 2022.02.24 モンハンワイルズチームに共有した
ときに実際に使用したキャッチコピー
99
「次世代の風を感じよう」 です。
これは実際に 2022.02.24『モンスターハンターワイルズ』チームにVORTEXELの情報を共有したときに使ったキャッチコピーです。
この映像はいくつもの重要な要素を示しています。詳しく見ていきましょう。
9


# Page. 11

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

ボルテクセル
VORTEXELとは?
GPUによる超並列処理を利用した
ジオメトリエコシステムの「総称」です
名前の由来
• 3D Texture の要素である Voxel(ボクセル)
• 渦・旋風を意味する Vortex(ボルテックス)
名前の通り ボクセル や 3D Texture といった
ボリュームデータで各種シミュレーションを行います
10
10
まずVORTEXELとは?
GPUによる超並列処理を利用したジオメトリエコシステムの「総称」です。
名前の由来は
3D Texture の要素である ボクセル
うず・せんぷうを意味する ボルテックス
から来ています。
名前の通り ボクセル や 3D Texture といったボリュームデータで各種シミュレーションを行います。
これによって何ができるか?それがこちらです。
10


# Page. 12

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

何ができるの?
地形に沿って風を吹かせられます!
11
11
地形に沿って風を吹かせられます!
このパーティクル群は直接はコリジョンを取っていません。
空間の風に流しているだけです。
つぎに
11


# Page. 13

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

何ができるの?
焼畑出来ます!
12
12
焼畑出来ます!
『モンスターハンターワイルズ』での草原の延焼も当機能によってできた表現です。
風の影響を受けて炎の勢いも変わります。
そして
12


# Page. 14

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

何ができるの?
小石を大量に転がせられます!
13
13
小石を大量に転がせられます
『ワイルズ』をプレイした方はプレイヤー/モンスター問わずあらゆる場面で破片が出ていたことに気づいたかと思います。
これが実現できたのはVORTEXELの恩恵があったからこそです。
13


# Page. 15

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

何ができるの?
大量の髑髏とインタラクション!
14
14
そして新たに『⿁武者WS』では髑髏が大量に転がった印象的なシーンでの戦闘演出にも使用されており、
キャラクターインタラクションによってより迫力のある戦闘となっています。
14


# Page. 16

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

複数の機能?
VORTEXELの中に複数のモジュールが存在
→ ジオメトリエコシステムとして連携
Geometry
地形解析
Physics
物理演算
Turbulence
風流体
Thermal Conductor
熱伝播
15
15
先ほどの動画を見ると複数の機能を有しているように見えます。
実際にそれぞれの機能を実現するために複数のモジュールがVORTEXELの中に存在しており
これがジオメトリエコシステムとして連携しています。
先に述べた「総称である」というのはこのことです。
連携に関してもう少し詳しく見ましょう。
15


# Page. 17

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

各機能との連携
VORTEXEL
Geometry
地形解析
Physics
物理演算
Turbulence
風流体
Thermal Conductor
熱伝播
16
16
VORTEXEL内のモジュールはそれぞれ
16


# Page. 18

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

各機能との連携
VORTEXEL
Geometry
地形解析
Physics
物理演算
Turbulence
風流体
Thermal Conductor
熱伝播
17
17
片方向でのみ依存するように設計されています。
これは保守コストや処理をスケールしやすくするために気を使った部分でもあります。
例えば
17


# Page. 19

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

各機能との連携
VORTEXEL
Geometry
地形解析
Physics
物理演算
Turbulence
風流体
風下でより燃える
Thermal Conductor
熱伝播
18
18
熱伝播は風下でより燃えるように風流体を参照し
18


# Page. 20

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

各機能との連携
VORTEXEL
Geometry
地形解析
遮蔽情報の参照
Physics
物理演算
Turbulence
風流体
風下でより燃える
Thermal Conductor
熱伝播
19
19
風流体は流体シミュレーションのために地形の遮蔽情報を参照
19


# Page. 21

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

各機能との連携
VORTEXEL
Geometry
地形解析
地形を参照
Physics
物理演算
遮蔽情報の参照
Turbulence
風流体
風下でより燃える
Thermal Conductor
熱伝播
20
20
もちろん物理演算でも地形情報を参照します。
そしてこれらの情報はVORTEXEL内で完結せず
20


# Page. 22

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

各機能との連携
VORTEXEL
遮蔽情報の参照
Geometry
地形解析
小石を転がす
Physics
物理演算
2D/3D流体
エフェクト
パーティクル
Turbulence
風流体
Thermal Conductor
熱伝播
21
21
他システムでも利用されます。
21


# Page. 23

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

各機能との連携
VORTEXEL
Geometry
地形解析
2D/3D流体
Physics
物理演算
エフェクト
パーティクル
Turbulence
風流体
風で揺れる
Thermal Conductor
熱伝播
草燃え検出
Cloth
タイトル
スクリプト
22
22
最終的にはエフェクトユニットだけではなく他ユニットのシステムからも利用されるまでに至りました。
実装時に他ユニットからの利用のしやすさなどにも気を付けたのも功を奏しました。
その辺の話も後ほど行いたいと思います。
22


# Page. 24

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

23
23
というわけでここからは各モジュールの説明をしていきます。
まずはGeometryです。
23


# Page. 25

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

Geometry
GPU上で認識される衝突判定空間の構築および管理を担当
└ VORTEXELの基点となる機能
24
24
GeometryはGPU上で認識するための衝突判定空間を
解析および構築するモジュールです。
この機能はVORTEXELの中でも比較的重要な機能です。
なぜならばまずは空間を認識しないと始まらないためです。
24


# Page. 26

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

構築範囲
• 224x112x224mの範囲をカバー
└ MH:Wの古代樹の森が約500x500m
→「半分の距離をカバーできればいいだろう」
• 一辺当たり0.5mのボクセル精度
25
25
構築範囲は224x112x224mの範囲をカバーすることを目指して作成を開始しました。
選定理由としては 『モンスターハンター:ワールド』の古代樹の森が一辺約500mなので 「半分の距離をカバーできればいいだろう」 というところから来ています。
その際
25


# Page. 27

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

構築範囲
• 224x112x224mの範囲をカバー
└ MH:Wの古代樹の森が約500x500m
→「半分の距離をカバーできればいいだろう」
• 一辺当たり0.5mのボクセル精度
26
26
一辺当たり0.5メートルのボクセル精度で地形を解析するので左下の画像のように元オブジェクトにかなり近いフィット率を実現しています。
26


# Page. 28

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

リアルタイム地形解析
元データはCPU側のコリジョン情報を使用
└ 専用アセットの事前準備不要
27
27
この時用いられる衝突判定データはCPU側にあるプレイヤーなどが参照する一般的な地形コリジョンを利用します。
そのためVORTEXEL用にアセットを用意する必要がありません。
しかし地形コリジョンはトライアングルの集合体なのでGPUで都度利用するにはコストが高いです。
そのために「解析処理」を行います。それもリアルタイムで。
一体どのように解析をしていくのか見ていきましょう。
27


# Page. 29

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

SDF (Signed Distance Field) への変換
投入されたトライアングルをSDFへとラスタライズ
は内側を示す角
28
28
内部では投入されたトライアングルをSigned Distance Fieldへとラスタライズする処理を行っています。
ラスタライズはトライアングルからAABBを作って、AABB内のボクセルを全走査する単純なものです。
これらの処理はCompute Shaderを使用して1スレッドグループ当たり1トライアングルをラスタライズしています。
ところで急に出てきたSDFですが、皆様ご存じでしょうか?
まだ知らない人も多いと思いますので少しだけ解説します。
28


# Page. 30

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

SDF (Signed Distance Field)って?
は内側を示す角
29
29
SDFは簡単に言うと
29


# Page. 31

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

SDF (Signed Distance Field)って?
• ボクセルの"角"毎に一番近いトライアングルまでの距離が記録されているテクスチャ
は内側を示す角
30
30
ボクセルの角毎に、一番近いトライアングルまでの距離が格納されている2次元または3次元テクスチャです。
30


# Page. 32

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

SDF (Signed Distance Field)って?
• ボクセルの"角"毎に一番近いトライアングルまでの距離が記録されているテクスチャ
└ メッシュの外は正の値、内側は負の値
+0.2
+0.6
+0.1
-0.5
+0.2
-0.8
は内側を示す角
31
31
メッシュの外にいる角は正の値、内側は負の値を持っています。
これの良いところは
31


# Page. 33

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

SDF (Signed Distance Field)って?
• ボクセルの"角"毎に一番近いトライアングルまでの距離が記録されているテクスチャ
└ メッシュの外は正の値、内側は負の値
• 周囲の4点(3次元だと8点)をサンプルするだけで
地形にめり込んでいるか判定ができる
+0.2
+0.6
+0.1
-0.5
+0.2
-0.8
float calcDistance(float d[8], float3 uvw) {
float d0 = lerp(d[0], d[1], uvw.x);
float d1 = lerp(d[2], d[3], uvw.x);
float d2 = lerp(d[4], d[5], uvw.x);
float d3 = lerp(d[6], d[7], uvw.x);
d0 = lerp(d0, d1, uvw.y);
d1 = lerp(d2, d3, uvw.y);
return lerp(d0, d1, uvw.z);
}
は内側を示す角
32
32
周囲の4点をサンプルして線形補間するだけで内側かどうかがわかる点です。
32


# Page. 34

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

SDF (Signed Distance Field)って?
• ボクセルの"角"毎に一番近いトライアングルまでの距離が記録されているテクスチャ
└ メッシュの外は正の値、内側は負の値
• 周囲の4点(3次元だと8点)をサンプルするだけで
地形にめり込んでいるか判定ができる
└ これが大事
+0.2
+0.6
+0.1
-0.5
+0.2
-0.8
float calcDistance(float d[8], float3 uvw) {
float d0 = lerp(d[0], d[1], uvw.x);
float d1 = lerp(d[2], d[3], uvw.x);
float d2 = lerp(d[4], d[5], uvw.x);
float d3 = lerp(d[6], d[7], uvw.x);
d0 = lerp(d0, d1, uvw.y);
d1 = lerp(d2, d3, uvw.y);
return lerp(d0, d1, uvw.z);
}
は内側を示す角
33
33
VORTEXELではこれを使用して高速な接触判定を行います。
33


# Page. 35

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

ただし・・・
• 完全なSDF構築は非常にコストがかかる
└ 全ての角とトライアングルの距離計算
└ 内外判定をする必要がある
34
34
ただし、完全なSDF構築はリアルタイムでやるにはコストがかかりすぎます。
というのも行う場合はすべての角とトライアングルとの距離を計算し、さらに内外判定をする必要があります。
34


# Page. 36

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

ただし・・・
• 完全なSDF構築は非常にコストがかかる
└ 全ての角とトライアングルの距離計算
└ 内外判定をする必要がある
• VORTEXELでは簡易的なSDF構築
35
35
そのためVORTEXELでは簡易的なSDF構築のみ行っています。
しかし簡易的なのでいろいろ問題があり
35


# Page. 37

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

ただし・・・
• 完全なSDF構築は非常にコストがかかる
└ 全ての角とトライアングルの距離計算
└ 内外判定をする必要がある
• VORTEXELでは簡易的なSDF構築
└ ダイヤ形状が生成される
36
36
ダイヤ形状が中空に生成される可能性があります。
36


# Page. 38

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

ただし・・・
• 完全なSDF構築は非常にコストがかかる
└ 全ての角とトライアングルの距離計算
└ 内外判定をする必要がある
• VORTEXELでは簡易的なSDF構築
└ ダイヤ形状が生成される
└ トライアングル周囲のボクセルは
有効値が入っているが内側は"空洞"になっている
37
37
他にもトライアングルに隣接した周囲のボクセルにはある程度の有効値が入ってますが
37


# Page. 39

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

ただし・・・
• 完全なSDF構築は非常にコストがかかる
└ 全ての角とトライアングルの距離計算
└ 内外判定をする必要がある
• VORTEXELでは簡易的なSDF構築
└ ダイヤ形状が生成される
└ トライアングル周囲のボクセルは
有効値が入っているが内側は"空洞"になっている
?
38
38
そこから離れたボクセルには触れないので中が空洞になっています。
そうすると当たり抜けやトンネリングといった問題が起きやすくなります
が、
38


# Page. 40

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

ただし・・・
• 完全なSDF構築は非常にコストがかかる
└ 全ての角とトライアングルの距離計算
└ 内外判定をする必要がある
• VORTEXELでは簡易的なSDF構築
└ ダイヤ形状が生成される
└ トライアングル周囲のボクセルは
有効値が入っているが内側は"空洞"になっている
• 実用上は問題ない
└ エフェクトはゲーム性に影響がないので
厳密に判定する必要が無い
?
└ ゲーム中コリジョンは
可視化されないので気づかない
39
39
実用上は問題ないのですべて無視します。
というのもあくまでエフェクトで利用されるデータ、つまり見た目だけある程度担保出来ればいいので、ゲーム性に影響がなく厳密に判定する必要が無いためです。
39


# Page. 41

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

厳密に判定する必要が無い
40
40
厳密に判定する必要が無いと思いましたが、すぐに許容できない日がやってきました。
40


# Page. 42

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

薄い屋根
薄い壁
41
41
SDFの宿敵である「薄い板」の参戦です。
41


# Page. 43

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

穴あき対策(⿁武者WS向け拡張)
• ⿁武者WSでは薄い板で出来た日本家屋が多い
└ SDFの分解能の関係で穴あきになってしまう
※軒下から見た図
42
42
『ワイルズ』の時は問題なかったのですが、『⿁武者WS』では薄い板で出来た日本家屋が多く出てきます。
そうするとSDFの分解能では穴だらけになってしまいます。
42


# Page. 44

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

穴あき対策(⿁武者WS向け拡張)
• ⿁武者WSでは薄い板で出来た日本家屋が多い
└ SDFの分解能の関係で穴あきになってしまう
※軒下から見た図
43
43
例えばこの屋根では4本の「骨」のようなコリジョンとなってしまっています。
43


# Page. 45

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

穴あき対策(⿁武者WS向け拡張)
• ⿁武者WSでは薄い板で出来た日本家屋が多い
└ SDFの分解能の関係で穴あきになってしまう
└ 雨漏りがひどい!
44
44
こうなると雨が降ったらそれはもう大変なことになります。
幸いなことに元になったコリジョンはOBB等のプリミティブ形状で表現されているので
44


# Page. 46

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

穴あき対策(⿁武者WS向け拡張)
• ⿁武者WSでは薄い板で出来た日本家屋が多い
└ SDFの分解能の関係で穴あきになってしまう
└ 雨漏りがひどい!
• SDFではなくキャラクターなどに付いている動的コリジョンに変換
└ OBB形状が扱えるので穴を塞げる
※ワイヤーフレーム表示
45
45
これをコリジョン属性でフィルタして、キャラクター等で使用している動的コリジョン領域にフォールバックすることで低コストで対応できました。
動的コリジョンに関してはPhysicsの章でお話いたしますのでまた後程。
45


# Page. 47

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

46
46
VORTEXELはSDF以外にもデータを提供します。
それが
46


# Page. 48

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

High-Res Occlusion
高解像度遮蔽情報
ボクセル(一辺0.5m)のさらに2x2x2精度
└ つまり25cm単位での精度
47
47
High-Res Occlusionと呼んでいるデータです。
このデータでは
47


# Page. 49

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

High-Res Occlusion
高解像度遮蔽情報
ボクセル(一辺0.5m)のさらに2x2x2精度
└ つまり25cm単位での精度
ボクセル内に壁があるかどうかの2値
1bit情報
48
48
遮蔽されているかどうかの2値が取れます。
1ボクセル1bitなので非常に軽量かつアクセスも高速です。
特に
48


# Page. 50

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

High-Res Occlusion
高解像度遮蔽情報
ボクセル(一辺0.5m)のさらに2x2x2精度
└ つまり25cm単位での精度
ボクセル内に壁があるかどうかの2値
1bit情報
流体シミュレーションでは2値で十分
49
49
流体シミュレーションで利用する場合は遮蔽されているかどうかの2値があれば十分なので相性が非常に良いです。
49


# Page. 51

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

まとめ
ボクセルで管理されているのでピンポイントでアクセスできる
└ 毎回トライアングル単位でチェックしなくていい!
サンプリング座標を渡すだけでアクセス可能
└ GPU Particleと相性最高!
SDF特有の穴あき対策も可能
└ 雨漏り等を防ぎましょう!
高速に遮蔽情報が手に入る
└ 流体シミュレーションと相性最高!
50
50
ここまでのまとめです
ボクセルで管理されているのでピンポイントでアクセスできます。毎回トライアングル単位でチェックしなくていいのです。
サンプリング座標を渡すだけでアクセス可能なためGPU Particleと非常に相性が良いです。
SDF特有の穴あきにもある程度対策が可能となり、ここぞというニーズにこたえられます。
高速に遮蔽情報が手に入るので流体シミュレーションとも相性が良いです。
50


# Page. 52

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

51
51
とてもよさそうな管理システムですがその情報を提供するためにはいろいろな苦労があります。
ということで最適化にも触れていきます。
51


# Page. 53

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

ラスタライズ負荷
52
52
ラスタライズに関しては非常に苦労しました。
52


# Page. 54

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

ラスタライズ負荷
• 3D Textureの広範囲ランダムアクセスは負荷が高い
53
53
そもそも3D Textureに並列で広範囲にランダムアクセスされるので、アクセス効率があまりよくないです。
それでも大抵の場合は特に気にせず動くのですが、時折強烈なスパイクが発生することがありました。
53


# Page. 55

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

ラスタライズ負荷
• 3D Textureの広範囲ランダムアクセスは負荷が高い
• 投入されるトライアングル数がまちまち
54
54
これはエリアによって投入されるトライアングル数がまちまちなのもあり、場所によっては平均値の数倍の密度になる場所もあったためです。
54


# Page. 56

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

ラスタライズ負荷
• 3D Textureの広範囲ランダムアクセスは負荷が高い
• 投入されるトライアングル数がまちまち
• 大きなトライアングルが投入されると⾧大なThread Groupが発生する
55
55
さらに問題なのは非常に大きなトライアングルで、これが投入されると1Thread Groupあたり1トライアングルを処理している都合で非常に⾧く処理するThread
Groupが出てきます。
これらをどう対処したのかをご紹介します。
55


# Page. 57

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

フレーム分散
• 1フレームで全領域を処理しない
• 1フレームあたり
└ 1000区画
└ 1区画あたり1辺3.5m
└ 4000トライアングル以下
→ 約130フレームで全領域を構築
※デフォルト設定
• これらの設定で処理負荷を
簡単にスケールできる
└ ⿁武者WSではより低負荷で構築
56
56
まず最初に行ったのはフレーム分散です。
これは全領域を1度にラスタライズするのではなく複数フレームに分割します。
デフォルトでは1フレームあたり 1000区画 かつ 4000トライアングル以下としています。
これで130フレームでカバー範囲の全領域を構築できます。
これらの値はタイトル側で設定できるので予算に合わせて処理負荷を簡単にスケールできます。
『⿁武者WS』では「高速な乗り物」は無いのでもっと時間をかけて低負荷で構築しています。
56


# Page. 58

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

トライアングル再分割
1Thread Groupで 1トライアングルを処理
AABB領域のボクセルごとに接触判定
57
57
次にトライアングル再分割です。
先に触れましたが、ラスタライズ時には1Thread Groupで 1トライアングルを処理しています。
比較的単純な実装でAABBを構築した後にそこに被るすべてのボクセルを対象に各Threadで分担して処理するイメージをしていただければ良いです。
57


# Page. 59

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

トライアングル再分割
細⾧かったり大きかったりすると1Thread Groupで処理すべき範囲が増える
図は2次元だが3次元だとより顕著
58
58
しかし細⾧かったり大きかったりすると対象のボクセルが一気に増えていきます。
図では2次元ですが、実際の3次元だと縦・横・奥行の掛け算なので顕著に増えます。
大きなトライアングルが斜めに存在する平らな坂が一番やばいです。
58


# Page. 60

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

トライアングル再分割
図では4つのThread Groupに分離
合計処理ボクセルは増えても処理負荷が偏らないのが重要
59
59
なので閾値サイズを超えたトライアングルは再分割します。
こうすると合計処理ボクセル数は増える場合がありますが、1つのThread Groupが走り続けるということがなくなるので結果的に高速化につながります。
ただ、この図だと流石に余白が気になるので、その場合は適切な稼働数になるまで再分割を繰り返します。
そうすると結果的に合計処理ボクセル数もへります。
59


# Page. 61

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

トライアングル再分割
トライアングルを規則的に分割しバッファに詰めなおす
Divide:0
Divide:1
p0
p0
c
p2
p1
p2
Divide:2
a
b
p1
60
60
トライアングルは複雑なことを考えずに4分割してラスタライズ用のバッファに詰めていきます。
60


# Page. 62

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

トライアングル再分割
トライアングルを規則的に分割しバッファに詰めなおす
└ 1トライアングルあたりfloat3の3頂点(3*3*4byte=36byte)は重い
Divide:0
Divide:1
p0
p0
c
p2
p1
p2
Divide:2
a
b
p1
61
61
が、1トライアングルあたり3次元の3頂点を格納しなおすのは重たいです。
61


# Page. 63

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

トライアングル再分割
トライアングルを規則的に分割しバッファに詰めなおす
└ 1トライアングルあたりfloat3の3頂点(3*3*4byte=36byte)は重い
└さらに1段階ごとに4倍の容量に増加
Divide:0
Divide:1
p0
p0
c
p2
p1
p2
Divide:2
a
b
p1
62
62
しかも分割するごとに4倍になっていくのでさらに重たいです。
なので保存方法をかえます
62


# Page. 64

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

トライアングル再分割
分割数とインデックスがわかれば分割後のトライアングルが一意に求まる
└ 1トライアングルあたり8byteで済む
└頂点バッファは元のデータを使用する
Divide:0
Divide:1
p0
p0
Divide:2
00
0
c
02
a
p2
p1
p2
1
b
01
20
3
2
03
p1
22
23
10
21
12
13
11
※わかりやすいように4進数(各桁2bit)
63
63
元の頂点データをそのまま使い、
トライアングルのインデックス、分割数、分割後のローカルインデックスさえわかればどのトライアングルかがすぐわかります。
なのでその値をパックすることで、1トライアングルあたり8byteに抑えることができ実行速度が改善されました。
63


# Page. 65

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

容量削減
64
64
最適化はなにも実行速度の高速化だけではありません。
ボクセルを扱うシステムとしては容量とも戦う必要があります。
というわけでSDFを触ります。
64


# Page. 66

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

容量削減
短距離SDF
SDF(Signed Distance Field)…に近い情報
VORTEXELでは短距離だけ表現できればいい
?
65
65
VORTEXELでは短距離SDFとしてデータを取り扱います。
一般的な名称ではないですがSDFの低精度版と思っていただければよいと思います。
65


# Page. 67

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

容量削減
短距離SDF
SDF(Signed Distance Field)…に近い情報
VORTEXELでは短距離だけ表現できればいい
-2.0~+2.0 を 1byte で表現
つまり2.0ボクセル先まで
1ボクセル先までだとカクカクした
見た目が出るので2ボクセル先は必要
?
66
66
具体的には-2.0～+2.0ボクセル距離でよいので、これを1byte、256段階で表現しても事足ります。
66


# Page. 68

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

容量削減
短距離SDF
SDF(Signed Distance Field)…に近い情報
VORTEXELでは短距離だけ表現できればいい
-2.0~+2.0 を 1byte で表現
つまり2.0ボクセル先まで
1ボクセル先までだとカクカクした
見た目が出るので2ボクセル先は必要
?
しかし・・・
全域に詳細なSDFを割り当てるとメモリ量が爆裂
仮に512x512x512解像度のGridを割り当てると
1ボクセル 1byte でも 134MB…
67
67
しかし、全域に詳細なSDFを割り当てるとメモリ量が爆裂します。
仮に512x512x512解像度のGridを割り当てると簡単に134MBいきます。
もちろん精度もカバー領域も足りません。
なので不要なところは刈り取ります。
67


# Page. 69

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

疎なSDF
• 大域範囲は均一格子
└ 64x32x64解像度
└ 八分木ではない
68
68
といっても複雑なことを考えずに疎にSDFを管理するだけです。
ただ昨今SDFでよく利用されている八分木ではなく1階層の均一格子で管理しています。
これはできる限り少ない階層アクセスで目的のデータにたどり着きたいという明確な意図があります。
68


# Page. 70

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

疎なSDF
• 大域範囲は均一格子
└ 64x32x64解像度
└ 八分木ではない
• 各ノードに8x8x8の3D Textureを割り当て
69
69
各ノードには8x8x8の3D Texture相当のデータが割り当てられ、そこにSDF情報が記録されています。
69


# Page. 71

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

疎なSDF
• 大域範囲は均一格子
└ 64x32x64解像度
└ 八分木ではない
• 各ノードに8x8x8の3D Textureを割り当て
└ オリジナルの値は7x7x7範囲に格納
70
70
注意しないといけないのはオリジナルのデータ領域は7x7x7範囲で、
70


# Page. 72

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

疎なSDF
• 大域範囲は均一格子
└ 64x32x64解像度
└ 八分木ではない
• 各ノードに8x8x8の3D Textureを割り当て
└ オリジナルの値は7x7x7範囲に格納
└ 側面は隣接ノードの値を転写
XY
Y
Z
X
71
71
側面は隣接ノードの値を転写します。
こうすることで8点をサンプリングする際に隣接ノードを見に行かなくて済みます
71


# Page. 73

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

必要メモリ
Geometryモジュール全体で
約65MB
• 224x112x224mの範囲をカバーしながら!
• ボクセルを扱うシステムとしては破格の省メモリ
└ 4Kテクスチャ1枚分くらいの容量
MH:W時代にメモリ周りで苦労した経験が生きた
• 最初から省エネ志向で設計
• メモリ消費量が少ないと結果的に動作も速くなりやすい
72
72
こうして諸々最適化を行なった最終的なGeometryモジュールのメモリ量は約65MBに収まりました。
思い出してほしいのは224x112x224mの範囲をカバーしながらこれです。
4Kテクスチャ1枚分くらいの容量なのでボクセルを扱うシステムとしては破格の省メモリかと思います。
『モンスターハンター:ワールド』時代にメモリ量で非常に苦労した経験があったのでそれが生きた気がします。
今回制作するにあたり最初から省エネ志向かつGPUに適合した構造で組めたのが良かったです。
72


# Page. 74

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

73
73
さて、やっと次のモジュールです。
Turbulenceと呼んでいるモジュール、つまり風に関してです。
73


# Page. 75

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

リアルタイム流体シミュレーション
説得力のある風
• 壁付近は対流
• 岩肌を避ける気流
└ Geometryの当たり判定を利用
GPU/CPU両方で風速が取れる!
• 結果はCPU側にリードバック
※画像では一方向の風しか与えてません
74
74
最初に出した動画と合わせてこれらの動画は皆様に対してどれほどのインパクトを与えられたでしょうか?
非常に説得力のある風だと感じていただけていたらうれしいです。
壁付近は対流ができ、岩肌を避け、沿うような気流が見て取れます。
これらは先のGeometryの当たり判定も利用して実際にシミュレーションしています。
そしてこのモジュール、なんと
GPUだけではなくCPUでも風情報が取れます。
そのため非常に汎用的で強力な表現力を提供します。
74


# Page. 76

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

リアルタイムで流体シミュレーションする利点
オフラインベイク不要!
• 高いイテレーション速度
• リアルタイム即時反映
• 地形修正に追従する必要が無い
追加アセット不要!
• 面倒なセットアップが不要
• アセット容量も増えない
リアルタイムでもこのくらいの精度が出る
75
75
リアルタイムでシミュレーションする利点は非常に大きく、とにかくオフラインベイクが不要なことが非常に大きいです。
時間帯による風、動的に迫りくる砂嵐による暴風、それによるエフェクトの見た目の変化を即座に確認できますし、エフェクト側から爆風を発生させたり、それらの風圧の
強さなど各種調整がその場で確認できます。
そしてもう一つ。地形修正に追従する必要がなくなります。
制作中は地形が頻繁に修正されますが、そのたびにオフラインでベイク処理をして面倒だった、なんていう経験をした方が皆さんの中にもいらっしゃるかもしれません。
しかし、VORTEXELではそういった負担から解放されます。
それに伴い、追加アセットが不要になります。
これも大きいです。たとえば新規タイトルでとりあえず機能を試してみよう、というときに面倒なセットアップが不要なのです。
検証および導入コストが非常に低いのも魅力となっています。
ベイク済みアセット不要なのでストレージ容量も気にする必要がありません。
75


# Page. 77

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

動的な遮蔽
モンスターのコリジョンにも反応
76
76
実はモンスターなどのコリジョンにも反応しています。
比較的大型の敵と風下で戦う時は威圧感に寄与するはずです。
正直なところ風は可視化されないので、チリや砂煙が周囲に無いとわかりづらいものではあります。
それでも服やアクセサリのはためきとして影響を受けるのでそういった細かい挙動が空気感や威圧感といったものを生み出します。
76


# Page. 78

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

シミュレーション範囲外に関して
77
77
さて、シミュレーション範囲内に関してお話しをしてきました。
が、範囲外はどうなるのか気になるかと思います。
77


# Page. 79

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

シミュレーション範囲外に関して
• シミュレーションは比較的狭い範囲
└ デフォルトで128x32x128m
└ 範囲外はタイトルのシステムで賄う想定だった
78
78
まず前提としてTurbulenceモジュールはGeometryモジュールと比べ比較的狭い範囲でシミュレーションを行います。
それより外は単にグローバルな風を参照するか、タイトル実装のエリア区切りの古典的な風システムで賄う予定でした。
しかし
78


# Page. 80

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

シミュレーション範囲外に関して
• シミュレーションは比較的狭い範囲
└ デフォルトで128x32x128m
└ 範囲外はタイトルのシステムで賄う想定だった
しかし
• タイトル側の管理が煩雑に
• タイトル側ではGPU対応が難しい
• 毎回タイトルで固有の風システムを実装するのは非効率的
79
79
タイトル側の管理が煩雑になったり、毎回タイトルで固有の風システムを実装するのは非効率です。
なので今回
79


# Page. 81

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

シミュレーション範囲外に関して
• シミュレーションは比較的狭い範囲
└ デフォルトで128x32x128m
└ 範囲外はタイトルのシステムで賄う想定だった
しかし
• タイトル側の管理が煩雑に
• タイトル側ではGPU対応が難しい
• 毎回タイトルで固有の風システムを実装するのは非効率的
→ VORTEXEL側で機能を提供するように
80
80
VORTEXEL側で全域をサポートしてしまおうと決心しました。
80


# Page. 82

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

シミュレーション範囲外
• シミュレーションはしない
└ 境界部分はブレンドして切れ目が見えないように
• 風の発生源は直接参照/デコードする
└ 均一格子で分割管理はされている
81
81
と言っても大層な話ではなく範囲外は単にシミュレーションしません。
シミュレーション結果との境界部分はブレンドして切れ目が見えないようにはしていますがそのくらいです。
注目点としては風の発生源に関しては直接参照及びデコードします。
発生源は均一格子で分割管理され高速に探索されます。
これはCPU/GPU共通で行います。
81


# Page. 83

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

風の発生源
プロシージャルに生成
• 一つ当たり80byteにパック
• 逆行列が含まれており、サンプリング座標を直接 -1.0 ～ +1.0 空間へ変換
└ -1.0~+1.0空間だと計算が非常に簡単
└ 距離関数をベースとして実装
(+1,+1,+1)
// 形状内距離関数。
// 別途内外判定関数も必要
// さらに別関数で距離とlocationから風速・風向を求められる
float shapeDistance(float3 location, WindInfo info) {
switch(getShapeType(info)){
case PROCEDURAL_SHAPE_BOX:
return max(max(abs(location.x), abs(location.y)), abs(location.z));
case PROCEDURAL_SHAPE_SPHERE:
return length(location);
case PROCEDURAL_SHAPE_CYLINDER:
return length(location.xz); // 上下距離は見ない。
default:
return 0.0;
}
}
(-1,-1,-1)
82
82
風の発生源情報に関してはすべての風形状共通で80byteにパックされており、そこからプロシージャルに風を生成します。
計算に関してもできる限り単純な計算と共通の手順で取得できるように工夫しています。
82


# Page. 84

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

対応している発生源形状
Box, Sphere, Cone, Cylinder
• さらに一方向、渦巻き、放射状などの風向きもそれぞれ表現可能
Box+一方向
Cylinder+渦巻
Sphere+放射状
83
83
現在対応されている形状はBox、Sphere、Cone、Cylinderの4つとなっています。
さらにこの形状に対してどのように風を生成するか、距離によってどのように減衰するかといった詳細設定も可能です。
83


# Page. 85

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

直接参照して重くない?
84
84
気になるのは直接参照するには重くないか?という部分ですが、
84


# Page. 86

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

直接参照して重くない?
負荷は限定的
• 風の発生はほぼVFXアーティストが管理
• 遠方はエフェクト自体がカリングされる
• 発生しても瞬間的なものが多い
85
85
この負荷は限定的となっています。
というのも風の発生はほぼエフェクトで行われており、エフェクト自体遠方ではカリングされます。
仮に発生しても瞬間的なものが多く、
85


# Page. 87

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

直接参照して重くない?
負荷は限定的
• 風の発生はほぼVFXアーティストが管理
• 遠方はエフェクト自体がカリングされる
• 発生しても瞬間的なものが多い
→ 実際にはほとんど参照・計算されない
86
86
実際にはほとんど参照・計算されないので大きな負荷にはなりませんでした。
86


# Page. 88

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

グローバル風問題
地域全体に吹いてるとして設定される風
87
87
ここまでに風の発生源、つまりローカルな風についてお話してきました。
しかし実際には地域ごとに大域的な風というものが空間を占めています。
87


# Page. 89

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

グローバル風問題
地域全体に吹いてるとして設定される風
88
88
現実世界では言ってしまえばすべてのシミュレーション空間が地続きなので問題ないのですが
88


# Page. 90

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

グローバル風問題
地域全体に吹いてるとして設定される風
現実世界では風は湧き出てくるわけではない・・・
89
89
VORTEXELでは一部の狭い領域を切り取ったシミュレーションなので範囲外の風が流入してきません。
そうなると大域的な風ってどこから湧き出しているの?となります。
ボクセル空間を真上から見て考えてみましょう。
89


# Page. 91

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

グローバル風問題
90
90
90


# Page. 92

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

グローバル風問題
境界部分に書き込み
• 全域に伝わるのに時間がかかる
• 精度が低いので隅々まで伝搬しない可能性
91
91
まず最初に考えられるのは境界ボクセルに風を書き込む方法です。
が、こちらは全域に伝わるのに時間がかかってしまいますし、ゲーム内時間で求められる流体シミュレーションの精度では隅々まで伝搬しない可能性が高いです。
さらにちょうど 崖際(がけぎわ) だったり、境界部分に壁があるとそもそも風が発生しないなど問題が出ます。
91


# Page. 93

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

グローバル風問題
全体書き込み
• シミュレーションの意味がない
• 壁付近も書き込まれてしまう
92
92
次はとりあえず全体にグローバル風を吹かせる方法です。
が、これだとシミュレーションの意味がないですね。
いい感じに元の風とブレンドするなど試行錯誤はできますが、すぐに遷移してしまって求めている結果になりません。
92


# Page. 94

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

グローバル風問題
フィルタして全体書き込み
• 地形複雑度
• 圧力値
93
93
ではVORTEXELではどうしているかと言いますと、フィルタしながら全体書き込みしています。
このフィルタで使用しているのは地形複雑度と圧力値です。
93


# Page. 95

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

地形複雑度
High-Res Occlusionのボクセル割り当て数から算出
• 赤いボックスが大きいほど複雑度が高い
• つまり壁付近
94
94
Geometryの章でお話ししたHigh-Res Occlusionを覚えていますか?
94


# Page. 96

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

地形複雑度
High-Res Occlusionのボクセル割り当て数から算出
• 赤いボックスが大きいほど複雑度が高い
• つまり壁付近
95
95
これを使って各Grid毎に割り当てられたボクセル数をカウントアップすることで簡単に地形の複雑度が手に入ります。
赤い場所ほど割り当て数が多い、つまり複雑度が高い事になります。さらに言うとそこは壁付近であるともいえるわけです。
95


# Page. 97

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

圧力値
前回のフレームの流体シミュレーションの過程で手に入る
• 緑はマイナスの圧力
• 赤はプラスの圧力
96
96
そしてもう一つの圧力値ですが、これを可視化すると非常に面白いパターンを見ることができます。
これは前回のフレームの流体シミュレーションの過程で手に入る圧力値のことをさします。
動画はマイナスの圧力値を緑色、プラスの圧力値を赤色のボックスで表示しています。
この地域では画面右下に向かって風が吹いています。
そのため風下の壁付近は空気が引っ張られるような状態になっており、
風上の壁付近では空気が壁にぶつかって圧力値が高いような状態になっているわけです。
なのでこの圧力値を使って・・・
96


# Page. 98

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

マスクマップ
複雑な地形と圧力の「絶対値」が高い場所をマスク
• 赤い場所に追加の風を吹かせない
「風の波」
ができた!
97
97
圧力の「絶対値」が高い場所をマスクします。
この赤い場所にはグローバル風を追加しません。
理由としては、風下の壁付近は既に真空のような状態で無風または風が回り込んできている状態、
反対に風上の壁は既に対流した風が出来上がってるとみなし、
その部分の風の形を崩さないようにたもてれば、欲しい見た目になるはずだからです。
ちょうど空白地帯は広くひらけている場所であることがうかがえるかと思います。
結果として非常に有機的な動きを観測でき、
これは結果として「風の波」として作用します。
97


# Page. 99

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

風の吹く場所の自動化
クナファ村では自然と風を避ける場所に
98
98
ここまでの機能の結果、クナファ村のような入り組んだ土地では自然と風を避けるような、なぜその地に村を築いたのかを感じさせるたたずまいとなりました。
これはつまりアーティストが地形ごとに細かい風の調整をしなくても説得力のある風が自動で設定されることを意味しており、工数削減の一助となります。
もちろん、雰囲気付けで風を吹かせたい場合は風の発生源を置くことで要望に応えることも可能です。
98


# Page. 100

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

エフェクト連携
焚火
• 風に合わせてたなびく
• 現実的な風速を使うのと
すぐ反映チェックできるので
何処に置いても違和感が出にくい
└ アセットの再利用性を促進
砂嵐
• 迫力のある演出
• 砂丘の「影」は実際に風が弱い
└ シミュレーションの効果
99
99
今回の風の使用例を見ていきますとエフェクトでは焚火の流され方、そして隔ての砂原の砂嵐などで使用されています。
特に砂嵐では迫力のある演出を実現しており砂丘をなぞる強い風を感じられるかと思います。
さらに砂丘の影では風が弱いなどシミュレーションの効果もあります。
もちろん、これだけではなくエフェクトだけでも他にも数多くの場所で使用されています。
99


# Page. 101

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

外部モジュール連携
Cloth
• 服の"はためき"でも参照
└ cm単位のシミュレーション
ではないのでパタパタする
アニメーションは追加で必要
草、木、クナファ村の鳴子
• 一貫した見た目
• 空気感を演出
100
100
ではエフェクト以外ではどうかというと装備や服のはためき等でも参照されています。
といってもcm単位のシミュレーションではないのでパタパタするアニメーションはまだ必要です。
他にも草や木々の揺れ、クナファ村の鳴子(なるこ)などでも使用されており、一貫した見た目かつ説得力のある世界観を生み出しているかと思います。
100


# Page. 102

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

101
101
次に熱伝播処理を司るサーマルコンダクターモジュールです。
101


# Page. 103

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

草燃えで利用
• インタラクション可能
• 一部モンスターは火を避ける
└ CPU側へ発火情報をリードバック
102
102
簡単に言えば草燃えを表現しているモジュールになります。
結構毛色が違う機能な気がしますが、これもVORTEXELで管轄している機能になります。
CPU側へ発火情報などをリードバックしているのでそれに反応してモンスターは逃げようとします。
オトモのお尻も燃えます
102


# Page. 104

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

自由な配置
隣接する発火点(球形状)によるリンクを構築
• 2Dヒートマップではない
└ 広範囲に発火点が配置できる
└ 高低差があっても使用可能
103
103
熱の伝搬処理には 球形状の発火点 を置くことで実現しています。
これが隣接している場合にリンクを構築し相互監視し熱伝播を行います。
配置面積に応じて容量が増える2Dテクスチャヒートマップとは違い、
個数に応じて線形にしか容量が増えないので広範囲に配置できますし、高低差があっても使用可能なので便利です。
103


# Page. 105

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

応用の効くデータ管理
CPUとGPU両方からアクセス可能
• どのくらい炭化しているか0.0~1.0で手に入る
• 火が来た方向も手に入る
• マテリアルアニメーションで
草束を"削る"表現が可能に
利用場面
• 隔ての砂原の草原
└ 草束単位で仕込んでます
• 油涌き谷の油田
└ タール地帯も同じ方式
104
104
熱源の情報はCPUとGPU両方からアクセス可能で、
もちろんシェーダーマテリアルからも直接アクセス可能です。
その際、現在どのくらい燃えたのか、どこから火が来たのかという情報も手に入るので燃え削りアニメーションが実現できます。
これをアーティスト側が利用し、燃え削りの表現を実現しています。
104


# Page. 106

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

説得力のある絵作り
• 燃えた草がわかるのでそこから火のエフェクトをだせる
• 火の進行方向も持っており風下のほうが火の勢いが強い
└ 風流体でより臨場感が増す
※開発当時の検証映像
105
105
そして諸々を合わせて検証したところ非常に説得力のある絵が出来上がりました。
燃えた草はCPUからも手に入るのでそこから炎や煙エフェクトを出すことも可能です。
今回は先にお話しした風流体があるのでそれと合わせると非常に良い感じになりました。
105


# Page. 107

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

パラメータの選定
106
106
燃やせることはわかりましたがどのようなパラメータで管理されているのでしょうか?
パラメータの選定に関しても苦労話があります。
106


# Page. 108

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

パラメータの選定
• 当初"温度"を伝搬させる予定だったがコントロールが難しかった
107
107
当初熱伝播という名前にのっとり実際に"温度"を伝搬させる予定でしたがコントロールが難しいことがわかりました。
というのも
107


# Page. 109

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

パラメータの選定
• 当初"温度"を伝搬させる予定だったがコントロールが難しかった
└ 燃える速度や延焼範囲の調整が特に難しい
└ 基準値やプリセット値の策定が困難
1700℃の火球を出したら
草原が一瞬で消し炭に
草の発火点って何度?
小タル爆弾だと
全然燃えない
108
108
超高温の火球が着弾すると一瞬で全域が燃えたり
草って何度で燃えるの?とか小タル爆弾だと瞬間火力はあるが燃えない、みたいなそれぞれの設定が非常に難しかったためです。
とくに現実的な設定に近づけるほど材質パラメータとかが増えてくるので、それをアーティストに設定してもらうのはよくないなと悩んでました。
108


# Page. 110

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

パラメータの選定
• 最終的に時間指定方式に
└ 小さい火種でも着火可能
└ 延焼時間と着火時間で延焼範囲もコントロールできる
109
109
で、ある程度アーティストの要望や出したい絵に関してヒアリングして、最終的には時間指定方式になりました。
つまり2秒あぶられたら着火して、5秒間燃える、みたいな時間指定です。
109


# Page. 111

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

パラメータの選定
• 最終的に時間指定方式に
└ 小さい火種でも着火可能
└ 延焼時間と着火時間で延焼範囲もコントロールできる
火球の着弾点から
5秒間延焼させよう
小タル爆弾でも
延焼できる!
草は1秒間火に触れたら着火!
2秒間燃え続ける!
延焼時間と着火時間から
延焼範囲も逆算できる!
110
110
おかげで小さい火種でも着火可能になり、延焼時間と着火時間で燃える範囲もコントロールできるようになりました。
正直今思えばそりゃそうだ、って感じではありますが、燃えるという現象に囚われすぎました。
110


# Page. 112

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

裏話
111
111
このThermal Conductorが開発された発端の裏話を少々。
111


# Page. 113

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

裏話
モンスターハンター:ワールド開発時の頃
• 当時出た「某すごいゲーム」と比較して
「グラフィックすごいのにこっちは草とか燃えないじゃん!」みたいな声があった
112
112
『モンスターハンター:ワールド』開発時に、当時出た「某すごいゲーム」と比較して「グラフィックすごいのにこっちは草とか燃えないじゃん!」みたいなユーザーの声がありま
した。
112


# Page. 114

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

裏話
モンスターハンター:ワールド開発時の頃
• 当時出た「某すごいゲーム」と比較して
「グラフィックすごいのにこっちは草とか燃えないじゃん!」みたいな声があった
当時の自分「要望に応えたい! 燃やしたい!」
• しかし断念
└ 他に必須な実装物が多かった
└ 既に処理負荷がきつかった
└ 当時まだ社会人3年目とかだったのでいっぱいいっぱいだった
113
113
当時の自分としても「要望に応えたい!燃やしたい!」とは思っていましたが諸々の事情で対応が難しかったので一旦お蔵入りに。
113


# Page. 115

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

裏話
モンスターハンター:ワールド開発時の頃
• 当時出た「某すごいゲーム」と比較して
「グラフィックすごいのにこっちは草とか燃えないじゃん!」みたいな声があった
当時の自分「要望に応えたい! 燃やしたい!」
• しかし断念
└ 他に必須な実装物が多かった
└ 既に処理負荷がきつかった
└ 当時まだ社会人3年目とかだったのでいっぱいいっぱいだった
ついに燃やせるように
114
114
そうして今回ついに燃やせるようになりました。
114


# Page. 116

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

裏話
• いろんなエフェクトに仕込まれている
• 特にチャージアックスやガンランス
└ 動画サイトやSNSなどで話題になって個人的に嬉しかった
115
115
で、仕込めるようになった結果、VFXアーティストの皆さん 芸が細かいのでいろんなものにエフェクトが仕込まれています。
オープンベータ当時にチャージアックスやガンランスによる草燃えを見つけてくれたユーザーを発端に各所で話題になっており個人的にも嬉しかったです。
草原を頑張って燃やし尽くそうとしてくれたユーザーもいて楽しく反応を見させていただきました。
115


# Page. 117

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

裏話
ところで・・・
よく見ると強制鎮火というパラメータが・・・?
116
116
ところで、Heat Sourceには温度上昇、強制発火、強制鎮火の3つのパラメータがあるのですが、この強制鎮火とは何でしょう?
実際に仕込まれているのでぜひ探してみてほしいです。既に見つけている方もいて流石だなと思いました。
116


# Page. 118

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

117
117
さて、お待たせしました。Physicsモジュールです。
117


# Page. 119

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

Physics
一番やりたかったやつ
制作フローの関係で実装時期としては一番最後に
飛び散る破片!
ばらまかれる薬莢!
118
118
今回のVORTEXELの構想で一番やりたかった機能です。
動画を見ているだけで楽しいです。
ただしタイトル制作フローの関係で実装時期としては一番最後の実装となりました。
118


# Page. 120

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

コンセプト
119
119
VORTEXELのPhysicsモジュールに関しては別途重要なコンセプトを設けていました。
それが
119


# Page. 121

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

コンセプト
エフェクトのための物理
120
120
「エフェクトのための物理」です。
120


# Page. 122

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

物理演算エンジンの再開発?
既存の物理演算エンジン
• メリット
└ 高い精度
└ 複雑な形状に対応
121
121
実を言うとRE ENGINEには以前から信頼と実績のある物理演算エンジンが完備されています。
こちらは高い精度と安定性、複雑な形状に対応しており重要な機能としてRE ENGINEに息づいています。
ただし
121


# Page. 123

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

物理演算エンジンの再開発?
既存の物理演算エンジン
• メリット
└ 高い精度
└ 複雑な形状に対応
• デメリット
└ 嘘がつきづらい
物理法則に従わないほうが問題
└ 処理タイミングの都合で
エフェクトのGPU Particleとの
協調動作が難しい
122
122
動きに嘘がつきづらく、エフェクトのGPU Particleと協調動作が難しいため、エフェクトで利用するには難がありました。
誤解しないでほしいのはこれは既存のエンジンが悪いという話ではなくそもそもコンセプトが違うという話です。
122


# Page. 124

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

物理演算エンジンの再開発?
既存の物理演算エンジン
• メリット
└ 高い精度
└ 複雑な形状に対応
• デメリット
└ 嘘がつきづらい
物理法則に従わないほうが問題
└ 処理タイミングの都合で
エフェクトのGPU Particleとの
協調動作が難しい
VORTEXEL Physics
• メリット
└ エフェクト側の好きな
タイミングで実行可能
└ 精度を犠牲に超高速
• デメリット
└ 雑な精度
└ 比較的小さな物体でのみ使用可能
└ 上方向に積むことはできない
123
123
なのでVORTEXELではエフェクトに特化した物理演算エンジンを提供することにしました。
エフェクトで完全管理された実行タイミング、嘘物理、GPU Particleで大量に扱える、そういった要望をかなえます。
そのために意図的に精度を犠牲にするという、既存の物理演算エンジンとは対照的なコンセプトとなっています。
123


# Page. 125

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

物理演算エンジンの再開発?
既存の物理演算エンジン
• メリット
└ 高い精度
└ 複雑な形状に対応
• デメリット
└ 嘘がつきづらい
物理法則に従わないほうが問題
└ 処理タイミングの都合で
エフェクトのGPU Particleとの
協調動作が難しい
VORTEXEL Physics
• メリット
└ エフェクト側の好きな
タイミングで実行可能
└ 精度を犠牲に超高速
• デメリット
└ 雑な精度
└ 比較的小さな物体でのみ使用可能
└ 上方向に積むことはできない
124
124
さて、デメリットの中に「比較的小さな物体でのみ使用可能」とあります。
これはなんでしょうか?
124


# Page. 126

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

Tiny Physics (と呼んでる概念)
125
125
これはTiny Physicsと個人的に呼んでいる概念で、
125


# Page. 127

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

Tiny Physics (と呼んでる概念)
比較的小さな物体でのみ使用可能
• 具体的には半径が「短距離SDFの1ボクセルサイズ」以下
└ つまりモンハンワイルズ環境なら半径0.5m以下
126
126
Geometryの章でお話しした短距離SDFの1ボクセルサイズ以下の形状の場合に使えるテクニック群となります。
126


# Page. 128

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

Tiny Physics (と呼んでる概念)
比較的小さな物体でのみ使用可能
• 具体的には半径が「短距離SDFの1ボクセルサイズ」以下
└ つまりモンハンワイルズ環境なら半径0.5m以下
• 小さい物体だからバレないことが多々ある
└ バレない範囲で精度を落として高速化
127
127
瞬間的に発生するエフェクトにおいては小さい物体だからばれないことが多々あるので、ばれない範囲で精度を落として高速化します。
127


# Page. 129

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

サポートされている剛体形状
• Sphere
Box
Tetrahedron
• Box
• Card
• Capsule
• Tetrahedron
128
128
説明に移る前にサポートされている形状を軽くお話ししておきます。
剛体形状としては比較的よくつかわれる形状をサポートしています。
128


# Page. 130

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

サポートされている剛体形状
• Sphere
Box
Tetrahedron
• Box
• Card
• Capsule
• Tetrahedron
Mesh
• 16頂点以下のMesh
129
129
さらにおまけで16頂点以下のMeshもサポートされてたりします。
パーティクルだからSphereだけ、ということはないです。
大事なのは地面に自立可能な多面体が使用できるという点です。
129


# Page. 131

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

地面との接触
130
130
さて、そんな多面体と地面の接触に関して想像しましょう。
130


# Page. 132

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

地面との接触
131
131
131


# Page. 133

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

地面との接触
132
132
通常地面と接触する場合は角、辺、面などをそれぞれ見ていく必要があります。
が、
132


# Page. 134

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

地面との接触
133
133
すでに重すぎます。
VORTEXELではこれを
133


# Page. 135

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

地面との接触
134
134
角とPlaneの交差にまで落とし込みます。
134


# Page. 136

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

地面との接触
中心点がいるボクセルの短距離SDF情報を参照
凸凹があるとめり込む事はもちろんある
135
135
このPlaneはパーティクルの中心点のいるボクセルのSDFから構築されます。
隣接するボクセルがデコボコしてたらもちろんめり込みます。
が、小さい物体のめり込みなんてまず気になりません。
135


# Page. 137

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

接触と法線
接触の検出は簡単
136
136
SDFから衝突情報を算出する場合は注意点があります。
接触の検出自体は非常に簡単です
136


# Page. 138

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

接触と法線
接触の検出は簡単
• SDFから1点だけ距離をサンプル
• (距離 – 外接球の半径)が0.0以下なら接触
└ 外接球は後述します
137
137
SDFから一点だけ距離をサンプルして、距離 - 外接球の半径が0以下なら接触とみなせます。
ここで出てきた外接球に関してはまた後程
しかし
137


# Page. 139

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

接触と法線
接触の検出は簡単
• SDFから1点だけ距離をサンプル
• (距離 – 外接球の半径)が0.0以下なら接触
└ 外接球は後述します
法線の算出は難しい
• Marching Cubes法でトライアングルを構築
└ トライアングルを構築して判定は流石に重い
Marching Cubes法では
1ボクセルで最大5枚のトライアングルを生成
138
138
法線の算出は難しいです。
SDFを可視化するときに用いられるMarching Cubes法ですがこれでトライアングルに展開して全トライアングルと接触判定は流石につらいです。
もう一つ
138


# Page. 140

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

接触と法線
接触の検出は簡単
• SDFから1点だけ距離をサンプル
• (距離 – 外接球の半径)が0.0以下なら接触
└ 外接球は後述します
法線の算出は難しい
• Marching Cubes法でトライアングルを構築
└ トライアングルを構築して判定は流石に重い
• ごくわずかに離れた位置で数回
サンプリングして計算
└ 複数回サンプリングしたくない
Marching Cubes法では
1ボクセルで最大5枚のトライアングルを生成
139
139
ごくわずかに離れた位置を再サンプリングして計算する方法がありますが、正直複数回サンプルもしたくないです。
ではどうするか
139


# Page. 141

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

代表法線
ボクセル毎にただ一つの法線を決定する
• とても軽い!
float3 calcOcclusionNormal(float corner[8]) {
float3 v = float3(0, 0, 0);
v += float3(-1, -1, -1) * corner[0];
v += float3(+1, -1, -1) * corner[1];
v += float3(-1, +1, -1) * corner[2];
v += float3(+1, +1, -1) * corner[3];
v += float3(-1, -1, +1) * corner[4];
v += float3(+1, -1, +1) * corner[5];
v += float3(-1, +1, +1) * corner[6];
v += float3(+1, +1, +1) * corner[7];
// 0割りを回避しながら normalize
return v / max(length(v), 0.00001);
}
法線
サーフェス
法線は「normalize( ∑(中心点から角までのベクトル * 距離) )」で求める
140
140
代表法線と個人的に呼んでいるものを求めます。
SDFをサンプリングするときにボクセルの角8点を既にロードしているのでこれを再利用します。
角8点に向かう方向に距離値をかけてすべて合算し、最後にNormalizeすると代表法線が求まります。
ただし、
140


# Page. 142

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

代表法線
ボクセル毎にただ一つの法線を決定する
• とても軽い!
• 正確ではない法線が発生する
float3 calcOcclusionNormal(float corner[8]) {
float3 v = float3(0, 0, 0);
v += float3(-1, -1, -1) * corner[0];
v += float3(+1, -1, -1) * corner[1];
v += float3(-1, +1, -1) * corner[2];
v += float3(+1, +1, -1) * corner[3];
v += float3(-1, -1, +1) * corner[4];
v += float3(+1, -1, +1) * corner[5];
v += float3(-1, +1, +1) * corner[6];
v += float3(+1, +1, +1) * corner[7];
// 0割りを回避しながら normalize
return v / max(length(v), 0.00001);
}
法線
サーフェス
同じ距離に向き合うように2つの
サーフェスが生成される場合は0法線
法線は「normalize( ∑(中心点から角までのベクトル * 距離) )」で求める
141
141
これはあくまで簡易的な計算なので必ずしも正しい法線が得られるわけではありません。
特にMarching Cubes法において複数のトライアングルを生成するようなボクセルで一本しか法線が取れないことになります。
141


# Page. 143

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

代表法線
ボクセル毎にただ一つの法線を決定する
• とても軽い!
• 正確ではない法線が発生する
└ 軽さ最優先
float3 calcOcclusionNormal(float corner[8]) {
float3 v = float3(0, 0, 0);
v += float3(-1, -1, -1) * corner[0];
v += float3(+1, -1, -1) * corner[1];
v += float3(-1, +1, -1) * corner[2];
v += float3(+1, +1, -1) * corner[3];
v += float3(-1, -1, +1) * corner[4];
v += float3(+1, -1, +1) * corner[5];
v += float3(-1, +1, +1) * corner[6];
v += float3(+1, +1, +1) * corner[7];
// 0割りを回避しながら normalize
return v / max(length(v), 0.00001);
}
法線
同じ距離に向き合うように2つの
サーフェスが生成される場合は0法線
サーフェス
法線は「normalize( ∑(中心点から角までのベクトル * 距離) )」で求める
142
142
しかしそれを許容してでも軽さを優先しています。
142


# Page. 144

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

代表法線
143
143
実際に可視化するとこんな感じ。
ちゃんと壁の外側に矢印が向いていることがわかるかと思います。
143


# Page. 145

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

形状とPlaneの衝突
144
144
これで法線と接触点が取れたのでこの二つでPlaneを生成します。
そのあと各形状との衝突を行うのですがこれはすべての形状で同じ処理、
144


# Page. 146

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

形状とPlaneの衝突
全頂点 to Planeでの衝突判定
• 頂点はシェーダーに焼きこまれている
└ グローバルメモリアクセスが無い!
└ 形状ごとのシェーダーバリエーション
による最適化
145
145
つまり全頂点とPlaneの衝突で判定します。
ただし各頂点はシェーダーに直接焼きこまれているため、グローバルメモリのアクセスは発生しません。
形状ごとにシェーダーバリエーションが生成されるようになっており、ついでに各形状で出来る古典的な最適化も入ってます。
145


# Page. 147

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

形状とPlaneの衝突
全頂点 to Planeでの衝突判定
• 頂点はシェーダーに焼きこまれている
└ グローバルメモリアクセスが無い!
└ 形状ごとのシェーダーバリエーション
による最適化
Meshの場合のみ、グローバルメモリからロード
146
146
ただしMeshに関してはグローバルメモリからロードしています。
そのためこちらは多少コストはかかりますが、明確な形をもった状態から崩す場合に便利です。
146


# Page. 148

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

形状とPlaneの衝突
全頂点 to Planeでの衝突判定
• 頂点はシェーダーに焼きこまれている
└ グローバルメモリアクセスが無い!
└ 形状ごとのシェーダーバリエーション
による最適化
Meshの場合のみ、グローバルメモリからロード
• 利便性向上のため重複座標の
刈り取りもリアルタイムで初回だけ行っている
147
147
便利ついでに初回利用時は重複位置にいる頂点は刈り取るような機能も入れています。
後からわかった事ですがDCCツールで事前に色々設定しないと位置は重複しているが法線が違うから別頂点扱いになる場合が多く
アーティストのトラブルシューティングが大変になりそうだったのでいれています。
147


# Page. 149

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

外接球と内接球
形状を完全に内包する球
▼ 外接球
148
148
次に先ほど少し触れた外接球、ついでに内接球について。
これは幾何学用語に出てくるものと大体一緒で、ここでは形状を完全に覆う球というニュアンスです。
この球の半径を用いて、SDFで構築される壁との接触判定を行います。
ただし、この後さらに各頂点と先ほど構築したPlaneの接触判定を行う必要があることは忘れないでください。
さてそれに対して、
148


# Page. 150

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

外接球と内接球
形状を完全に内包する球
▼ 外接球
形状に完全に内包される球
▼ 内接球
149
149
こちらが内接球です。
外接球とは反対に形状に完全に内包「される」球です。
なぜ触れたかと言えば、こちらが次につながる重要な要素だからです。
149


# Page. 151

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

パーティクル同士の衝突
150
150
というわけでパーティクル同士の衝突についてお話いたします。
VORTEXELでは壁とパーティクルだけではなく、パーティクル同士の相互干渉もサポートしています。
しかしパーティクル同士の衝突も地面の時と同じく角、辺、面などをそれぞれ見ていく必要があります。
が、
150


# Page. 152

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

パーティクル同士の衝突
151
151
もちろんこちらもそんなことやってられないので
151


# Page. 153

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

パーティクル同士の衝突
152
152
パーティクル同士の衝突は完全に球同士のみの判定にします。
ここで先ほどの内接球が使用されます。形状は一切見ません。
そのため
152


# Page. 154

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

パーティクル同士の衝突
153
153
横⾧の物は見かけ上すごくめり込みますがやはりエフェクトという特性上そこまで気になりません。
153


# Page. 155

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

パーティクル同士の衝突
154
154
そしてこれがその結果です。
154


# Page. 156

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

パーティクル同士の衝突
155
155
いかがでしょう? パーティクル同士は本当に球形状同士でしか行っていません。
ボックス同士のめり込みは気になりますか?
この時点で個人的に求めていたクオリティが達成できました。
155


# Page. 157

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

動的なコリジョン
地形更新は1フレームに
実行できる範囲が限られている
• 武器やモンスターのコリジョンも取りたい
• 扉や動的に動くものにも反応したい
動的コリジョン
• プロシージャルな形状限定
• 風の遮蔽も有効
156
156
地形とパーティクルの衝突が取れますが、まだ必要な衝突があります。
それは武器やモンスター等の衝突です。
小石は敵の体で跳ねてほしいし、大剣の切り上げで小石もつき上げたいです。
しかし先にも話した通り、コリジョンのラスタライズは1フレームに1回で範囲も限られているので難しいです。
そのために動的コリジョンも実装されています。
こちらはプロシージャルな形状限定となりますが毎フレーム更新が可能です。
風の遮蔽としても機能します。
156


# Page. 158

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

パフォーマンス
PlayStation5 での10,000
パーティクル のコスト
• 相互干渉有り:+0.06ms
• 相互干渉無し:+0.03ms
ゲーム中に10,000も
パーティクルは出ない
• 攻撃から出る破片は100パーティクル弱
• つまりほぼノーコストで常用可能
→「気軽に使っていいよ」
※開発当時の検証映像
157
157
気になるパフォーマンスに関してもお話ししておきましょう。
10,000パーティクルを PlayStation5 で出した時、物理演算シミュレーション有りと無しの差は
相互干渉有りで+0.06ms
相互干渉無しで+0.03ms
この密度感、この量でです。
しかしゲーム中に10,000パーティクルも出すことはないです。出ても攻撃から100個破片が出るくらい。
つまりほぼノーコストで常用可能と言えます。
なのでアーティストには「気軽に使っていいよ」とアナウンスを出しました。
157


# Page. 159

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

結果、あらゆる物に使ってもらえた!
• 大量の髑髏
• 叩きつけで出る小石
• ライトボウガン等の薬莢
• etc…
158
158
結果、あらゆる物に使ってもらえました。
『⿁武者WS』では大量の髑髏による演出、
『モンスターハンターワイルズ』では叩きつけによる小石、そしてライトボウガン等の薬莢。
あらゆる場所で利用されています。
158


# Page. 160

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

利用例
あまりにも気軽に使えるのでガンランスのパイル分離にも使われている
• 大量に出せるGPU Particleとしてのアドバンテージはないが開発工数を大幅に低減
159
159
あまりにも気軽に使えるのでガンランスのパイル分離なんかにも使われてます。
正直パーツが少ないのでGPU Particleとしてのアドバンテージはないのですが、代わりに開発工数の低減に一役買っています。
159


# Page. 161

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

利用例
焚火料理のハーブにも!
• 肉に動的コリジョンが仕込まれている
一瞬コリジョンが見える
160
160
焚火料理のハーブなんかにも使われてます。
小回りが利きますし実装もしやすいので実装工数の低減ができ、大量の物量をさばく一助となったと伺っています。
160


# Page. 162

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

葉っぱの嘘物理
風
風
風
161
161
さて、もう一つ、エフェクトのための嘘物理についても触れておきます。
VORTEXELの風シミュレーション精度は1m単位なので、
葉っぱのような場合は風が葉っぱの下に潜り込んでひっくり返す、ということはできません。
出来ても
回転せず真横にスライド移動するだけです。
161


# Page. 163

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

Wakeup Over Reaction
安定状態から外力が働いたら"オーバーなリアクション"を取るように
• エフェクト向けに作られてるからできる"嘘挙動"
162
162
なので葉っぱのような薄いものに舞ってもらうためにWakeup Over Reactionという機能を入れています。
これを有効にすると安定状態から外力が働いたら"オーバーなリアクション"を取るようになります。
どうですかこの風圧! これこそエフェクト向けに作られてるからこそできる嘘挙動という感じです。
162


# Page. 164

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

最終形態
• Turbulenceと組み合わせると
めちゃめちゃすごい!
• チームへの共有時に
かなり評判が良かった
うれしい!
※開発当時の検証映像
163
163
さて、ここまでの機能を組み合わせたらどうなるのか、
開発当時の検証時の動画がこちらとなっています。
これです!これが見たかった!
これを初めてアーティストに見せてもらった時、安っぽい表現ですが私は「次世代感」を感じました。
ああ、ついにここまでできる時代が来たんだなと。
とにかく、Turbulenceと組み合わせるとめちゃくちゃすごいです。
最後の飾りのプロペラで葉っぱを掃く表現も非常にユニークです。
そして何より空気感や風をしっかり感じられるのが素晴らしいです。
アーティスト側でチームへ共有したときもかなり評判が良かったとうかがっており個人的にも非常に嬉しかったです。
163


# Page. 165

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

SNSでの反応
• チャタカブラの叩きつけの小石の一個一個物理演算かかってる!(PVの反応)
• ガンランスの薬莢が体に当たって弾かれる!
• レ・ダウの巣の大量の小石が蹴れる!?
ゲーム性とは関係ないエフェクト単体で面白さが提供できたのは個人的には満足
164
164
ベータテストや製品版ではSNSで楽しんでもらえていたところを見させていただきました。とても嬉しかったです。
ゲーム性とは関係ないエフェクト単体で面白さが提供できたので個人的には非常に満足しております。
164


# Page. 166

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

165
165
使いやすさについて工夫した点もお話しさせてください。
165


# Page. 167

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

アーティストフレンドリーな設計
166
166
VORTEXEL周りの使いやすさとして自分の中の理想が一つあって
それが
166


# Page. 168

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

アーティストフレンドリーな設計
Click to Go
167
167
Click To Goという考えです。
と言っても何か既にある言葉というわけではなく自分が頭の中で考えた用語で、たぶん既に似た概念はあるはずです。
167


# Page. 169

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

アーティストフレンドリーな設計
Click to Go
1クリックですぐに使用できる状態にする
168
168
とにかく1クリックあるいは1アクションしたらすぐに使用できる状態にしたいと考えていろいろと工夫しました。
168


# Page. 170

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

アーティストフレンドリーな設計
Click to Go
1クリックですぐに使用できる状態にする
少なくとも試用検証が非常に簡単!
169
169
そうすることで試用検証が非常に簡単になり、導入コストや参入障壁が取り払われます。
169


# Page. 171

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

アーティストフレンドリーな設計
Click to Go
1クリックですぐに使用できる状態にする
少なくとも試用検証が非常に簡単!
流石に製品仕様では調整したほうが良い
170
170
といっても流石にそのまま最後まで行くのは難しいのでちゃんと調整できるようにもしています。
170


# Page. 172

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

アーティストフレンドリーな設計
チェックボックスを入れるだけ
• 冒頭で述べた通りCPU側の既存の当たり判定を利用
• 事前ベイクなども不要
└ あとは処理負荷と相談して構築範囲などの調整をするだけ
171
171
まずはVORTEXEL自体の機能を有効化する方法です。
動画中のマウスカーソルをご覧ください。チェックボックスを入れるだけです。
初期検証するだけならプログラマ対応も必要ありません。
冒頭で述べた通りCPU側の既存の当たり判定を利用しているので事前ベイクなども不要です。
あとはアーティストは普段通りエフェクトエディタをつかってコリジョンアイテムを入れるだけです。
171


# Page. 173

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

アーティストフレンドリーな設計
エフェクトではアイテムを入れるだけ
• とりあえず跳ねるようになる
172
172
エフェクトで実際に使用する場合もアイテムを一個入れるだけで転がって跳ねるようになっています。
この時に設定されるデフォルトパラメータもちょうどよい値が最初から設定されています。
172


# Page. 174

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

高度な物理パラメータをマスク
質量すらマスク対象
• Advanced Settingsを有効にすると出る
旧来のエフェクトのパラメータ調整で「重さの表現」ができる
• 基本的に同じエミッター内の同一質量の物体としか接触しないので
質量で「重さの表現」はあまりできない
173
173
さらにパラメータのうち、高度と考えてる一部物理パラメータをマスクしています。
というのも複雑で多様な物理パラメータは正直物理挙動の利用においては障壁になりうると個人的に考えているためです。
何だったら質量ですら初期状態ではマスクしています。
形状の変化しない剛体物理において、同じ質量同士の物体では質量を上げても動作は変わらないですし、
エフェクトにおける重さの表現はVelocityアイテムの減衰率で表現することがとても多いのでそちらを制御したほうが直感的だと考えています。
つまるところアーティストは慣れ親しんだ今まで通りのエフェクトのパラメータ調整を行うだけでそれっぽい物理挙動を設定できるというわけです。
173


# Page. 175

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

174
174
さてここからは、より幅広い環境で動かすための拡張に関してご紹介します。
174


# Page. 176

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

より幅広い環境で動かすために
必要VRAM
• 全部合わせても100MB未満
└ Geometryで65MB
└ Turbulenceで20MB
└ 残りは他モジュール
※いずれもデフォルト値での計測であり、タイトルごとに調整されてます
175
175
先にも述べましたが導入コストはできるだけ安く設計しているつもりです。
特に必要VRAMは全部合わせても100MB未満です。およそ4Kテクスチャ2枚分以下です。
175


# Page. 177

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

より幅広い環境で動かすために
必要VRAM
• 全部合わせても100MB未満
└ Geometryで65MB
└ Turbulenceで20MB
└ 残りは他モジュール
処理時間
• TurbulenceはVORTEXELの中では"比較的"コストがお高め
└ 風の3次元流体計算が原因
└ PlayStation5では0.6ms程
└ Async Computeによって裏で動作
※いずれもデフォルト値での計測であり、タイトルごとに調整されてます
176
176
しかし処理時間に限っていえば、これらの中でもTurbulenceは比較的重い部類になります。
3次元の流体計算は処理する要素数と反復回数が多いのでやはり重くなりがちです。
176


# Page. 178

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

重要度の考察
エフェクト自体が削減対象に挙がりやすい…
177
177
そして残念なことにVORTEXEL関係なく、そもそもエフェクト自体が削減対象に挙がりやすいという悲しい背景があります。
現実は厳しいです。ならばいっそ
177


# Page. 179

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

重要度の考察
エフェクト自体が削減対象に挙がりやすい…
• いっそのことシミュレーション自体を無効化できるようにしよう!
→ 品質は落ちるが選択肢があるということが大事
178
178
エフェクトがほとんど表示されなくなるなら開き直ってシミュレーション自体を無効化できるようにしよう!となりました。
かなり本末転倒に聞こえますが、選択肢があるという事が大事なのです。
178


# Page. 180

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

重要度の考察
エフェクト自体が削減対象に挙がりやすい…
• いっそのことシミュレーション自体を無効化できるようにしよう!
→ 品質は落ちるが選択肢があるということが大事
• あとからシミュレーション消して大丈夫…?
179
179
しかし、削減を迫られるのは決まって開発終盤です。
開発終盤にいきなりシミュレーションを無くすとかなり見た目が変わってしまいます。
流石にそれは良くないのである程度見た目を担保出来るように手を加えています。
179


# Page. 181

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

Turbulenceの風シミュレーションのオミット対応
範囲外風のシステムを拡張
• 常にWind Emitterを直接サンプルするように
└ 爆風とかはちゃんとインタラクションできる
• 遮蔽率も常にチェック
└ シミュレーション無しでも壁付近は風が吹かない
180
180
まず出発点としてシミュレーション範囲外を管理しているシステムを拡張して全域で常に直接参照できるようにしました。
小手先の調整機能として微妙な減衰、微妙な範囲の拡張用係数も利用可能です。
遮蔽率も常にチェックされるので壁付近で風が吹かない機能も引き続き利用可能です。
180


# Page. 182

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

Turbulenceの風シミュレーションのオミット対応
範囲外風のシステムを拡張
• 常にWind Emitterを直接サンプルするように
└ 爆風とかはちゃんとインタラクションできる
• 遮蔽率も常にチェック
└ シミュレーション無しでも壁付近は風が吹かない
Indoor Mask
• 遮蔽率の低い広い屋内でも風を吹かないようにする機能
• 元々3D Textureにキャッシュしていた
└ 全域で直接サンプルできるように拡張
181
181
他にもIndoor Maskという機能にも手が入っています。
これは遮蔽率が低い「広い屋内」で風が吹かないように屋内としてマークする機能で、
実は前から入っていたのですが、こちらも全域で参照できるようにしました。
シミュレーション有りと比べれば差異がいろいろ出てきますが、
今回はエフェクト自体が削減されているという事情と勘案して妥当な見た目に抑えられるだけの機能がはいったと思います。
181


# Page. 183

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

Geometryの局所利用
容量的にも削減したい…
• Geometryの65MBを何とか減らしたい
└ 分散実行されているがそのわずかな処理時間も減らせる
182
182
その次は、想像以上にメモリ環境が厳しくなった昨今、Geometryのメモリも削減検討がなされました。
基本戦術としては構築範囲を狭めることである程度のメモリ削減が図れますが、
182


# Page. 184

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

Geometryの局所利用
容量的にも削減したい…
• Geometryの65MBを何とか減らしたい
└ 分散実行されているがそのわずかな処理時間も減らせる
Geometryの構築範囲を手動制御可能に
• 導入のしやすさのために自動構築がデフォルト動作だった
→ 特定エリアをピンポイントで処理できるように
183
183
より突き詰めたい場合のために局所的に手動構築できるようにしました。
もともとは導入のしやすさを重視して自動で構築処理が走るようにしていましたが、
これをOFFにするフラグを用意し、タイトル側でAABBをクエリするとその範囲だけを構築してくれます。
コリジョン頼みで配置されていたエフェクトや、印象的なパーティクルコリジョンのあるステージなどのためにGeometry自体を後からOFFにするのは難しいですが、
逆にそういった場所のみピンポイントで構築してしまえば他は妥協できるわけです。
183


# Page. 185

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

Geometryの局所利用
⿁武者WSでは一部ボス部屋は常に構築
• そのほかのエリアはターゲットスペックによる
184
184
『⿁武者WS』では一部ボス部屋は常に構築するように手が入れられています。
そのほかのエリアはターゲットスペックによって構築するか無効化するかを切り替えています。
184


# Page. 186

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

185
185
ここまでがVORTEXELの内容に関する説明でした。
この後はおまけ話です。
185


# Page. 187

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

2025年 大阪・関西万博で公開されていた
体験型コンテンツのモンスターハンター関連作品
186
186
じつは、2025年に大阪・関西万博で公開されていた体験型コンテンツである『モンスターハンターブリッジ』でもVORTEXELが利用されていました。
186


# Page. 188

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

開発終盤にエフェクトの
クオリティアップで必要に
• モンスターの動きに合わせて
岩の破片を動かしたり煙を風圧で流したり
• 自分は使われているのを知らなかった
└ ほぼノーサポートで導入できたということに
187
187
開発終盤にエフェクトのクオリティアップで必要になったとのことで、モンスターの動きに合わせて岩の破片を動かしたり煙を風圧で流したりする際に利用されているとのことで
す。
正直自分は使われているのを知らず、後から聞いて驚きました。
つまるところほぼノーサポートで導入できた事例となりました。
現在は公開が終了していますが、今後移設展示されることが公表されていますので、
もし行く際はエフェクトの動きなんかを気にするのも楽しみ方の一つになるかもしれません。
187


# Page. 189

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

初期構想
実はMHW:IBの開発開始頃に思い付きで実装
• といっても開発フロー的にこのタイミングで載せてもあまり効果が無いのでお蔵入りに
※2018年MHW:IB開発環境で撮影
188
188
最初期の構想に関しても少しだけ。
実は『モンスターハンター:ワールド アイスボーン』の開発開始頃に思い付きで実装してたりします。
といっても開発フロー的に今から載せても活用しきれない、となったのでお蔵入りに。
映像は古代樹の森での検証動画となっています。
なのでだいぶ前から構想されていたことが伝わるかと思います。
188


# Page. 190

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

初期構想
当初はメモリ量を恐れて1ボクセルあたり1bitのSDFをCPUで構築
• 驚いた事に1bit単位ならPlayStation4環境のCPUでも1秒かからず全域を構築できる!
• かわりに勾配が45度単位でカクカクしてる
※2018年MHW:IB開発環境で撮影
189
189
当初はメモリ量を恐れて1ボクセルあたり1bitのSDFをCPUで構築していました。
驚いた事に1bit単位ならPlayStation4のCPUでも1秒かからず全域を構築できました。
かわりに勾配が45度単位でカクカクしていますが、それでもパーティクルは地形に沿って流すことができました。
この頃から非常に可能性を感じていましたね。
そんな感じの思い出話でした。
189


# Page. 191

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

最後に
この数年間VORTEXELについてずっと語りたかった!
個人的にも非常に満足のいくプロダクトが作れた
素晴らしいエフェクトを作ってくれたアーティストの皆様にも感謝
皆様に何かしらの刺激になれば幸いです!
190
190
というわけでVORTEXELについての講演でした。
正直もっとたくさん語りたいことがあるのですが残念ながらここまでです。
この数年間ずっとずっと語りたくて仕方がなかった内容であり、CEDEC発表時も非常に多くの好評をいただきましたので、今回再び皆様にお話しする機会ができて良かっ
たです。
個人的にも非常に満足のいくプロダクトが作れたと思っています。
そしてこのVORTEXELを使って数々のすばらしいエフェクトを作ってくれたアーティストの皆様にも感謝しています。
今回の講演が皆様にとって何かしらの刺激になれば幸いです!
190