UE4の勉強記録

UE4の勉強の記録です。個人用です。

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する 村人用のAIの開発 Part4

f:id:kazuhironagai77:20211128232703p:plain

<前文>

<英語はテニス、日本語はボーリングは間違いか?>

英語喉®︎カズ先生 (シカゴ大学Ph.D.) の木村ここみさんの英語をシカゴ大学Ph.D.が評価してみた [1] を見てたら日本人の会話はキャッチボールと解説されています。

f:id:kazuhironagai77:20211128232744p:plain

私は常々、英語の会話はテニス、日本語の会話はボーリングと言っています。

この事自体は私が発見したアイデアではないですが、これほど日本語と英語の会話の違いを端的に表した言葉はないと思っています。それと全く違う、それも180度違う意見を言う人、しかも私より英語が上手な日本人が言っているのを聞いてびっくりしたんです。

で、全部、この動画を見たんですが、英語は喉を使うとか、英語はアコーディオンのように発音するとか、かなり英語と日本語の違いの本質を突いた発言をしていました。

英語はアコーディオンのように発音する部分では、私が昔、英語はバイオリンのよう、日本語はピアノのようだ。と感じた事を思い出しました。これは英語の発音は日本語のように単語毎に音が切れない事から感じたんですが、兎に角、音の出し方が根本から違うんです。

英語は喉を使うに関してもかなり同感です。日本に帰って来てから日本人からよく小馬鹿にしているように感じると言われて、何で?と思ったら、私が相槌を打つときに喉に響かせていたんです。それがどうも他の日本人には小馬鹿にされていると感じたみたいなんです。それから喉に響かせて音を出すのを止めたら以後一切、小馬鹿にしているように感じると言われなくなって、ふーん。日本では喉に響かせて音を出すと小馬鹿にしているように感じるんだ。と思ったのも覚えているからです。

つまり完全とは言わないですが英語と日本語の違いについてほとんどの意見が一致しているんですが、英語の会話と日本語の会話の違いは全く真逆な意見を言っています。

それで一番最初に思い出したのが、話の粒度(Granularity)の違いと山本義隆氏の「熱学思想の史的展開」に書かれていた熱力学第一法則の発見に関わる話です。

山本義隆氏の「熱学思想の史的展開」に書かれていた熱力学第一法則の発見の話は、熱力学を勉強した事のない人には馴染みがない話なのでここに簡便にまとめておきます。ただしこの本が手元にないんで細かい点では間違いがあるかもしれません。

フランス人のカルノー熱力学第二法則を発見します。その後でドイツ人のメイヤーが熱力学第一法則を見つけるですが、実はイギリス人のジュールの方が先に発見していたんです。

しかし当時のイギリスの学会のボスであるケルビンは、ジュールの発見がカルノー熱力学第二法則に一見反する結果を示しているので、どっちかが間違っているはずとの考えから逃げられなかったんです。のでジュールの実験結果が間違っているだろうと思って相手にしなかったんです。

ところが、ドイツではあるアマチュアの論文でジュールの発見はカルノー熱力学第二法則に反しない形で存在出来る、つまり両方が正解の可能性もある。との認識が既に広まっていたので、ドイツ人であるメイヤーはケルビンと違って、カルノー熱力学第二法則に惑わされる事なく、熱力学第一法則を見つける事が出来たんです。

うろ覚え過ぎて、かなり間違っている部分があるかもしれませんが、言いたい事は、科学の世界では一見相反して見える結果が両方正しい事はありえる。です。

つまり、どっちも正しいんじゃないのかな。と思ったんです。

もう一つは、先週の勉強で出て来た粒度(granularity)の違いについてです。

私が、英語はテニスのようだ。という理由は単純に、英語でHow Are You?と言われたら必ず返事を返さなければならない会話のルールが、必ずボールを打ち返さないといけないテニスに似ているから言っています。

粒度に例えると非常に荒いレベルの話をしています。この動画の話は、ほとんど完璧に英語がしゃべれる日本人がアメリカ人との会話で本当に微妙なニュアンスの違いで誤解している、粒度に例えると非常に細かいレベルの話をしているので粒度(granularity)が違っているのではないのかと思いました。

正し、私自身は、この動画のような粒度(granularity)が非常に細かいレベルの英語の会話でも積極的に、今ここで自分の意見を打ち返さないと。とテニスをPlayしているように感じて会話していました。後、アメリカ人に自分の発言が無視されていると感じた事はあんまりないです。

兎に角、アメリカ人は会話中の無音状態を恐れるんです。だから何があっても会話中は無音状態にしないようにしないといけないんです。それで英語での会話は私にとってはテニスのラリーのように感じます。それに対して日本語の会話は、どちらかと言えば会話中の無音状態も音が発している時と同じぐらい大切です。私にとっては日本語の会話はまるでボーリングをやっているようです。

ところで、回りの英語がしゃべれない日本人にこの話をしたら、全員が日本語の会話がキャッチボールなわけねーだろ。って言われました。上司との会話でお前は、一々、コメント返すのか。と。それで気が付いたのですが、粒度だけじゃなくて、会話の相手が上司の場合とかの場合も関係してるのかもしれません。

後、関東と関西の違いもあるのかもしれません。一回だけ日本人の友達と大阪に遊びに言った時に、自販機にコーラがなかったので「コーラないぞ。」とその友達に言ったら、50m位離れた所にいる全く知らないおばさんが「こっちにあるよ。」って大声で怒鳴ってきたんです。ホントにびっくりしました。

だから私は日本全体が、東京のように会話していると思っていたんですが、実は関西圏では会話はキャッチボールのようにやっているのかもしれません。東京文化圏で育った私には、英語の会話はテニス、日本語の会話はボーリングに感じます。しかし関西文化圏で育った人には逆に感じるのかもしれません。

これを書いていて思い出したんですが、Learn Japanese From Zero!とMatt vs. Japanが日本語のPitchについて議論してた時に、英語喉®︎カズ先生も議論に参加してました。その参加の仕方が私にはとてもテニス的だったです。日本人で他にこの議論に参加した人は他にはいなかった気がします。それは他の日本人はボーリングをPlayしている時のように二人の議論を見てたからだと思っています。

と言う訳で私は自説である英語の会話はテニス、日本語の会話はボーリングを保持していきますが、それは違うと言う人の意見も良く聞くようにします。

今週書こうと思っていたKyle Rittenhouse Trialの感想については来週以降に回します。

それでは今週の勉強を始めます。

<本文>

1.今週の予定

今週は以下の内容をやっていきます。

  • Niagara: Convertible Floor in UE5 Niagara Tutorialについて
  • Material : Content Exampleをみる
  • NPCのAIを作成するためのAIの復習の続き(Environment Query System
  • Game Designポケモン+HxHの念能力 Part 2
  • Landscape4にLoad Stream Levelノードを使用する
  • UE5におけるWorld Partitionの勉強の続き

2.Niagara

2.1 Convertible Floor in UE5 Niagara Tutorial [2]の復習

先週使用したModuleやDynamic Inputなどで機能が分からないものや、始めて使用したものを調査します。

<Spawn Particles in Grid Module

まずは当然ですがこのModuleです。

f:id:kazuhironagai77:20211128232905p:plain

こんなModuleあるの知らなかったと先週も言っていますがホントですね。

試しにParticle をSpawn Particles in Grid Moduleを使用してGrid状に配置してみます。

f:id:kazuhironagai77:20211128232930p:plain

これ、先週のBlogでもやっていましたね。

CGHOW氏もこの辺はTutorialできちんと解説していました。

でもこれでSpawn Particles in Grid Moduleの機能を理解する事が出来ました。

<Grid Location Module

f:id:kazuhironagai77:20211128233137p:plain

Grid Location ModuleはSpawn Particles in Grid Moduleと対で使用するModuleです。Spawn Particles in Grid ModuleがEmitter Update Sectionに配置するのに対して、Grid Location ModuleはParticle Spawn Sectionに配置します。

<Mesh Renderer

Convertible Floor in UE5 Niagara TutorialではMesh Renderer Moduleを使用しています。

f:id:kazuhironagai77:20211128233208p:plain

私はVFXにおけるSpriteの手法って何か詐欺っぽくて嫌いなんです。のでMesh RenderingのでもっとMesh Renderingを勉強しようとは思っています。

でも中々出来ていないです。

<Lerp Linear Colors

f:id:kazuhironagai77:20211128233237p:plain

Lerp Linear ColorsはDynamic Inputの一種で二つの色をLerp で表示します。

Materialでいう所の以下の実装と同じ事をしていますね。

f:id:kazuhironagai77:20211128233302p:plain

上記の実装だと0は赤、1は青、その中間は二つの色をそれぞれの割合で混ぜた色で表現されています。

f:id:kazuhironagai77:20211128233324p:plain

でもそうするとoutput Xの値が0から1の間である必要がありますね。

調べます。

output Xの値は結構複雑な計算で求められていました。

f:id:kazuhironagai77:20211128233346p:plain

ただ最後にSaturate Floatを使用しているので値が0と1の間で示されてるのは間違いないです。

f:id:kazuhironagai77:20211128233359p:plain

Codeを読んだら分かりました。Pointは以下に示した2つのInputです。

f:id:kazuhironagai77:20211128233420p:plain

任意の位置であるPosition Xを適切なOutput Xに変換するためには、全てのGridの最初の位置と最後の位置が分からないと求められません。のでどうやってそれを求めているのかと推測しながらコードを読んでいきますが、実際は最初の位置と最後の位置は最後まで分からないんです。

ではどうしてるかと言うと、上の二つのInputの値を変えてOutput Xが適切な結果になった(この場合、以下に示した様に色が綺麗に表示されたら)時が正解としているんです。

f:id:kazuhironagai77:20211128233445p:plain

これで大体理解したんですが、先週のBlogを読み直すともう少し細かい話、粒度(Granularity)を下げた調査が欲しい気がしてきました。

のでもう少し細かく調査し直します。

私はこの話の粒度(Granularity)をそろえるのがかなり苦手です。大学4年、大学院生一年レベルの人が対象の粒度(Granularity)の話をまとめていても、途中で一般人向けの粒度(Granularity)になってしまったり、またその逆になったりしてしまいます。

先週のBlogで何でFadeの値を追加すると実際の色がFadeするのか分からないと言っていますが、

f:id:kazuhironagai77:20211128233523p:plain

今週の粒度(Granularity)ではこの理由を説明する事は出来ません。

この辺は来年、1年間の課題にします。

<Lerp Linear Colorsの解説やり直し>

まず先程示したこのScreenshotですが

f:id:kazuhironagai77:20211128233555p:plain

正確に言うとこれに使用したOutput Xの実装は

f:id:kazuhironagai77:20211128233620p:plain

これだけです。こっちの結果は

f:id:kazuhironagai77:20211128233643p:plain

これです。

f:id:kazuhironagai77:20211128233704p:plain

言っている内容は正しいのですが、

f:id:kazuhironagai77:20211128233725p:plain

こっちを使用して説明する為にはもう一回、この実装を書く必要があり、それが面倒なので先程の説明で終わらせてしまいました。

それだとFadeの機能の調査が出来ないのでTutorial自体の解説より私が調査した内容の方が薄くなってしまいます。

私の話の粒度(granularity)がコロコロ変わる理由の一つが分かりました。実装し直すのが面倒なので粒度(Granularity)を変えて対応していたんですね。

仕方ない。もう一回、此処までの実装をします。

しました。

Scratch Moduleの中身が以下の状態で

f:id:kazuhironagai77:20211128233804p:plain

結果が以下の様になっています。

f:id:kazuhironagai77:20211128233826p:plain

<<Saturate Floatについて>>

この粒度で考えるとこの時点で良く分からない部分があります。

今使用しているCubeの大きさは1m^3です。UE4のUnitは1㎝ですのでxの値は、110、220、330、440が返ってくるはずです。それをSaturate Float Moduleを使用して0から1にSaturateしているので全部1になるはずです。なのに0にあたる緑が表示されています。

はい。

実際のMap上に配置して上から見ると分かります。

f:id:kazuhironagai77:20211128233855p:plain

Xの位置の値は-110、-220、-330..のCubeが緑色になっていました。

これはこのEffectの位置を原点からずらすと良く分かります。

原点よりー側にずらしました。

f:id:kazuhironagai77:20211128234011p:plain

原点より+側にずらしました。

f:id:kazuhironagai77:20211128234034p:plain

Tutorialでもそのように解説していました。

f:id:kazuhironagai77:20211128234059p:plain

CGHOW氏のTutorialって全部World Coordinateの原点を中心にして作成しているんですね。

これだとそのままGameのEffectには使用出来ないですよね。

うーん。もしかして前にどっかのGame 会社に丸コピされたりしたんでしょうか?

でも丸コピされないためには良いアイデアですね。全部Local Coordinateに直さないと実際のGameには使用出来ない訳ですから。

<<Fade とWipe>>

ここでFadeとWipeの機能を解析します。

まずWipeについてです。

Wipeの実装は以下に示します。

f:id:kazuhironagai77:20211128234128p:plain

もう単純にGridの原点からの位置の値を減らしているだけですね。

Wipe=0です。

f:id:kazuhironagai77:20211128234148p:plain

一個のCubeが100cmで隙間が10cmだから110cmずらすとヒトマス分の色が変わるはずです。

Wipe=110です。

f:id:kazuhironagai77:20211128234211p:plain

ヒトマス分赤が増えています。

赤が6個あるので‐660を引いてみます。

f:id:kazuhironagai77:20211128234252p:plain

‐550にしてみます。

f:id:kazuhironagai77:20211128234643p:plain

はい。Wipeの機能についてはこれだけですね。

次はFadeです。実装部を以下に示します。

f:id:kazuhironagai77:20211128234707p:plain

割っているだけですね。

110cmでGridされているんで110以上で割れば、0と1の間の値0.5とかがでてきてそのGridは黄色系になります。

試しにFade = 220にしてみました。

f:id:kazuhironagai77:20211128234725p:plain

黄色が出来ました。

<<Fade とWipeの結論>>

結論から言えばFadeやWipeは単なる引き算、割り算でした。ただし、

  • Lerpの機能を理解する事。
  • Grid 1m^3Cubeを並べている事。
  • Gridの隙間が10cmである事。
  • UE4の単位、UU1㎝である事。

を知っていないと何をしているのか分からなくなります。それだけです。

<Girdがオレンジと黄色に成る点について>

f:id:kazuhironagai77:20211128234814p:plain

これは(1-同じ計算)を掛けているだけです。

f:id:kazuhironagai77:20211128234837p:plain

それがどうなるのか良く分からないので計算してみました。

f:id:kazuhironagai77:20211128234903p:plain

X*(1-x)を計算すると0と1の間以外の値は全てNegative になりました。この習性を利用して計算したんですね。

因みにオレンジの線はSaturateした後です。

<Scale Mesh Size Moduleについて>

Scale Mesh Size Moduleを使用するためには以下に示したようにParticle Spawn SectionのInitialize Particle ModuleのMesh Scale ModeをUnsetから変更する必要があります。

f:id:kazuhironagai77:20211128234941p:plain

これは覚えておく以外の解決方法はないですね。

<Cubeの下側の伸びを消す>

f:id:kazuhironagai77:20211128235011p:plain

Cubeの下側の伸びを消すために50を足しています。

f:id:kazuhironagai77:20211128235119p:plain

これはCubeの大きさが100cmだからでしょう。

でも一応試してみます。粒度(Granularity)は揃える必要がありますから。

f:id:kazuhironagai77:20211128235142p:plain

ここまで作り直しました。

そしたら説明で

f:id:kazuhironagai77:20211128235203p:plain

f:id:kazuhironagai77:20211128235209p:plain

とはっきり言っていました。

一応確認のためにCubeのサイズを0.5m、Pivot Offsetを0に変更してみます。

f:id:kazuhironagai77:20211128235255p:plain

f:id:kazuhironagai77:20211128235303p:plain

こんな感じで真ん中でz軸に膨張しています。

f:id:kazuhironagai77:20211128235327p:plain

サイズが半分になったのでPivot Offsetを25ずらしたら、上方向にのみ膨張するはずです。試してみます。

f:id:kazuhironagai77:20211128235401p:plain

結果です。

f:id:kazuhironagai77:20211128235419p:plain

今度はCellのサイズを2倍にしてみます。

f:id:kazuhironagai77:20211128235437p:plain

セルの隙間を作るためにParticle Spawn SectionのGrid Locationの

f:id:kazuhironagai77:20211128235503p:plain

XYZ Dimensionsの値を110から220に変更します。

f:id:kazuhironagai77:20211128235524p:plain

こんな感じです。

f:id:kazuhironagai77:20211128235549p:plain

サイズが2倍になったのでPivotを100ずらします。

f:id:kazuhironagai77:20211128235610p:plain

結果です。

f:id:kazuhironagai77:20211128235627p:plain

はい。

Pivotで50ずらしているのはCubeのサイズが1mだからです。Cubeのサイズが50cmならばz軸のPivotを25cmずらせば上方向にのみ伸長します。Cubeのサイズが2mの時はz軸のPivotを1mずらす必要があります。

<回転が途中で止まってしまう>

f:id:kazuhironagai77:20211128235651p:plain

Tutorialの回転も途中で止まっていまいした。

f:id:kazuhironagai77:20211128235711p:plain

<<Update Mesh Orientation Moduleについて>>

Update Mesh Orientation ModuleはMeshを回転させるModuleなのは分かっていますが、これもPivotを中心に回転しているんでしょうかね。

f:id:kazuhironagai77:20211128235737p:plain

以下の青い点を中心にして回っています。

f:id:kazuhironagai77:20211128235803p:plain

Pivotの位置を変えてみます。

Pivot Offsetの値を0に戻しました。

f:id:kazuhironagai77:20211128235822p:plain

Cubeの中心で回り始めました。

f:id:kazuhironagai77:20211128235840p:plain

やっぱりpivotを中心にして回っていますね。

一応解説も載せておきます。

f:id:kazuhironagai77:20211128235902p:plain

<波が最後まで行かない>

f:id:kazuhironagai77:20211128235921p:plain

これはPreviewから見ていたからでした。

Previewは10秒間表示します。

そしてEmitter Update SectionのEmitter State ModuleのLoop Durationは4秒です。

f:id:kazuhironagai77:20211128235944p:plain

f:id:kazuhironagai77:20211128235950p:plain

更にParticle Spawn SectionのInitialize Particle ModuleのLife timeは4秒に指定しています。

f:id:kazuhironagai77:20211129000013p:plain

f:id:kazuhironagai77:20211129000020p:plain

つまり最後の2秒は途中で終わっていたんです。

Level状に配置したら普通に最後まで回転していました。

f:id:kazuhironagai77:20211129000105p:plain

Convertible Floor in UE5 Niagara Tutorial [2]の復習のまとめ

もう今週は粒度(Granularity)をそろえる事だけを考えてやりました。

粒度(Granularity)が突然荒くなる時は、その箇所を検証するためには、実装を一からやり直す必要があってそれが面倒だったのでやらなかったのが原因の一つでした。

もう一つ、先週やった内容もきちんと復習しておかないとTutorialの粒度(Granularity)と揃わないです。

だたその点に関しては最初の粒度(Granularity)は荒くても段々細かくなっていってもいいのかも知れないとも思いました。

今週の最初の部分ですが、

f:id:kazuhironagai77:20211129000144p:plain

結果的には先週のTutorialの内容と同じですが、その過程を解説していてその結果、先週のTutorialはこの事を解説するためにわざわざSpriteで最初は作成していたんだと言う事も分かりました。

楽しくやるのがもっと大切なのかもしれませんね。

楽しかったら自然と粒度(Granularity) も揃いそうです。

2.1 Convertible Floor in UE5 Niagara Tutorial [2]の残りをやる

先週やらなかった個所がちょっとだけ残っています。でもやるほどの内容はないかもしれません。

一応見てみます。

特に記録しなければならない事はなかったです。

今週は、CGHOW氏のHLSL Triangle code to UE4 Material nodes Tutorial [3]をやってみたかったんですが、時間がなくなってしまいました。来週やります。

3.Material

3.1 Content Exampleをみる

先週の続きをやります。

<先週の復習>

先週のBlogを読み直しました。先週は、Content ExampleのMaterial NodesのTessellation Multiplierについてまで勉強したら、公式のDocumentにそのものずばりMaterial Nodes [4] がある事を発見しました。そこにはそれぞれのNodeの詳しい解説が載っていました。結局、これやり直す必要があるのかとなりBase ColorとMetallicはやり直したんですが、疲れてそこで一端中断となりました。

思い出して来ました。

Material Nodes [4]の解説がそんなに期待した内容じゃなかったんです。

Page半分とかParagraph一個の解説しかなかったんです。粒度(Granularity)で言えばとても荒い解説です。今更読む必要がある内容じゃないです。

それで一端これは一端中止にします。

そもそもContent Exampleを見直した目的は、先週のBlogで述べたように

f:id:kazuhironagai77:20211129000237p:plain

を調査するためでした。

パラッと見てこれは知っている。これはやった事がある。これは全く知らない。位の区別がつけばOKだったんです。つまり粒度(Granularity)は非常に荒いレベルで良かったんです。

例えるなら、博物館でも見に行ってその感想をまとめるレベルで良かったんです。

それを忘れてしまった。しかも楽しく見ると言う事も忘れてしまったんです。

3.2 Material Propertiesを見る

今週はMaterial Propertiesを見ます。

f:id:kazuhironagai77:20211129000304p:plain

先週の反省を活かして、

  • 楽しく見る
  • 軽く見る

を心がけてやります。

公式のDocumentも最初にチェックしておきます。まずそのものずばりのMaterial Properties [5] があります。しかし内容を見るとContent ExampleのMaterial Propertiesとは一致していませんね。

これはMaterialのResult NodeのPropertiesを一個ずつ簡潔に解説してます。以下に示したものです。

f:id:kazuhironagai77:20211129000342p:plain

Content ExampleのMaterial Propertiesはその中の一部の機能に注目してExampleを作っているみたいですね。中には一致しているモノもあるみたいです。

公式のDocumentではその次のShading Models [6]に解説されている内容をやっている箇所もあるみたいです。

まあ、焦らず軽く見て行く事にします。

<Blend Mode

f:id:kazuhironagai77:20211129000413p:plain

Blend Modeは以下に示したようにMaterialのBlend Modeについてのそれぞれの特徴を示した展示です。

f:id:kazuhironagai77:20211129000513p:plain

この中で私が使用した事があるのはOpaque、Masked、Translucentの3つですね。

AdditiveとModulatedは使用した事はないです。Translucentとどう違うんでしょうか?

公式のDocumentであるMaterial Blend Modes [7]にはそれぞれの特徴について詳しい解説が載っています。これを読みながらそれぞれの展示を観察していきましょう。

<<Opaque>>

f:id:kazuhironagai77:20211129000532p:plain

普段使用しているヤツですね。

Material Blend Modes [7]では、後ろの物体が透けて見えない所を解説しています。

<<Masked>>

f:id:kazuhironagai77:20211129000600p:plain

透明な部分がある奴です。

設定方法は以下の様にします。

f:id:kazuhironagai77:20211129000631p:plain

Material Blend Modes [7]では、Maskedは物体の一部が透明でその他は透明でない物に対して使用すると解説されていました。

更にお得な豆知識が一つ紹介されていました。Maskedの透明な部分とTranslucentの違いについてです。Translucentは透明ですがRenderingはしています。何故かと言うと、光の干渉は計算する必要があるからです。それに対してMaskedで透明な部分は最初から描いていません。Renderingしてないそうです。

<<Translucent>>

f:id:kazuhironagai77:20211129000656p:plain

Translucent。つまり半透明です。

Transparentが透明ですが、似ていてよく勘違いします。先程のMaskedの解説でReflectionが出て来ていますが、Reflectionは反射で屈曲であるRefractionと似ていてこれもよく勘違いして使ってしまいます。

Material Blend Modes [7]に以下の解説が載っていますが

f:id:kazuhironagai77:20211129000722p:plain

TranslucentとTransparentをそれぞれ正しく認識しておかないと意味が分からなくなります。

この解説によると黒が完全な透明、白が完全な不透明、グレイは半透明としてRenderingされるそうです。

Content Exampleに展示されている例はOpacityに0.5が設定されていました。

f:id:kazuhironagai77:20211129000737p:plain

Material Blend Modes [7]に、またお得な豆知識がのっていました。

Translucentは現状ではSpecular lightは計算されていないそうです。しかしCube mapの機能を利用して似た効果を追加する事は出来るそうです。

<<Additive>>

f:id:kazuhironagai77:20211129000800p:plain

これは全く知らないです。

一見、Translucentと同じに見えますがどう違うんでしょうか?

Material Blend Modes [7]を読んでみます。

f:id:kazuhironagai77:20211129000824p:plain

と書かれていました。

ああ。

2021-09-19のblogに詳しく解説していますが、Dither Temporal AA ノードと同じ働きをするんですね。

f:id:kazuhironagai77:20211129000841p:plain

後、ここでも黒がTransparentとして扱われるそうです。

当たり前ですが、この方法もlightの影響は計算されません。

先程の2021-09-19のblogを読むとDither Temporal AA ノードはBlend ModeはTranslucentを使用するみたいなんです。このAdditive Blend Modeと色々比較したいですね。

Content ExampleのサンプルのMaterialを見ると

f:id:kazuhironagai77:20211129000940p:plain

f:id:kazuhironagai77:20211129000950p:plain

これしか設定していません。

粒度(Granularity)を保つのが大切です。これ以上細かくすると全体の主旨から外れてしまうのでこれ以上の調査はここでは止めましょう。

<<Modulate>>

f:id:kazuhironagai77:20211129001017p:plain

f:id:kazuhironagai77:20211129001032p:plain

これも全く知らないBlend Modeです。

Material Blend Modes [7]を読んでみます。

f:id:kazuhironagai77:20211129001104p:plain

と書かれていました。

単に掛けているだけならLightの影響は計算されているの。と思ったらされていないそうです。

<Lighting Model

次はLighting Modelについてです。

f:id:kazuhironagai77:20211129001144p:plain

Lighting Modelと紹介されていますが、実際はShading Modelの項についてです。

f:id:kazuhironagai77:20211129001204p:plain

先程も述べましたが公式のDocumentではShading Models [6]に解説されています。

f:id:kazuhironagai77:20211129001227p:plain

<<Default Lit>>

f:id:kazuhironagai77:20211129001248p:plain

f:id:kazuhironagai77:20211129001259p:plain

Default Litについてです。

いつも使っているヤツです。

Shading Models [6]によると、Default Lit ではDirect lighting、Indirect Lighting、そしてSpecular Lightingが適用されるとあります。

でも先週のBlogでも述べましたが、以下に示した陰の無い瓶のMaterialをみると

f:id:kazuhironagai77:20211129001321p:plain

Default Litが使用されているんです。

f:id:kazuhironagai77:20211129001339p:plain

これは本当に謎です。

<<Unlit (Emissive)>>

f:id:kazuhironagai77:20211129001403p:plain

f:id:kazuhironagai77:20211129001413p:plain

f:id:kazuhironagai77:20211129001422p:plain

Shading Models [6]を見てみます。

Unlitの特徴について以下の事が述べられていました。

  • Emissive LightもしくはColorを発する。
  • 火や発光体に使用する
  • LightCastするのではなくGlow 効果を発する。
  • この光から影が作成される事はない。

だそうです。

ここに述べられている事は大体知っていますね。

<<Subsurface>>

f:id:kazuhironagai77:20211129001502p:plain

f:id:kazuhironagai77:20211129001510p:plain

これは知ってはいますが使用した事はないと思います。

これもShading Models [6]を見てみます。

簡単に説明すると表面の下に別な色があってそれが光の錯乱によって浮き出てくるMaterialです。

以下にSample ContentのExampleのMaterialを示しましたがSubsurface Colorに表面下の色を指定しています。

f:id:kazuhironagai77:20211129001602p:plain

更に詳しい解説は、Subsurface Shading Model [8] にあるそうです。

<Translucent Lighting Mode

f:id:kazuhironagai77:20211129001630p:plain

これは全く知らない機能ですね。

TranslucencyのLighting Modeについての例を展示しています。

f:id:kazuhironagai77:20211129001648p:plain

公式のDocumentがないのか探したらありました。Materials Content Examples [9]です。

f:id:kazuhironagai77:20211129001712p:plain

先週の反省を活かしてまず公式のDocumentを探して見ました。

ないと思っていたんですが全く違う箇所にありました。

このPageのMaterial Properties Mapの所に

f:id:kazuhironagai77:20211129001744p:plain

全部の解説場所がしるされています。

f:id:kazuhironagai77:20211129001757p:plain

これのTranslucent Lighting Mode [10] をみます。

f:id:kazuhironagai77:20211129001823p:plain

これを参考にして展示されているサンプルを見てみましょう。

<<Volumetric Non Directional>>

f:id:kazuhironagai77:20211129002020p:plain

f:id:kazuhironagai77:20211129002029p:plain

Translucent Lighting Mode [10]によると

f:id:kazuhironagai77:20211129002056p:plain

と解説されています。

ふーん。

成程。VolumetricとしてMeshをRenderingしているんですね。このやり方ではDiffuse lightingのみ表示されてNormalは使用されない。そうです。

因みにCursorをVolumetric Non Directionalに合わせた時に表示される解説では

f:id:kazuhironagai77:20211129002114p:plain

Lightは計算されるけどLightの方向性までは計算しません。と言う事とLighting Modeの中でもっとも安価なやり方であるとあります。

ああ。分かった。

先程のBlend ModeのTranslucentの更に先の選択についてここで解説していたんです。

はー。やっとわかった。

f:id:kazuhironagai77:20211129002130p:plain

つまり、この展示されているサンプルはBlend ModeのTranslucentで展示されているサンプルと同じ物って事です。

前の節の<Lighting Model>は

f:id:kazuhironagai77:20211129002144p:plain

Blend ModeのOpaqueの場合のその先の選択について解説していたんです。

やっと繋がりました。

分かってくると楽しくなって来ますね。

うーん。でもTranslucentでもShading ModelでDefault Lit以外も選択出来はしますね。

f:id:kazuhironagai77:20211129002158p:plain

Blend ModeがTranslucentの時のShading Modelの違いについては自分で調べろと言うみたいですね。

<<Volumetric Directional >>

f:id:kazuhironagai77:20211129002221p:plain

f:id:kazuhironagai77:20211129002232p:plain

まず公式の解説、Translucent Lighting Mode [10]を見ます。

f:id:kazuhironagai77:20211129002257p:plain

こっちはNormalの影響も計算するみたいです。Diffuse lightingのみ表示されるそうです。

Cursorを合わせた時に表示される解説です。

f:id:kazuhironagai77:20211129002311p:plain

こっちの解説を見るとLightの計算で方向を考慮するので結果的にNormalの値も考慮されるとあります。

おお。

役立つ豆知識がここに書かれています。

ParticleのTangent Spaceはdefaultではカメラに向いているので、b Generate Spherical Particle Normalを使用可能にしてもっと役立つTangent Spaceを使用しましょう。と

b Generate Spherical Particle NormalはMaterialの項にあるこれの事でしょうか?

f:id:kazuhironagai77:20211129002345p:plain

Particleの作成にTranslucentかつVolumetric DirectionalなMaterialを使用する時は、この事を気を付けておきましょう。

<<Surface(Metallic Material to show reflections)>>

f:id:kazuhironagai77:20211129002412p:plain

Translucent Lighting Mode [10]をみます。

f:id:kazuhironagai77:20211129002432p:plain

これはReflectionつまり反射が写っているんですね。

確かに透明な部分に床か反射して写っています。

単純に凄いです。

私、この解説を読むまでこの反射して床が写っている事に全く気が付きませんでした。これと前節で解説されていたCube mapを使用してSpecularを追加する方法って同じ事をやっているんでしょうか?ちょっと気になります。

Cursorをおいた時に表示される解説です。

f:id:kazuhironagai77:20211129002446p:plain

表面のLightingが計算されると書かれています。これはReflectionについて述べているんでしょうか?

あんまりCostはかからないみたいな事も書かれていますね。

機会があったらぜひ使ってみたいです。

3.2 Shader Performance Measurement - Shader Graph Basics - Episode 21 [11]について

Ben Cloward氏のShader Performance Measurement - Shader Graph Basics - Episode 21 [11]を勉強します。

まずパラっと見ました。

今回は題の通りShaderの計算コストの測り方についてです。

簡単に結論から述べるとMaterialのStatsに表示されるInstructionの数からでは本当のShaderの計算コストを推測する事は出来ないと言う事です。

f:id:kazuhironagai77:20211129002526p:plain

その理由は

  • InstructionではLoopはすべての可能性についてCountされている。
  • InstructionはDataが大きくなる事による余計なCostについてもCountされていない。
  • 幾つかのInstructionは他のInstructionより極めて高いCostがかかる。

だからだそうです。

途中で、Shader Playground(https://shader-playground.timjones.io/)を使用して本当のコストを計算します。

f:id:kazuhironagai77:20211129002557p:plain

これの使い方を覚えるのが今回のTutorialの肝ですかね。

<Weather_Rainノードを使用したInstruction数の変化の確認>

f:id:kazuhironagai77:20211129002616p:plain

このNodeを付けたり外したりしてInstructionの数が増えたり減ったりするのを確認したんですが、再現出来ません。理由はこのノードが見つからないからです。

<Shader Translation Steps

MaterialのShaderがどうやって実際のInstructionまで変換されるのかについての解説です。

f:id:kazuhironagai77:20211129002644p:plain

最初のMaterial BPからHLSLの変換はまあ誰でも知っています。2つ目のHLSLからAssemblyへの変換も分かります。最後のそれぞれのVideo Cardに対応したCommandに変換する処は全く知らんかったです。

因みに、Materialに表示されているInstruction数は三番目のAssembly言語におけるInstructionの数だそうです。

なのでLoopの全ての可能性をInstruction数に含んでしまう訳です。

うーん。勉強になる。

<Shader Playground

この最後のそれぞれのHardware独自のCommandに変換するところをもっと詳しく勉強します。そのためにShader Playgroundを使用します。

これですね。

f:id:kazuhironagai77:20211129002707p:plain

このShader Playgroundがあんまりにも素晴らしいからこれからはUnityやUnrealは使用しないでここにCode書いていきます。って言ってます。

f:id:kazuhironagai77:20211129002723p:plain

f:id:kazuhironagai77:20211129002728p:plain

f:id:kazuhironagai77:20211129002735p:plain

え。と思ったら

f:id:kazuhironagai77:20211129002818p:plain

だって。

正直、それはそれでHLSLの勉強が出来て助かると思ってしまいました。

HLSLのコードです。

f:id:kazuhironagai77:20211129002842p:plain

これを以下の条件でCompileします。

f:id:kazuhironagai77:20211129002901p:plain

以下の結果になります。

f:id:kazuhironagai77:20211129002926p:plain

ほぼ同じコードで同じ事をします。

f:id:kazuhironagai77:20211129002945p:plain

前とほぼ同じですがSineが追加されています。

これを前と同じCompilerでCompileすると

f:id:kazuhironagai77:20211129003003p:plain

こうなります。

ここからがShader Playgroundの凄い所です。

このCompilerの値をRadeon GPU Analyzerに変更すると

f:id:kazuhironagai77:20211129003025p:plain

以下に示した様にRadeon 用に書き直したAssembly Codeを示してくれるんです。

f:id:kazuhironagai77:20211129003044p:plain

凄い。

全然違う。

しかしこれ位で驚いてはいけません。

何とCodeが表示されている上の部分の設定をISA Breakdownに変更すると

f:id:kazuhironagai77:20211129003100p:plain

以下に示した様にそれぞれのInstructionのcycle数まで示してくれるんです。

f:id:kazuhironagai77:20211129003119p:plain

SinのCycle数は16もありますね。

もう丸裸と同じですね。

ただ残念な事にGeForceはないです。のでこの計算結果は厳密に言えばGeForceの時と同じかどうかは分かりません。

はい。

Tutorialによると、ここで注目するのはSineのInstructionの数だそうです。

4個ありますね。

これは

f:id:kazuhironagai77:20211129003229p:plain

計算に使用される変数がFloat4でFloatが4つあるからです。

しかしAssembly Codeを見直すとそこでは一行で書かれています。

f:id:kazuhironagai77:20211129003249p:plain

これはFloat4じゃなくてFloatだとしてもAssembly Codeでは同じ1行で示されます。しかし実際のCycleはFloat4の場合はFloatの4倍の長さになります。

更にSineは計算するのに16 cyclesも使用しています。

以下にTutorialにのっていたAssembly CodeのそれぞれのInstructionのCycle数を示します。

f:id:kazuhironagai77:20211129003311p:plain

全然違いますね。

Shader Performance Measurement - Shader Graph Basics - Episode 21 [11]のまとめ>

はい。これで最初に説明した

  • InstructionではLoopはすべての可能性についてCountされている。
  • InstructionはDataが大きくなる事による余計なCostについてもCountされていない。
  • 幾つかのInstructionは他のInstructionより極めて高いCostがかかる。

の具体的な理由が説明されました。

Dataが大きくなるとはFloatからFloat4になる事です。

それで解決策なんですがそれは次のTutorialでやるそうです。

うーん。今回のTutorialは本気で神回でした。

4.NPCAIを作成するためのAIの復習の続き(Environment Query System

今週からEnvironment Query Systemの勉強を開始します。

公式のDocumentであるEnvironment Query System [12] を見ると

Starting Outに一個

f:id:kazuhironagai77:20211129003349p:plain

Essentialsに4つの解説兼Tutorialが載っています。

f:id:kazuhironagai77:20211129003410p:plain

これらをやっていきます。

4.1 今まで勉強したEnvironment Query Systemの復習と整理

その前に今までに勉強したEnvironment Query Systemについて一回復習します。

自分のBlogを読み直すと結構良い感じにまとまっています。その結果、自分のBlogで復習した方が速く理解出来ます。のでBlogの復習からやります。

2021-02-01のblog2021-02-07のBlogでEnvironment Query Systemについて勉強しています。

2021-02-01のblogではOnline LearningのIntroduction to AI with Blueprintを勉強しています。

f:id:kazuhironagai77:20211129003441p:plain

その中でEnvironment Query Systemについて勉強したんでした。

2021-02-07のBlogでは何と、Environment Query System [12]の

f:id:kazuhironagai77:20211129003500p:plain

を勉強していました。しかもかなり本格的に勉強して記録もしっかりしています。

Environment Query System Quick Startを勉強した事なんてすっかり忘れていました。

これは復習して正解でした。

2021-02-01blogの復習>

Online LearningのIntroduction to AI with Blueprintでは以下のLectureでEQSについて勉強しています。

  • 講義22: Creating the First EQS Query
  • 講義23: Creating the Second EQS Query
  • 講義24: Using the EQS Testing Pawn
  • 講義 25: EQS Gameplay Debugger

です。

<<講義 22: Creating the First EQS Query>>

ここで講義とは直接関係ないんですが、超重要な発言しています。

f:id:kazuhironagai77:20211129003536p:plain

4.26ではEnvironment Query Systemは標準装備になっている事です。

Environment Query System [12]でも

f:id:kazuhironagai77:20211129003549p:plain

と書かれていますが、EQSは既に標準装備になっています。

EQSを使用する目的に

f:id:kazuhironagai77:20211129003611p:plain

と書いていますが、こんな事EQSを使ったら出来るようになるんでしょうか?全く覚えていません。

後、EQSはBehavior TreeでTaskのように使用すると書いていますね。

f:id:kazuhironagai77:20211129003626p:plain

確かにEQSがTaskの代わりとして使用されています。

<<講義23: Creating the Second EQS Query>>

ここでは、EQS Queryを使用してPlayerに最も近い場所かつPlayerから見つからない場所を探す実装を勉強しています。

ただし

f:id:kazuhironagai77:20211129003723p:plain

動画を見てただけなので実装はしていません。

こうやって見直すと自分の弱点が良く見えてきますね。本当に実装嫌っています。

見たり感想をまとめたりするのは好きですが、実際の物作りは例えSoftwareでProgrammingしか書かなくて良い場合でもやってないですね。

その後、代案として講義で説明された実装をBlogにまとめると書いてあります。

まとめられた内容を読みましたが、あんまり分かり易くないですね。

まず以下に示した様にSimpleGrid: generate around Querierノードを追加するとあります。

f:id:kazuhironagai77:20211129003747p:plain

でもどこのBPに追加しているのかは書かれていません。Behavior Treeなのか別なEQS専用のBPクラスがありそこに作成しているのかはこのBlogからは分かりません。

f:id:kazuhironagai77:20211129003826p:plain

そのノードにPlayerから見えない場所か?距離は?そこにたどり着く道は存在するのか?などをチェックする機能を追加しています。

<<講義24: Using the EQS Testing Pawn>>

f:id:kazuhironagai77:20211129003855p:plain

と書かれていました。

あー。すっかりこんなDebugがある事忘れていました。

EQS Testing Pawn BPクラスと言うEQSをテストする為だけに作成されたクラスがあるんです。それの使用方法がまとめられています。

今回の復習ではこのクラスの存在を思い出しただけで十分です。

<<講義 25: EQS Gameplay Debugger>>

これ何の説明もしてません。先週、復習したGameplay Debuggerのnum3を押すとEQSのDebugが出来ますが、それの使用方法について解説した講義だと推測されます。

2021-02-07Blogの復習>

ぱっと読んだらEQSに対してかなり重厚な勉強をしています。

まずEQSに対して仮説を立ててそれを検証しながら勉強を進めています。

f:id:kazuhironagai77:20211129003922p:plain

この仮説に基づき

f:id:kazuhironagai77:20211129003937p:plain

のやり方を判明させるのを目的としています。

何というかやる気を感じます。この週はどうしちゃったんでしょうか?

ここからEnvironment Query System [12]の

f:id:kazuhironagai77:20211129003957p:plain

をやっていきます。

<<Required Project Setup>>

以下のクラスを作成しました。

f:id:kazuhironagai77:20211129004020p:plain

UE4のAIで必要ないつもの4つのクラスに+2つのクラスをEQS様に追加して作成しています。2つの新しいクラスはEnvironment QueryとEnvQueryContext_BlueprintBaseから作成しています。

<<Environment Query Context>>

f:id:kazuhironagai77:20211129004104p:plain

これを作成して終わりです。コメントには何をやっているのか全然分からないと書かれていました。

<<EQS Setup>>

Environment Queryから派生して作成したEQS_FindPlayerにBPで実装します。

f:id:kazuhironagai77:20211129004125p:plain

先程も出て来たSimple Grid: generate around Querierノードを追加してます。

この後ずっとこのノードの設定方法について推測しています。

ここは来週、実際に

f:id:kazuhironagai77:20211129004145p:plain

をやる時に読み直します。

<<Blackboard and Behavior Tree Setup>>

この内容はスキップしています。確かにこれはEQSの勉強とは関係ないです。

<<Behavior Tree: Patrol Setup>>

Get Random Reachable Point in Radiusノードについて検証しています。

f:id:kazuhironagai77:20211129004214p:plain

このNodeが「Reachableじゃない時はfalseを返すのでは無くて、GetRandomReachablePointInRadius関数の返した値は全てReachableですが、何らかの理由で値が返せない時に、falseが返されるみたいです。」と言う結論になると書かれています。

時間があったらこれも検証し直してみましょう。

<<Behavior Tree: In Combat Setup>>

ここではBehavior TreeからEnvironment Queryから作成したEQS_FindPlayerを呼び出す方法が説明されています。

<<AI Controller Setup並びにFinal Setup>>

EQSに関係ないのでSkipしています。

<<テスト>>

BugがあってTutorial通りに動いてないと書かれえていました。波乱万丈です。自分で書いてあれですが、読んでて面白いです。

次の章でEQSのDebug方法について習うのでそれを勉強した後で直すと書かれています。

これを読んだとき思わず笑みがこぼれてしまいました。

<<End Result>>

GamePlay DebuggerでEQSを見る方法が紹介されていたそうです。

何かのテストを行って望んだ結果が出ている事が書かれていますが、

f:id:kazuhironagai77:20211129004258p:plain

書かれている内容からは今一全体像が把握出来ません。

上の図だとPlayerの操作するキャラとNPCの位置関係が分からないのでこの結果で正しいのかが不明です。

<<EQS Testing Pawnいろいろ>>

最後に色々なテストを行っています。

これで終わりかと思ったらこれからまだ色々やっています。

<<EQS Quick Start 勉強まとめ(仮)>>

EQSの勉強した内容をまとめています。

f:id:kazuhironagai77:20211129004330p:plain

いや勉強した内容をまとめると言うより勉強して分からなかった事をまとめています。

<<EQSのDebugの復習>>

復習と言いながら、また疑問を書いています。

f:id:kazuhironagai77:20211129004349p:plain

Num/を押すとDivideが選択出来るそうです。

f:id:kazuhironagai77:20211129004413p:plain

これは今は質問の意味が分からないですね。来週、もう一回やるのでその時には質問の意味も理解出来るようになるでしょう。

この問題に対する解答も書かれていました。

f:id:kazuhironagai77:20211129004429p:plain

これはBlogの解説を読んだんですが今の知識では意味が分かりません。今週はパスします。

<<EQSのバグの直し>>

最後にここまで学んだEQSのDebug知識を使用して先程作成したけどきちんと動いていないEQSを直します。

色々検討していますが、これも来週やった後で読む事にします。今の知識では良く分かりません。

<EQSの復習まとめ>

今週はここまでとします。自分の書いたBlogとは思えないです。凄くよくまとまっています。

5.Game DesignポケモンHxHの念能力 Part 2

5.1 先週の内容をまとめ直す

先週、HxHの念能力をどうやってGameに落とすのかを考察している昔のBlog(2021-02-01のBlog)を発見しました。

読み直したら以外に面白かったんです。それでどうしてこんなに面白いのか考察しました。

結論はHxHの念能力はポケモンなどの火とか水などのタイプ別ゲームとは全く違う機能があり、それがHxHの念能力を凄く興味深いものにしていたんです。

ポケモンに代表される火とか水などのタイプ別ゲームは、基本的には戦略ゲームなんです。分かり易く言うと戦闘する前に勝敗が決定します。戦闘中に出来る事は非常に限られています。

それに対して念能力は戦術ゲームなんです。戦闘が不利な条件で開始しても戦闘中の工夫で逆転して勝利する事も可能になります。

この逆転の要素がHxHの念能力を面白くしています。

具体的に言うと、味方の戦闘力やStatusを一時的に上げる(強化系)、味方や敵の属性を変化させる(変化系)、召喚する(具現化系)、敵を眠らせる(操作系)などです。

これらの能力は戦局を一変します。今まで有利だったのが一気に不利になりえますし、その逆もありえます。

これが戦闘を面白くさせているんです。

ここから議論を一般的な戦闘システムに展開する為に、一端まとめます。

まず戦闘が開始する前に勝敗が決してしまうポケモンなどの火とか水などのタイプ別な要素などを戦略的要素、戦闘中でも逆転出来るHxHの念能力な要素を戦術的要素と呼ぶ事にします。

これらは、一般的なゲームでは魔法として使用されていますが、タイプ別のモンスターや念能力のタイプのようにその種族や個人の特徴として存在する場合もあります。

この分類を使ってまず少年マンガの戦闘システムを分析してみます。

ドラゴンボール

ドラゴンボールは戦闘力が全てを決定します。つまり戦闘する前に勝敗が決定してしまう、戦略的な戦闘システムです。

界王拳のような戦闘中でも逆転出来る戦術的要素は極僅かに存在しますが勝敗はほぼ100%、戦う前に決定している戦略的な戦闘システムです。

<ワンピース>

ワンピースには戦闘システムが存在しません。その場限りのルールがあって話の展開にそって戦闘ルールがどんどん変更してしまいます。ので考えるのは無駄です。

これ凄い不思議な話で、ワンピースは七武海やワンピースそのもののアイデアをゲームから発展させているにも関わらず、ゲームに必須である戦闘システムが存在していないんです。これが映画ファンであらゆる映画を観たみたいな人が書いた漫画なら納得ですが凄い不思議です。

<ナルト>

ナルトの戦闘システムは大変複雑で簡単には言えませんが、戦闘力などが高い方やタイプ別で有利に立った方が勝つ戦略的な要素と、感知タイプや幻術使いなどの戦闘中でも逆転出来る戦術的な要素が存在しています。これに体術などの直接攻撃の要素や召喚術などもあります。

戦略的な要素と戦術的な要素が半々で存在している戦闘システムとみなせるでしょう。

よし。段々調子に乗って来ました。

次はゲームの戦闘システムに対してこの分類を適応してみます。

まずはRPGゲームの戦闘システムに対してです。

JRPGの代表としてドラゴンクエストの戦闘システムから見てみます。

ドラゴンクエストの戦闘は面白いんです。見てて飽きない。それはHxHの念能力のような戦闘中でも逆転できる戦術的な魔法がふんだんにちりばめられているからだと思います。

ただし私、あんまりゲームをしないので具体的な内容が分かりません。

【ドラクエ5】呪文・特技一覧【DQ5】を参考にして議論する事にします。

ドラゴンクエスト5だけは一寸だけやったからです。

基本的にはドラゴンクエストの戦闘システムは、戦略的な戦闘システムだと思います。レベルを上げてぶん殴れば勝てるからです。ここで紹介されている魔法も大体は戦略的要素が高い、つまり高い攻撃力のみが重要なものが多いです。その中で戦術的な要素を感じるのが、グループ全体に攻撃する魔法です。これは戦闘中に最適な攻撃方法を考える必要が生まれます。一体の強い敵を先に倒すのか、沢山の弱い敵を先に倒すのかの選択を迫られます。

更に戦術的な要素そのものである味方の戦闘力を上げたり、敵を眠らせたりする魔法も結構あります。

何故かこれらの戦闘システムを面白くするための必須の戦術的な要素を持つ魔法は補助魔法に分類されています。

この補助魔法を先程のHxHの念能力別に分類しています。

<<強化系>>

スカラ、バイキルド、マホキテフバーハなど。

<<変化系>>

なし。

ドラゴンクエストには属性がないからなくてもおかしくはないのかも。

<<具現化系>>

なし。

ドラゴンクエストには召喚魔法もないのでなくてもおかしくはない。

<<操作系>>

マヌーサラリホールカニマホトーンなど

<<放出系>>

これは分類が難しいので後回し。

となりました。

見事にこれらの補助魔法はHxHの念能力にフィットします。

ドラゴンクエストの戦闘が面白い理由の一端が解明しました。

しかしドラゴンクエストの戦闘システムの分析をここまでまとめて二つの疑問が出て来ました。

最初の疑問は、なんでこれらの戦局を一変する魔法が補助魔法のような分類になっているんでしょうか?こっちが主の魔法じゃないんでしょうか?というモノです。

これは結局、ドラゴンクエストがレベルを上げてぶん殴る事で勝つ戦略的なゲームに属するからでしょう。戦闘中に逆転出来る戦術的な魔法は補助に留まっている必要があったんだと思います。

次の疑問は、回復系魔法は戦局を一変する魔法で戦術的な魔法です。ドラゴンクエストでも重要な魔法となっています。しかしHxHの念能力にはぴったし当てはまるタイプがありません。

あ、分かった。HxHは漫画だからゲームほど回復系の能力が必要じゃないんです。

だったらHxHの念能力のような戦術的な魔法だけを集めてもう一回分類したら良いと思いました。

更にNarutoの感知タイプみたいなのも念能力のタイプに入っていないので追加しました。

そしたらこうなりました。

f:id:kazuhironagai77:20211129004628p:plain

ここまで先週は考えました。

5.2 新しい戦闘システムの作成

先週のこの考察を踏まえて、新しい戦闘システムが構築出来るのではないのかと思い結構考えました。

まず、HxHの念能力のような戦闘中に戦局を逆転出来る戦術的な魔法は、これがRPGの戦闘を面白くする要にも拘わらず、現在のJRPGでは補助魔法として不当な低い評価をされています。

私がこの原因は以下の理由によるものだと思っています。

この理由は、戦闘中の工夫で勝敗が変わってしまうと戦闘前に必死にレベルを上げたり、貴重なポケモンを集めたりする必要がなくなってしまうからです。だからJRPGの戦闘システムは常に戦闘前に勝敗が決定する戦略型戦闘システムになっています。そうする事で、レベルを上げたり、ポケモンを集めたりする価値を保っています。しかしそれだと戦闘する意味そのものが無くなってしまうので少しだけ戦術面の工夫ができるように、HxHの念能力のような戦闘中に戦局を逆転出来る戦術的な魔法は、威力を弱めて補助魔法として少しだけ戦闘に影響を与える事が出来る程度、追加しています。

これを改善します。

<案1>

Playerが操作する魔術師はHxHの念能力のような戦闘中に戦局を逆転出来る戦術的な魔法のみを使用出来る。

Playerが操作する魔術師が召喚したMonsterはポケモンのようなタイプ別モンスター兼タイプ別の魔法のような戦闘前に勝敗が決定する魔法だけ使用出来る。

f:id:kazuhironagai77:20211129004705p:plain

この形のポイントは3体のmonsterが同時に戦う事です。そうするとPlayerが操作する魔術師が強力なHxHの念能力のような戦闘中に戦局を逆転出来る戦術的な魔法を発動しても、3体全部の不利を逆転する事は出来ません。一体位なら出来るでしょう。

これでポケモンのようなタイプ別モンスター兼タイプ別の魔法のような戦闘前に勝敗が決定する戦略的な面白さを保ちつつ、HxHの念能力のような戦闘中に戦局を逆転出来る戦術的な魔法も使用出来る事で面白い戦闘システムも確保できる気がします。

<案2

HxHのグリーンアイランドのカードの様に、HxHの念能力のような戦闘中に戦局を逆転出来る戦術的な魔法はカード化、もしくはアイテム化して一回使用すると消滅するようにする。

f:id:kazuhironagai77:20211129004737p:plain

これだけだといくらでも貯めれるので貴重性がなくなります。のでHxHのグリーンアイランドのカードの様にカード化限度枚数とゲームのクリア条件に全ての種類の魔法カードをそろえる条件は付ける必要があります。

作るのなら案2の方が簡単ですね。

このアイデアはかなり使える気がします。もう少し継続して検討する事にします。

6.RPGの作成の続き

Landscape4は自分で作成したMonster生成クラスがあるので敢えてLoad Stream Levelで作り直す必要はないと思うようになりました。のでLoad Stream Levelノードは別なmapを作成した時に使用する事にします。

それで今週のRPGの製作はやる事がなくなってしまいました。のでこれから作成する必要がある箇所をMap1を探索しながら検討します。

6.1 修正が必要な個所を見つける

Map1にPlayerが操作するキャラが現れた時点でLandscapeが出来ていないので見た目が変です。

f:id:kazuhironagai77:20211129004805p:plain

Effectを追加してワープしている所をアピールするとか、画面を暗くしてLandscapeが生成出来ていない事を隠すなどをする必要があります。

井戸の前に立っています。

f:id:kazuhironagai77:20211129004825p:plain

こういうObjectの前に立った時も(!!)を表示してEボタンをクリックする事で、「井戸だ。水が満ちている。」のようなコメントが表示出来るようにしたいです。

宿屋ですが、看板が英語になったままです。日本語に直します。

f:id:kazuhironagai77:20211129004852p:plain

以下の二つのEffectは重いので近づいた時だけ点火するようにしたいです。

f:id:kazuhironagai77:20211129005109p:plain

このABCの看板は

f:id:kazuhironagai77:20211129005136p:plain

地図についているWarp機能のワープ先です。

f:id:kazuhironagai77:20211129005200p:plain

この機能を消すのか、今は使用出来ないけど将来的には使用出来るようにするのか考える必要があります。

戦闘画面に移動する時も

f:id:kazuhironagai77:20211129005222p:plain

以下のLoad画面が3秒間表示されます。戻るときだけでいい気がします。

f:id:kazuhironagai77:20211129005243p:plain

後Load画面とLoad中に表示される文章の数をもっと多くする必要があります。

戦闘画面ですが空が明かるすぎます。

f:id:kazuhironagai77:20211129005303p:plain

Good Skyを入れて戦闘が開始した時と同じ明るさにしたいです。

戦闘に勝利した後、石像に話掛ける時、石像の頭に(!!)が表示されても見えません。

f:id:kazuhironagai77:20211129005332p:plain

頭を上げる必要があります。

f:id:kazuhironagai77:20211129005349p:plain

戦闘後に戦闘場を動き回るのためにはMonsterの死体は邪魔です。

f:id:kazuhironagai77:20211129005412p:plain

消してしまいましょう。

この警告が唐突過ぎます。

f:id:kazuhironagai77:20211129005439p:plain

立て看板を作成してそれを読んだら、このようなWidgetが表示されるようにしたいです。

Playerの操作するキャラが最初からとんでもないお金を持っています。

f:id:kazuhironagai77:20211129005459p:plain

0に戻します。

ポーズ画面の名前の欄にKUMOと表示されています。直します。

f:id:kazuhironagai77:20211129005518p:plain

HP、MPのみが表示されていて最大HPと最大MPが分かりません。

落下による死亡の時も

f:id:kazuhironagai77:20211129005536p:plain

以下のLoad画面が表示されます。

f:id:kazuhironagai77:20211129005552p:plain

要らないか落下死専用のLoad画面を表示したいです。

同じMonsterしかいません。Monsterの種類を増やしたいです。

f:id:kazuhironagai77:20211129005614p:plain

使用出来る魔法が2種類の火の魔法しかありません。

f:id:kazuhironagai77:20211129005644p:plain

増やしたいです。

最初の村で全てのItemと全ての武器が買えるようになっています。

f:id:kazuhironagai77:20211129005747p:plain

f:id:kazuhironagai77:20211129005754p:plain

直します。

どこかのBPにPrint Stringが配置されたままです。

f:id:kazuhironagai77:20211129005824p:plain

消します。

ぱっと見ただけでこんなに問題がありました。

それで来週からはこれらを直していこうと思います。

6.2 ゲームの制作に関して改善が必要な点

ここまで制作してどうしても改善が必要な個所が2つあります。それをここにまとめておきます。

<目的をはっきりさせる。Gameを作成したいのか、Gameで使用する一部のパーツを作成したいのかなど>

一つ目は、また粒度(Granularity)の話になりますが、もし目的がゲームの作成ならば、一人で制作するのですから全部を全て作成する事は出来ません。ゲームの作成に必要なパーツを集めてプラモデルのように組み立てる事を主な作業にすべきでした。

ゲームの作成が目的ならば

  1. ゲームの設計
  2. そのゲームの作成に必要なパーツの決定
  3. それぞれのパーツを集める、もしくは作成する
  4. パーツを組み立てる
  5. テスト

の順で作成する事になると思います。

ここでRPGを作成するとすると必要なパーツもそこで決定します。このパーツを全部一人で作成したい訳です。私は。これだと終わりません。ある程度は既に存在しているモノを利用する事も考える必要があります。

例えば今回のケースだとGameのEffectがあります。

もうNiagaraの勉強そのものが面白くなってしまってGameの製作そっちのけで勉強しています。それはそれで良いのですが、目的をはっきりさせないとGame制作の方が永遠に終わらなくなってしまいます。

このGameは4.24で制作しているのでNiagaraは使用出来ないんです。だから魔法のEffectを追加するとなるとCascadeで自分で作成するか、今あるEffectをそのまま使用するかしかないです。つまりこのGameの製作においてNiagaraの勉強は全く役に立ちません。

恐らくこのGameに使用するEffectは無料で頂いた以下のAssetにあるEffectをそのまま使用する事になると思います。

f:id:kazuhironagai77:20211129005903p:plain

後Game Designに関しては、販売するためでなくGame作成の勉強のためなら既存のGameの丸コピをしても良かったと思います。

そうする事でGame Designというパーツは既に存在しているモノをそのまま利用できるからです。

例えば今回のGameの場合だったら、ドラゴンクエストの1と全く同じGameを作成しても良かったと思うんです。勉強が目的だから。そうした方が一定のLevelが保てるのと、技術が足りない部分がはっきりしたりしたと思います。

今回はどんなパーツが必要なのかも知らなかったし、それぞれのパーツを自作するためにどこまで勉強が必要なのかも分からなかったですのである程度の回り道をするのは仕方ないです。

次回作はもっと計画をしっかり立てて作成する事にします。

<テスト用のProjectと本番用のProjectを分ける>

本番用のProjectでテストしていると何時まで経ってもテスト用のままになってしまいます。

これはどうやったら分けられるのかちょっとまだ分かりません。でも分けないと完成しない気がします。

7.UE5におけるWorld Partitionの勉強の続き

7.1 先週の間違い

f:id:kazuhironagai77:20211129005935p:plain

ここWorld Compositionではなく

f:id:kazuhironagai77:20211129005953p:plain

でした。

完全に書き間違えています。

7.2 Level Instancing [13]を勉強する

今週はこれを勉強します。

まずLevel Instancingが何を指しているのか不明です。その辺を明らかにする事から始めます。

f:id:kazuhironagai77:20211129010019p:plain

って書かれています。

うん。これじゃほとんど分からないですね。

今までWorld Partitionを勉強して来ましたが、Non World Partition Worldって何を指しているんでしょうね。

現状、World Partitionを起動させるためにはEngineのWorld Partitionにチェックを入れるしかないはずです。

f:id:kazuhironagai77:20211129010038p:plain

でこれをするとProject全部のLevelがWorld Partitionになるはずです。

となるとNon World Partition WorldはProject内には存在出来ないですよね。全部World Partitionになりますから。

EngineのWorld Partitionにチェックを入れない状態で存在するMapにWorld Partitionの機能を使用すると言う事でしょうか?

そんな事可能なんでしょうか?

その後に、create complex streaming strategiesと書かれています。

f:id:kazuhironagai77:20211129010059p:plain

一番目は何を言っているのか不明です。Level Instanceは特別なActorを使用する必要があるんでしょうか?

2番目は意味が分かります。

複数のStreamingを同じLevel上で行う事が出来るとあります。UE4ではこれは出来ないそうです。今知れてよかったです。実は複数のStreamingを組んでみようと思っていました。

3番目の意味も分かります。

Sub Level内にSub Levelを作成する事も出来るみたいです。

これまでの文章から推測するにLevel InstancingはUE4のLoad Stream Levelノードの進化版じゃないでしょうか?

まあ結局、何をしているのか不明です。

ネットで調べたら、Tech Art Aid 氏の動画、UE5 Quick Tip: Packed Level Instances (Prefabs?) [14] がありました。

これを見ると単に幾つかのActorをまとめて一つのActorとして扱う機能のようです。

World Partitionとは関係なさそうです。

うん。分からん。

今回は分かる所が分かれば良い位の気持ちで読んでいきます。

<Creating Level Instances

Level Instanceの作り方が説明されています。UE5 Quick Tip: Packed Level Instances (Prefabs?) [14]では実演されているので、自分でも試してみます。

以下に示した4つCubeでLevel Instanceを作成してみます。

f:id:kazuhironagai77:20211129010124p:plain

4つのCubeを選択したまま、Shift + 右クリックします。

以下に示した表示が示されるのでそこからCreate from selectionを選択します。

f:id:kazuhironagai77:20211129010143p:plain

すると以下に示したNew Level Instanceが表示されます。

f:id:kazuhironagai77:20211129010201p:plain

TypeにPacked Level Instanceを選択します。

するとどこにSaveするかと聞いて来ますのでこのLevelがあるFolderを指定しました。

f:id:kazuhironagai77:20211129010219p:plain

このNew Mapがその時にSaveしたものです。統合したActorをSaveするんじゃなくて統合したActorのあるMapを新しくSaveしています。

4つのCubeは一つのActorとして動かせるようになりました。

World Outlinerでも以下に示した様に

f:id:kazuhironagai77:20211129010242p:plain

一個のActorとして表示されています。

<<Packed Level Instances>>

先程、Level Instanceを作成するのにPacked Level Instanceを選択しましたが、ここではそれについて勉強します。

f:id:kazuhironagai77:20211129010303p:plain

先程、Group化したCubeのGroup化を最小限のStatic Mesh Instanceで行う方法のようですね。

Static Mesh以外はPackされないそうです。

<Editing Level Instances

Level Instancesの編集方法について解説しています。

編集画面を開きます。

Level Instancing [13]には2種類のやり方が載っていました。

一つ目は右クリックして表示させたメニュー欄からEdit(Level Instanceの方を選ぶ、その下のC++のEditは選ばない)を選択する方法です。

f:id:kazuhironagai77:20211129010325p:plain

2つ目はDetailにあるEditボタンを押す方法です。

f:id:kazuhironagai77:20211129010347p:plain

Tech Art Aid 氏はUE5 Quick Tip: Packed Level Instances (Prefabs?) [14] では2つ目の方法を使用して編集画面を開いていますね。

こっちでやってみます。

画面が真っ白になりました。

f:id:kazuhironagai77:20211129010405p:plain

この後、Tech Art Aid 氏のUE5 Quick Tip: Packed Level Instances (Prefabs?) [14] では編集のやり方が説明されるのですが、公式のDocumentであるLevel Instancing [13] にはそれが書かれていないようです。

一応、Tech Art Aid 氏のやり方をここで記しておきます。

以下に示した様にCubeの位置を変更しました。

f:id:kazuhironagai77:20211129010425p:plain

Level Instanceを選択した状態で右クリックしてCommitを選択します。

f:id:kazuhironagai77:20211129010447p:plain

これで変更がSaveされるそうです。

変更を消したい場合はその下のDiscardを選択すれば良いそうです。

試しにCommitを選択したら以下のようにCubeの位置がずれたLevel Instanceに変更されました。

f:id:kazuhironagai77:20211129010512p:plain

後、Commitを選択したら自動的に編集画面から出る事も出来ました。

何気に編集画面から出れなかったらどうしようか心配してたんで、編集画面からの出方も分かって良かったです。

因みにDiscard を選択した場合も編集画面から出れました。

Tech Art Aid 氏のUE5 Quick Tip: Packed Level Instances (Prefabs?) [14] ではこの後、Level InstanceをDuplicateしたりしています。

面白そうなので私もやってみました。

f:id:kazuhironagai77:20211129010540p:plain

f:id:kazuhironagai77:20211129010555p:plain

<Level Streaming at Runtime

Level Instancing [13]はここで突然、Embedded ModeとLevel Streaming Modeについての解説を始めます。

がそれらを何処で指定するのかとかの説明が全くないです。

結局どこでそれらの指定をしているのか分からなかったです。

ので軽く読むだけにします。

<<Embedded Mode>>

書かれている事を私が理解した範囲で書くと以下の様になりました。

まずEmbedded Modeつまり通常のModeではLevel Instanceは編集の状態でのみ存在しています。Runtime中はLevel Instanceは廃棄され、Level Instance内のそれぞれのActorがWorld Partitionに追加されます。

後、Level Instancing [13]ではOne File Actor (OFPA) Systemを使用するLevel Instanceはと但し書きされていますが、これが文章のどの範囲のLevel Instanceを指しているのか分からないです。

想像で考えるとRuntime中は全てのLevel Instanceが無くなると考えるのがより自然なのでOne File Actor (OFPA) Systemを使用してないLevel Instanceでも廃棄されそうです。

これは他のLevel InstanceのTutorialが出てから検討するしかないですね。

その後のNoteにもう少し情報が書かれていました。

f:id:kazuhironagai77:20211129010629p:plain

やっぱりRuntime中はOne File Actor (OFPA) Systemを使用してないLevel Instanceも廃棄されるみたいですね。

だたこれを読むと廃棄されたOne File Actor (OFPA) Systemを使用してないLevel InstanceはWorld Partitionには追加されないみたいです。

これって大変学術的な書かれ方しているから気が付きにくいですが、Level Designを効率よくするためにLevel Instanceを沢山使用して、いざGame をPlayしたらLevel Instanceが全部消えてしまった。みたいな事態が起きるわけですよね。

Level Designを担当している人達って専門学校で1,2年ソフトの使い方だけを勉強したほとんど素人に毛が生えたレベルの人たちですよね。

その人達にイキナリこの問題が降りかかる訳ですか。

解決出来るんでしょうか?

<<Level Streaming Mode>>

f:id:kazuhironagai77:20211129010650p:plain

OGPAを使用していないLevel InstanceはWorld Partitionに追加されません。しかし代わりに通常の Level Streaming を使用します。

と書かれていました。

と言う事は、Runtime中はOne File Actor (OFPA) Systemを使用してないLevel Instanceは廃棄されますが、廃棄されたLevel Instance内のActor達は通常の Level StreamingとしてWorld Partitionに追加されるので、いざGame をPlayしたらLevel Instanceが全部消える事はないと言う事でしょうか?

いやでもこれ、Level Streaming Modeにセットした場合は、と言うニュアンスが言外に入っている可能性もありそうです。

一番、確かなのは実験して確認する事ですね。

OFPAのActorを含むLevel Instanceと含まないLevel Instanceを使用してLevel を作成してGame をPlayしてみれば良いわけです。

う。でもこれを実行するにはEmbedded Mode とLevel Streaming Modeの切り替えとする方法が分からないと出来ないですね。

現状は、お話として聞いておく位しか出来ないのかもしれませんね。

その後の文章ですが、

f:id:kazuhironagai77:20211129010707p:plain

One File Actor (OFPA) Systemを使用してないLevel InstanceはSub LevelとしてLoadされます。と解釈出来ますね。

うん。それぞれのActorが勝手にLoadされるんじゃなくてLevel InstanceそのものがSub Levelに変換されるみたいですね。

じゃあ、これでも良いじゃん。と思ったらその後の解説を読むと結構コストがかかるみたいな事が書かれています。

ええー。

Level Instanceの最初で

f:id:kazuhironagai77:20211129010722p:plain

Level Instanceを使用すると沢山のLevel InstanceをStreamしたり、Sub Level の中にSub Levelがあるような複雑なLevelを作成したり出来るって言ってたじゃないですか。

この辺の具体的な作成方法やコストの問題についての説明は残りの文章の短さから推測するとなさそうですね。

その後は、コストを掛けたくなければ

f:id:kazuhironagai77:20211129010736p:plain

を使えと書かれていました。

<<Data Layers>>

Data LayerはEmbedded ModeでもLevel Streaming Modeでも使用出来ますとだけ説明されていました。

Level Instancing [13]の勉強まとめ>

Level Instanceは簡単に言えば幾つかのActorをまとめて一つとして扱う方法です。

だったらBP内に幾つかのActorをComponentとして付加すれば良いじゃんとなりますが、それとは構造が全く違うみたいです。

実際の作成方法も結構複雑です。Tech Art Aid 氏のUE5 Quick Tip: Packed Level Instances (Prefabs?) [14] でやり方を細かく示してくれています。

Level InstanceのLevel Streaming at RuntimeにはEmbedded ModeとLevel Streaming Modeがあります。ありますがそれぞれの指定方法は説明されてなくて実際にどうやって試したら良いのかは不明です。

このEmbedded ModeとLevel Streaming Modeの解説部分はかなり深く読み込みました。

のでそこから色々な知見を得る事が出来ました。

一つ、心残りなのがOne File Actor (OFPA) Systemを復習してから読んだらもっと理解が進んだと思う事です。

確かOne File Actor (OFPA) Systemも自動でセットされると思っていたら手動でセットする必要があった気がします。その辺が曖昧なまま読んでいたので、もしその辺をはっきりさせてから読んだらもっと深い知見が得られたかもしれません。

Embedded ModeとLevel Streaming Modeに関して言えば、誰かがやり方をYouTubeで示したら一発で解決するのでそれを待つのが正解でしょう。

以上です。

8.まとめと感想

今週は別な用事が入ってしまい、UEの勉強は中止しなければならなくなってたんですが、うまい具合に用事が解決してそれなりに勉強出来ました。

ただ今週は「6.RPGの作成の続き」で実際のコードを全く書かなかったので、見た目はそれなりに進んだように見えるだけかもしれませんね。やっぱり文章だけ書くのは楽だと実感しました。特に「5.Game Design:ポケモン+HxHの念能力 Part 2」を書いていてそれを感じました。

Programを書く場合にしろ、NodeやModuleの機能を調べるにしろ、仮説を立ててそれを検証するための実装を書いたりとかの色々な文章にならないけどやらないといけない部分があります。Game Designに関してはその辺をスキップ出来るので結構、言いたい事だけ書けてしまいますね。

そういう意味ではあんまりGame Designに関してはここには書きたくなかったんですが、戦闘が開始する前に勝敗が決してしまうポケモンなどの火とか水などのタイプ別な要素などの戦略的要素、戦闘中でも逆転出来るHxHの念能力な要素を戦術的要素と分類する方法は、それを超えるほど凄い発見なのではないのかとも思ったので敢えて載せる事にしました。

<参照(Reference)>

[1] Sensei, K. [英語喉®︎カズ先生 (シカゴ大学Ph. D. ) ]. (2021, November 21). 木村ここみさんの英語をシカゴ大学Ph.D.が評価してみた [Video]. YouTube. https://www.youtube.com/watch?v=a6F2SnFohRo

[2] CGHOW. (2021a, August 23). Convertible Floor in UE5 Niagara Tutorial | Download Files [Video]. YouTube. https://www.youtube.com/watch?v=pxSdLRMv8hY

[3] CGHOW. (2021b, November 22). HLSL Triangle code to UE4 Material nodes Tutorial | Download Files [Video]. YouTube. https://www.youtube.com/watch?v=JUnjDu33Nq8

[4] Epic Games. (n.d.-e). Material Nodes. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/4.27/en-US/Resources/ContentExamples/MaterialNodes/

[5] Epic Games. (n.d.-f). Material Properties. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Materials/MaterialProperties/

[6] Epic Games. (n.d.-h). Shading Models. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Materials/MaterialProperties/LightingModels/

[7] Epic Games. (n.d.-d). Material Blend Modes. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Materials/MaterialProperties/BlendModes/

[8] Epic Games. (n.d.-i). Subsurface Shading Model. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Materials/LightingModels/SubSurface/

[9] Epic Games. (n.d.-g). Materials Content Examples. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/4.27/en-US/Resources/ContentExamples/Materials/

[10] Epic Games. (n.d.-a). 1.3 - Translucent Light Mode. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/4.27/en-US/Resources/ContentExamples/MaterialProperties/1_3/

[11] Cloward, B. [Ben Cloward]. (2021, November 4). Shader Performance Measurement - Shader Graph Basics - Episode 21 [Video]. YouTube. https://www.youtube.com/watch?v=E82XxlXMJs4&list=PL78XDi0TS4lEBWa2Hpzg2SRC5njCcKydl&index=22

[12] Epic Games. (n.d.-b). Environment Query System. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/4.27/en-US/InteractiveExperiences/ArtificialIntelligence/EQS/

[13] Epic Games. (n.d.-c). Level Instancing. Unreal Engine Documentation. Retrieved November 28, 2021, from https://docs.unrealengine.com/5.0/en-US/WorldFeatures/WorldPartition/LevelInstancing/

[14] Tech Art Aid. (2021, September 15). UE5 Quick Tip: Packed Level Instances (Prefabs?) [Video]. YouTube. https://www.youtube.com/watch?v=PtGDgMIbyyg