UE4の勉強記録

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

Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する  Effectの勉強など Part 4

f:id:kazuhironagai77:20210516232423p:plain

<前文>
<インド英語についてと>
皆さんはインド英語についてどういう印象をお持ちですか?
私は、独特な訛りがあって聞きづらいですが、英語そのものはネイティブと同じ位出来る。と言うイメージを持っています。訛りも幅があってアメリカ人とほとんど変わらないアクセントで話す人もいれば、全く聞き取れない人もいます。
私がアメリカにいた時は、インド人の英語は、工学部の大学院生以外のアメリカ人からは「あいつら何言っているか分からねー。」とはっきり言うとバカにされていました。
それが最近知ったのですが、最近インド人に対するアメリカ人の態度がガラッと変わっているらしいんです。
それは何故かと言うと、YouTubeのおかげだそうです。
アメリカの大学では、日本の大学と比較すると工学や理学は物凄い人気です。理学部は卒業後に医科大学など進学するために行くため、工学部は卒業後、即高収入が得られる仕事が得られるため世間からの評価も凄く高いです。
それで毎年大量の学生が理工系を専攻するのですが、大体の生徒は落第して専攻を変えるか別な大学へ転校するかの選択を迫られます。
そういうわけで理工系を専攻する学生は必死こいて勉強するわけですが、ほとんどの生徒は教科書読んだり、授業を聞いただけじゃ何言っているのか分からない訳です。それでYouTube先生の出番ですが、ほとんど全ての教科でYouTubeで教えているのがインド人なんです。
それもインド訛り全開の英語でです。
学生はそれこそ藁をも掴む思いでYouTubeを見る訳で、訛りなんて気にしているどころじゃない訳です。そして聞いてみると教授の教え方より遥かに分かり易い。やっと理解出来た。との高評価と感謝に繋がるそうです。
確かに、私がYouTubeで検索して出て来るtutorialできちんと作成されているモノの中にインド人が作成した物はかなり多いですし、その評価はかなり正確であると私も思います。
ここで、驚きなのが、インド人でもYouTubeでTutorialを作成する人達は、ずっと勉強して来たのに欧米の大学院に入学出来なかった、いわゆるインド人の中での負け組の人達なんです。それでもその人達は腐らずに、真面目に勉強を続けてその成果をYouTubeに発表していたんです。それが突然、花開いてとんでもない高評価をアメリカ人から得る結果になったようです。
この話を聞いて私が思ったのは、日本人でも物理や数学でYouTubeではないにしてもTutorialを作成していた人は結構いたんです。でもみんな日本語で作成していたんで日本人から評価されなかったから止めちゃったんです。
一般的に言っても日本人は英語の勉強には熱心ですが、英語で動画は作成しません。英語で動画を作成した方が、後からアメリカ人からの高評価を得られて得なのではないかと言う事です。
Computer scienceの分野で言えば、アメリカ人が日本人からどうしても習いたい分野が一つあります。
それはアニメ調の3d グラフィックの実装方法です。
これ、日本人のプロの方が英語でTutorialをYouTubeに挙げたら、とんでもない高評価を得られるはずです。ひょっとするとMITクラスの大学から教授としてお誘いがくるかも知れないレベルの評価を得るかもしれません。
それでは今週も勉強を始めます。
<本文>
1.今週の予定
以下の事をやる予定です。

  • NiagaraCascadeの勉強の続き(特にコストについて)
  • モンスターの配置についての考察
  • 魔法陣の改良
  • Landscape4で戦闘しまくってバグ出しをする。
  • Landscape4で戦闘後、沼にワープするバグの直し

これだけだと直ぐに終わってしまうかもしれません。もし直ぐに終わるようならば、

  • アイテムや宝箱を拾う機能を作成する。
  • モンスターの攻撃方法を増やす。
  • モンスターの種類を増やす。
  • モンスターが復活する機能を追加する。
  • Landscape4に昼夜を追加する。
  • 魔法のEffectを増やす。

などを行います。
2.Niagaraの勉強の続き
2.1 Events and Event Handlers Overview [2] を勉強します
いつものサイト、Niagara Visual Effects [1] のStarting Outで唯一勉強していないEvents and Event Handlers Overview [2] を勉強します。

 

f:id:kazuhironagai77:20210516232645p:plain

先週、一応Emitterが3つあるNiagara systemをちょっとだけいじったので、多分このDocumentを勉強して理解出来るレベルには達しているでしょう。

Events

f:id:kazuhironagai77:20210516232723p:plain

最初のこの一文の意味が分かりません。
EmitterのPropertiesを調べたらありました。

f:id:kazuhironagai77:20210516232841p:plain

こういうのは初心者向けのDocumentなんだから図付きで説明して欲しいです。
ここだけ簡単に文章で説明して残りは図と文章の両方で説明されると整合が取れてない分、読者は混乱します。
<<Location Events>>
Location Eventsを試すために新たなNiagara systemとEmitterを作成します。名前はNE_EventTest、NS_EventTestとしました。先週、議論した通りEmitterのPrefixもNS_を使用するとNiagara systemとの区別がつきにくくなるので、NE_としました。

f:id:kazuhironagai77:20210516232926p:plain

Required Persistent IDsにチェックを入れて

f:id:kazuhironagai77:20210516232950p:plain

Particle Update CategoryからGenerate Location Eventを選択します。

f:id:kazuhironagai77:20210516233013p:plain

なるほど。EventsはGenerate Collision Event、Generate Death Event、Generate Location Eventの3つしかないんですね。

f:id:kazuhironagai77:20210516233044p:plain

Generate Location Eventを追加しました。
Errorが出ています。

f:id:kazuhironagai77:20210516233108p:plain

良く分からないのでFixを選択します。

f:id:kazuhironagai77:20210516233831p:plain

Errorに説明があったようにSolve Forces and Velocity moduleが追加されました。
それは兎も角として、Generate Location Eventを追加するとこのEmitterから作成される全てのParticleはそれぞれの位置情報を生成するそうです。
その情報を別のEmitter内のEvent Handlerが受け取って何かするそうですが、
Generate Location Eventはこれ以上何もしなくても良いでしょうか?

f:id:kazuhironagai77:20210516233854p:plain

うーん。分かりませんね。
この謎を解くためには先にEvent Handlerを勉強すべきですね。
<Event Handlers>
以下に示した説明によれば、Event HandlerはEvent Handler PropertiesとReceive Eventの二つがあるそうです。

f:id:kazuhironagai77:20210516233949p:plain

f:id:kazuhironagai77:20210516233957p:plain

Event Handler PropertiesはどのEvent moduleのEventを受け取るのかを指定するみたいですね。
なるほど。
これで先程の謎も解けました。Event自体が、電話というより町のサイレン放送みたいなものなんですね。例えば「5時ですよ」と放送があったらそれを聞いた子供たち(Event Handler)が野球を止めて家に帰るとかを考えると納得出来ますね。
Event module側で、どのhandlerにどんな情報を送るのか決めるのではなく、Event側は持っている情報をみんなに送る訳です。その中でHandler側が必要な情報を自分で取捨選択して受け取る訳ですね。
実際に作成してみます。
先程、作成したNS_EventTest内に、同様に先程作成したNE_EventTestを追加しました。

f:id:kazuhironagai77:20210516234028p:plain

Event Handler用に新しくEmitterを作成しようとしたらEmptyというEmitterがNS_EventTest内から選択出来る事を見つけました。これを使用します。
EmptyのEvent Handler categoryにEvent Handler Moduleを追加します。

f:id:kazuhironagai77:20210516234052p:plain

設定も同様にしました。

f:id:kazuhironagai77:20210516234116p:plain

そしてEvent Handlersに必要なもう一つのModuleであるReceive Eventを追加します。

f:id:kazuhironagai77:20210516234140p:plain

追加しましたが、このModuleの目的が分かりません。公式のDocumentの説明も良く分かりません。
これでお終いでした。
2.2 UE4 4.25 Niagara Event Handler Simplest Example [3] を勉強します
Eventについて簡単に説明したtutorialを探したらそのものズバリのタイトルがありました。UE4 4.25 Niagara Event Handler Simplest Example [3] です。
軽く最初だけ見たら、インド英語ですね。今週は前文でインド英語について述べたので何か奇縁を感じます。もう少し見てみます。
はい。これで勉強する事にしました。非常に分かり易くEventの使用方法について説明しています。
まずEmitterを作成しています。このTutorialではFountainを選択していました。

f:id:kazuhironagai77:20210516234247p:plain

Fountainの発音ですが、フォウンテインが正しい発音ですが、フォウンッインって発音する人も結構いた気がします。英語には小さいツの音はないらしいんですが、私はFountainをtなしで発音する時、小さいツが入ってると思うんです。フォウンインじゃなくてフォウンッインってフォウンとインの間にためがある気がします。
今回、気になって調べたんですが、Fountainをフォウンッインって発音しているサイトがまず見つからなかったです。やっぱり英語には小さいツの音はないんでしょうか?

f:id:kazuhironagai77:20210516234332p:plain

EmitterなのでNE_をPrefixに付けました。
今度は、Eventを受け取る側のEmitterを作成します。

f:id:kazuhironagai77:20210516234411p:plain

f:id:kazuhironagai77:20210516234420p:plain

最後にこれらのEmitterを使用するNiagara systemも作成します。

f:id:kazuhironagai77:20210516234453p:plain

作成したNiagara systemを開いて、2つのEmitterを追加します。

f:id:kazuhironagai77:20210516234512p:plain

まず最初に、最初のemitterのParticleが死んだら、次のEmitterが発動するEventを作成するそうです。
このTutorialではSelectionから追加しています。
Generate Death Eventを追加しました。

f:id:kazuhironagai77:20210516234538p:plain

何かErrorが出ています。Logを見ろと書いてあるので見ると

f:id:kazuhironagai77:20210516234555p:plain

Requires Persistent ID’sのチェックを忘れていました。

f:id:kazuhironagai77:20210516234617p:plain

TutorialでRequired Persistent IDsの意味を簡単に説明していました。
Niagara systemで作成される全てのParticleはIDを持っているそうです。しかしそのIDはParticleがUpdateするたびにどんどん変わってしますそうです。所がこのRequired Persistent IDsにチェックを入れるとそのIDはずっと変わらずに同じになるそうです。
更に、GPUで計算した場合もEventは使用出来ない事も説明していました。そうでした。その事はすっかり忘れていました。
TutorialではGenerate Death EventのGap Correction Amountの値が1.5になっているんですが、私のは0になっています。

f:id:kazuhironagai77:20210516234637p:plain

一応、1.5に変更しときました。
更に、Generate Death Eventを受け取るためにNE_OmnidirctionalBurstのEvent Handler CategoryにEvent Handler Propertiesを追加します。
Source、Execution ModeそしてSpawn Numberを以下の様に変更しました。

f:id:kazuhironagai77:20210516234718p:plain

Spawn NumberはEventで前のEmitterのParticleが消滅したと連絡が入った時に、このEmitterのParticleを何個発生されるのかを指定するためのものだそうです。つまりこの設定だと5個のParticleが発生するわけです。
見にくいのでOminの方のParticleの色を赤に変えます。
Particle SpawnのInitialize ParticleのColor Modeで変更してました。

f:id:kazuhironagai77:20210516234738p:plain

このTutorialにおける、この辺の細かい説明はかなり親切に感じます。
私の結果は、全然Eventを受け取っていません。最初からOmni Directional Burstが前回で発動しています。

f:id:kazuhironagai77:20210516234759p:plain

何ででしょう?
Tutorialの続きを見たら分かりました。Receive Death Eventを追加してなかったからです。

f:id:kazuhironagai77:20210516234836p:plain

出ました。

f:id:kazuhironagai77:20210516234901p:plain

やっぱり私の作成したヤツちょっとオカシイです。一回しかOmniのParticle を作成しません。

f:id:kazuhironagai77:20210516234928p:plain

はい。これもTutorialに説明されていました。
Emitter State CategoryのLife Cycle ModeをSystemにセットすれば良いそうです。

f:id:kazuhironagai77:20210516234946p:plain

凄い。直りました。

f:id:kazuhironagai77:20210516235004p:plain

このエフェクト、血飛沫の作成にも応用出来そうですね。
もう少しEventの効果をはっきりさせるためにFountainのparticleの数を減らします。

f:id:kazuhironagai77:20210516235022p:plain

確かにFountainのparticleが消滅した時に赤いOmniのparticleが生成しています。

f:id:kazuhironagai77:20210516235128p:plain

ただ、私のヤツは最初に赤い爆発が起きているです。

f:id:kazuhironagai77:20210516235154p:plain

これはTutorialにはないです。
多分何かやり忘れているんでしょう。
はい。Tutorialに完璧に説明されていました。
以下に示した白いひし形の印があると最初の爆発が起きるそうです。

f:id:kazuhironagai77:20210516235212p:plain

このひし形を消したら爆発は無くなるそうです。
消し方はこのひし形を選択してDeleteキーを押せばいいそうです。

f:id:kazuhironagai77:20210516235231p:plain

消えましたね。
最初に現れていた赤い爆発もなくなりました。

f:id:kazuhironagai77:20210516235248p:plain

出来ました。

f:id:kazuhironagai77:20210516235314p:plain

次はCollusion Eventで作成するそうです。
やり方は前と同じですので、これは結果だけ示します。

f:id:kazuhironagai77:20210516235334p:plain

FountainのParticleが地面と衝突した時に赤い爆発が起きています。
最後にLocation Eventです。

f:id:kazuhironagai77:20210516235353p:plain

FountainのParticleの位置がupdateするたびに赤い爆発が起きる様に成りました。
一応これでEventの使用方法について理解出来ました。
3.Cascadeの勉強の続き(特にコストについて)
今週は、公式のdocumentにあるVFX Optimization Guide [4]を勉強します。
最初から以下のように書かれていました。

f:id:kazuhironagai77:20210516235949p:plain

Matineeってなんでしたっけ。
公式のdocumentである、Matinee and Cinematics [5]では以下の説明がされていました。

f:id:kazuhironagai77:20210517000151p:plain

ああ。アニメーションを作成するやつか。
何となくは知っていますが、この分野も本格的な勉強した事はなかったです。後で勉強する事にします。
<Common Offenders For Poor Effects Performance>
一般的にいって、以下のヤツがコストが掛かりますと説明しています。

f:id:kazuhironagai77:20210517000226p:plain

うーん。何が言いたのか分からないよ。
Tick TimeはTick一回にかかる時間の事でしょう。全てのParticle SystemがUpdateするのに必要とされる時間。って書かれているって事はCascadeに限っての話をしているのか。
あ、分かった。
ここに載っているのは、Cascadeを実行する時に、行われるそれぞれの処理の中で、油断すると凄い仕事量になってPCがヒィヒィ言ってしまう箇所を述べているんです。
多分、Cascadeを実際に実行すると、10とか20の工程がある訳です。その工程の中でいつも凄いコストがかかったり、実行するのが特別遅かったりする工程を担当している箇所を4つ説明しているんです。
一般的に言って3D Graphicsで最も処理が遅くなる箇所って、CPUからGPUにデータを送る時でしょう。
この4つの中だと、Draw Callsがその処理を担当しているんでしょうか?そんな風に読めなくもないですね。
上記の仮定に基づいて上の4つを私が超訳すると、

  • Overdraw:一枚の絵を描くのにかかる時間を指します。カメラがParticleに近い程、絵を大きく描かなければならないので時間がかかります。更に一枚の絵が沢山のLayerで作成されている場合はそのLayerの数の分だけ、更に絵を描く時間がかかります。絵の大きさ(Pixelの数)、描く絵の枚数(Layerの数)なので、難しく言うと、Overdraw =(Layerの数)*(Pixelの数)となります。
  • Tick Time:全部のParticleを一回だけUpdateするのにかかる時間を指すそうです。

今、唐突に思ったんですが、Tick timeってFrame毎に決まっているんでしたっけ。そのFrame数内で終わらない量の処理をTick関数内で実行した時はどうなるんでしたっけ。次のTickは前のTickが実行し終わるまで待機するのか?それとも勝手に実行し始めるんでしょうか?

Tick()関数がThreadならば、多分Particleの位置を変えたりする場合にThread Safeが働くはずです。そうなると後のTick()関数のThreadは前のTick() 関数のThreadが実行を終わるまで待っている事になるんでしょうね。
うん。そうなるとTick Timeの時間が増えると、線形的に全体の計算時間も増えてしまうわけですね。
でも、これってO(n)ですよね。別にそんなに悪くないんじゃん。
ああ、段々分かって来ました。コストを削減するには最もコストがかかってる箇所を理解するだけでは足りなかったんっだ。コストがかかったとしても必要な部分はやらないといけない訳です。その中でこの部分を減らすと指数的(O(nc))にコストが減らせる箇所とそうでない箇所があって、前者は何としても減らせるならば減らせるべきですが、後者は出来れば減らしたい位の箇所になるわけです。
でも何でこのDocument、コストについての考察なのにBig O notation についての考察が全く述べられていないの?
ちょっとパラッと全部読んでみます。
うーん。ここにまとめる価値はないかもです。
結局、私が知りたい、Particle systemを勉強している人全般が知りたい事は、以下の事でしょう。
Emitterを増やすとコストは指数的に増えるのか?

f:id:kazuhironagai77:20210517000407p:plain

その場合でも、一万個のEmitterを追加した場合は影響が凄いでるが、5個や6個のEmitterなら関係ないのか?
Emitter内で使用しているMaterialが使用してるTextureのサイズはコストに影響するのか?

f:id:kazuhironagai77:20210517000429p:plain

生成するParticleの数はコストにどのように影響するのか?

f:id:kazuhironagai77:20210517000448p:plain

これら以外もあるかもしれませんが、私自身があまりParticle Systemについて知らないので取りあえず思い付くのは以上になります。
それらがParticle systemのどの辺の処理に関連しているのか、つまり先程の説明であった、Overdraw、Tick Timeなどの処理に使用されているならば、少なくした方がコストがかからないのかと定性的に理解出来ますし、その後でこの部分はO(n^C)なので絶対コスト少なくすべきとの定量的な考察に入るべきでしょう。
はい。時間が勿体ないのでこのDocumentの勉強は中止します。
4.コストと最適化について
本当は、別なcascadeについての勉強をしようと思ったのですが、先程のcostと最適化についてもっとしっかりしたtutorialはないのかと探したらMaterialの作成についての最適化で直接はparticle systemには関係ないですが、一個見つかりました。
ので、今週はそれを勉強する事にします。
4.1 Shader Performance Optimization - UE4 Materials 101 - Episode 7 [6] を勉強します
Shader Performance Optimization - UE4 Materials 101 - Episode 7 [6] を勉強します。
最初に、Materialのコストを測定する3つの方法を紹介しています。
3つの方法を紹介するというかこの3つ以外にMaterialのコストを測定する方法はないって感じで説明しています。
最初の方法は、Shader Complexityを使用する方法です。

f:id:kazuhironagai77:20210517000551p:plain

以下のようなシーンが見られます。

f:id:kazuhironagai77:20210517000624p:plain

これは大変有名で私も知っています。
しかしこの色は、Instraction countに基づいて表示されていて、Instraction count自体が完璧な評価方法でないので正確ではないそうです。
おお。
これは勉強しがいがあります。
上記のShader ComplexityはShaderのInstractionの数を何となく比較するには都合が良いですが、実際の数字を見る方法もあるそうです。
それが2つ目の方法です。
まず、あるMaterialを開きます。
試しに以下のMaterialを開いて見ます。

f:id:kazuhironagai77:20210517000655p:plain

開くと以下に示した様なStas欄があります。

f:id:kazuhironagai77:20210517000713p:plain

私が参考にしたMaterialにはDefaultではありませんでした。
追加します。

f:id:kazuhironagai77:20210517000733p:plain

以下の表示が現れました。

f:id:kazuhironagai77:20210517000750p:plain

最初のInstructionの意味ですが、Materialに書かれたBPは以下のように変換されて実行されるそうです。

f:id:kazuhironagai77:20210517000809p:plain

このAssembly Instructionに変換された時のInstructionの数を表しているそうです。
ただしこの数と一つのInstructionの実行にかかる時間は同じではなく、あるInstructionは他のInstructionの何倍の時間がかかったりするため単純にこのInstructionの数が減ったから最適化したとは言えないそうです。
Assembly レベルでの話ならば一個の指令を実行する時間はどの指令でもそんなに差はないような気もしますが、どうなんでしょう?
三番目の方法ですが、実際の環境で試す事だそうです。
これは設定するのに大変時間がかかりますが最も正確だそうです。
そりゅあそうです。
そしてこの方法は最も信頼に値しますし。当たり前と言えばそうですが、これ以上正しい方法はないですね。
実際、PCやPS、Xboxで試すとHardwareによってコストが全然違うそうです。
うーん。深い。
Materialのコストは三番目の方法で最終的には最適化しますが、最初の段階では2番目の方法で大体最適化出来ているだろうとの目安にするそうです。
はい。
これが重要になってくるわけですね。

f:id:kazuhironagai77:20210517000832p:plain

この点を理解した上で、4つの最適化のための方法を教えてくれるそうです。
一つ目です。

f:id:kazuhironagai77:20210517000908p:plain

流石にこれは当たり前だろうと思いましたが、良く考えると私のProjectのGameModeやThirdPersonCharacterには結構使用していないコードが残っています。謙虚に受け止めます。
具体例も結構説明していました。
実際に使用しない計算をoffの状態で残しているだけでも影響はあるそうです。
以下にMacro Texture Variationを示しますが、

f:id:kazuhironagai77:20210517000936p:plain

これもMaterialを使用する物体が十分小さい場合は、全部のパターンは要らないですよね。こういう部分を削れと言う事ですね。

2番目の方法です。

f:id:kazuhironagai77:20210517000955p:plain

計算結果がほぼ同じで計算の負担が減る方法があるならばそちらを採用すべきだそうです。
このTutorialではPowerノードの代わりに、3つの単純な足し算、掛け算のノードを使用する事で、結果がほぼ同じでShader Instructionを5つ位減らす方法が紹介されていました。
以下のPowerのノードを

f:id:kazuhironagai77:20210517001014p:plain

以下の様なノードに変換する事で

f:id:kazuhironagai77:20210517001034p:plain

Base Pass ShaderのInstructionの数が115から

f:id:kazuhironagai77:20210517001050p:plain

111に下がっています。

f:id:kazuhironagai77:20210517001106p:plain

3番目の方法です。

f:id:kazuhironagai77:20210517001126p:plain

以下にTutorialに載っていた例を示します。

f:id:kazuhironagai77:20210517001146p:plain

以下の様に改良しました。

f:id:kazuhironagai77:20210517001206p:plain

ただし、この例のBase Pass ShaderのInstructionの数は両方96で変化していませんでした。
あくまでもこんなやり方もあると言う位に聞いておきます。
4番目の方法です。

f:id:kazuhironagai77:20210517001239p:plain

これが知りたかったです。
説明は簡単でした。
Ambient Occlusion、Metallic、Specular、そしてRoughnessは一個のTexture Sampleにまとめてしまえ。と言う事でした。

f:id:kazuhironagai77:20210517001304p:plain

そう言えば、2021-04-11 のブログでGameTexture.comからdownloadしたTextureにMrao.pngというMetalness-Roughness-Ambient OcclusionをまとめたTextureがありましたね。こっちはそれに更にSpecularまで一緒にしたTextureだそうです。
この例のBase Pass ShaderのInstructionの数は102 から100に下がりました。
ただし、このTextureからデータを読み込むのは例え一回にしか数えられなくても最もコストがかかるInstructionなので数字に見えないコスト削減が出来ているそうです。
以上でした。
5.モンスターの配置についての考察
先週、Landscape4のBlock 1にモンスターを2体配置しました。

f:id:kazuhironagai77:20210517001406p:plain

はっきり言うと何も考えないで作成したので色々な問題を内包していそうです。
それについての対策を考えておきます。
5.1 Trigger boxのサイズ
Trigger boxのサイズをBlock 1 の範囲であるNav Mesh Bound Volumeよりも大きくしています。

f:id:kazuhironagai77:20210517001454p:plain

これはplayerが操作するキャラが縄張り内に侵入した途端に、モンスターが発生したらPlayerが対応するのは大変だからそうしたのですが、その結果、その他のblockのTrigger boxと重複する箇所が発生します。
5.2 Monster Territory Numberについて
Monster Territory Number はRPG Game Instance内に作成されたInt型の変数で、Landscape4のどのBlockから戦闘画面に飛んだのかを記録するための変数です。

f:id:kazuhironagai77:20210517001535p:plain

先週、Landscape4に戦闘から戻った時に、どのBlockに属するMonsterを生成すべきなのか指定する必要があったので急遽作成しました。
以下のように使用されています。

f:id:kazuhironagai77:20210517001600p:plain

RPG Game Instance BP内だけで以下の変数が追加されています。早急に整理しないと何が何をしているのか分からなくなります。

f:id:kazuhironagai77:20210517001619p:plain

5.3 Remove Defeated Monster from Landscape 4 () 関数について
Landscape 4 上で配置されているモンスターが戦闘で倒された後、二度と再生されないようにGame Instance内のdata tableから消去する関数です。
この関数、先週は何も考えないで、Block1ならGame Instance内のdata table、Monster Spawn Data Landsape4-1を検索、それ以外ならdata table 、Monster Spawn Data Landsape4から検索と設定しています。

f:id:kazuhironagai77:20210517001650p:plain

もう少しうまく実装出来ないか検討します。
5.4 戦闘画面に移動する場合もOn Actor End Overlap (Trigger box) が呼ばれている事について
先週はこの事が分からなくて、戦闘から戻って来たら倒したモンスターが復活して来て困惑しました。
On Actor End Overlap (Trigger box)が呼ばれると当然ですが、RPG Game Instanceにある変数、Monster Territory Numberは0 にセットされます。
戦闘後、Remove Defeated Monster from Landscape 4 () 関数は、Monster Territory Numberの値に基づいて、どのデータテーブルからモンスターを消去するかを決定するので、Monster Territory Numberが0 にセットされると正しいData tableにaccessする事が出来ません。
先週は、以下に示した様に戦闘画面に移動するために、On Actor End Overlap (Trigger box)が呼ばれた場合は、RPG Game Instanceにある変数、Monster Name in FightingがNone以外である事を利用して、この問題を解決しました。

f:id:kazuhironagai77:20210517001725p:plain

以下の問題点が今の時点でも考えられます。

  • 別なレベルに移動する時、必ずOn Actor End Overlap (Trigger box)は呼ばれるのか?呼ばれなかった場合はどうなるのか?
  • 戦闘画面からBlock1内に戻って来た時に、On Actor Begin Overlap (Trigger box)は呼ばれるのか?呼ばれなかった場合、それぞれのParameterはどうなっているのか?
  • Block1内から移動する時、必ずMonster Name in Fighting 変数の値はNoneになっているのか?
  • Block1内から直接、Block2に移動した時はどうなるのか?

これ以外の問題も発生するかもしれませんが、今の所思い付くのはこれだけでした。
5.5 Territory 1に一端侵入した後に、Territory 1から逃走するとMonsterが消滅しなかった事について
先週のBlogを読み直していたら、Block 1をTerritory 1と読んでいました。
用語の使用を統一しないと、後で混乱を招くのでここできちんと定義する事にします。
Trigger boxの範囲をBlock 1とします。

f:id:kazuhironagai77:20210517001920p:plain

そして、実際にmonsterが徘徊する領域をTerritory 1と呼ぶ事にします。

f:id:kazuhironagai77:20210517001953p:plain

新しい定義に従ってもう一度、問題を言語化すると、「Block 1に一端侵入した後に、Block 1から逃走するとMonsterが消滅しなかった事について」となります。
先週は、このバグの原因が、

  • Trapでモンスターを発生させた時に、モンスターが消滅する前に新しいモンスターを発生した時に起きたバグと同じである。
  • 今回は更に、Monsterの発生や消滅でLoopを使用してるため更に問題が複雑になっている。

の2点にあると考え以下の解決方法を実装しました。
Trapでバグが発生したのは、Monsterのanimationが終了する前に、そのanimationが終了した後に実行してほしいコードが実行される事で起きていました。基本的にPlay Animationノードを使用すると、アニメーションの終了を待たずに次のコードが実行されます。
Trapの時は、Animationが終了するまで、次のコードを実行しない事で解決しました。
今回の問題に関しては、先週は、以下のようにして解決しました。
Landscape4のLevel BPにMonster BPのArray、Monster Territory 1を作成して生成したそれぞれのモンスターを管理します。

f:id:kazuhironagai77:20210517002039p:plain

これで生成したmonsterそれぞれにこのArrayからいつでもアクセス出来ます。
分解、消滅のアニメーションをPlayする場合は、以下の方法で実行出来ます。

f:id:kazuhironagai77:20210517002058p:plain

このAnimationが終了する前まで次のコードを実行させないために、

f:id:kazuhironagai77:20210517002115p:plain

必ず2秒ほど、待つ事にしています。
分解、消滅のAnimationの時間は1.4秒なので2秒間までは全てのMonsterの分解消滅のアニメーションが終了しているはずという考えです。もし何らかの原因でAnimationが2秒以内に終わらなかった場合は、この部分のコードは正常に作動しなくなります。
その後、以下のコードを実行しています。

f:id:kazuhironagai77:20210517002136p:plain

まずDestroy ActorでそれぞれのMonster BPを破壊します。その後で、Monster Territory 1をclearします。
ここで新しいBoolean変数、Monster Cleanを使用する事で、生成したMonsterが全員消滅した事を確認出来る様にしています。
更に、Block 1から出てモンスターが消滅する前にもう一度Block 1に侵入した場合についてです。
先程説明した、Boolean変数、Monster CleanがTrueになるまで、新しいMonsterは生成しません。

f:id:kazuhironagai77:20210517002155p:plain

このやり方で、今の所バグは発生していませんが、論理的な破たんがないか検討すべきです。
5.6 Landscape4、Territory 1における戦闘
Territory 1 で戦闘した後にLandscape 4の沼に戻ってしますバグがありました。

f:id:kazuhironagai77:20210517002250p:plain

これは後で検討します。
更に、戦闘から戻った時に発生したErrorが、On Actor End Overlap (Trigger Box) のDestroy Actorノードの前にIs Validをつける事で解決した理由もはっきり分かりません。

f:id:kazuhironagai77:20210517002310p:plain

これについても検討します。
6. モンスターの配置についての考察-その2
6.1 Trigger boxのサイズについての検討
以下に示した様にBlock 1から出ずにBlock 2に侵入する場合が考えられます。
その場合、Block1からは出ていませんが、Territory 1からは出ている場合があります。
これを条件1とします。

f:id:kazuhironagai77:20210517002347p:plain

Territory 1からも出ていない場合もあります。
これは条件2とします。

f:id:kazuhironagai77:20210517002408p:plain

更に、Block1からは出ない内にBlock2に入り、かつTerritory2にも入っている場合も考えられます。
これは条件3とします。

f:id:kazuhironagai77:20210517002459p:plain

条件1の場合から考えます。
Monster Territory Numberは1から0 に成る前に2 になります。

f:id:kazuhironagai77:20210517002519p:plain

うん。Monster Territory NumberなのにBlockに入った時に値が変化するのか?
うーん。
やっぱりこの方法で管理するためにはTerritoryとBlockのサイズを同じにする必要があるみたいですね。
TerritoryとBlockのサイズを同じにすれば上記の問題を何も考える必要がなくなります。しかし5.1で論じたようにUserには不親切になります。
考えるのが面倒くさいです。
TerritoryとBlockのサイズを同じにして別なBlockは絶対に重ならないようにします。
以下に示した様に、Block 1とTerritory 1のサイズを全く同じにしました。

f:id:kazuhironagai77:20210517002557p:plain

これで解決です。
6.2 Monster Territory Numberについて
6.1でBlock 1とTerritory 1のサイズを同じにしたので、この変数自体が間違った値を示す可能性は無くなりました。
RPG Game Instance BP内に変数が多すぎて整理が出来ない問題については、以下に示した様にLandscape4で使用する変数はCategoryとしてLandscape4を作成する事で区別しました。

f:id:kazuhironagai77:20210517002630p:plain

6.3 Remove Defeated Monster from Landscape 4 () 関数について
この関数をもっと簡単な形に変更出来ないか検討します。
検討した結果、関数を更に作成する事で見た目を簡便にする事が出来る事が判明しました。
しかし、それをやるとその関数が正しく働いているのかの検討をしなければならず、ちょっと大変になるので、以下に示した様に簡単な整理だけやりました。

f:id:kazuhironagai77:20210517002701p:plain

6.4 戦闘画面に移動する場合もOn Actor End Overlap (Trigger box) が呼ばれている事について
5.4で見つけた問題点、以下の事について考察、検討します。

  • 別なレベルに移動する時、必ずOn Actor End Overlap (Trigger box)は呼ばれるのか?呼ばれなかった場合はどうなるのか?
  • 戦闘画面からBlock1内に戻って来た時に、On Actor Begin Overlap (Trigger box)は呼ばれるのか?呼ばれなかった場合、それぞれのParameterはどうなっているのか?
  • Block1内から移動する時、必ずMonster Name in Fighting 変数の値はNoneになっているのか?
  • Block1内から直接、Block2に移動した時はどうなるのか?

<別なレベルに移動する時、必ずOn Actor End Overlap (Trigger box)は呼ばれるのか?呼ばれなかった場合はどうなるのか?>
これが問題になるのは戦闘画面に移動した時だけです。もしOn Actor End Overlap (Trigger box) が呼ばれなかった場合は、Monster Territory Number変数は1のままです。何の問題も生じません。
<戦闘画面からBlock1内に戻って来た時に、On Actor Begin Overlap (Trigger box)は呼ばれるのか?呼ばれなかった場合、それぞれのParameterはどうなっているのか?>
テストしてみます。
On Actor Begin Overlap (Trigger box)は呼ばれませんでした。
しかしまた沼に戻って来ました。

f:id:kazuhironagai77:20210517002829p:plain

2回目の戦闘で沼に移動するバグになりました。
パラメーターに関して言えば、問題になるParameterはMonster Territory Number変数だけでした。On Actor Begin Overlap (Trigger box)は呼ばれない場合でも、この変数は1を保持していて、それが正しい値ですので問題はないです。
<Block1内から移動する時、必ずMonster Name in Fighting 変数の値はNoneになっているのか?>
戦闘が終了してから何時、Monster Name in Fighting 変数の値をNoneにセットしているのか調べました。
そしたらなんと、先程整理していたRemove Defeated Monster…関数の最後で呼ばれていました。
以下に示した様に、この関数の後で、Open Level ノードが呼ばれています。

f:id:kazuhironagai77:20210517002911p:plain

Block1内から移動する時は、Monster Name in Fighting 変数の値は必ずNoneにセットされていると考えて良いと思います。
<Block1内から直接、Block2に移動した時はどうなるのか?>
この条件は起きない設定に変更しましたので検討する必要はなくなりました。
6.5 Territory 1に一端侵入した後に、Territory 1から逃走するとMonsterが消滅しなかった事について
このバグ自体は、先週、既に解決しています。
先週行った解決方法を5.5で示しましたが、このやり方で問題無いのかの検討も5.5でやっているのでここでは特に何も検討しません。
6.6 Landscape4、Territory 1における戦闘
5.6でIs ValidノードをDestroy Actorの前にセットする必要性が分からない点について考察します。

f:id:kazuhironagai77:20210517003011p:plain

先ず、このErrorが何時呼ばれたのかが不明なんです。戦闘から帰って来て気が付きましたが、戦闘画面から帰って来た時にOn Actor End Overlap (Trigger box)が呼ばれる訳がないです。
と言う事は、戦闘が始まる時に呼ばれて、それと同時にLevelが切り替わる為、Landscape4に存在していたActorも消去されるはずです。多分その後で、Destroy Actor()関数が呼ばれる時もあるんじゃないんでしょうか?
その時にErrorになってしまうと思われます。
それが原因ならIs Valid () 関数を今の様にかましておけばErrorは起きません。更に理論的な解釈の間違いもないと成りますので、他に直さなければならない部分も無いはずです。
7. Landscape4で戦闘後、沼にワープするバグの直し
2時間位、原因が分からなくて悩みましたが、結論から言うと直せました。
Landscape4内で戦闘になった時、元の位置をRPG Game Instance BPのThird Person Character Location変数内に保持します。

f:id:kazuhironagai77:20210517003044p:plain

この時に、戦闘開始になった位置を保持するのではなく、X軸に500ずれた位置を保持していました。
このせいで、モンスターに捕まった位置からX軸に500ずれた箇所が地面より下だった場合、戦闘から帰ってきたキャラは地面の下で再生され、落下して消滅してしまいます。これが沼の再生とerrorの原因だったのです。
勿論、モンスターに捕まった位置からX軸に500ずれた箇所が地面より上の時は、Errorは起こりません。つまり一見再現性が無いようにも見えます。
兎に角、直せました。
8.モンスターの出現方法についての再考
8.1 Triggerを追加する。
「7.Landscape4で戦闘後、沼にワープするバグの直し」で何十回もテストしましたが、やはりモンスターはterritoryに侵入する前に出現して欲しいです。
そこで思い付いたのが、Trigger Boxをもう一個足す方法です。以下に図を示します。

f:id:kazuhironagai77:20210517003134p:plain

Trigger1内に侵入した時にTerritory 1のモンスターが発生します。しかし前の様に、Monster Territory Numberは1になりません。0のままです。Monster Territory NumberはTrigger 2に侵入した時に初めて1に変化します。
8.2 Triggerを追加した場合の理論的考察
「6.1 Trigger boxのサイズについての検討」で説明した条件に基づいて具体的に解説します。
条件1の場合です。
Playerの操作するキャラはBlock1内にいながらBlock2に侵入しました。

f:id:kazuhironagai77:20210517003217p:plain

Territory 1から既にでているのでTrigger2 の働きにより、Monster Territory Numberは0 にセットされています。しかしBlock1からは出てないのでTerritory1のモンスターは消滅しません。更にBlock2に侵入したため、Territory2のモンスターも出現しました。
ここでモンスターと戦闘になる事は無いので、Monster Territory Numberは0で正しいです。全部正しく作動しています。
条件2の場合です。
Playerの操作するキャラはTerritory1内にいながらBlock2に侵入しました。

f:id:kazuhironagai77:20210517003239p:plain

Territory1にいるので、Monster Territory Numberは1 にセットされています。しかしBlock2にも入っているので、Territory2のモンスターも出現します。出現しますが彼らはTerriory2から出る事はないので、Playerの操作するキャラと戦闘になる事はありません。Playerの操作するキャラと戦闘になる可能性のあるモンスターはTerritory1内にいるモンスターです。つまりMonster Territory Numberは1が正しいです。
この条件でも正しく作動します。
条件3の場合です。
Playerの操作するキャラはBlock1内にいながらTerritory2に侵入しました。

f:id:kazuhironagai77:20210517003300p:plain

Territory2にいるので、Monster Territory Numberは2 にセットされています。しかしBlock1にも入っているので、Territory1のモンスターも出現します。出現しますが彼らはTerriory1から出る事はないので、Playerの操作するキャラと戦闘になる事はありません。Playerの操作するキャラと戦闘になる可能性のあるモンスターはTerritory2内にいるモンスターです。つまりMonster Territory Numberは2が正しいです。
この条件でも正しく作動します。
はい。
この方法でやれば、戦闘後の混乱を起こさないでMonsterを遠くから発生させる事が出来ます。
8.3 実際の作成
よく考えたらまだ、Block1しか作成しておらず、上記の条件でBlock1だけで上手く作動出来るかの検討が先に必要でした。
つまり、

  • Block1に侵入して直ぐにBlock1から退去した場合、モンスターは消滅するのか?
  • Block1に侵入して直ぐにBlock1から退去して、更にもう一度、Block1に侵入した場合、Monsterは消滅してから生成されるのか?
  • 戦闘で倒したモンスターは二度と再生されないようになっているのか?

の検討を忘れていました。(先週のBlogの4でやった部分です。)

これが出来てからBlock同士が重なった場合の検討が必要になります。Blockを増やすのは後でやります。今週はBlock1だけで上手く作動出来るように実装します。
Block1に侵入した場合です。

f:id:kazuhironagai77:20210517003421p:plain

Monsterが生成されます。
Block1に侵入して直ぐにBlock1から退去して、更にもう一度、Block1に侵入した場合、Monster Clean変数がTrueになるまで待ちます。のでMonsterは消滅してから生成されるはずです。
Block1から退去した場合です。

f:id:kazuhironagai77:20210517003444p:plain

実装している内容は先週のBlogの4でやった事と同じですのでコードの説明は省きます。
今度はTerritory1に侵入、退出した場合です。

f:id:kazuhironagai77:20210517003540p:plain

新しいTriggerを追加しようとしたら、Nav Mesh Bounds Volume もOverlapの機能を持っていたのでNavをそのまま使用しています。
ここではMonster Territory Numberを変更しています。
8.4 テスト
テストしてみます。
Block1に侵入します。

f:id:kazuhironagai77:20210517003607p:plain

f:id:kazuhironagai77:20210517003615p:plain

Monsterが生成されました。
Block1から退出します。

f:id:kazuhironagai77:20210517003633p:plain

f:id:kazuhironagai77:20210517003641p:plain

Monsterは分解消滅します。
Block1に侵入して直ぐにBlock1から退去して、更にもう一度、Block1に侵入します。

f:id:kazuhironagai77:20210517003707p:plain

f:id:kazuhironagai77:20210517003720p:plain

Monsterが消滅してから新しいモンスターが生成されました。
ここまでは出来ています。
今度は戦闘を試してみます。
Monsterを一体倒して戦闘から戻ってきたら、別のMonsterもいません。

f:id:kazuhironagai77:20210517003744p:plain

何故でしょう?
一回、Block1から退出して侵入し直したら、Monsterが2体出て来ました。

f:id:kazuhironagai77:20210517003802p:plain

出来ていませんね。
直します。
調べたら以下のNavはOverlapしてもEventを発信していなかったです。

f:id:kazuhironagai77:20210517003821p:plain

やっぱりTrigger boxが必要でした。
Trigger box_ Territory1を作成します。

f:id:kazuhironagai77:20210517003839p:plain

テストします。

f:id:kazuhironagai77:20210517003858p:plain

戦闘します。
一体倒して戻ってきたら、直ぐに残りの一体と戦闘になりました。
それを倒して戻ってきたら今度は、モンスターはいなくなりました。
と言う事は出来ています。
これで完成とします。
9.Landscape4で戦闘しまくってバグ出しをする。
今週はもう疲れたのでやりません。
来週、Block1のモンスターの数を増やして試します。来週は更にBlockの数も増やします。
10.魔法陣の改良
これも来週やります。
11.まとめと感想
今週は以下の事をやりました。

  • Niagara:Eventの使用方法の勉強
  • Cascade:Costについて勉強しようとしたら良いTutorialが見つからなかったので代わりにMaterialのコストについて勉強
  • Block1のモンスターについての考察
  • Landscape4における戦闘後に沼に戻ってしますバグの直し
  • Block1のモンスターの出現の実装

今週は勉強している途中でぎっくり背中になってしまって途中、集中力が落ちてしまいました。
来週は以下の事をやる予定です。

  • NiagaraCascadeの勉強
  • Block1にもっとモンスターを出現させる
  • Block2,3を作成する時に簡単に出来る様にBlock1をActor化する。
  • Block2,3を作成する。
  • 魔法陣の改良

などを考えています。
12.参考文献(Reference)

[1] Epic Games. (n.d.-c). Niagara Visual Effects. Unreal Engine Documentation. Retrieved May 16, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/index.html

[2] Epic Games. (n.d.-a). Events and Event Handlers Overview. Unreal Engine Documentation. Retrieved May 16, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/EventHandlerOverview/index.html

[3] Hrishikesh Andurlekar. (2020, May 18). UE4 4.25 Niagara Event Handler Simplest Example [Video]. YouTube. https://www.youtube.com/watch?v=wJ5o8mxeyXY

[4] Epic Games. (n.d.-d). VFX Optimization Guide. Unreal Engine Documentation. Retrieved May 16, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/Optimization/index.html

[5] Epic Games. (n.d.-b). Matinee and Cinematics. Unreal Engine Documentation. Retrieved May 16, 2021, from https://docs.unrealengine.com/en-US/AnimatingObjects/Matinee/index.html

[6] Ben Cloward. (2020, January 2). Shader Performance Optimization - UE4 Materials 101 - Episode 7 [Video]. YouTube. https://www.youtube.com/watch?v=D8E47BJOE6E

 

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する  Effectの勉強など Part 3

f:id:kazuhironagai77:20210509225618p:plain

<前文>

第二言語習得法と大量リスニング

先々週、英語の収得方法のアドバイスを書いたせいか、第二言語習得方法についての英語の記事を結構読んでいます。アメリカは移民の国なので移民が英語しゃべれなかったら困る訳です。第二言語習得の熱心さがまるで違います。その中でこの学習方法ならある程度の成果が出ると言われているのが、日本人からするとかなり意外ですが、大量リスニングです。

大量リスニングって、スピード〇―二ングでしょう。あれって〇欺でしょう。とほとんどの日本人は思うと思います。私もそう思いました。良く読んでみると英語を聞いているだけで良いのではなく、9:1ぐらいで聞く勉強としゃべる勉強にするのが最も効率が良いらしいです。

にしても大量リスニングって効果ないです。とほとんどの日本人が思っているのと相反しています。

ここからが私の仮説ですが、どちらの考えも正しいのだと思います。

まずアメリカの大量リスニングが第二言語習得に最も効果があると言うのは、恐らくですが被験者たちのほとんどがヨーロッパからの移民であるからだと思われます。ヨーロッパからの移民は、文化がほとんど同じで言語もかなり似ていますから、聞いているだけで覚えられる可能性があります。

欧米の文化が如何に同一であるかを実感した体験を以下に記します。

アメリカでは、何かをやる前にWish me luckと言って、日本で言うエンガチョのハンドサインをやります。

ある時ですが、その場にいたドイツ人の女の子が、EUじゃこうやるのって別なハンドサインを見せたら、ロシア人の女の子がロシアじゃこうっとまた別なサインを見せたんです。そしてその場にいたみんなが私を見つめて、日本ではどうやるのか興味津々で私の発言を待っていたんですが、「日本じゃWish me luckって言わない。だからハンドサインもない。」と私が言うと、そんな事あるか、とみんなから突っ込まれて、日本ではVサインをやる。と勝手に決められてしまいました。

でも、日本でWish me luckに該当する言い回しなんてないですし。

この文化の違いが、日本人の場合は、大量リスニングしても効果がない理由かもしれないと思っています。

よく英語が出来ない人が「いただきます」「がんばって」「えらいね」などの英訳を英語が出来る人に聞いて、英語が出来る人がつっけんどんに「これらの日本語に1;1で対応する英語はないですよ。」と答えたりしていますが、実際それらの単語は、その文脈毎に、その意味を汲み取って訳するしかありません。ところが、ヨーロッパの人達はあるんですよ。全く同じ意味の言い回しが。そしてこうやって聞いているだけで英語がしゃべれるようになってしまうんです。文化が同じと言う事はそう言う事なんです。

そうはいっても、アメリカで第二言語習得において一定の効果が出ているのが、大量リスニングである事は、英語が喋れるようになりたい日本人にとってはかなり重要な情報です。

私は、日本人には大量リスニングをやる前に、何かの予備学習をする事でヨーロッパ人と同様の効果が出るようになると思っています。

発音とか、文法とかの最低限の基礎を身についてからやるのが一つ。もう一つは英語圏で実際に生活する事です。

この辺の勉強方法について、ちょっと研究したいと思っています。

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

<本文>

1. 今週の予定

今週は以下の事をやります。

  • Niagaracascadeの勉強
  • モンスターをもっと配置する
  • 武器屋のバグの直し
  • ワープゲートのセリフの直し
  • Lightmass Importance Volume…の警告の直し
  • Effectのコストについての勉強
  • 魔法陣の改良

2. Niagaraの勉強

先々週、先週とUE4VFXを勉強しましたが、かなり面白かったので今週ももう少しだけ勉強します。

いつものサイト、Niagara Visual Effects [1] を見ますと

f:id:kazuhironagai77:20210509225944p:plain

Event and Event Handlers Overviewだけはまだ読んでいません。読んでいませんが、まだEmitterを2個以上使用したNiagara Systemを作成した事がないので、今勉強してもあんまり身に付かないとも思っています。

じゃGuidesの方を勉強しますか?

f:id:kazuhironagai77:20210509230003p:plain

緑とオレンジの色の違いは何なんでしょうね。緑はBeginner でオレンジはIntermediate の事を指しているんですかね?

Enable the Niagara Plugin は今のUE4のVersionで勉強する必要はないのでスキップします。

次のAudio Effects in Niagaraは、興味深い内容ですが、基本を勉強している今、やる必要があるのかと言うとちょっと疑問です。後に回しましょう。

残りのCreate a Sprite Particle Effect in Niagara、Create a GPU Sprite Effect、Create a Mesh Particle Effect in Niagara、Create a Particle Light、Create Ribbon Effect in Niagara、How to Create a Steam Effect in Niagara、How to Create a Sparks Effect in Niagara、そしてCreate a Beam Effect in Niagaraを整理すると、

  • Sprite Particle、Sprite Particle(GPU) 、Mesh Particle、そしてParticle Light
  • Ribbon、Steam、Sparks、そしてBeam

の構成になっています。

この順番で勉強するのが一番の正攻法なのかもしれませんが、Niagara Quick Start [2]で既にMesh Particleを使用しているので、そんなに真剣に勉強する所なのかな?とも思っています。

f:id:kazuhironagai77:20210509230037p:plain

あるいは先週勉強したYouTubeにある NiagaraのTutorial(UE4-VFX [3])の続きを勉強する方法もあります。

f:id:kazuhironagai77:20210509230057p:plain

先々週、先週と公式のDocumentばっかしで勉強して来たのと、ビデオで学習した方が文書を読むより効果が高いはずなので、今週はこっちをやる事にします。

2.1 UE4 - Introduction to Niagara - Part 2 [4]を勉強する

UE4 - Introduction to Niagara - Part 2 [4]を勉強します。

今回は、Niagara Systemをいきなり作成します。

f:id:kazuhironagai77:20210509230128p:plain

New System from a templateを選択します。

f:id:kazuhironagai77:20210509230148p:plain

前回は、Create empty systemを選択したんでしたっけ。

そしてDirectional Burst、Radial Burst、Simple Explosionの中からSimple Explosionを選択します。

f:id:kazuhironagai77:20210509230309p:plain

先々週、Niagara Quick Start [5] を勉強した時はどれを選んでしったけ。全く覚えていません。

見直したら、基本的にNiagara Systemすら使用していなかったです。

f:id:kazuhironagai77:20210509230330p:plain

Niagara Dynamic Input Scriptですか。うーん。まだ分からない事だらけですね。

名前をNS_IN2としました。先週、ConventionでNiagara SystemはNS_とすると習いましたのでNS_を付けました。

f:id:kazuhironagai77:20210509230354p:plain

全然、関係ないですがConventionって

  • 偉い人たちが一同に集まって、どんな基準でもいいんですが統一すると便利な事象、例えば長さの単位、の基準を決定する。
  • 決定した後は、全ての人がそのルールに絶対に従わないといけない。

っていう2つの意味があると思います。

これを慣習とかしたきりと訳すと、古くからある約束事になって新しく制定するという意味合いが完全に消えてしまいます。条約、協定と訳すると国の場合に限定しすぎていて何かしっくりきません。約束と訳すと、どんな基準でもいいんですが統一すると便利な事象と言うニュアンスもないし、偉い人たちが一同に集まって決めたという前提条件も無くなってしまいます。

どの訳もしっくりこないのでConventionとそのまま使用する事にしました。

NS_IN2を開いて見ます。

f:id:kazuhironagai77:20210509230438p:plain

おお。Emitterが3つもあります。Niagaraで初めて複数のEmitterを取り扱います。

Reviewを見てみると

f:id:kazuhironagai77:20210509230455p:plain

大量の矢印の放出、淡い白い球の発生、そして小さい白い粉の落下、が見られます。これらをそれぞれのEmitterが作成しているのでしょうか?

Tutorialの説明でこれらのEmitter内のModuleが継承している訳ではないと言っています。

そして、その証拠に以下の赤で囲った部分に緑のマークが表示されていないとも言っています。

f:id:kazuhironagai77:20210509230527p:plain

しかし先週作成したNiagara systemのModule(継承しているはず)をみても緑のマークは表示されていません。

f:id:kazuhironagai77:20210509230706p:plain

自分で改良したり作成したりしたEmitterを別なNiagara systemで使用する方法が説明されていました。

Emitter上で右クリックしてCreate Asset From Thisを選択します。

f:id:kazuhironagai77:20210509230734p:plain

Emitterが出来ました。

f:id:kazuhironagai77:20210509230750p:plain

EmitterもNSで呼ぶのは混乱を引き起こす気がしますね。

NS_IN2にあるOmni directional Burst Emitterを消去してNS_test1をNS_IN2に追加します。

何でこんな事するのかと思ったら、このやり方だとNS_test1にあるModuleは継承されるはずだからでした。

しかし実際は継承されておらず、継承されるためには、右上のギアのようなアイコンを左クリックしてSet New Parent Emitterを選択する必要があります。

f:id:kazuhironagai77:20210509230909p:plain

選択すると以下のようなwindowが表示されるので適切な親Emitterを選びます。

この場合はNS_test1を選択します。

f:id:kazuhironagai77:20210509230946p:plain

すると以下に示したような緑(?)アイコンが表示され継承した事が確認出来ます。

f:id:kazuhironagai77:20210509231025p:plain

とTutorialにありますが、

私のNS_IN2にはそんなアイコンは表示されません。

f:id:kazuhironagai77:20210509231052p:plain

以下に示した様に、Moduleを消去する事は出来ないので、継承した事は間違いないみたいですが、何故緑(?)アイコンは表示されないんでしょうか?

f:id:kazuhironagai77:20210509231110p:plain

分かりました。

値を弄ったら表示されます。

f:id:kazuhironagai77:20210509231159p:plain

どうでもいいですが「このアイコン青くない」と思って切り取って拡大して確認しました。

f:id:kazuhironagai77:20210509231224p:plain

緑でした。

Tutorialでemitterやmoduleを複数選択出来ると説明されていましたがやり方の説明がなかったです。

Ctrl+左クリックで出来ましたが。

f:id:kazuhironagai77:20210509231319p:plain

以下のチェックを外すとこのEmitterが担当しているEffectが消えます。

f:id:kazuhironagai77:20210509231337p:plain

NS_Test1のチェックを外したらPreviewに表示されていた白い粉が消えました。

f:id:kazuhironagai77:20210509231354p:plain

今度は以下に示した人型のアイコンについてです。

f:id:kazuhironagai77:20210509231410p:plain

これをクリックするとIsolationします。と説明していますが、Isolationって具体的に何を意味しているのか分かりません。

試しにクリックしてみたら、白い粉だけ表示されるようになりました。これがIsolationなんでしょうか?

f:id:kazuhironagai77:20210509231430p:plain

必殺のカーソル乗せも今回は駄目でした。

f:id:kazuhironagai77:20210509231447p:plain

Tutorialは2つ同時にIsolateする方法を説明しています。

2つ以上Isolateする場合は以下のように右クリックから選択する必要があります。

f:id:kazuhironagai77:20210509231506p:plain

以下のように2つのEmitterのEffectだけが表示されています。

f:id:kazuhironagai77:20210509231523p:plain

以下に示したマークの説明です。

f:id:kazuhironagai77:20210509231602p:plain

これはSprite Rendererを使用している事を示しているそうです。

Renderを見ると確かに使用してます。

f:id:kazuhironagai77:20210509231658p:plain

隣のEmitterは四角のアイコンになっていました。

f:id:kazuhironagai77:20210509231849p:plain
これは

f:id:kazuhironagai77:20210509231815p:plain

Mesh Rendererを示すアイコンのようです。

Time lineにも全く同じアイコンがあり、機能も全く同じだそうです。

f:id:kazuhironagai77:20210509231918p:plain

以上でした。

流石にこれだけだと物足りないのでもう少し勉強します。

2.2 UE4 - Cascade to Niagara Converter [6]を勉強する

次のTutorialであるUE4 - Cascade to Niagara Converter [6]も勉強します。

4.26 からCascadeNiagaraに変換するPluginがついているそうです。その使用方法についての解説でした。

試してみます。

f:id:kazuhironagai77:20210509232005p:plain

これを使用出来るようにします。

Cascadeで制作されたParticle systemをNiagaraに変換します。

f:id:kazuhironagai77:20210509232023p:plain

以下のNiagara Systemが作成されました。

f:id:kazuhironagai77:20210509232041p:plain

f:id:kazuhironagai77:20210509232049p:plain

TutorialではこのPluginを使用する事で、Cascadeに詳しい人がNiagaraの仕組みを簡単に理解出来る様になります。と説明していました。

Cascadeの仕組みを知らない私にとっては関係ない話ですが。

2.3 UE4 - Cascade to Niagara - 4.26+ [7]を勉強する

さっきのTutorialは更に短かったので次のUE4 - Cascade to Niagara - 4.26+ [7]も勉強します。

単に前節で紹介したPlugin、Cascade to Niagara Convertorが実験的なPluginでバグがあったりするので、あくまでNiagaraの初心者でCascadeに詳しい人が基礎を理解する助けのために使用すべきである。との事でした。

先程、Cascade to Niagara ConvertorをEnableした時に、同様の警告が表示されていましたが、それでもこのTutorialの作者に文句言う人がいるんでしょうか?

まあ、いるから敢えてこのtutorialを作成したんでしょうね。

2.4 UE4 - Niagara Learning Resources [8] を勉強する

UE4 - Niagara Learning Resources [8] を勉強します。

正直これが一番見たかったヤツです。これを見れば、Niagaraを勉強するための他の教材を教えてくれそうだからです。

最初のお勧めは、Content Exampleでした。

f:id:kazuhironagai77:20210509232235p:plain

これは後で見なければなりませんね。

これだけでした。

ならばContent Exampleを今見てみます。

4.26のVersionをdownloadしてMapのNiagaraを開きます。

f:id:kazuhironagai77:20210509232301p:plain

最初のサンプルですが、Ctrl+Eを押しても何も起きません。

f:id:kazuhironagai77:20210509232321p:plain

Playを切ってCtrl+Eを押して見ました。

以下の解説が現れました。

f:id:kazuhironagai77:20210509232342p:plain

これは以下のNiagara Systemが開いたんでした。

f:id:kazuhironagai77:20210509232402p:plain

ついにこの青のやつの説明に巡り合えました。

f:id:kazuhironagai77:20210509232425p:plain

この青のヤツはBlue System Scriptと呼ぶらしいです。

後、今までヤツと呼んでいたこの塊、Nodeじゃないし呼び方が分からなかったんですが、ScriptもしくはStackと呼ぶ事が分かりました。

Blue System ScriptはParticle systemのLifecycle全体を管理するStackでした。と言ってもそれだけだと何の事だか意味分かりませんね。

ここで作成されたParameterはEmitterやParticle groupなどのどこからでもアクセス出来るそうです。System->Emitter->Particleとデータが流れるとありますから、このBlue System Scriptは最初に実行されるんでしょう。

一応、全部読みましたが、何か分かったような分からないような感じです。もう少しNiagaraの知識と実践が増えたら別な感想に変わるのかもしれませんが。

唯一、ああこれだと思ったのは以下に示したEmitterの追加についてです。

f:id:kazuhironagai77:20210509232507p:plain

先週、Emitterを追加しようとしましたが何も表示されませんでした。これを試してみます。

f:id:kazuhironagai77:20210509232601p:plain

沢山のEmitterが表示されました。

3. Cascadeの勉強

Cascadeで勉強したい事は決まっていて先週のCascade Particle Systems [9] のLODとOptimizationです。

f:id:kazuhironagai77:20210509232637p:plain

3.1 Particle System Level of Detail (LOD) [10] を勉強する。

今週はarticle System Level of Detail (LOD) [10] を勉強します。

先週、Key Particle Concepts [11] でParticle systemのコストを下げるためにはLODが非常に大切である事を学びました。今週はそれをもっと勉強して行きます。

Cascade LOD Controls

何と、Particle SystemのToolbarにあるToolの半分がLOD関連でした。

f:id:kazuhironagai77:20210509232806p:plain

これに関する解説だそうです。

それぞれのToolに関して詳しい説明がありましたが、こんなの実際に使用しないと理解出来るはずもないです。今読んでも何も分からないです。スキップします。

<Creating LOD Levels in a Particle System

以下の手順で行うそうです。

f:id:kazuhironagai77:20210509232921p:plain

と言う事は最初に自分でCascadeを作成する必要があるんですね。

今回は手順を理解するだけにしておきます。

f:id:kazuhironagai77:20210509233001p:plain

このdocumentで使用しているEffectですが、Sub UVを使用して作成したそうです。

しかし私、Sub UVの使用方法を知りません。

Documentを読んで想像する限りでは、一枚のTextureにそれぞれのLODで使用するTextを貼り付けているようです。

f:id:kazuhironagai77:20210509233154p:plain

でも上記の形状でTextureを貼り付けたらTextureのサイズがLODの最も高い場合と最も低い場合でも同じになってしまいますよね。

Mipmapみたいなのなら分かるんですが。

ここは、LODのLevelが最も高い時にTextureの1の部分を使用、LOD のLevelが最も低い時にTextureの4の部分を使用する。(もしくはその逆)と仮定して読み進めます。

まず兎に角、Particle systemを完成させます。Documentでは、以下の物を作成しています。

f:id:kazuhironagai77:20210509233220p:plain

これはLODのLevelが最も高い状態で作成したものだそうです。

と言う事はLOD0の状態と言う事でしょうね。

そしたら以下のToolボタンを押すそうです。

f:id:kazuhironagai77:20210509233245p:plain

そうするとLODのLevelが最も低い状態に勝手に成るみたいですね。

うーん。

良く分からない。

Starter Kitに付属のFireのEffectをDuplicateしてFire1を作成しました。Fire1のEmitterを一個だけ残したParticle systemを作成しました。

これで試してみましょう。

f:id:kazuhironagai77:20210509233323p:plain

Regen LODボタンを押してみます。

f:id:kazuhironagai77:20210509233342p:plain

警告されました。

f:id:kazuhironagai77:20210509233406p:plain

と言う事はこのEmitterをもっともLevelの低いLODに変換すると言う事なんでしょうか?

2個別々なEmitterを作ってくれるのかと思っていました。

良く分からないので、Fire1の複製、Fire2を作成して、Fire1だけRegen LODボタンを押しました。

左側がもっともLevelの低いLODで作成されたはずの炎(Fire1)で、右側はもっともLevelの高いLODで作成されたはずの炎(Fire2)です。

f:id:kazuhironagai77:20210509233443p:plain

全く違いが分かりません。

うーん。何か勘違いしていそうです。

一応、コストも確認してみます。

f:id:kazuhironagai77:20210509233502p:plain

同じに見えますね。

念のために少しだけ遠くに移動してみました。

f:id:kazuhironagai77:20210509233519p:plain

左側の方がコストがかかっているみたいですね。でも左側がもっともLevelの低いLODで作成されたはずの炎のはずなんですが。

ちょっとこれだけ読んだんじゃ意味が分からないですね。

一端中断します。

3.2 Intro to Cascade: Particle LODs | 11 | v4.2 Tutorial Series | Unreal Engine [12] を勉強する。

Intro to Cascade: Particle LODs | 11 | v4.2 Tutorial Series | Unreal Engine [12] にParticle systemのLODの使用方法が説明されていました。

かなり古いTutorialではありますが、ざっと見た感じではこっちは理解出来そうですので、これで勉強してみます。

まず、距離によって使用されるLODが変わる事についての解説がされています。

f:id:kazuhironagai77:20210509233558p:plain

これは常識かもしれませんが、先程のEmitter、Regen LODを使用したら、もっともLevelの低いLODに変換するけどそれで良いですか?みたいな警告が出て来て、それまで在ったもっともLevelの高いLODのデータは消えてしまうみたいなニュアンスでした。

f:id:kazuhironagai77:20210509233800p:plain

f:id:kazuhironagai77:20210509233816p:plain

やっぱり一つのEmitter内で幾つかのLODが保持出来ないと距離によってLODの使用を変える事は出来ないですよね。

もう少し続きを見てみましょう。

Starter ContentにあるP_Smokeを使用して説明してくれるそうです。

f:id:kazuhironagai77:20210509233921p:plain

探したらP_Smokeありました。

f:id:kazuhironagai77:20210509234007p:plain

DuplicateしてP_Smoke1を作成しました。

f:id:kazuhironagai77:20210509234026p:plain

これで試してみます。

Tutorialと同じようにRateのConstantを50にセットします。

f:id:kazuhironagai77:20210509234127p:plain

Tutorialの方はDistributionもRequired Distribution Spawn Rateになっています。

f:id:kazuhironagai77:20210509234221p:plain

こっちはよく分からないのでそのままにしておきます。

Tutorialによると、まず最初にこのEmitterがLODを何個保持しているのかを確認する必要があるそうです。

LODの項目のLOD Distanceをみると

f:id:kazuhironagai77:20210509234319p:plain

LODは0だけ示されています。つまりLODは現状一個しかありません。

これだわ。

先程のEmitterは元々LODを何個も持っていたんでしょう。それでRegen LODを使用したら、もっともLevelの低いLODに変換するけどそれで良いですか?みたいな警告が出て来たんですわ。

確認します。

先程のFireのParticle でRegen LODを使用する前の状態のLODを見てみました。

f:id:kazuhironagai77:20210509234351p:plain

やっぱり元々LODを2個持っていました。

Regen LODを使用した後のFireをみたら、LOD Distanceの1が2500になっていました。

f:id:kazuhironagai77:20210509234410p:plain

これは先程の遠くから見たら、左側がもっともLevelの低いLODで作成されたはずの炎のはずなのに、左側の方がコストがかかっている理由も分かりましたね。

f:id:kazuhironagai77:20210509234424p:plain

Regen LODを使用した左の炎は、2500(cm?) 離れないとLOD1は使用されませんが、元々の炎は、1200(cm?) 離れればLOD1を使用します。

だから右の炎の方がこの距離ではコストが低い訳です。

全て繋がりました。

Tutorialでは以下のボタンを使用してLODを追加しています。

f:id:kazuhironagai77:20210509234441p:plain

私もAdd LODをクリックしてP_Smoke1に新しいLODを追加します。

f:id:kazuhironagai77:20210509234456p:plain

新しく作成されたLODの個々の設定はLOD Methodの設定によって決定します。

自動でセットしたい時は、Automaticのままで良いそうです。

f:id:kazuhironagai77:20210509234511p:plain

ToolbarのLODを1にセットすると

f:id:kazuhironagai77:20210509234548p:plain

Emitter内の全てのModuleのバックに大理石のようなTextureが表示されます。

f:id:kazuhironagai77:20210509234603p:plain

Tutorialでは灰色に変わると言っていますが、灰色じゃないですよね。

このLOD1のそれぞれのModuleのparameterの値を自分で編集したい時は、Duplicate From Higherを選択します。

f:id:kazuhironagai77:20210509234618p:plain

Spawn Moduleで試したところ、Spawnのバックの大理石のようなTextureの表示が消えました。

f:id:kazuhironagai77:20210509234635p:plain

これでLOD1のSpawn Moduleの編集が可能になりました。

先程 LOD0 で50にセットしたRateのConstantを0.5にセットします。

f:id:kazuhironagai77:20210509234650p:plain

テストしてみます。

このEffectに近い場合は凄い煙を発しています。

f:id:kazuhironagai77:20210509234757p:plain

ちょっと離れると

f:id:kazuhironagai77:20210509234833p:plain

煙が消えました。

LOD0とLOD1が指定した距離によって切り替えられています。

この後、このTutorialは煙を二つにして色々見せていますが、基本は同じ事をやっているのでここで終了します。

一つだけ。

Viewportのbackground colorを変えるにはToolbarのBackground Colorから出来ます。

f:id:kazuhironagai77:20210509234953p:plain

f:id:kazuhironagai77:20210509235000p:plain

3.3 Particle System Level of Detail (LOD) [10] をもう一度勉強する。

article System Level of Detail (LOD) [10] をもう一回勉強します。

途中からやり直しても良かったんですが、前節ではっきりとCascadeにおけるLODの仕組みが理解出来たので、それを踏まえてもう一度全部読み直します。

Cascade LOD Controls

先程使用したRegen LODの解説ですが今ならよく意味が分かります。

f:id:kazuhironagai77:20210509235030p:plain

要するに、今まで作成したLODの内最もLevelの高い一個を除き全部消去し、その一個の複製をLOD1として作成すると言う意味です。

他のボタンの解説も読みましたが全部意味が理解出来ました。

<Creating LOD Levels in a Particle System

以下の説明によると

f:id:kazuhironagai77:20210509235214p:plain

Regen LODで作成した複製のLOD1は、全ての値がLOD0 と同じではなくSpawn rateは低くなっているようです。

以下の部分の説明は、最初に読む人には訳分からな過ぎでしょう。

f:id:kazuhironagai77:20210509235255p:plain

せめて以下の図くらいは示してほしかったです。

f:id:kazuhironagai77:20210509235313p:plain

<LOD Method and Distance Settings

今度はそれぞれのLODが使用される距離を指定します。

Documentに表示されている図は少し今のVersionとは違いますが中身は一緒です。

f:id:kazuhironagai77:20210509235336p:plain

f:id:kazuhironagai77:20210509235343p:plain

以上です。

思ったよりLODで手こずってしまったので、Cascade Particle system のOptimizationについては来週勉強します。

4. モンスターをもっと配置する

4.1 兎に角、配置する。

まず、Levelいっぱいにモンスターを配置してみます。それで重くなるようなら対策を考えます。

以下のように静的に配置しました。

f:id:kazuhironagai77:20210509235621p:plain

モンスターが徘徊している様はかなり壮観です。

f:id:kazuhironagai77:20210509235638p:plain

壮観ですがPCの負担も大きそうです。

トリガーボックスを作成してその中にPlayer が操作するキャラが侵入した時だけMonsterが発生するようにします。

f:id:kazuhironagai77:20210509235657p:plain

戦闘から戻って来た時の管理が難しそうですね。

4.2 一体だけモンスターを動的に生成する

一体だけモンスターを動的に生成出来る様にしてその後で考えます。

f:id:kazuhironagai77:20210509235727p:plain

これでモンスターが発生するはずです。

テストします。

何か沢山発生しているんですが?

f:id:kazuhironagai77:20210509235928p:plain

確認します。

f:id:kazuhironagai77:20210509235946p:plain

以下のノードを忘れていました。

f:id:kazuhironagai77:20210510000004p:plain

今度は一体だけ発生しています。

f:id:kazuhironagai77:20210510000018p:plain

今度は、Trigger boxから出たらこのモンスターが消えるようにします。

f:id:kazuhironagai77:20210510000032p:plain

色々考えたんですが、このTrigger box が発生させるモンスターが徘徊出来るNavがあります。そのNav内に存在する全てのモンスターを消す事で実現しました。

テストします。

f:id:kazuhironagai77:20210510000052p:plain

Trigger box から出るとMonsterが一瞬で消えました。

出来ています。

ただ一瞬で消えてしまうので見ている方は何だか分かりません。

消える前に分解して倒れるアニメーションをplayします。

f:id:kazuhironagai77:20210510000107p:plain

以下のような感じでモンスターが分解して消えます。

f:id:kazuhironagai77:20210510000122p:plain

ただし分解して消える時も、モンスターのAIは動いているので微妙に移動しています。これは後で直します。

4.3 そのモンスターとの戦闘終了後、色々。

まずそのモンスターは再生出来ないようにする必要があります。

Landscape4のどのTerritoryから戦闘場面に移動したのかが分かるようにInt型の変数、Monster Territory Numberを作成します。

f:id:kazuhironagai77:20210510000145p:plain

今作成している場所は1とします。

f:id:kazuhironagai77:20210510000220p:plain

Landscape4に発生するモンスターから戦闘で負けたモンスターを消す関数は以下に示したRemove Defeated Monster from Landscape 4です。

f:id:kazuhironagai77:20210510000238p:plain

このRemove Defeated Monster from Landscape 4関数にMonster Territory Number変数が1の場合を追加しました。

f:id:kazuhironagai77:20210510000255p:plain

これでLandscape4のTerritory1にいるモンスターは戦闘で倒した後は復活しないはずです。

試してみます。

戦闘から戻って来た時にはMonsterはいませんでしたが、一端Terriroy1から出てもう一度入ると、普通に発生しました。何故なんでしょう?

DebugしたらMonster Territory Number変数が0のままでした。

f:id:kazuhironagai77:20210510000312p:plain

理由が分かりました。

例え別なレベルに移動してもLandscape4のTrigger boxのOn Actor End Overlap (Trigger box) は呼ばれていました。

f:id:kazuhironagai77:20210510000328p:plain

戦闘場面に移動する時はMonster Territory Number変数の値を0に戻さないようにしました。

f:id:kazuhironagai77:20210510000343p:plain

といっても戦闘画面に移動する事を示す変数はないので、代用としてMonster Name in Fighting変数の値はNoneであるかどうかで判断する事にしました。

こういう変数は、きちんとしたゲーム会社ならば最初からFlagを使用して全部一括で管理しているんでしょうね。

なんせ行き当たりばったりで作成しているのでどんな変数が必要になるのかその時まで全く分かりません。

テストします。

今度はTerritory1に再度、侵入しても、倒したモンスターは再生しませんでした。

f:id:kazuhironagai77:20210510000422p:plain

4.4 モンスターを増やす

モンスターが2体でも大丈夫か確認します。

もう一体だけモンスターをLandscape4、Territory1に追加しました。

f:id:kazuhironagai77:20210510000457p:plain

確認します。

モンスターが2体生成されていました。

f:id:kazuhironagai77:20210510000513p:plain

一端、Territory1から出て生成されたモンスターを破壊します。

そしてもう一回、Territoryに侵入すると破壊されたモンスターは、破壊されたままの形で再生されて動き続けています。

f:id:kazuhironagai77:20210510000532p:plain

このバグを直します。

4.5 Territory1のモンスターを確実に消滅させる

多分ですが、このバグはTrapでモンスターを発生させた時に、モンスターが消滅する前に新しいモンスターを発生した時に起きたバグと同じ原因で起きてるはずです。

それを直します。

更に今回注意しないといけないのは、loopを使用している事です。

Loop内でdelayを使ったり、ForLoopの元のArrayにLoop中に干渉したりすると色々オカシクな事が起きます。

まずMonsterBPのArrayを新しく作成しました。

On Actor begin Overlap event で作成した全てのMonsterBPをそのArrayに追加します。

f:id:kazuhironagai77:20210510000608p:plain

これでそれぞれのMonsterBPに直にアクセスする事が出来ます。

On Actor End Overlap Eventでそのarrayを使用して分解、消滅のアニメーションをそれぞれのMonsterBPのMeshに対してplayします。

f:id:kazuhironagai77:20210510000655p:plain

ここでそれぞれのMonsterBPにFor Loop内でDelayを使用すると、Delayが終わらない内に先のコードを実行してしまうようです。

なので、AnimationをPlayする時間を確保するためにFor Each Loopが終了した後で、Delayを使用しました。

f:id:kazuhironagai77:20210510000712p:plain

分解、消滅のアニメーションは1.2秒程度ですが、念のために2秒ほどDelayします。

その後でArrayにAssignされた全てのMonsterBPをDestroyします。

更にArrayそのものもCleanします。

f:id:kazuhironagai77:20210510000734p:plain

Boolean 変数、Monster Clean については後で説明します。

テストします。

Monsterを発生させた後で、Territoryから逃走します。

Territoryを外れるとMonsterは分解、消滅のAnimationをplayします。

f:id:kazuhironagai77:20210510000759p:plain

そして消滅します。

f:id:kazuhironagai77:20210510000815p:plain

今度は、Monsterが消滅する前にもう一度Territoryに侵入した場合を検討します。

On Actor begin Overlap eventでMonsterを新しく生成する前に、先程出て来たMonster Clean Boolean変数をチェックします。

f:id:kazuhironagai77:20210510000915p:plain

この変数は、Arrayにある全てのMonsterBPがDestroyされ、更にそのArrayがCleanされなければTrueになりません。

Monster Clean Boolean変数がTrueになったら、On Actor begin Overlap eventは新しいMonsterBPを生成出来ます。

これでテストしてみます。

Monsterのアニメーションが終わる前にもう一回Territory1に侵入します。

f:id:kazuhironagai77:20210510000934p:plain

前の分解、消滅したモンスターが消えるまで、新しいモンスターは生成されませんでした。

バグは直ったようです。

4.6 Territory1のモンスターを一体だけ倒してみる。

それでは戦闘も試してみます。Territory1のモンスターを一体だけ倒してみます。

戦闘が終わったら沼に戻って来ました。

f:id:kazuhironagai77:20210510000957p:plain

勿論、Errorの山と共にです。何故なんでしょうか?

もう一度試したら、普通に戦闘した箇所に戻って来ました。

f:id:kazuhironagai77:20210510001014p:plain

一端、Territory1から出てもう一回侵入したら、倒していないMonsterだけ再生されました。

f:id:kazuhironagai77:20210510001030p:plain

沼に戻ってくるバグに関しては後でしっかり検討しましょう。

Territory1でモンスターと戦闘になった後は、Territory1のモンスターを生成します。

f:id:kazuhironagai77:20210510001052p:plain

試してみたら、Monsterを一体倒してこの場所に戻ってきてすぐに別のモンスターとの戦闘になりました。

f:id:kazuhironagai77:20210510001110p:plain

一応、考えていた通りに動いています。

ただしErrorが表示されています。

f:id:kazuhironagai77:20210510001128p:plain

多分、実在しないMonsterBPにアクセスしているんでしょう。

IsVaildノードで確認してから実行する事にします。

f:id:kazuhironagai77:20210510001145p:plain

もう一回テストします。

今度はErrorは表示されませんでした。

f:id:kazuhironagai77:20210510001207p:plain

思ったより複雑になってしまい、頭の整理が追いつきません。今週はここまでとして、少し頭の中を整理します。

5. 武器屋のバグの直し

スクリーンショットだと見えないんですが、武器屋で買い物をした後にWidgetを消すとカーソルが消えてします。

f:id:kazuhironagai77:20210510001238p:plain

カーソルが無いと画面の動きが激しすぎて3D酔いします。のでこのバグを直します。

まず正しく出来ているケースの実装を調べます。

武器屋に入って直ぐに出た時の場合です。

カーソルはそのまま残っていて、画面の動きが激しすぎて3D酔いする事はありません。

実装部は以下のようになっていました。

f:id:kazuhironagai77:20210510001301p:plain

Show Mouse Cursor if Not 関数を使うんでした。自分で作成して忘れていました。

この関数はWidgetを開いたときにキャラが動かないようにするためにどうしたら良いのかとか、色々検討して作成した関数でした。

f:id:kazuhironagai77:20210510001317p:plain

折角いろいろ研究して作成した関数を使わないのは勿体ないです。

これを使用して、武器屋で買い物をした後にカーソルが消えるバグを直します。

以下のように直しました。

f:id:kazuhironagai77:20210510001333p:plain

テストします。

カーソルはスクリーンショットに写らないので、証拠はないですが直りました。

他のWidgetも念のために調べておきます。

武器屋で武器を売った後も、カーソルが消えるバグがありました。

f:id:kazuhironagai77:20210510001350p:plain

直しました。

会話した後も同じでした。これはバグと言うより、前はカーソルが見えない方が良いと思ってカーソルを全部消していたのですが、後でカーソルが無いと3D酔いする事に気が付いて、カーソルの表示をするように変更したのですがその時に直し切ってなかった部分です。

全部のUIをチェックして直してしまいます。

道具屋で会話した後も直してなかったです。

直しました。

宿屋で会話した後も直しました。

これで全部のUIのカーソルが消えるバグを直したはずです。

6. ワープゲートのセリフの直し

6.1 兎に角、直す

直しました。

Map1からLandscape4にワープする時です。

f:id:kazuhironagai77:20210510001432p:plain

Landscape4からMap1にワープする時です。

f:id:kazuhironagai77:20210510001447p:plain

以下のようにセリフ部分の実装を変更しました。

f:id:kazuhironagai77:20210510001515p:plain

セリフは一括で管理するようにしたはずですが、どうやって管理する事にしたのか忘れてしまいました。

確認します。

6.2 セリフの管理方法を確認する。

セリフの管理をDataTableで一括するようにしたのは覚えていますが、具体的にどうやったのかは忘れてしまいました。

確認します。

戦闘中のセリフの表示ですが関数に任せていました。

f:id:kazuhironagai77:20210510001537p:plain

その関数の実装を見てみると以下のようになっていました。

f:id:kazuhironagai77:20210510001551p:plain

セリフそのものは以下の様にData tableで管理されていますね。

f:id:kazuhironagai77:20210510001606p:plain

戦闘中の会話は以下のように全てData Tableに落とされています。

f:id:kazuhironagai77:20210510001623p:plain

お店の会話はどうしたんでしたっけ?

Data Tableは見当たらないですが

宿屋の主人との会話を見てみます。

f:id:kazuhironagai77:20210510001641p:plain

Textのarrayで整理していますね。こっちはdata tableは作成しなかったんでしたったけ。

思い出しました。

NPC_ParentというWidgetを作成してその中に全てのセリフを管理したんです。

f:id:kazuhironagai77:20210510001658p:plain

f:id:kazuhironagai77:20210510001705p:plain

実際にお店の主人が会話に使用する時は、このNPC_Parentを継承したWidgetを作成してNPC_Parentのセリフを使用しました。

このやり方は教科書、Building an RPG with Unreal 4.xに載っていたやり方です。

f:id:kazuhironagai77:20210510001724p:plain

今、教科書を見直したら、6章の「NPCs and Dialog 」のDialog box setupにこのやり方の詳しい手順が紹介されていました。

作成したWidgetの親にNPC_Parentを指定する事で、NPC_Parentで作成したDialogueが、新しく作成したwidgetから使用出来る事が説明されている箇所です。

f:id:kazuhironagai77:20210510001742p:plain

懐かしいです。

このやり方で、WarpGateのセリフもNPC_Parentで管理しましょう。

6.3 W_WarpGateのセリフをNPC_Parentで管理する。

ToolbarからClass Settingsを選びます。

f:id:kazuhironagai77:20210510001802p:plain

DetailのClass OptionsにあるParent ClassにNPC Parentをセットします。

f:id:kazuhironagai77:20210510001821p:plain

NPC_Parentに新しいText型のArrayであるNPCWarpGateKeeperを作成し、その要素に、W_WarpGateで使用しているセリフを移します。

f:id:kazuhironagai77:20210510001836p:plain

f:id:kazuhironagai77:20210510001843p:plain

W_WarpGateのセリフの実装は以下のようになりました。

f:id:kazuhironagai77:20210510001903p:plain

テストします。

f:id:kazuhironagai77:20210510001920p:plain

f:id:kazuhironagai77:20210510001929p:plain

出来ています。

7. Lightmass Importance Volume…の警告の直し

7.1 バグの直し

Landscape4でBuild light onlyをすると以下の警告が出ます。

f:id:kazuhironagai77:20210510002021p:plain

何となくは意味は分かるのですが、折角直すのなら、完全に理解して直したいです。

ので調べます。

UE4のForum にあるPerformance Warning No importance volume found and the scene is so large []で解決方法が説明されていました。

f:id:kazuhironagai77:20210510002040p:plain

Lightmass Importance VolumeでLandscape全体を覆います。

f:id:kazuhironagai77:20210510002057p:plain

f:id:kazuhironagai77:20210510002104p:plain

Build light onlyをします。

f:id:kazuhironagai77:20210510002120p:plain

何も表示されなくなりました。

7.2 Lightmass Basics [14]の勉強

公式のDocumentにあるLightmass Basics [14]の勉強をします。

f:id:kazuhironagai77:20210510002406p:plain

以下に示した様にLightmassが何であるかについての説明が最初にありました。

f:id:kazuhironagai77:20210510002431p:plain

この事は2021-04-112021-04-19、そして2021-04-26のブログでLightingの勉強をした時に既に勉強しましたが、これとLightmass Importance Volumeはどう関係しているのでしょう。

f:id:kazuhironagai77:20210510002451p:plain

説明されていました。実際にPlayerが操作するキャラが移動する範囲は作成したLevelより小さいのでその中だけLightmassすれば良いです。その範囲を指定するのがLightmass Importance Volumeだそうです。

そんだけでした。

8. Effectのコストについての勉強

Cascadeの勉強でLODについて勉強したので今週はスキップします。

9. 魔法陣の改良

試しに以下の様な物を作成してみました。

f:id:kazuhironagai77:20210510002541p:plain

EmitterのParticle EmitterにSize By Lifeを追加しました。

f:id:kazuhironagai77:20210510002557p:plain

それで魔法陣もサイズが変化するように使用としたのですが、全くサイズが変わりません。

良く分からないので色々いじっていたらサイズが変わるようになりました。成りましたが記録してなかったのでどうやったのかが分かりません。

来週、もう一回勉強します。

10. まとめと感想

今週は以下の事を行いました。

  • Niagaraの勉強としてUE4-VFX [3]を勉強しました。
  • Cascadeの勉強としてarticle System Level of Detail (LOD) [10]を勉強しました。
  • Landscape4にもっとモンスターを配置するために色々しました。
  • バグを直しました。
  • 魔法陣の改造を少しだけしました。

来週は、

  • NiagaraCascadeの勉強の続き(特にコストについて)
  • モンスターの配置についての考察
  • 魔法陣の改良

などを行います。

11. 参照(Reference

[1] Epic Games. (n.d.-f). Niagara Visual Effects. Unreal Engine Documentation. Retrieved May 9, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/index.html

[2] Epic Games. (n.d.-d). Niagara Quick Start. Unreal Engine Documentation. Retrieved May 9, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/QuickStart/index.html

[3] gameDev Outpost. (2021b, April 9). UE4 - VFX [Video]. YouTube. https://www.youtube.com/playlist?list=PLomQNLPOWtzYXU_pRIUVVEV9uY7bjENZ5

[4] gameDev Outpost. (2020a, September 14). UE4 - Introduction to Niagara - Part 2 [Video]. YouTube. https://www.youtube.com/watch?v=fpuMkVfCRBo&list=PLomQNLPOWtzYXU_pRIUVVEV9uY7bjENZ5&index=2

[5] Epic Games. (n.d.-e). Niagara Quick Start. Unreal Engine Documentation. Retrieved May 9, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/QuickStart/index.html

[6] gameDev Outpost. (2020b, September 29). UE4 - Cascade to Niagara Converter [Video]. YouTube. https://www.youtube.com/watch?v=Dy_oJ23UH1A&list=PLomQNLPOWtzYXU_pRIUVVEV9uY7bjENZ5&index=3

[7] gameDev Outpost. (2020c, December 10). UE4 - Cascade to Niagara - 4.26+ [Video]. YouTube. https://www.youtube.com/watch?v=i1w2eZ4nofs&list=PLomQNLPOWtzYXU_pRIUVVEV9uY7bjENZ5&index=4

[8] gameDev Outpost. (2021a, January 30). UE4 - Niagara Learning Resources [Video]. YouTube. https://www.youtube.com/watch?v=jJa9uLmg2Q8&list=PLomQNLPOWtzYXU_pRIUVVEV9uY7bjENZ5&index=5

[9] Epic Games. (n.d.-a). Cascade Particle Systems. Unreal Engine Documentation. Retrieved May 9, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/index.html

[10] Epic Games. (n.d.-g). Particle System Level of Detail (LOD). Unreal Engine Documentation. Retrieved May 9, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/LODs/index.html

[11] Epic Games. (n.d.-b). Key Particle Concepts. Unreal Engine Documentation. Retrieved May 9, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/Overview/index.html

[12] Unreal Engine. (2014, July 8). Intro to Cascade: Particle LODs | 11 | v4.2 Tutorial Series | Unreal Engine [Video]. YouTube. https://www.youtube.com/watch?v=ZeGUfwAlL7U

[13] Epic Games. (2014, April 16). Performance Warning No importance volume found and the scene is so large. Unreal Engine Forums. https://forums.unrealengine.com/t/performance-warning-no-importance-volume-found-and-the-scene-is-so-large/7026

[14] Epic Games. (n.d.-c). Lightmass Basics. Unreal Engine Documentation. Retrieved May 9, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Lightmass/Basics/index.html

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する  Effectの勉強など Part 2

f:id:kazuhironagai77:20210502231033p:plain

<前文>

To Tableの意味について

Tableって恐らく中学1年生の最初に習う単語だと思うんですが、皆さんは本当の意味を知ってますか?

最近Redditで中国のウイグル人の問題についての議論をしているスレを読んでたら、イギリスの新聞がこの問題についてTo Tableしたと記事にしたら、アメリカ人が怒った事が紹介されていました。

どういう事が良く分からなかったんで良く読んでみたら、アメリカ英語だとTo Tableって面倒な議題を後回しにするという意味なんだそうです。つまりこの中国のウイグル人の問題は色々面倒くさい事があるので後回しにすると言う意味になります。それでアメリカ人はイギリスがこの問題を無視して中国と仲良くやってくつもりかと怒ったんです。まあ、アメリカ政府が怒ったのかどうかは知りませんが、この記事を読んだアメリカ人で怒った人がいたのは確かだそうです。

しかしイギリス英語だとTo Tableって面倒な問題を決着つけるまでとことん議論する事らしいんです。だからこの記事はイギリスは中国に対して徹底的にウイグル人の問題についてやってるぞと言う意思表示だったんです。

つまり、イギリスもアメリカも中国のウイグル人の問題についてとことんやってやるぞ。と意気込んでいたのにTo Tableの意味がイギリス英語とアメリカ英語で180度違っていたので、中国と戦う前に味方同士で喧嘩になってしまったと言う話だったんです。

ちなみに、カナダでは両方の意味でとれるので会議などのビジネスでは使用しない人が多いそうです。南アフリカとオーストラリアではイギリス英語と同じだそうです。

この話を読んで私は、英語は世界共通の言語であると思われていますが、正しく通じる範囲は結構少ないのかもしれないと思いました。

Mazie Hirono上院議員とアジア人差別

アメリカのニュース番組を見てたら、近所のスーパーにでもいそうなおばちゃんが出ていてました。

そしたらそのおばちゃん、実は議員で、何かの法案を提出したらしいんですが、凄い量の批判のコメントと低評価なんです。一体何が起きたのかとコメント欄を読んだんですが、その時はもう夜も遅かったので、今一内容を把握出来ない内に寝てしまいました。何か差別的なニュアンスのコメントのような気もしたんですが、どんな法案を提出したのかも分からないんじゃ何も言えないです。

次の日になって気になって調べて見たら全容が分かったんですが、そのおばちゃんはMazie Hirono上院議員と言う方で、アメリカにおけるアジア系の差別に対しての抗議を示すために、全く実行力はないんですが、ある法案を提出したそうなんです。それを上院で可決する事でアメリカの上院もアジア人差別に対して抗議している事を示そう。と言う意図だったようです。

その法案はたった一人の反対を除いて圧倒的な支持で可決されたそうです。その後で、たった一人否決した上院議員は左派のメディアから白人至上主義者である事が判明したとボロクソに叩かれていました。

それ見てやっぱりあのボロクソなコメントと低評価の嵐は、白人至上主義者からの攻撃だったのかと分かり恐ろしくなりました。

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

<本文>

1.今週の予定

以下の事を行います。

  • Map1でBuildするとLandscape_0 instead mesh…と警告される事の検証の続き
  • Niagaraの勉強の続き
  • Effect(魔法陣)をWarpGateに追加する。
  • Landscape4にもっとモンスターを配置する。
  • Landscape4からMap1に戻るためのWarpGateを作成する。
  • 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する。

2. Niagaraの勉強の続き

先週、Niagaraの勉強を始めてしました。勉強は公式のdocumentであるNiagara Visual Effects [1]にあるNiagara Overview [2]、Niagara Key Concepts [3]で全体像を勉強してNiagara Quick Start [4]で実際にNiagaraを使用してEffectを作成しました。

Niagara Quick Start [4]では以下の二つの疑問が残りました。

  • Effectのほこりに透明感が全くない。
  • 足元にEffectが自然に発生するようになっている。その理由が分からない。

更にVisual Effectって本当に物理現象を数値解析で解くようなProgrammerでなくても作成出来るの?という疑問も残っています。

2.1 Effectのほこりに透明感が全くない

Niagara Quick Start [4]のビデオをみたらほこりは透明じゃなかったです。

f:id:kazuhironagai77:20210502231446p:plain

ので、この問題は解決です。

2.2 足元にEffectが自然に発生するようになっている。その理由が分からない。

普通に考えれば、Notifiesの1にSocketを指定する箇所があってそこで右足底を指定しているはずです。

f:id:kazuhironagai77:20210502231514p:plain

Notifiesの1じゃなくて、Niagara SystemのFX_FootstepDustPoofにSocket Nameの項目がありました。

f:id:kazuhironagai77:20210502231529p:plain

f:id:kazuhironagai77:20210502231535p:plain

でも何も指定されていません。

ひっとして何も指定していないからRootの箇所に発生しているだけなのかもしれません。

f:id:kazuhironagai77:20210502231555p:plain

試しに、

f:id:kazuhironagai77:20210502231610p:plain

f:id:kazuhironagai77:20210502231618p:plain

を作成して

f:id:kazuhironagai77:20210502231641p:plain

と指定してみたら、

f:id:kazuhironagai77:20210502231656p:plain

頭からほこりが発生しました。

2.3 Niagara Overview [2]Niagara Key Concepts [3]をもう一回読み直す。

何か勉強しなくてはいけない事があったような気がしますが、忘れてしまったのでもう一回、Niagara Overview [2]、Niagara Key Concepts [3]を読み直す事にします。一応Niagara Quick Start [4]で一回ですがNiagaraを実際に使用したので先週とは違った観点や更に深い理解が出来ると思います。

Niagara Overview [2]から読んでいきます。

<Core Niagara Components

<<Systems>>

f:id:kazuhironagai77:20210502231834p:plain

まず最初のSystemについての解説で、Emitterを一個ではなく沢山保持出来ると書かれていますね。Niagara Quick Start [4]では一個のEmitterしか保持していませんが沢山のEmitterを保持する必要がある時とはどんな場合なんでしょう。

その直ぐ後で、花火のeffectを作成した時に、いくつかの爆発が欲しかったとすると、それらの爆発の一個、一個をEmitterで作成出来るとありました。

Niagara Quick Start [4]で使用したProject内のNiagara systemを開いてGraph上で右クリックするとAdd Emitterが表示されますが追加出来るEmitterは存在しませんね。

f:id:kazuhironagai77:20210502231925p:plain

Timelineパネルにも新しく追加したEmitterは表示されるそうです。

f:id:kazuhironagai77:20210502231945p:plain

やっぱり一回でも実際に使用すると理解が段違いで高まりますね。ここに書かれている事自体は全て理解出来ます。

<<Emitters>>

EmitterはModuleのための入れ物です。と書かれていますが、実際はParticle Spawn、Particle UpdateなどがModuleで、それらのModuleはEmitter UpdateなどのGroupに入っています。

そのGroupを保持しているのがEmitterなのでEmitterはGroupための入れ物というのが正しいです。

f:id:kazuhironagai77:20210502232140p:plain

後、EmitterはRe-useableと書かれています。

f:id:kazuhironagai77:20210502232200p:plain

恐らくSystemに更にEmitterを追加する時に前に作成したemitterが追加出来るのでしょう。やり方はまだ分かりませんが。

<<Modules>>

ModuleはCascadeにおけるBehaviorと同じですと書かれていました。

f:id:kazuhironagai77:20210502232228p:plain

Cascadeもほとんど勉強した事ないのでCascade’s behaviorsの名前は初めて聞きました。覚えておきます。

Moduleには以下の機能があると述べています。

  • 共通データとのやり取りが出来る
  • 振る舞いのカプセル化
  • 別なModuleStackする
  • 関数が書ける

最初の共通データとのやり取りが可能とは、Niagara Quick Start [4]の例で言えば、Material で設定したDynamic Parameterの値を

f:id:kazuhironagai77:20210502232344p:plain

Module Dynamic Material Parameterで決定する事を指してると思われます。

f:id:kazuhironagai77:20210502232502p:plain

そう言えばこの設定もどうやって作ったのかうろ覚えです。Niagara Quick Start [4]を復習する時にもっと詳しく見る事にします。

関数を作成する方法や、振る舞いをカプセル化する方法はまだ分かりませんね。別なModuleとStackするのは当然ですね。

当然、Moduleで一番興味があるのはここですね。

f:id:kazuhironagai77:20210502232527p:plain

一見するとHLSLを使用して作成している事からMaterial の事を指しているように思えますが、どうなんでしょうか?

MaterialではないですがHLSLをBPで組み立ててModuleを自作出来るのならとても興味深いです。しかしそれは先週議論した、錬金術師系戦士、つまり物理現象を数値解析で解くようなProgrammerかつデザイナーであるタイプの人達が必要になってくるのではないでしょうか?

Niagaraにおいて私が最も注目している所です。

f:id:kazuhironagai77:20210502232640p:plain

うおおお。

やっぱりHLSLをBPで組み立ててModuleを自作出来るみたいです。

更に詳しい部分はDocumentの以下の部分でやるそうです。

f:id:kazuhironagai77:20210502232701p:plain

流石にこれ全部読む訳には行きませんね。いや読む分には全然問題ないんですが、実体験の伴わない読書は本当の理解は出来ませんので読んでも無駄になってしまいます。

他に情報はないのかと調べて見たら、

HLSL in UE4 Niagara & Material Custom node | Unreal Engine Niagara HLSL [5]でMaterial内でCustom HLSLを使用していました。

f:id:kazuhironagai77:20210502232739p:plain

この赤い四角で囲った部分がCustom HLSLだそうです。

このCustom HLSLはそのままHLSLが書けるそうです。

f:id:kazuhironagai77:20210502232807p:plain

うーん。

何か想像したのと違う。まずMaterialですし、Custom HLSLはそのままHLSLのコード書いています。

でもMaterialはmaterialでModuleとは違うと思うんですが。どうなんでしょう?

<<Parameters and Parameter Types>>

Parameterに関しては今は特に興味がないのでパスします。

Niagara Stack Model and Stack Groups

ここも特に先週から特に学んだ事はないですね。

ここから先は特に書く事がないので以下の2つ以外はパスします。

Niagara Paradigms

<<Events>>

先週勉強しなかった初心者向けのNiagaraのDocumentがEventなんです。

f:id:kazuhironagai77:20210502232855p:plain

一応読んでおいた方が良いのかな。

<<Houdini>>

Houdiniって何だよ。って先週はスルーしてしまったんですが、今週は少しだけ調べました。

Houdini to Niagara | Overview [6]に簡単な説明が紹介されていました。

色々な事が紹介されていましたが、その中で重要なのは以下の様なMeshを破壊するアニメーションが作成出来る事ですね。

f:id:kazuhironagai77:20210502233349p:plain

後はHoudiniを使用したいときに勉強する事にします。

後良く分からないですが、Houdiniは無料なんでしょうか?

Houdiniで作成したデータをUE4にImportするためのplug-inは無料みたいですがHoudiniそのものの商用利用は有料みたいです。

Niagara Key Concepts [3]も読み直しましたが、こっちは特に先週から理解が変わった個所とか無かったので省略します。

2.4 Events and Event Handlers Overview [7] を読む

先週勉強しなかったEvents and Event Handlers Overview [7] を一応読んどく事にしました。

一つのSystem内で2つ以上のEmitterを使用した時、それぞれのEmitter同士の連絡を取り合うのがEventとEvent handlerだそうです。

ただし、

f:id:kazuhironagai77:20210502233426p:plain

だそうです。

実際の作成は以下の様になるそうです。

f:id:kazuhironagai77:20210502233446p:plain

うーん。Emitter同士の連絡がCPUベースのSimulationでしか出来ないと言う事は、実際のNiagaraの運用では、System一個に付きEmitter一個みたいですね。

なるほど。

ここまで分かればNiagaraの最初の勉強としては十分です。

2.5 UE4 - Introduction To Niagara [8]を試してみる

本当は2.4で終にしてよかったんですがせっかくここまで理解出来たので、先週、理解出来ないから途中で見るのを止めたUE4 - Introduction To Niagara [8]を勉強してみます。

かなりNiagaraに関する基礎知識がついたので、今度は理解出来ると思います。

別にこのTutorialに関係している訳ではありませんが、このTutorが使用しているUE4には、Houdini Niagara Pluginが入っていますね。

f:id:kazuhironagai77:20210502233515p:plain

Niagara Quick Start [4]とは違い、Emitterから作成します。

f:id:kazuhironagai77:20210502233622p:plain

Templateを選択します。

f:id:kazuhironagai77:20210502233641p:plain

Emptyを選択します。

Emptyと言う事は全部自分で設定するって事でしょうか?

f:id:kazuhironagai77:20210502233734p:plain

名前を付けます。名前の付け方は「NE_+何でもいい」だそうなので、NE_Introと名付けました。

f:id:kazuhironagai77:20210502233751p:plain

Groupの事をCategoryと呼んでいますね。このTutorialでは。

f:id:kazuhironagai77:20210502233805p:plain

最初のGroupであるEmitter SettingのmoduleであるEmitter Propertiesです。

ここで重要なのはScalabilityだそうですが今回は、使用しないそうです。

f:id:kazuhironagai77:20210502233827p:plain

更にCPUベースかGPUベースで計算するのかもここで決定します。

f:id:kazuhironagai77:20210502233841p:plain

Events and Event Handlers Overview [7]ではGPUではEventは使用出来ないと言っていましたがここの事でしょうね。

GPUを選択した場合はFixed Boundsをチェックする必要があるそうです。

f:id:kazuhironagai77:20210502233857p:plain

この辺の細かい、しかし実装するのに重要な説明は、実装する時にかなり役に立ちそうです。理解出来るのなら、このTutorialシリーズはかなり良いかもしれません。

それでは何かをEmit出来るようにします。

何かをEmitするために、一番最初に設定しなければならないGroupは、Renderingだそうです。

f:id:kazuhironagai77:20210502233925p:plain

ただしSprite Renderer moduleが既に実装されているので今回は何もする必要はないそうです。

次は、EmitterをSpawnする必要があります。

f:id:kazuhironagai77:20210502234115p:plain

ありますがこのGroupは常に何もする必要がないそうです。

次にEmitter Updateです。

f:id:kazuhironagai77:20210502234148p:plain

ここで色々やる必要があります。

Spawn Rateを追加します。

f:id:kazuhironagai77:20210502234222p:plain

Spawn Rateを1にセットします。

f:id:kazuhironagai77:20210502234238p:plain

一秒間に一回Spawnするという意味だそうです。

実際、今まで何も無かったPreviewに白い丸が現れました。

f:id:kazuhironagai77:20210502234254p:plain

今度はSpawn Brust Instantaneous moduleを追加します。

f:id:kazuhironagai77:20210502234322p:plain

このmoduleは幾つのParticleをSpawnするかという事と、そのParticleを何時Spawnするかの2つを決定するためのものだそうです。

ここからSpawn Brust Instantaneous moduleの値の設定方法の説明をするのかと思いきや、突然Emitter Stateについての説明を始めました。

f:id:kazuhironagai77:20210502234411p:plain

f:id:kazuhironagai77:20210502234418p:plain

TutorialだとLoop Durationに値を入れるとTime Lineの緑色のバーの長さが入れた値通りに変化するんですが、

f:id:kazuhironagai77:20210502234449p:plain

私のProjectでは緑色のバーの長さは変わりません。

f:id:kazuhironagai77:20210502234505p:plain

Loop Delayにチェックを入れたら

f:id:kazuhironagai77:20210502234521p:plain

緑色のバーの長さが、Loop Durationに値と同じになりました。

f:id:kazuhironagai77:20210502234537p:plain

しかしTutorialではLoop Delayにチェックは入っていません。

f:id:kazuhironagai77:20210502234614p:plain

うーん。分かりません。どっかで間違えているんでしょうか?

今度はParticle SpawnとParticle Updateについてです。

f:id:kazuhironagai77:20210502234634p:plain

f:id:kazuhironagai77:20210502234643p:plain

この二つもGroupなんでしょうか?

それぞれModuleを保持出来るみたいなのでGroupみたいですが、Emitter Updateとの関係が分かりません。Emitter Updateの下に存在するGroupなのか、それとも全く独立しているのかが不明です。

Particle SpawnのInitial Particle moduleについての解説です。

f:id:kazuhironagai77:20210502234704p:plain

Lifetimeがありますが、

f:id:kazuhironagai77:20210502234725p:plain

このInitial Particle moduleのlife timeはEmitter stateのLoop Durationとは違うそうです。

f:id:kazuhironagai77:20210502234757p:plain

Initial Particle moduleのlife timeはそのParticleがどれくらい生きるかを示します。一方、Emitter stateのLoop DurationはEmitterがどれくらい生きるのかを示すそうです。

このEmitterとParticleの関係性が、今一分かりませんね。

この辺を理解するのは後の課題ですね。

Particle SpawnにAdd Velocityを追加しました。更にParticle UpdateにもAdd Velocityを追加しました。

f:id:kazuhironagai77:20210502234833p:plain

Particle SpawnにAdd Velocityの値は以下の様にセットしました。

f:id:kazuhironagai77:20210502234849p:plain

Particle UpdateにもAdd Velocityの値は以下の様にセットしました。

f:id:kazuhironagai77:20210502234906p:plain

結果、以下の様にParticleがx軸方向に移動するようになりました。

f:id:kazuhironagai77:20210502234948p:plain

Time lineのUIの操作方法についての解説です。

実は私、Niagaraに限らずTime lineの操作方法があまり分かっておらず、いつも適当にいじって何とかやっていました。いい機会なのでTime lineの操作方法についても勉強してしまいます。

右クリックで全体の移動が出来ます。

f:id:kazuhironagai77:20210502234929p:plain

右クリックしたまま右に移動させました。

f:id:kazuhironagai77:20210502235016p:plain

Ctrlボタンを押しながら、Midボタンを回すと

f:id:kazuhironagai77:20210502235045p:plain

全体のサイズを拡大縮小出来ます。

以上でした。

今度は作成したEmitterをLevel上で使用するためにNiagara systemを作成します。

Niagara systemを選択します。

f:id:kazuhironagai77:20210502235133p:plain

Empty systemを選択します。

f:id:kazuhironagai77:20210502235151p:plain

名前は「NS_何か」で決めるのが通常らしいので、NS_Introとします。

f:id:kazuhironagai77:20210502235415p:plain

開いたら、先週見た謎の奴が有りました。

f:id:kazuhironagai77:20210502235444p:plain

これが何なのか説明も聞けそうです。

f:id:kazuhironagai77:20210502235501p:plain

思わず「なにー!」ってつぶやいてしまいました。

Niagara systemに先程作成したEmitterを追加します。

Tutorialの追加の仕方が超カッコイイです。

Emitterのアイコンを掴んでNiagara systemのTime lineに落として追加しました。

f:id:kazuhironagai77:20210502235515p:plain

この後TutorialではSystem内のEmitterが実際は継承されていてEmitter内のModuleを消したりする事が出来ない事などを説明していますが、今回はその辺の事はスキップします。

Emitterを追加したNiagara systemをLevel内に配置します。

f:id:kazuhironagai77:20210502235532p:plain

以上です。

2.6 Niagara勉強まとめと感想

今回は、先週勉強した内容の復習と新しいTutorialを一個やりました。

段々Niagara systemの内容が理解で着て来ました。かなり分かり易い作りになっています。これならほとんどの事は、デザイナーでも単独で出来そうですね。ただし、簡単な事しか出来ない訳でもなくCustom HLSLを使用すればProgrammerしか出来ない高度な技術を使用する事も出来るようです。

4.26でもそうなのかは不明ですが、GPUベースにするとEventを使用したEmitter同士の連絡は出来ないそうです。これはちょっと残念でした。

2週間しか勉強していませんが、正直言ってかなりNiagara system気に入っています。来週も勉強するかもしれません。

3. Map1でBuildするとLandscape_0 instead mesh…と警告される事の検証の続き

UE4 Answer HubのLandscape Error after build in Lighting Results [9]によると

f:id:kazuhironagai77:20210502235619p:plain

と書かれています。

先週この情報に基づいてStatic lightingをMoveableに変更したり、Landscapeに使用している草木のMeshにLOD1を追加したりしました。

しかしこの警告は一向に消えませんでした。

今週はもっと簡単な条件を作成してこの警告の原因を解明しようと思います。

以下に示したように最低限のLightしか存在しないmapを作成しました。

f:id:kazuhironagai77:20210502235655p:plain

f:id:kazuhironagai77:20210502235704p:plain

LandscapeにはLandscape4に使用しているMaterial InstanceのLandscape4_instを使用しています。

f:id:kazuhironagai77:20210502235720p:plain

この状態でBuild light onlyをすると以下の警告が出ます。

f:id:kazuhironagai77:20210502235735p:plain

この中の光に関係するactorでMobilityを変えられるのは、

  • Directional light
  • Sky light

だけです。

これらのMobilityを

f:id:kazuhironagai77:20210502235804p:plain

f:id:kazuhironagai77:20210502235818p:plain

に変えてBuild light onlyにすると

f:id:kazuhironagai77:20210502235947p:plain

同じ警告が表示されます。

どうやらlightのMobilityを変化させてもこの警告は無くならないようです。

となるとFoliageに使用している草木用のstatic mesh全てを調べる必要がありますね。

Material のLandscape4の

f:id:kazuhironagai77:20210503000004p:plain

を見ると以下の二つのLandscape Grass Typeが使用されています。

f:id:kazuhironagai77:20210503000036p:plain

Landscape4_Foliageから見ますと、

f:id:kazuhironagai77:20210503000052p:plain

4種類の草木用のStatic meshを使用しています。

試しにこの三番の木を外してみます。

f:id:kazuhironagai77:20210503000111p:plain

3番を無くしたLandscape4_Foliageを作成しました。

f:id:kazuhironagai77:20210503000127p:plain

このLandscape4_FoliageをGrassのLandscapeに使用します。

全部Compileし直すみたいで時間がかかります。

f:id:kazuhironagai77:20210503000146p:plain

出来ました。

f:id:kazuhironagai77:20210503000208p:plain

木が消えています。

Build light onlyをします。

f:id:kazuhironagai77:20210503000229p:plain

あれ。警告が出て来ません。

ひょっとしてこの木が問題だったんでしょうか?

先程、消した木を戻します。

この機にLOD1を追加すれば良いんでしょうか?

f:id:kazuhironagai77:20210503000254p:plain

調べたんですが、LOD1が元々備わっていないと追加出来ないみたいです。

あれ?

警告が消えています。

Build light onlyをもう一回して確認します。

警告が出て来ません。

調べたら先程の木のLOD SettingsのNumber of LODsの数字が1に変わっていました。

f:id:kazuhironagai77:20210503000333p:plain

以下に元々の値を示します。Number of LODsの値は2です。

f:id:kazuhironagai77:20210503000354p:plain

ひょっとして、この数字が2になっていたからこのStatic meshはLODが2個あるはずと勘違いされて警告が発せられていたんでしょうか?

分かりませんが、Landscape4で試してみます。

Landscape4で木の設定を上記と同じにしてbuild light only をします。

凄い時間がかかりました。

以下の警告が表示されましたが前の警告は表示されませんでした。

f:id:kazuhironagai77:20210503000512p:plain

以下に示したLightmass Importance Volumeを追加すればいいんでしょうか?

f:id:kazuhironagai77:20210503000529p:plain

まあ。この警告は後で対応します。

Ch4_3 で試してみます。

Foliageに使用している木のLOD SettingsのNumber of LODsの数字を1に変えました。

f:id:kazuhironagai77:20210503002019p:plain

これでBuild light onlyをします。

以下の結果になりました。

f:id:kazuhironagai77:20210503002050p:plain

Building 12の警告は昔からありました。

Landscape_0 instead mesh…という警告は完全に無くなりましたね。

これが正しい解決方法なのかは分からないですが、兎に角、警告は消えました。

一応、Ch4_3 のLandscape4でもbuild light only をやってみます。

f:id:kazuhironagai77:20210503002118p:plain

別なProjectで試した時と全く同じ結果でした。

Landscape_0 instead mesh…という警告を取り除くという目的は、一応は達成出来ました。

しかしNumber of LODsとは何なんでしょうか?

分からない時はカーソルを乗せるです。

f:id:kazuhironagai77:20210503002139p:plain

と言う事は、LOD1を作成しないように設定した訳ですね。

カメラから、あまり遠くの木を生成する事はないのでこれでも良い気がします。

今回はここまでとして、Lightmass Importance Volumeについての警告は来週解決します。

4. Effect(魔法陣)をWarp Gateに追加する。

以下のActorにEffectで魔法陣を追加しようと思っています。

f:id:kazuhironagai77:20210503002223p:plain

Ch4_3 は4.24で作成しているのでCascade Particle Systemを使用します。

Magic Aura Effect - Particle System - [UE4 Tutorial] [10] を使用してそのまま作成するつもりでしたが、Niagaraは基礎をしっかり勉強したので一応何をやっているのか理解出来ました。

やっぱりCascade でも一応基礎は勉強すべきかもしれませんね。

先週、見つけた公式のDocumentであるCascade Particle System [11]ですが

f:id:kazuhironagai77:20210503002239p:plain

こちらのDocumentのうち一つ二つを先に読んでみる事にします。

4.1 Key Particle Conceptsを勉強する

Cascade Particle System [11]の中から全体像を把握するための最適なDocumentを選択するとしたらKey Particle Concepts [12] ですかね。

まずこれを読んでみます。

f:id:kazuhironagai77:20210503002303p:plain

まあ当然ですがDocumentもちょっと古いです。それはしょうがないですね。

<A Modular Approach to Particle Effects

CascadeはModule 方式でParticle Systemを作成しているそうです。

Module 方式とは、私が理解した範囲では、一つのModuleが、一つの振る舞いとその振る舞いを決定する最低限のPropertyを担当します。そして必要に応じてModuleを足していく方式の様です。

<<Default Modules>>

ただし以下に示したModuleはDefaultで入っています。

f:id:kazuhironagai77:20210503002332p:plain

以下のような説明がありました。

  • Required:Particle systemを作成するのに絶対必要なParameterを管理するModuleだそうです。気のせいかもしれませんが過去にこのModuleを消して使用した事があったような…
  • Spawn:どのくらいの速度でEmitterからParticleが生成されるのかを管理するModuleだそうです。
  • Lifetime:Particleの寿命を管理するModuleだそうです。
  • Initial Size:Particleが生成された時のサイズを管理するModuleです。
  • Initial Velocity:Particleが生成された時の速度を管理します。
  • Color Over Life:Particleの色の管理を担当します。

やっぱりDocument読んで良かったです。

これだけでもCascadeの全体像をかなり把握出来ました。今まではHow to物のTutorialしか見た事なかったので、理由が分からないまま、単にTutorialをコピーしていました。

もっと速いうちに公式のDocumentを読むべきでした。

ちょっと反省しています。

<<Module Categories>>

それぞれのModule の振る舞いを管理するために同じような振る舞いをするModuleはCategory内でまとめられているそうです。これはNiagaraと同じか似たSystemですね。

Documentに載っていたCategoryの内、幾つかを以下に示します。

f:id:kazuhironagai77:20210503002423p:plain

Cameraなんて、Particleにカメラをつける事が出来るのかと驚いてたら、解説にParticleのカメラに対しての動作を決めるModule達をまとめているCategoryだそうです。

<<Initial vs. Over Life>>

読んで字のごとしでした。

<<Module Time Calculation>>

時間の経過に基づいて変化するModuleは、絶対時間で管理されるタイプと相対時間で管理されるタイプがあるそうです。

<<Emitters, Particle Systems, and Emitter Actors>>

それぞれの名称が何を指しているのかを説明しています。

Emitterは以下のヤツです。

f:id:kazuhironagai77:20210503002505p:plain

沢山のModuleを管理しています。

Particle systemはそのEmitterを編集出来るアセットですね。以下に実際のParticle systemを示しました。

f:id:kazuhironagai77:20210503002521p:plain

f:id:kazuhironagai77:20210503002528p:plain

最後のEmitter Actorsが何を指しているのか今一分かりません。作成したParticle systemを付加するActorの事を指しているのでしょうか?

<Particle Calculation

計算の順番についてです。

以下に示した様に実際のParticle systemではEmitterも一個ではなく沢山あります。

f:id:kazuhironagai77:20210503002559p:plain

この中でEmitterは左から右へ計算し、Moduleは上から下に計算するそうです。

非常に分かり易いです。

<Emitter Types

Emitterにも色々なタイプがあるそうです。先程の例ではMesh Data タイプのEmitterが使用されていました。

f:id:kazuhironagai77:20210503002624p:plain

このタイプのEmitterはParticle の代わりにMeshを放出するそうです。

<Parameters

それぞれのModuleにParameterがあるのに、一体何の話をしているのかと思ったら、BPなどの別な場所とのデータのやり取りをする機能のようです。

細かい内容は実際に使用する時に勉強します。

<Lit Particles

どうやらParticleは光らせる事も出来るみたいです。しかしそれをするためには2つ条件を守らないといけないそうです。

<Levels of Detail (LODs)

なるほど。最初は何でParticle systemにLODが関係しているんだと思いましたが、説明を読んだら納得です。Particle systemは計算コストが非常に高いです。ので遠くにある時は積極的に計算コストを減らすためにLODを活用しましょうと言う事のようです。

この遠くの距離を決定するためのParameterを管理しているのがここのようです。

<Distributions

Particle systemでは、データの塊を独特な方法で取り扱います。その色々な取り扱いのタイプを表すのがDistributionsのようです。

<まとめ>

後半部はいじった事がない部分なので非常に簡単にまとめました。でも全体像はかなり掴めました。

全体像を掴んだ上での感想ですが、これならデザイナーでもある程度地頭が良い人なら使いこなせそうですね。

錬金術師系戦士の出番はないかもしれませんね。残念です。

4.2 Magic Aura Effect - Particle System - [UE4 Tutorial] [10] を利用して魔法陣を作成する。

Magic Aura Effect - Particle System - [UE4 Tutorial] [10]の説明通りに魔法陣を作成します。

Tutorialで使用している魔法陣用のTextureは自分で作成しました。

f:id:kazuhironagai77:20210503002720p:plain

そしたらdownload出来ます。と

f:id:kazuhironagai77:20210503002735p:plain

DesignからMaterialを作成します。

以下の様な実装をします。

f:id:kazuhironagai77:20210503002751p:plain

f:id:kazuhironagai77:20210503002758p:plain

f:id:kazuhironagai77:20210503002805p:plain

Duplicateします。

Blast用に改変します。

f:id:kazuhironagai77:20210503002823p:plain

赤で囲った部分をTexture Sampleに掛けます。

f:id:kazuhironagai77:20210503002837p:plain

するとBlastのリングが回転し始めました。

f:id:kazuhironagai77:20210503002859p:plain

RotatorというNodeを使用するとこういう事が出来るんですね。覚えておきます。

f:id:kazuhironagai77:20210503002917p:plain

See full documentationをクリックすると公式のDocumentのRotator [13]のサイトに飛びました。

f:id:kazuhironagai77:20210503002933p:plain

詳しく勉強するのは後にします。

Particle Systemを作成します。名前はAura_Circleです。

f:id:kazuhironagai77:20210503002950p:plain

あれ、今気が付きましたが名前、魔法陣じゃなかったです。

というか魔法陣の英語名知らないです。

一応、調べておきますか。

何と、Wikipediaの魔法陣のページによると、魔法陣は水木しげる先生の創作らしいです。本当は魔法円と言うらしいです。英語名はMagic circle。そのままですね。

それよりも、何でしょうか?実際の魔術って?

f:id:kazuhironagai77:20210503003014p:plain

やばいページを開いてしまったようです。見なかった事にして先に進みましょう。

Aura_Circleを開きます。

先程、Key Particle Concepts [12]で勉強した内容が表示されています。

f:id:kazuhironagai77:20210503003034p:plain

多少でも仕組みが分かってくるとEditorを見るだけでも楽しいです。

Particle EmitterのModule であるRequiredのMaterialを先程作成したDesign_Matに変更しました。

f:id:kazuhironagai77:20210503003050p:plain

Reviewの発生し上昇しているparticleがDesign_Matに変更しました。

f:id:kazuhironagai77:20210503003104p:plain

このMaterialは動かないのでInitial Velocity Moduleを削除します。

f:id:kazuhironagai77:20210503003121p:plain

以下のようになりました。

f:id:kazuhironagai77:20210503003135p:plain

これって動いていないだけで大量に発生はしているんでしょうね。

Initial Size moduleのDistributionをDistribution Vector Constantに変更してConstantの値を400, 400 400にセットしました。

f:id:kazuhironagai77:20210503003153p:plain

Distributionについて調べてみます。

もうどこを見ればこのModuleについての解説が書かれているか分かっています。

f:id:kazuhironagai77:20210503003211p:plain

Size Modules [14] です。

f:id:kazuhironagai77:20210503003227p:plain

はい。ありました。

f:id:kazuhironagai77:20210503003244p:plain

うーん。これしか説明していませんね。これぐらいなら大体想像していた通りです。

Distributionの意味が知りたいんです。

[UE4] WTF is.. Cascade's Initial size Module [15] で少しだけ説明されていました。

f:id:kazuhironagai77:20210503003300p:plain

f:id:kazuhironagai77:20210503003306p:plain

では、生成されるParticleのサイズは一定です。

f:id:kazuhironagai77:20210503003324p:plain

f:id:kazuhironagai77:20210503003331p:plain

では生成されるParticleのサイズは指定した範囲でバラバラになります。

おお、分かり易い。

と思ったら「Curveは使わないから説明しない。」で終わってしまいました。

f:id:kazuhironagai77:20210503003349p:plain

ここまで来てちょっと思い出してきたんですが、ひょっとすると、このMagic circle、昔作成した事があったかもしれません。

Blogを見返しましたが該当する記事は見つかりませんが。

まあ良いです。このまま続行します。

頼みの綱の「分からない時はカーソルを合わせる。」も役に立ちません。

f:id:kazuhironagai77:20210503003405p:plain

何なんですか?

Distribution Vector Constant Curveの説明がDistribution Vector Constant Curveって。こんなの初めて見ました。

Googleで検索してたら出て来ました。

公式のDocumentのDistributions [16 ]で説明されていました。

f:id:kazuhironagai77:20210503003425p:plain

Distributionsって、先程Key Particle Concepts [12]で勉強した所じゃないですか!

f:id:kazuhironagai77:20210503003445p:plain

Distributionsってこの部分のデータを扱う機能を指していたんですね。やっと分かりました。

因みに、Distribution Vector Constant Curveの機能は、時間によってParticleのサイズを変化させると説明されていました。

f:id:kazuhironagai77:20210503003502p:plain

もう完璧に歯車が噛み合いました。Cascade Particle Systemの骨格が頭に入りました。

先に進みます。

こんどはSpawn moduleのDistributionです。

f:id:kazuhironagai77:20210503003516p:plain

公式のDocumentのDistributions [16 ]によればDistribution Float Constantは一つの値をずっと使用する時に選択するDistributionだそうです。

f:id:kazuhironagai77:20210503003532p:plain

今回は0を選択しましたが、これって最初の一回だけ生成すると言う意味なんでしょうか?それとも全く生成しないと言う事でしょうか?

Spawn moduleのBurstのBurst Listの+をクリックして要素を一個作成します。

f:id:kazuhironagai77:20210503003611p:plain

Countを1にセットします。

そしたらまたDesignのイメージが表示されました。今度は一秒毎ぐらいに点滅しています。

f:id:kazuhironagai77:20210503003627p:plain

Burstって何なんだよ。

…勿論調べます。

f:id:kazuhironagai77:20210503003652p:plain

はい、ありました。公式DocumentのDefault Required and Spawn Modules [17] です。

f:id:kazuhironagai77:20210503003709p:plain

と説明されていました。

と言う事は、Burst ListのCountを1にしたのは、一回のEmitで一個のParticleを放出しろと言う意味だったんですね。

f:id:kazuhironagai77:20210503003726p:plain

しかしこの説明だとSpawnとBurstの違いが分かりません。

そっちをもう少し調べてみます。

分かりませんでした。

全然、検索に引っかかりません。この公式のDocument以上の内容はネット上には存在していないのかもしれませんね。

ただカンですが、SpawnとBurstは時間の管理の仕方が違うのかもしれません。Key Particle Concepts [12]のModule Time Calculationで勉強した絶対時間と相対時間に関係している気がしています。この辺が理解出来た後でここは勉強し直す事にします。

今度はLifetime Moduleです。

Lifetimeを以下の様にセットしました。

f:id:kazuhironagai77:20210503003755p:plain

0にすると永遠に持続するそうです。

Lifetime Moduleについても調べておきます。

f:id:kazuhironagai77:20210503003813p:plain

はい。公式のDocumentも直ぐに見つかりました。Lifetime Modules [18] です。

f:id:kazuhironagai77:20210503003833p:plain

ところで、The initial lifetime of a particleのInitialってどういう事なんでしょう?

A particleを人間に例えるならば、赤ちゃんが生まれた時に持っている寿命って事でしょうか?となると人生の途中で殺されたりする事とかは、ここでは設定されていないって事でしょうか?そしてそれは別なModuleが管理したりしているんでしょうか?

initial一個でとても怖い意味を暗示していますね。

0にすると永遠に持続する事に関しては説明されていませんね。

何かEffectが、ぼやっとするからそれを直しますと言っています。

Required moduleのEmitter Loopsを1にセットしました。

f:id:kazuhironagai77:20210503003848p:plain

Emitter Loopsにカーソルを乗せたらEmitter Loopsの機能について説明されました。

f:id:kazuhironagai77:20210503003903p:plain

更にUse Local Spaceにチェックを入れました。

f:id:kazuhironagai77:20210503003917p:plain

以下の様に説明されています。

f:id:kazuhironagai77:20210503003942p:plain

Use Local Spaceにチェックを入れるとImageのラグなしで移動出来ると説明しています。が、自分で動かした限りでは変わりませんね。

今度は、このParticleを地面に固定します。

Orientation Category のLock Axis Moduleを追加します。

f:id:kazuhironagai77:20210503004001p:plain

Z軸に固定します。

f:id:kazuhironagai77:20210503004016p:plain

View portの映像が以下の様になりました。

f:id:kazuhironagai77:20210503004032p:plain

今度はColor Over Life Moduleです。

f:id:kazuhironagai77:20210503004046p:plain

ここでもConstantを選択しています。Life Time の色を決定するなら変化した方が綺麗だと思います。ので後でこのDistributionは変える事にします。

今度はこのParticleに回転を追加します。

そのためにはRotation Rate CategoryからInitial Rotation Rate Moduleを追加します。

f:id:kazuhironagai77:20210503004102p:plain

Distributionを固定値にセットして値は0.2にしました。

f:id:kazuhironagai77:20210503004119p:plain

Distributionを固定値にセットしましたが今回のケースは納得ですね。魔法陣の回転速度が変化する必要はないでしょうから。

ここまでで魔法陣の作成は終わりです。

この後はこの魔法陣にEffectを追加します。

新たなEmitterを追加しました。

f:id:kazuhironagai77:20210503004136p:plain

Required ModuleのMaterialにBlast_Matをセットしました。

f:id:kazuhironagai77:20210503004152p:plain

大体理解出来たので、こっちは結果だけ記録するようにします。

f:id:kazuhironagai77:20210503004208p:plain

正直これで十分です。

自分で作成した魔法陣のデザインに変更しました。

f:id:kazuhironagai77:20210503004228p:plain

これを追加します。

f:id:kazuhironagai77:20210503004247p:plain

以下の様になりました。

f:id:kazuhironagai77:20210503004304p:plain

結構負担が大きいかもしれません。計算のコストも後で検討します。

5. Landscape4にもっとモンスターを配置する。

どうやって配置するモンスターの数と位置を決定しようかと思っていたのですが、分かりました。まずは静的にモンスターを配置して試します。

Monsterの縄張りを以下の様に決めました。

f:id:kazuhironagai77:20210503004417p:plain

最初の縄張り内にモンスターを配置します。

f:id:kazuhironagai77:20210503004433p:plain

ここは、テレポートしたての冒険者が準備が整う前に殺そうとするモンスター達のたまり場です。

以下のようにモンスターを配置してみました。

f:id:kazuhironagai77:20210503004450p:plain

試しにモンスターを倒してみたら、静的に配置したため、戦闘が終わっても倒したモンスターが復活してもう一回襲って来ました。

やっぱり動的にモンスターを配置する必要があります。

5.1 動的なモンスターの生成方法の復習

Map1のBPを見ると以下の部分でモンスターを動的に生成しています。

f:id:kazuhironagai77:20210503004516p:plain

これみるとかなり簡単そうですね。

5.2 Landscape4内で動的なモンスターを生成する。

Landscape4に生成するモンスターを管理するためのarrayを作成します。

f:id:kazuhironagai77:20210503004539p:plain

静的に配置しているモンスターの中で赤で囲ったモンスターをこのArrayに追加します。

f:id:kazuhironagai77:20210503004557p:plain

f:id:kazuhironagai77:20210503004606p:plain

Landscape4のBPにモンスター発生のためのコードを実装します。

f:id:kazuhironagai77:20210503004623p:plain

Spawned Monster()関数の中身です。

f:id:kazuhironagai77:20210503004640p:plain

Map1のMonster生成の部分では以下の赤い四角で囲った部分が何をやっているのか不明です。

f:id:kazuhironagai77:20210503004655p:plain

多分、必要ないです。のでLandscape4のモンスター作成の実装ではこの部分は削りました。

テストします。

f:id:kazuhironagai77:20210503004711p:plain

またこれが表示されています。

取りあえず無視しておきます。

f:id:kazuhironagai77:20210503004729p:plain

バグを一個見つけました。武器屋で武器を買った後にPause画面から戻るとカーソルが消えています。

これも後で直します。

f:id:kazuhironagai77:20210503004744p:plain

Landscape4にワープします。

普通にモンスターが生成されて直ぐに戦闘になりました。

f:id:kazuhironagai77:20210503004801p:plain

倒した後で、戦闘画面からLandscape4に戻ってもモンスターが消えていません。その部分を直します。

倒したモンスターを消去する関数はRPGGameModeにあるRemove Defeated Monsterです。

f:id:kazuhironagai77:20210503004816p:plain

実装を見てみます。

f:id:kazuhironagai77:20210503004830p:plain

ここが原因ですね。

f:id:kazuhironagai77:20210503004846p:plain

倒したモンスターを消去する時、Map1 用のMonster Spawn Dataしかチェックしていません。

直します。

RPGGameModeのRemove Defeated Monster関数を改良してRemove Defeated Monster from Map1とRemove Defeated Monster from Landscape4を作成しました。

f:id:kazuhironagai77:20210503004906p:plain

テストします。

モンスターを倒した後、Landscape4に戻って来ました。

f:id:kazuhironagai77:20210503004922p:plain

倒したモンスターは消えています。

成功です。

5.3 Landscape4内の他のモンスターも動的に生成する。

Monster Spawn Data_Landscape4に他のモンスターのデータを追加します。

f:id:kazuhironagai77:20210503004946p:plain

f:id:kazuhironagai77:20210503004953p:plain

これで十分なはずです。

テストします。

全部のモンスターを倒してみました。倒した後は消滅しました。

f:id:kazuhironagai77:20210503005015p:plain

モンスター達も適度にばらけて居てずっと戦闘と言うわけでもなく、かといって緊張感がないわけでもありません。

かなりバランスはイイと思います。

残りのモンスターの配置は後で考えます。

6. Landscape4からMap1に戻るためのWarp Gateを作成する。

W_WarpGateウィジェットのワープ先のLevelを決める変数を作成します。

f:id:kazuhironagai77:20210503005052p:plain

f:id:kazuhironagai77:20210503005100p:plain

次にWarpGateKeeperBP内にワープ先のLevel名を保持する変数を作成します。この変数はInstance毎に値が変えられるようにします。

f:id:kazuhironagai77:20210503005117p:plain

更にThirdPersonCharacter内にもワープ先の名前を保持する変数を作成します。

f:id:kazuhironagai77:20210503005133p:plain

WarpGateKeeperBP内でPlayer が操作するキャラがボックス内に侵入した時に、WarpGateKeeperBPのWarp To変数に保持している値を、ThirdPersonCharacterのWarp Gate Nameにパスします。

f:id:kazuhironagai77:20210503005149p:plain

ThirdPersonCharacter内でW_WarpGateウィジェットを作成する時に、Warp Gate Nameの値をW_WarpGateウィジェットWarp Gate Nameにパスします。

f:id:kazuhironagai77:20210503005206p:plain

その結果、ワープする先はWarpGateKeeperBPのそれぞれのInstanceで決めたLevelになるはずです。

f:id:kazuhironagai77:20210503005222p:plain

テストします。

Landscape4に配置したWarpGateKeeperBPです。

f:id:kazuhironagai77:20210503005238p:plain

Warp toの値をMap1に変更します。

f:id:kazuhironagai77:20210503005256p:plain

Landscape4のVillage Nameも考えないといけませんね。

こっちはMap1のWarpGateKeeperBPです。

f:id:kazuhironagai77:20210503005315p:plain

勿論、Map1のWarp toの値はLandscape4にセットします。

f:id:kazuhironagai77:20210503005329p:plain

テストします。

Map1からLandscape4にワープします。

f:id:kazuhironagai77:20210503005347p:plain

出来ました。

f:id:kazuhironagai77:20210503005400p:plain

今度はLandscape4からMap1へワープします。

f:id:kazuhironagai77:20210503005415p:plain

セリフが一緒です。これは後で直します。

Map1に戻って来ました。

f:id:kazuhironagai77:20210503005431p:plain

出来ましたね。

ワープに関しては、今週はここまでにしておきます。

7. 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する。

ずっと前に作成した地図からワープ出来る機能があります。

f:id:kazuhironagai77:20210503005504p:plain

それとは別に町から外の世界へワープ出来る機能も作成しました。

f:id:kazuhironagai77:20210503005521p:plain

はい。もうアイデアがあります。地図は町から町へワープ出来ますが、一端外の世界へ出たら使用できません。

  • Warp Gate:町から外の世界、外の世界から町
  • 地図:町から町

これで使い分けます。

8. まとめと感想

今週は、以下の事を行いました。

  • Niagaraの勉強の続き
  • Landscape_0 instead mesh…と警告される事の検証
  • Cascade Particle Systemの勉強
  • Warp GateEffect(魔法陣)を追加する
  • Landscape4にもっとモンスターを配置する
  • Landscape4からMap1に戻るためのWarp Gateを作成する
  • 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する

Niagaracascadeの勉強は楽しかっただけでなくかなり全体像が掴めるようになりました。多分来週も勉強します。Landscape…の警告は消す事が出来ましたがもう少しLODについての勉強が必要な事を知りました。

来週の予定は

  • Niagaracascadeの勉強
  • モンスターをもっと配置する
  • 武器屋のバグの直し
  • ワープゲートのセリフの直し
  • Lightmass Importance Volume…の警告の直し
  • Effectのコストについての勉強
  • 魔法陣の改良

などをやる予定です。

9. 参考文献(Reference

[1] Epic Games. (n.d.-m). Niagara Visual Effects. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/index.html

[2] Epic Games. (n.d.-j). Niagara Overview. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/Overview/index.html

[3] Epic Games. (n.d.-i). Niagara Key Concepts. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/NiagaraKeyConcepts/index.html

[4] Epic Games. (n.d.-k). Niagara Quick Start. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/QuickStart/index.html

[5] CGHOW. (2020, September 1). HLSL in UE4 Niagara & Material Custom node | Unreal Engine Niagara HLSL [Video]. YouTube. https://www.youtube.com/watch?v=SkkZvf3rpwo

[6] Houdini. (2020, November 17). Houdini to Niagara | Overview [Video]. YouTube. https://www.youtube.com/watch?v=jA3uAxT5FhM

[7] Epic Games. (n.d.-e). Events and Event Handlers Overview. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/EventHandlerOverview/index.html

[8] gameDev Outpost. (2020, July 30). UE4 - Introduction To Niagara [Video]. YouTube. https://www.youtube.com/watch?v=VEG-Xp92cBk

[9] Epic Games. (n.d.-g). Landscape Error after build in Lighting Results - UE4 AnswerHub. UE4 ANSWERHUB. Retrieved May 2, 2021, from https://answers.unrealengine.com/questions/343146/landscape-error-after-build-in-lighting-results.html

[10] UnrealCG. (2017, July 19). Magic Aura Effect - Particle System - [UE4 Tutorial] [Video]. YouTube. https://www.youtube.com/watch?v=PEb7ujDkP44&list=PLnfzvYOawOqArAASPfH5rOErJNnLkk7Fw&index=5

[11] Epic Games. (n.d.-a). Cascade Particle Systems. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/index.html

[12] Epic Games. (n.d.-f). Key Particle Concepts. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/Overview/index.html

[13] Epic Games. (n.d.-b). Coordinates Expressions. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Materials/ExpressionReference/Coordinates/index.html?utm_source=editor&utm_medium=docs&utm_campaign=rich_tooltips#rotator

[14] Epic Games. (n.d.-j). Size Modules. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Size/index.html

[15] Yoeri -Luos- Vleer. (2016, June 19). [UE4] WTF is.. Cascade’s Initial size Module [Video]. YouTube. https://www.youtube.com/watch?v=4iATVPAWWc0

[16] Epic Games. (n.d.-d). Distributions. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/Basics/Distributions/index.html

[17] Epic Games. (n.d.-c). Default Required and Spawn Modules. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Required/index.html

[18] Epic Games. (n.d.-h). Lifetime Modules. Unreal Engine Documentation. Retrieved May 2, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Lifetime/index.html

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する  Effectの勉強など

f:id:kazuhironagai77:20210425230912p:plain

<前文>

英語の勉強で気を付ける事

何回もここで書いていますがMinimal pairのアプリを作成しています。最近はそのアプリに使用するMinimal pairの例を探しています。日本人が苦手な/ʒ/と/dʒ/のMinimal Pairを作成しようとしたらpledgerと pleasure、 legion と lesion、jock とJacques、そしてvirgin とversionしか存在しないらしくて困っています。

Minimal pairによる発音の聞き分けの訓練はかなり効果が高いです。ので英語の勉強をしている全ての人達のお役に立てるアプリになると確信しています。

このアプリを作成していて気が付いたんですが、発音の勉強をする人には、私の様にアメリカに10年も暮らしていて通常の英語には全く問題ないですが、自分の英語の訛りを直したい人だけでなく、英語の勉強を始めたばかりの人も結構います。

正しい発音を英語学習の初期に覚えるのは、本当に英語を身に着けたい人には大変有利に働くと思います。

そういう初心者の人達に捧げるアドバイスとして、私自身が英語の勉強でここを気を付けるべきと思う事を列挙しました。

英語圏で暮らす必要がある>

どの程度、英語を身に着けたいのかにもよりますが、いわゆるバイリンガルレベルになりたいのなら絶対に英語圏で生活する必要があります。最低5年です。勿論、5年英語圏で暮らしたら、絶対バイリンガルレベルに成れると言っている訳ではありません。まれに日本で勉強しただけで英語ペラペラになったと主張する人がいますが、両親がアメリカ人で日本の米軍基地で育ったなどの特別な例外を除けばありえません。日本で勉強出来る英語の範囲は限られています。

この事を踏まえた上で私が言いたい事は2点です。

英語圏で生活する必要がある以上、日本にいる間は出来るだけ貯金すべきです。高額の英語教材を買ったり高額な英語教室に通ったりする必要は全くありません。そういう人達は全て詐欺だと思っていないと英語圏の国に行く前に金銭面で挫折する事になります。

イギリスやカナダは知りませんがアメリカでは有色人種は簡単に撃ち殺されます。裁判になっても大体、無罪ですので引き金も引きやすいんでしょうね。つまり冗談ではなく本当に殺される可能性があります。

これはずっとと言うわけではなく、地元の人間はどこが危ないとかどの時間が危ないとかを知っていて、それさえ守ればほとんど日本で暮らすのと同じくらい安全です。しかしそれを理解出来るようになり地元の人と同じような行動が取れる様になるまで2年はかかります。その2年くらいは本当に殺される可能性があります。

腹を括るしかありません。

この腹を括る事が出来ないのなら英語学習は趣味に留めておくか、いっその事、きっぱり止めて別な分野の勉強をやるべきです。腐った世の中ですが、あなたが自分の命を賭けてでもやりたい魅力的な事は必ずあります。その時のために運とかお金はとって置くのも選択の一つです。

<資本家に成れない!>

英語圏が移民で成り立っていると言っても実際に権力を握っている人達は全く変わりません。所謂WASPと呼ばれる人達です。彼らがアジア人に望んでいるのは彼らの使用人に成る事です。幾ら命賭けて英語の勉強します。と言っても別に奴隷に成りたい訳ではありません。使用人じゃなくて使用する側に成りたいんです。しかし英語を学習している内にその事を忘れてしまいRobert Kiyosaki氏の言う従業員タイプや専門職タイプになってしまいます。

それの何が悪いと思う人もいるかもしれませんが、従業員タイプや専門職タイプの人は社会全体が直面する問題は解決出来ないんです。

分かり易い例で説明しますが、クラスでいじめがあったとします。従業員タイプの子は目立たない事でいじめられないようにします。専門職タイプの人は勉強やスポーツで優秀に成る事でいじめられないようにします。つまりいじめそのものを無くすためにはどうしたら良いのかは全く考えないんです。

いじめそのものを無くすためにはどうしたら良いのかを考えられるは、投資家タイプと企業家タイプつまり資本家だけなんです。

英語の勉強を学校で強制されてするのではなく、自らやりたくてする子は資本家のうちの企業家タイプに成れる可能性を秘めていますし、リスクをとって海外留学するタイプの子は資本家のうちの投資家タイプになれる可能性があります。

投資家タイプと企業家タイプは非常にレアなだけでなく、成功した時の見返りもとんでもないです。

自分で自分の可能性を摘み取ってしまうのは勿体ないです。

発想の柔軟性を失っていない事と、問題の答えを探す時に自分だけが助かる事を考えていないか、3カ月に一回くらいは自問自答しましょう。

<努力は常にあなたの味方か?>

日本では、頑張っていると全部OK みたいな風潮がありますが本当でしょうか?

間違った方向に頑張るのは怠けているより問題を100倍も深刻にします。例えば発音ですが、間違って覚えた発音が癖になると直すのに初心者の何十倍も大変になりますし、究極的には無理になります。

この事を表した英語の格言に「練習は完璧を作らない。完璧に正しい練習だけが完璧を作る。」と言うのが有ります。この格言、昔は「練習は完璧を作る。」だったのですが、最近になり、それは間違っている。正しくは「完璧に正しい練習だけが完璧を作る。」と修正されています。

スポーツなどのフォームを身に着ける為には、何百回も反復練習する必要があります。しかし身に付いたフォームが正しくなかったとき、努力する前より成績が落ちる結果に成ります。楽器の演奏でも同じです。

個人的な例ですが、私中学生の時に子音を「シイン」と呼んで国語の先生からみんなの前で「シインじゃないシオンだ!」と怒鳴られた事があります。

この国語の先生、読書の量をいつも自慢していたんですが、私の方がもっと本を読む事を知って嫉妬していたみたいでとんでもない怒鳴り方で、その時私はとても萎縮してしまって良く調べもせずに自分が間違っていたと思い込んでしまいました。「シイン」が正しい発音だと知ったのは実に数年も後の事でした。ところが「シイン」が正しい発音だと知った後も治らないです。今でもたまに「シオン」と発音してしまいます。

今はネットで何でも調べられますしYouTubeでは映像付きで学習する事も可能です。練習を頑張るのではなく完璧に正しい練習が何であるのかを見つける事を頑張るべきです。

その中で完璧に正しい練習方法が見つからないなら英語の発音の練習は価値がないとなったらそれはそれで良いんです。更に言えば完璧に正しい練習方法が見つからないから英語の勉強自体を2、3カ月止めるのも全然有りなんです。

休んだり、サボったりする事は悪い事かもしれませんが、間違った努力を続けるよりは100倍マシだと言う事を理解して下さい。

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

<本文>

1.今週の予定

先週の予定通り以下の事を行っていきます。

  • バグの直し
    • 戦闘中にアイテムを使用した時のセリフの直し
    • Map1でBuildするとLandscape_0 instead mesh…と警告される
  • Effectの勉強
  • Effect(魔法陣)をWarpGateに追加する。
  • Landscape4にもっとモンスターを配置する。
  • Landscape4からMap1に戻るためのWarpGateを作成する。
  • 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する。
  • Map1の家の影が真っ暗な理由をConstructing Believable Environmentで勉強したGlobal Illuminationと絡めて勉強する。

後、先週のLightingの勉強で途中で投げ出してしまったんですが、何を学んだのかをもう一回まとめ直します。

2.先週のLightingの復習

先週、突然「もうenvironmental artistの勉強はイイや。」と言う気分になって、途中で投げ出してしまいました。勉強した二つのtutorialが、Indirect lighting というかGlobal Illuminationというか全く同じ分野の説明していました。

同じ事を、別な説明で解説しているので、後でblogを見直した時に分かり易いように、二つの説明を比較してまとめておくべきと思いました。

まずStationary lightについての解説です。

Stationary lightはMoveableとStaticの間で部分的にLightの影響をLight mapにBakeします。

Becoming an Environment Artist in Unrealの説明ですが、先週のBlogを見ると

f:id:kazuhironagai77:20210425231244p:plain

と説明してあったとまとめてありました。

最初からあれですが、明るさと光の色はLight mapに記録と逆に記憶していていました。この先週のBlogが間違って記録してしまったのかはたまた私の記憶が間違っているのか?ちょっと確認します。

f:id:kazuhironagai77:20210425231315p:plain

あってました。

先週、書き忘れていますが、Stationary lightはmoveable objectに対して光を追加出来るそうです。

Constructing Believable Environmentにおける説明です。

f:id:kazuhironagai77:20210425231348p:plain

こちらももう一度tutorialをチェックします。

Understanding Lightmass - Baking Checklistのところです。

f:id:kazuhironagai77:20210425231412p:plain

f:id:kazuhironagai77:20210425231418p:plain

はい。言っていました。

後、先週の時点では曖昧な理解しかしていなかったんですが、Lightとobjectの両方にStatic、Stationary、そしてmoveableがあります。ここで解説されているのは両方ともLightの事です。この事について先に考察します。

以下に示した様にDirectional lightとCubeそしてその影を移すPlaneのみを配置したLevelを作成します。

f:id:kazuhironagai77:20210425231439p:plain

まずObjectがStaticでlightがStatic、Stationary、そしてmoveableの場合を試します。

Object: Static、Light: Static

Cubeを動かすとCubeの影は動きません。Cubeの影がBakeされている証拠です。

f:id:kazuhironagai77:20210425231500p:plain

Object: Static、Light: Moveable

Cubeを動かすとCubeの影も付いて行きます。Cubeの影がBakeされていない証拠です。

f:id:kazuhironagai77:20210425231533p:plain

Object: Static、Light: Stationary

Constructing Believable Environmentの解説だとIndirect lightのみBakeされるとあります。Cubeの影はDirect lightから生成されているのでCubeを動かしたら影も付いてくると言う事でしょうか?

f:id:kazuhironagai77:20210425231601p:plain

げっ。影が二つ出来ました。

どういう事?

ちょっと慌てましたが、Becoming an Environment Artist in UnrealにあるStationary Lightingの説明にしっかり解説されていました。

f:id:kazuhironagai77:20210425231628p:plain

要するにBakeもするしRun Timeにも計算すると言う事ですね。

あ、分かりました。

昼夜のあるRPGのように太陽そのものが動く場合はDirectional lightをMoveableにする必要があります。高コストですが仕方ありません。

では常に昼であるFall guysみたいなゲームの場合はどうでしょうか?Directional lightは動く必要はありません。ので低コストであるStaticにセットしたいです。しかしStaticにセットするとPlayerの操作するキャラの影が消えてしまいます。CSで3d Graphicsを勉強した人なら常識ですが、影の無いキャラは地面から浮いて見えてしまうんです。なので絶対影は必要です。となると高コストで非常に無駄ですが、Directional lightをMoveableにセットするしかありません。

そこでStationary Lightingの出番です。

一応確認します。

Object: Moveable、Light: Stationary

はい。影はObjectについて動きます。

f:id:kazuhironagai77:20210425231702p:plain

Object: Moveable、Light: Static

Objectの影が消えてしまいました。予測通りです。

f:id:kazuhironagai77:20210425231727p:plain

Object: Moveable、Light: Moveable

動かす前から影の付き方が違うような気がしますが、動かします。

f:id:kazuhironagai77:20210425231751p:plain

Objectと影は一緒に動きます。

f:id:kazuhironagai77:20210425231827p:plain

Directional lightが動かない場合はこの方法は高コストすぎます。

やっぱりそうでした。

今度はCubeそのものの影、いわゆる陰影でいう陰の部分についての考察です。

Stationary Lightingでは以下のような淡い灰色です。

f:id:kazuhironagai77:20210425231851p:plain

Moveable lightingでは

f:id:kazuhironagai77:20210425231912p:plain

真っ黒になってしまいます。

調べたのですが、なぜこの違いが出るのか分かりませんでした。

考えられるのはConstructing Believable Environmentにおける説明であった

f:id:kazuhironagai77:20210425231938p:plain

です。

つまり、Directional lightの光が地面に当たって反射してCubeの陰の部分を照らしています。それをStationary Lightの場合はLight mapにBakeしているのかもしれません。

この仮説を検証するために地面を赤くしました。

すると、

f:id:kazuhironagai77:20210425232002p:plain

Cubeの陰の部分も赤くなりました。地面から反射した光がCubeの陰の部分を照らしているのは間違いないですね。

図らずも先週の疑問の答えも判明しましたね。

f:id:kazuhironagai77:20210425232024p:plain

Directional LightがMoveableなのでObjectは地面からの反射光を受ける事が出来ずに陰の部分が真っ暗になってしまうわけです。

しかしこれって問題もあるんじゃないでしょうか?

CubeがMoveableの場合、地面の色が違う場所に移動する可能性があります。その時、既にCubeに地面からの反射光をBakeしていたらその色を保持したまま移動してしまいますよね。

試してみます。

f:id:kazuhironagai77:20210425232045p:plain

あれ。Bakeされていないじゃん。

f:id:kazuhironagai77:20210425232105p:plain

どういう事?

ああ、分かっちった。

これは語弊があるかもしれないので仮説として説明します。

Constructing Believable Environmentの説明、

f:id:kazuhironagai77:20210425232126p:plain

が間違っているんですよ。

いいですか。

まずIndirect lightの情報だけLight mapにBakeするなら、

この実験で影がBakeされる訳がないんです。

f:id:kazuhironagai77:20210425232149p:plain

このBakeされた影はDirectなLightの情報ですから。

更にIndirect なlightがBakeされるなら

f:id:kazuhironagai77:20210425232213p:plain

これも起きるはずはないです。Cubeのオレンジ色は地面からのIndirectな光の反射の影響なんですから。

この二つの実験結果は、Constructing Believable EnvironmentのStationary lightingの説明である「Indirect lightの情報だけLight mapにBakeする」に矛盾します。

Stationary lightingは先程私が導いた結論、Directional lightが動かない状態のゲームで、キャラの陰影は最大限に表示しつつコストは、Directional lightをMoveableにセットしたよりも低くするために開発されたModeなんです。

それだけ理解すればいいんです。

3.バグの直し

3.1 戦闘中にアイテムを使用した時のセリフの直し

先週見つけた問題ですが、戦闘中にアイテムを使用した際に、要らない事を報告しすぎています。

f:id:kazuhironagai77:20210425232300p:plain

HPが回復した時でMPに変化が無い時は、MPについての報告は要らないですし、逆もまたしかりです。

3.1.1 セリフの実装部の流れを確認する。

まずこのセリフがどのように実装されているかの確認をします。

戦闘中にアイテムを使用すると

f:id:kazuhironagai77:20210425232325p:plain

Use Item in Combat関数が呼ばれます。

f:id:kazuhironagai77:20210425232344p:plain

Use Item in Combat関数の実装部は以下の様になっています。

f:id:kazuhironagai77:20210425232447p:plain

このクラスの変数finishedDesicionがTrueにセットされます。

するとこのクラスの関数、MakeDecision()が呼ばれた時にTrueを返します。

f:id:kazuhironagai77:20210425232503p:plain

この関数はGameCharacterクラスのMakeDecision()関数から呼ばれています。

f:id:kazuhironagai77:20210425232517p:plain

この関数がTrueを返すとRPGGameModeクラスのReportMakeDecision()関数が呼ばれます。

f:id:kazuhironagai77:20210425232553p:plain

RPGGameModeクラスのReportMakeDecision()関数のFunction Specifier の一つがBlueprintImplementableEventなので、BP内で実装しています。

RPGGameModeBPクラスのEvent Report Make Decisionを見ると

f:id:kazuhironagai77:20210425232614p:plain

以下のセリフを表示しています。

f:id:kazuhironagai77:20210425232629p:plain

GameCharacterクラスのMakeDecision()関数は同じクラスのTextFinishTyping()関数が呼ばれることによりTrueを返します。

f:id:kazuhironagai77:20210425232646p:plain

ちなみにText Finish Typing()関数はRPGGameMode() クラスのTextTypingDone()関数から呼ばれます。

f:id:kazuhironagai77:20210425232703p:plain

TextTypingDone()関数は、この関数のFunction Specifierの一つがBlueprintCallableなのでBPから呼ばれます。

f:id:kazuhironagai77:20210425232718p:plain

RPGGameModeBPクラスを見ると、TextTypingDone()関数はEvent Confirm Button is Clickedが発動すると呼ばれています。

f:id:kazuhironagai77:20210425232733p:plain

Event Confirm Button is Clickedは、CombatUIウィジェットの読みましたボタンがクリックされると発動します。

f:id:kazuhironagai77:20210425232747p:plain

f:id:kazuhironagai77:20210425232753p:plain

結局、CombatEngineクラスのTick()関数内のdecisionMade変数がTrueになるので、以下の部分のコードが実行され

f:id:kazuhironagai77:20210425232806p:plain

PhaseがActionに移行します。

Action内では最初にGameCharacterクラスのBeginExecuteAction()関数が実行されます。

f:id:kazuhironagai77:20210425232824p:plain

GameCharacterクラスのBeginExecuteAction()関数内では、RPGGameModeクラスのReportBeginExecuteAction()関数が実行されます。

f:id:kazuhironagai77:20210425232839p:plain

RPGGameModeクラスのReportBeginExecuteAction()関数のFunction Specifierの一つがBlueprintImplementableEventなので実装はBP内で行われます。

f:id:kazuhironagai77:20210425232857p:plain

RPGGameModeBPのReportBeginExecuteAction()をみると

f:id:kazuhironagai77:20210425232912p:plain

以下のセリフを表示し

f:id:kazuhironagai77:20210425232926p:plain

アニメーションをplayしています。ただしItemの使用はアニメーションが無いため、結局何もしていません。

それとは別に以下のコードも実行されています。

f:id:kazuhironagai77:20210425232943p:plain

TestCombatActionItemクラスのBeginExecuteAction()関数の実装部をみると

f:id:kazuhironagai77:20210425232958p:plain

GameCharacterクラスのReportDamgeHPtoRPGGameModeBase()関数などが呼ばれています。

f:id:kazuhironagai77:20210425233013p:plain

実装部を見ると、RPGGameModeクラスのReprotCharacterHPisDamaged()関数などが呼ばれています。

f:id:kazuhironagai77:20210425233028p:plain

RPGGameModeクラスのReprotCharacterHPisDamaged()関数などのFunction Specifierの一つはBlueprintImplementableEventなので実装はBP内で行われています。

f:id:kazuhironagai77:20210425233046p:plain

RPGGameModeBPクラスのReportCharacterHPisDamagedなどをみると

f:id:kazuhironagai77:20210425233107p:plain

f:id:kazuhironagai77:20210425233114p:plain

以下の実装部で問題のセリフを表示していました。

f:id:kazuhironagai77:20210425233137p:plain

f:id:kazuhironagai77:20210425233145p:plain

f:id:kazuhironagai77:20210425233151p:plain

f:id:kazuhironagai77:20210425233201p:plain

かなり遠回りしましたが、戦闘中のアイテムを使用した時の実際のコードの執行のされ方が確認出来ました。

3.1.2 MPやHPの変化が0の時はセリフを表示しないようにする。

TestCombatActionItemクラスのBeginExecuteAction()関数内で以下の関数がよばれています。ItemHPかItemMPが0の場合は

f:id:kazuhironagai77:20210425233229p:plain

ItemHPかItemMPが0の場合はこれらの関数を呼ぶのを止めれば、MPやHPの変化が0の時はセリフを表示しないように出来ます。

以下の様に改良しました。

f:id:kazuhironagai77:20210425233244p:plain

これで、ItemHPかItemMPが0の場合はこれらの関数を呼ぶのを止めるはずです。

Buildします。

UE4C++をいじるのは久しぶりです。ちょっと緊張します。

f:id:kazuhironagai77:20210425233404p:plain

成功しました。

一応、UE4editorも再起動させます。

それではテストしてみます。

まずは回復薬を使用します。

f:id:kazuhironagai77:20210425233423p:plain

MP云々は表示されなくなりました。成功です。

次にダークイーサーを使用します。

f:id:kazuhironagai77:20210425233437p:plain

こっちもHPは表示されません。

最後にイーサーを使用します。

f:id:kazuhironagai77:20210425233453p:plain

はい。この場合も不必要なHPについての報告はありません。

出来ました。

3.1.3 MPやHPがMaxまで上昇した場合とそれ以外で分ける。

まず思ったのはダークイーサーを使用した時のセリフが

f:id:kazuhironagai77:20210425233516p:plain

しか説明していないにも関わらず不自然じゃないんです。

ので「Maxまで上がりました。」を無くしてしまいます。

以下の様にしました。

f:id:kazuhironagai77:20210425233540p:plain

f:id:kazuhironagai77:20210425233548p:plain

これで良い気がしています。

理由が分かりました。

「ほど」と表現しているからです。「ほど」と断定を避けているので絶対20回復した訳ではありませんから、何となく不自然じゃないんです。

これでOKですね。

3.2 Map1でBuildするとLandscape_0 instead mesh…と警告される

以下の警告が表示されます。

f:id:kazuhironagai77:20210425233611p:plain

UE4 Answer HubのLandscape Error after build in Lighting Results [1]によると

f:id:kazuhironagai77:20210425233626p:plain

と書かれています。

言っている事は分かりましたが、これってStatic lightingじゃなくすれば全部解決するんじゃないでしょうか?試してみます。

3.2.1 Static lightingを外す。

配置してあるLightを全部調べたのですが、Static lightingにセットされているのはSky lightのみでした。取りあえずStationaryに変えてみます。

f:id:kazuhironagai77:20210425233653p:plain

赤くなってしまいました。

f:id:kazuhironagai77:20210425233709p:plain

あれ。赤いけど地面からの反射光がキャラに反映されています。

ひょっとして、Cubemapに何もセットしていないからでしょうか?

f:id:kazuhironagai77:20210425233725p:plain

Cubemapをセットしてみます。

f:id:kazuhironagai77:20210425233740p:plain

きれいな反射光が付きました。

f:id:kazuhironagai77:20210425233759p:plain

家も多少は明るくなりました。

f:id:kazuhironagai77:20210425233820p:plain

やっぱり影になっている方は真っ暗です。

f:id:kazuhironagai77:20210425233838p:plain

思い出しました。夜が明る過ぎる時はCubemapを外せ。みたいな事がGoodskyのFAQに書かれていたんです。

確かに夜は明る過ぎます。

f:id:kazuhironagai77:20210425233857p:plain

Goodskyの説明書をもう一回読んでみます。

f:id:kazuhironagai77:20210425233922p:plain

そんな事は書いてませんでした。

f:id:kazuhironagai77:20210425233938p:plain

f:id:kazuhironagai77:20210425233945p:plain

理由は分からないですが、兎に角あるときSky lightのCubemapを外してしまったようですね。

f:id:kazuhironagai77:20210425234004p:plain

それは兎も角として

f:id:kazuhironagai77:20210425234017p:plain

の警告は全く消えませんでした。

良く分かりません。

3.2.2 Landscape 4_FoilageやSwamp_Foliageに使用されているMeshのLODを変更する。

f:id:kazuhironagai77:20210425234039p:plain

正直言って、LODについてどうやって整理されているのかまだ良く分かっていないんです。

のでどこをいじればLower LODが独自のLightmapをサポートできるのかまだ分かりません。

Static meshのLODPickerのCustomをチェックすると

f:id:kazuhironagai77:20210425234053p:plain

LOD1などが現れます。

f:id:kazuhironagai77:20210425234110p:plain

これで良いのでしょうか?それともこの現れたそれぞれのLODに何かを指定する必要があるのでしょうか?

使用しているStatic mesh全てのLOD PickerのCustomにセットしましたが警告は変わりませんでした。

うーん。

もう少し簡単な条件でLandscape Grass Outputを使用しないと原因が絞れないですね。来週やります。それまでにどういう条件で問題を絞れるのかを考えておきます。

現状の問題は、

  • Static lightingは使用していないのに警告は消えない。
  • Landscape Grass Outputに使用しているGrassStatic meshLOD1が良く分かっていない。

です。

まあ、今回はmap1のSky lightをStatic lightingから変えると世界が赤くなってしまう理由とその対策方法が判明したのでちょっとずつは進歩していると言う事でOKとします。

4. Effectの勉強

そろそろというかとっくにEffectの勉強もすべきでしたが、時間が取れませんでした。ので今週はEffectを勉強しようと思います。

4.1 Niagaraを勉強すべきか?

全然、Effectの事情が分かりません。Particle systemはもう古くて誰も使っていないのか?それともNiagaraはまだ実験中なのか?この二つは全く違うものなのか?あるいはParticle systemを理解しないとNiagaraは理解出来ないのかとか?

その辺を調べます。

まず、公式のサイトです。Cascade Particle Systems [2] とNiagara Visual Effects [3] です。

Cascade Particle Systems [2]です。以下のDocumentが紹介されています。

全体像を把握したいのですがKey Particle Concept 位しか該当しているDocumentがなさそうです。

f:id:kazuhironagai77:20210425234211p:plain

Niagara Visual Effects [3]です。

こっちは逆に全部初心者向けみたいですね。

f:id:kazuhironagai77:20210425234230p:plain

紹介文だけ読みましたがかなり面白そうです。

このゲームに使用するかどうかは別にしてもちょっと勉強する分にはNiagaraの方が良いかもしれません。

Online Learningの方もチェックしましたが該当するTutorialは見つかりませんでした。

YouTubeのTutorialもチェックします。

UE4 - Introduction To Niagara [4] が一番最初に出て来ました。

ちょとだけ見てみます。

Niagaraが標準で使用出来るのは4.25からだそうです。

うーん。

勉強してもこのゲームには使用出来ないのか?

もう少しこの動画を見て考えます。

うーん。あんまり分かり易くないですね。

Unreal Engine Niagara Tutorials [5] というそのものズバリのPlay Listがありました。このPlay Listの最初の動画にNiagaraで作成したEffect集みたいなのがあったのですが圧巻の一言です。

f:id:kazuhironagai77:20210425234301p:plain

f:id:kazuhironagai77:20210425234308p:plain

f:id:kazuhironagai77:20210425234317p:plain

試しに実際のTutorialの動画を見たのですが、この人の英語、滅茶苦茶聞き取りにくいです。でも字幕が在るので理解出来ない事はないでしょう。

早速、一個間違えて覚えていた事が分かりました。NiagaraもParticle systemの一つで、今まで使用していたParticle SystemはCascadeと呼ぶそうです。つまりUE4には2種類のParticle systemがあってCascadeNiagaraとなります。

よし決めました。今週はNiagaraを勉強します。そしてParticle Systemそのものについても勉強します。ただしこのゲームは4.24で作成しているので、このゲームのEffectはCascadeで作成します。

4.2 Niagara Overviewを勉強する

公式のdocumentのNiagara Overview [6]を勉強します。

最初の文章から当たり前のようにVFXと言っていますが、私VFXの意味を知りません。

f:id:kazuhironagai77:20210425234340p:plain

調べたら元々は、映画などの編集技術の一つでCGを使って行う特撮の事を指すみたいです。その技術が3Dのゲーム内で燃え盛る炎や、煙、あるいは魔法の効果などを表現するために逆輸入され、そこで大発展しました。その事により3D Graphics における一分野としてのVFXとしてまとめられるようになったみたいです。

VFXはvisual effectsの略だそうです。Vがvisualを指すのは分かりますが、Effectsが何でFX何だと思ったら、Eを取ったffectsの発音がアメリカ英語だからtを発音しないんでfecs ≒FXだからでした。Factsがファックスに聞こえるヤツと同じです。

ここまで理解してもう一回最初の文を読んでみると

f:id:kazuhironagai77:20210425234356p:plain

UE4にはVFXを作成するための機能としてCascadeNiagaraの2つが用意されています。と言う意味だったんですね。

Niagaraの特徴としてデザイナー (Technical Artist) がProgrammerの助けを借りなくても機能の追加が出来るようになっているそうです。

うーん。

この機能の追加が何を示してるのかまだ分からないですが、Particle の移動の計算とか、そのParticle に貼りつけたTextureのイメージに対する光の屈折の計算とかなんでしょうか?

Technical ArtistってProgrammingが出来るデザイナーの事ですよね。

UE4におけるBPの実装は、Script ProgrammingをProgrammer以外の人にも可能にした事で、すごい可能性を広げたんだと思うんです。それ以前はC++でゴリゴリProgram 書ける人しかUE使えなかったと思うからです。

しかしここで見逃してしまった問題もあると私は思っています。

それはProgrammerの種類です。

  1. C++でゴリゴリProgrammingかけてそれこそGame Engineそのものを自作出来るレベルの人
  2. C++は使えないけどそれより簡単な言語なら使える人
  3. 物理や工学の専門家で、微分方程式で表される物理現象を数値解析で解く事が出来る人

BPの実装はこの2番の人達でもUE4が使用出来る様になりました。そして普段はDesignerで居る人でも、2番のProgrammer位の能力を持っている人達は、Technical Artistとして大活躍出来る素地が生まれたわけです。

所がですね。MaterialなんかBPが書けたって何も出来ない訳ですよ。何故なら3の能力が必要になってくるからです。

もうちょっと分かり易い例えを思い付きました。

デザイナーが戦士、Programmerは魔法使いとするとUE4にBPが生まれた事で、戦士の中で知能が高い人達も魔法が使えるようになり、魔法戦士というジョブが誕生したんです。

しかし3番のタイプのProgrammerは、魔法使いじゃなくて錬金術師なんです。錬金術師が必要となるクエストに魔法戦士が行って活躍出来るのかと言う事です。出来ないと思います。しかしだからと言って錬金術師に戦士の能力(デザイン力)が全く無ければこれも使えない訳です。つまり錬金術師系戦士(物理や工学の専門家かつデザインが出来る人)みたいなジョブが必要な気がするんです。

それでVFXもこの錬金術師系戦士が必要な分野な気がしている訳です。Niagara。デザイナー (Technical Artist) が、Programmerの助けを借りなくても機能の追加が出来ると書かれていますが、この錬金術師系戦士の存在に気が付かないと絵に描いた餅になってしまうんじゃないのとちょっと思いました。

そんな感想を抱きつつ続きを読んでいきます。

<Core Niagara Components

Niagaraは4つのComponent(System、Emitter、Module、Parameter)で構成されているそうです。ざっと読んだ感じではSystemの中にEmitterがあり、Emitterの中にModuleがあって、そのModule内でScriptのような物が書けて、データはParameterを使用して保持する。みたいです。

Niagara Stack Model and Stack Groups

上から順に実行されるらしいです。

<Templates and Wizards

こんなTemplateやWizardが用意されています。と言う説明でした。

Niagara VFX Workflow

Workflowと言っていますが、これWorkflowなんでしょうか?良く分かりません。今回はここはスキップします。

Niagara Paradigms

Niagara におけるInheritance、とかEventsが他のProgrammingとどう違うのかそれは何故かについて説明しています。これらは有効で大切な情報ですが、今読んでも正直理解出来ません。Niagaraにおける実際のVFXの作成方法を理解した後で必要になるかもしれません。

4.3 Niagara Key Conceptsを勉強する

正直言ってNiagara Overviewはあんまり全体像を把握する役に立たなかったんですが、一応Niagara Key Concepts [7]も軽く読んでおきます。

Niagara Design Philosophy

UE4はゲームの制作だけでなく建築、映像作品、そして工業製品(車など)のデザインなどにも使用されるようになったため、VFXもゲーム専用として作成すると応用出来ない分野が出で来ます。そのため今までのCascade systemの良い部分を残しつつ、UE4を使用する全ての分野の人がVFXを利用出来る様に新しいVFXを作成しました。それがNiagaraです。

こんな感じの説明でした。

こっちの説明はすんなりと納得出来ますね。

車とかのデザインをする人なら元々、流体力学なんかの専門家でかつデザインが出来る人でしょうから。もろに前節で行っていた錬金術師系戦士タイプでしょうし。

ここの説明で唯一不満があるとすればParticle Payloadが何なのか分かりません。初心者向けでありながら、この辺の専門用語を読者は既に知っていると仮定して話しているのは不親切かもしれません。

<Hierarchy for Niagara's Hybrid Structure

Module、Emitter、そしてSystemについての説明でした。

Niagara Overviewと同じ様な説明かと思ったら全然分かり易く説明されていました。

前節で「NiagaraはBPのGraph ParadigmとCascadeのStack Paradigmの両方が使用出来るようにした。」と解説されていたのですが、そのGraph Paradigmを担当してるのがModuleで、そのModuleを保持しながらStack Paradigmを実現してるのがEmitterと説明されていました。

更にSystemはEmitterを時間軸で管理してると説明されていました。

3つのComponentの役割分担がはっきり分かりました。

何で、Niagara Overviewの方はこういう分かり易い事全然説明してくれていないの?と思って見直したんですが、一応それなりには説明していました。

例えばModuleの所ではGraph内でCustom HLSLを使用するとか、SystemではTimelineを管理するとかです。

しかし、NiagaraUE4を使う全ての分野の人達がVFXを使えるように作られました!そのためにNiagaraではBPのGraph ParadigmとCascadeのStack Paradigmの両方が使用出来るようにしました。そのGraph Paradigmを担当しているのがModuleです。そのModuleを保持しながらStack Paradigmを実現してるのがEmitterです。そして最期に時間を管理してるのがSystemです。

と説明するのに比べると凄く分かりにくいです。

Niagara Selection Stack and Stack Groups

Moduleはグループ毎にまとめられていてそのグループ内にはStageがあるそうです。そのStage内でも特別なStage、Events やSimulation があるそうです。

<Stages, Groups, Namespaces and Data Encapsulation

Moduleがグループに属する事によってどのデータにアクセスするのかも管理出来るようです。ここでgroup の例としてSystem、Emitter、もしくは Particleと出ていたんですが、エッそれがグループなのとびっくりしました。

うーん。

まだ良く分からない事ばかりです。

4.4 Niagara Quick Startを勉強する

実際に試してみない事には分からんですのでNiagara Quick Start [8]を勉強します。

ここでは以下の3つの事が学べるそうです。

  • Niagaraを使用するために必要なMeshMaterialの作成方法
  • NiagaraEmitterSystemを使用して簡単なEffectが作成出来る
  • 作成したEffectをキャラに付着させてAnimationの中でEffectを使用する方法

こんだけ出来れば十分でしょう。

<Project Setup

4.26で新しいProjectを作成しました。4.24だとPluginからNiagaraを使用しないといけないので最新のVersionで試してみます。

最初に3Dモデルを作成してImportしろとか書かれています。

何これ?

条件の説明も何にもないし、別にStarter Kitの付属のStatic meshでも問題ないでしょう。

地雷臭半端ないんですが。このTutorial。

まあ。新しい分野ですし。完璧なTutorialが出て来るまでまだ時間がかかるのかなと好意的に考えて先に進めます。

Starter kitのPropにあった以下のStatic meshをコピーして

f:id:kazuhironagai77:20210425234607p:plain

名前を変えて使用する事にします。

f:id:kazuhironagai77:20210425234622p:plain

Materialも作成します。

f:id:kazuhironagai77:20210425234637p:plain

どうしてこのような実装に至ったのかの説明が全くありませんでした。

あー。やっぱり錬金術師系戦士の必要性に全く気が付いてないですね。

<Create the Effect

さすが、4.26。FXを見たらNiagaraに関するBPが表示されました。

f:id:kazuhironagai77:20210425234657p:plain

Niagara Systemを選択したら

f:id:kazuhironagai77:20210425234711p:plain

が表示されました。

Niagara Overviewでこの図の説明がされていましたが、こんなに早く必要になるとは思っていませんでした。

ちょっと読んで来ます。

まず、Systemを作成する時はこの4つのOptionから選択しないといけないそうです。Emitterの種類にはTemplateと今までに自作した物の2種類があるみたいです。その両方を表示してくれるのが最初のOption、Templateだけ表示するのが2番目、自作のemitterだけ表示するのが3番目、何も表示しないのが4番目の様です。

一番目を選択します。

凄い。Templateに色々なEmitterが表示されています。

f:id:kazuhironagai77:20210425235045p:plain

Tutorialに書かれている通りにSimple Sprite Burstを選択して終了します。

作成されたSystemを開くとYouTubeのTutorialで見たのと同じEditorが表示されました。

f:id:kazuhironagai77:20210425235106p:plain

System内に保持されるEmitterと言う表現がありますが、このEmitter SettingとかEmitter Spawnなどがそれに当たるんでしょうか?

f:id:kazuhironagai77:20210425235125p:plain

後、Stack Paradigmで表されると言う事は、

  • Emitter Setting -> Emitter Spawn -> Emitter Update ―> Particle Spawn ->Particle Update ―>Event Handler ―> Render

の順で実行されると言う事でしょうか?

Rendererの設定はTutorialに書かれていた通りに作成しました。

f:id:kazuhironagai77:20210425235149p:plain

MaterialのFacing ModeがVelocityと言うのは何を指すのでしょうか?

f:id:kazuhironagai77:20210425235208p:plain

ここは良く分かりません。

分からない時は、カーソルを乗せて見る。です。

f:id:kazuhironagai77:20210425235228p:plain

Meshのカメラに対する向きの決定方法だそうです。

はい。分かりました。

球を使用しているので私のMeshの場合は意味ないかもしれません。Tutorialが敢えて水分子みたいなのを使用しているのもここを強調するためかもしれませんね。

こっちの説明がないんですが、これは4.26から付いた新しい機能なんでしょうか?

f:id:kazuhironagai77:20210425235258p:plain

<Edit the Module Settings

Moduleの設定の編集だそうです。Niagara Key ConceptsでModuleはBPのGraph Paradigmを体現していると説明されていましたが、ここ見る限りではParameterの値を弄っているだけですね。

以下に値を弄った個所について簡単にまとめます。

<<Emitter Update>>

まずEmitter Updateですが、これがModuleなのかと思ったらEmitter UpdateはGroupだそうです。となるとEmitter Update内のEmitter StateとSpawn Burst InstantaneousがModuleに当たるんでしょうか?

カーソルを乗せると以下のようにEmitter Updateの機能の説明が表示されました。

f:id:kazuhironagai77:20210425235329p:plain

要するにtick()関数ですね。

Tutorialをよく読んだらEmitter State moduleと書かれていました。Emitter StateがModuleなんですね。

f:id:kazuhironagai77:20210425235349p:plain

Tutorialの指示に従って以下のParameterの値を変化させました。

f:id:kazuhironagai77:20210425235410p:plain

Tutorialではそれぞれの変数が何を指しているのかの説明は無かったんですが、カーソルを乗せたら、以下の説明が出て来ました。

f:id:kazuhironagai77:20210425235425p:plain

かなり詳しく解説されています。今回は読みませんが読んだらどんな機能の調節をするのか理解出来そうです。

Moduleの調節ってBPみたいなのはないんでしょうか?

何か想像していたのとはちょっと違いますね。

<<Particle Spawn Settings>>

以下のようにTutorialの指示通りに作成しました。

f:id:kazuhironagai77:20210425235446p:plain

Particleを作成するたびに呼び出されるそうです。EmitterとParticleの関係が良く分からないですね。

Emitterが一回呼ばれる毎にParticleは千個も2千個も作成されるはずです。となると

  • Emitter Setting -> Emitter Spawn -> Emitter Update ―> Particle Spawn ->Particle Update ―>Event Handler ―> Render

ではなくて

  • Emitter Setting -> Emitter Spawn -> Emitter Update ―>沢山のParticle Spawn…

となるのでしょうか?

あんまり細かく書いても全体が分からなくなってしまうので、残りは簡単に書きます。

<<Particle Update Settings>>

Tutorialに書かれている通りに作成しました。

かなり分かり易く作り方を説明しているので、良く読んだらNiagaraの作成手順に対する理解がかなり深まりそうです。今週はもう時間がなくなってしまったので駆け足で終わらせますが、来週もう一回復習する事にします。

<Attach the Niagara Effect to a Character

走っているアニメーションに上記の作成したNiagaraを追加するそうです。

そのまま作成しました。

NotifyにSystemを追加する方法が良く分からなくて凄く時間がかかりました。

f:id:kazuhironagai77:20210425235532p:plain

が一応出来ました。

<テストします。>

想像の100倍くらいデカイ球が生成されています。

f:id:kazuhironagai77:20210425235553p:plain

Particle SpawnのInitial Particleの以下の設定部分を1から0.1、2から0.2 に変更してみました。

f:id:kazuhironagai77:20210425235610p:plain

今度は大きさ的にはイイ感じです。

f:id:kazuhironagai77:20210425235626p:plain

f:id:kazuhironagai77:20210425235633p:plain

でもまず透明感が全くないですね。

後、何で足元に自然に発生するような設定になっているんですかね。

ちょっと時間がなくなってしまったのでここで中止しますが、このTutorial最初の印象と大違いでかなり勉強になります。

来週はもう少しかんばります。

以下の箇所は来週やります。

  • Effect(魔法陣)をWarp Gateに追加する。
  • Landscape4にもっとモンスターを配置する。
  • Landscape4からMap1に戻るためのWarp Gateを作成する。
  • 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する。

5.まとめと感想

今週は、

  • 先週のLightingの復習
  • バグの直し
    • 戦闘中にアイテムを使用した時のセリフの直し
    • Map1でBuildするとLandscape_0 instead mesh…と警告される事の検証
  • Effectの勉強

を行いました。

来週は、

  • Map1でBuildするとLandscape_0 instead mesh…と警告される事の検証の続き
  • Niagaraの勉強の続き
  • Effect(魔法陣)をWarp Gateに追加する。
  • Landscape4にもっとモンスターを配置する。
  • Landscape4からMap1に戻るためのWarp Gateを作成する。
  • 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する。

をやります。

. 参照(Reference

[1] Epic Games. (n.d.-b). Landscape Error after build in Lighting Results - UE4 AnswerHub. UE4 ANSWERHUB. Retrieved April 25, 2021, from https://answers.unrealengine.com/questions/343146/landscape-error-after-build-in-lighting-results.html

[2] Epic Games. (n.d.-a). Cascade Particle Systems. Unreal Engine Documentation. Retrieved April 25, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/index.html

[3] Epic Games. (n.d.-f). Niagara Visual Effects. Unreal Engine Documentation. Retrieved April 25, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/index.html

[4] gameDev Outpost. (2020, July 30). UE4 - Introduction To Niagara [Video]. YouTube. https://www.youtube.com/watch?v=VEG-Xp92cBk

[5] CGHOW. (2021, April 16). Unreal Engine Niagara Tutorials [Video]. Unreal Engine Niagara Tutorials. https://www.youtube.com/playlist?list=PLwMiBtF6WzsqC7_cJmD26ts0YDbtPCCfe

[6] Epic Games. (n.d.-d). Niagara Overview. Unreal Engine Documentation. Retrieved April 25, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/Overview/index.html

[7] Epic Games. (n.d.-c). Niagara Key Concepts. Unreal Engine Documentation. Retrieved April 25, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/NiagaraKeyConcepts/index.html

[8] Epic Games. (n.d.-e). Niagara Quick Start. Unreal Engine Documentation. Retrieved April 25, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/QuickStart/index.html

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する  Widgetの整理など

f:id:kazuhironagai77:20210418232534p:plain

<前文>

牛は食べて良くて馬は食べたらいけない件について

今の日本のクリエーターが最も恐れる事の一つにネットの炎上が挙げられると思います。

しかも炎上は国内だけじゃなくて海外から起きる事もちょくちょくです。ネットで作品を発表する人達にとって、炎上するかしないかはほとんど運まかせです。この海外からの炎上は主に、中国、イスラム圏、そして英語圏がありますが、アメリカに10年暮らしていた私は、この英語圏の炎上を防ぐためのアドバイスはかなり的確に出来ます。

今回はその話です。

アメリカ人はいつも激高しているように思う日本人も多いと思いますが、実際はアメリカ人が激怒するのは非常に稀です。

それにはれっきとした理由があって、キリスト教の価値観においては激高した事実自体を罪と見なすので、激怒すると社会から制裁を受けるからです。

しかし例外があります。例外に関してはいくらでも激高してもOKです。

その例外の一つに、馬、クジラやイルカ、そして犬を食べる人に対してはいくらでも切れて良いと言うのが有ります。

食い物に関して、そんな例外があっていいのか、と思いますし、実際、おかしいんじゃないの?と私も思いますが、事実なんでしょうがないです。

日本人が中国人とかベトナム人が犬を食べると聞くと、気持ち悪いと思う人は居るかもしれませんが、激怒する人はほとんどいないと思います。

それは日本人の文化では、馬、クジラやイルカ、そして犬は、畜生であって人ではないからです。

英米文化圏では、馬、クジラやイルカ、そして犬は、友人であって日本人が思う畜生ではないです。

おかしいと思うかもしれませんが、英語文化圏では、

  • 牛は食っていいが、馬は駄目。
  • ねこは可愛くないが、犬は可愛い。
  • クジラやイルカは見た事ないが友達。

なんです。

勿論、美味しんぼのように全力で、そのお前の文化。偽善だろ。と戦いを挑むのも選択の一つとして有りますが、日本人で馬やクジラを食った事ある人はほとんどないでしょう。無用な炎上は避けたいと思うのなら馬やクジラを食べる話などは避けるべきです。

どれくらいが許容範囲なのかですが、JOJO進撃の巨人が例として分かり易いです。どちらも欧米で大人気の作品ですが、JOJOでは犬が虐待されている。進撃の巨人では馬が虐待されている。と英語圏では認識されています。これぐらい大人気の作品だと、ファンも凶暴なので、虐待と指摘しづらく、野放しにされていますが、無名のクリエーターがJOJOと同レベルで犬を扱ったり、進撃の巨人と同レベルで馬を扱ったら炎上する確率はかなり高くなるでしょう。

一体JOJOのどこで犬が虐待されているの?とか進撃の巨人で馬の扱いは丁寧じゃない。と思う人は、自分の作品には馬や犬は出さない方が、炎上を避ける意味では賢明だと思います。

そう言えば、私、中学生の時、ムツゴロウさんの本が大好きで全著作を暗記する位読んだんですが、大人になった今思い返すと、犬と馬に対しては特別扱いしていたんだなと分かります。例えば、ムツゴロウさんが満州で馬の肉を食べる話ですが、ショックで食べれなかった点が強調されています。犬を食べる話は、私が覚えている限りですが、大学の野良犬が痩せて死にそうなので、ムツゴロウさんが一計を案じて、太らせて食べようと嘘ついてみんなから餌を集めて太らして、食べるために殺す前の日に逃がそうとしたら空手部の連中が先に殺してしまったみたいな話だったと思います。更に捕鯨にも終始反対の立場でした。

ムツゴロウさんなんて平気でライオンの口に頭突っ込む人です。そんな人でさえ、馬、クジラ、そして犬のタブーには首突っ込まなかったのかと思うと、常人は絶対避けるべき話題なのかもしれません。

勿論、これはあくまでもクジラや馬の食用なんでどうでも良い人向けで、人生には炎上しようが命掛けて戦わないといけない時もありますので、絶対、俺の作品から馬や犬は削らないと主張する人に強制するつもりはありません。

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

<本文>

1.今週の予定

以下の事を行います。

  • Environmental artist用のTutorialの続き
  • Widget内のBPの整理
  • Map1からLandscape4にWarp出来るようにする。
  • Landscape4で戦闘出来るようにする。

2.Environmental artist用のTutorialの続き

Becoming an Environment Artist in Unrealの続きとConstructing Believable Environmentを勉強します。

今週こそはLightingに集中して勉強したいです。

Lightingの勉強の目的ですが、実は以下に示した様に、Medieval KingdomからImportした建物やその影で非常に暗い部分があるんです。

 

f:id:kazuhironagai77:20210418233801p:plain

f:id:kazuhironagai77:20210418233907p:plain

これの理由を知りたいからです。

2.1 Becoming an Environment Artist in Unrealの続き

先週、残り二つで時間が無くなって途中で中断せざるえなかったので、その残りから勉強します。

<Lighting

基本的なLightの説明でした。

  • Static light -> light map のみに記録。最も低コスト。
  • Moveable light ->light map関係なし。全てRun time中に計算するため、最も高コスト。
  • Stationary light ->light mapに記録。ただし明るさと光の色はRun timeに計算。コスト的には2つの間。

Light mapって遥か昔の記憶では、空間上に点々で表現されていたような気がします。Medieval KingdomからImportした建物が暗いのはこのLight mapのせいなんでしょうか?

Sky light について興味深い話が説明されていましたので記録しておきます。

Sky lightは空の光の反射光を追加します。

以下の様に空の色を指定すると

f:id:kazuhironagai77:20210418233956p:plain

Sky lightによって以下の様に空の色が淡く追加されます。

f:id:kazuhironagai77:20210418234013p:plain

Affect Worldを切ってSky lightの影響を消すと

f:id:kazuhironagai77:20210418234029p:plain

以下の様になります。

f:id:kazuhironagai77:20210418234048p:plain

更に、Stationary やMovableでは以下の様にSky lightの反射光が見えますが、

f:id:kazuhironagai77:20210418234105p:plain

Staticだと以下のようにSky lightの色は全く表示されていません。

f:id:kazuhironagai77:20210418234127p:plain

Build light onlyを実行すると、Sky lightの反射光が追加されました。

f:id:kazuhironagai77:20210418234200p:plain

<Lightmaps

Light mapについてです。

最初からLight mapに関して間違って理解している事が分かりました。Light mapって空間上に点々で表現されているそれぞれの箇所で360°カメラの撮影みたいな方法で影をTextureに焼き付けていると思っていました。実際はMeshのUVをもう一枚作成してそのTextureに影の情報を追加していました。

World SettingのLightmassの項目でLight mapの質を調節出来ます。

f:id:kazuhironagai77:20210418234226p:plain

実際に作成されたLight mapも表示されています。

f:id:kazuhironagai77:20210418234246p:plain

Mayaを使用してLight mapを作成する方法が紹介されています。

f:id:kazuhironagai77:20210418234303p:plain

以下の様にLightmapの場合、それぞれのTexture上に配置されているMesh同士の間を4 ~ 8 pixelは確保する必要があるそうです。

f:id:kazuhironagai77:20210418234320p:plain

このTutorialでは、Mayaを使用して作成していますが、後でBlenderの作成方法を勉強する必要がありますね。

今回は、Meshが持つ二つ目のUV mapはLightmapとして使用されていた。と言う事だけ覚えておきます。

Importする時は、Generate Lightmap UVsのチェックを外す必要があるそうです。

f:id:kazuhironagai77:20210418234336p:plain

と言う事は、Lightmapを作成しなくてもUE4で勝手に作成してくれるみたいですね。

Meshを開いてDetailのLight Map Coordinate Indexに記されている番号のUVがLightmapに使用されるそうです。

f:id:kazuhironagai77:20210418234353p:plain

最後にLight mapの質についてです。

Light map ResolutionがLight mapの質を表します。

f:id:kazuhironagai77:20210418234527p:plain

Lightmap Densityを選択する事で適切なLight map Resolutionを選択出来ます。

f:id:kazuhironagai77:20210418234545p:plain

以下の様に表示されるので、Light map Resolutionの値を調節して最適化します。

緑色が適切なLight map Resolutionだそうです。

f:id:kazuhironagai77:20210418234602p:plain

こんなの本当に初耳です。

UE4内でLightmapを作成する方法ですが、Mesh内のDetailからGenerate Lightmap UVsをチェックするだけでした。

f:id:kazuhironagai77:20210418234707p:plain

ただその後がちょっと複雑です。

Source Light map Indexで元になるUV mapを選択します。

Destination Lightmap Indexで作成したLightmapを保存する箇所を指定します。

f:id:kazuhironagai77:20210418234731p:plain

これでSaveすれば完成かと思ったら、この後でApply Changesを押せと言っています。

f:id:kazuhironagai77:20210418234750p:plain

所がApply Changesって三か所あるんです。一応Tutorialをじっくり見るとReduction SettingsのApply Changesを押しているみたいです。

Lightmapの時はtexture上に配置されているMesh同士の間を、最低でも4 ~ 8 pixelは確保する必要があると言っていましたがUE4でLightmapを生成した時はそれはどうなってるの?

と思っていたら早速その説明がありました。

Min Lightmap Resolutionの値を大きくするとTexture上に配置されているMesh同士の間が小さくなって、小さくすると隙間が大きくなるそうです。

f:id:kazuhironagai77:20210418234810p:plain

試してみます。

付属のイス(SM_Chair)でLightmapを作成してみます。

f:id:kazuhironagai77:20210418234827p:plain

このイス、なんどUV mapが一個しかありません。

f:id:kazuhironagai77:20210418234842p:plain

じゃLightmapないの?と思ったら、Lightmap Coordinate Indexが0にセットされていました。

f:id:kazuhironagai77:20210418234934p:plain

この一個のUVmapがUVmap兼Lightmapになっているみたいです。

Generate Lightmap UVsにチェックを入れます。

f:id:kazuhironagai77:20210418234959p:plain

Reduction SettingのApply Changesをクリックします。

f:id:kazuhironagai77:20210418235014p:plain

新しいUV mapが作成されました。

f:id:kazuhironagai77:20210418235030p:plain

f:id:kazuhironagai77:20210418235038p:plain

Lightmap Coordinate Indexの値を1に変えました。

f:id:kazuhironagai77:20210418235054p:plain

以下に作成したLightmapを使用したイスを表示します。赤枠で囲ったほうがLightmapを作成した方です。隣のイスは元々のLightmapを使用しています。

f:id:kazuhironagai77:20210418235116p:plain

Lightmap Resolutionを64から128に挙げて見ました。

f:id:kazuhironagai77:20210418235135p:plain

まだ緑色ですのでこれぐらいの細かさでも適正と見なされています。

次はMin Light map Resolutionの値を変えてみます。

f:id:kazuhironagai77:20210418235153p:plain

2倍の128にしました。

f:id:kazuhironagai77:20210418235219p:plain

当たり前ですが、数字を変えただけではUV mapは変化しません。Reduction SettingのApply Changesをクリックする必要があります。

Texture上に配置されているMesh同士の間が半分になったはずです。Texture上に配置されているMeshの位置も変わりました。素人目にはこれでも十分な隙間があるような気がします。

一番の違いはTexture上に配置されているMeshのサイズそのものが大きくなっていますね。

Lightmap Densityも見てみます。

f:id:kazuhironagai77:20210418235237p:plain

こちらは特に変わっていませんでした。

<Wrapping Up and What is Next

特になしです。

このTutorialには続きがあるみたいですのでそれも調べて見ます。

f:id:kazuhironagai77:20210418235305p:plain

作者名から調べたのですが、これ以外のTutorialは作成していないみたいです。

<Quiz 4

二つも間違えてしまいました。SwitchとConstant1ですが一体何の話をしているのか分からなかったです。間違えてから気が付いたんですが、問題はLight関連だけじゃなくて先週勉強した範囲からも出題されていました。

要するにSwitch nodeとConstant 1 nodeの機能についての説明だったんですが、それに気が付きませんでした。

ちょっと後味の悪い終わり方になってしまいました。

2.2 Constructing Believable Environmentの勉強

こっちは確かボリュームが凄かったはずです。

7章もあります。1章だけで普通のTutorial位あるはずです。

f:id:kazuhironagai77:20210418235346p:plain

慌てずにIntroducing Global Illuminationからやって行きます。

2.3 Constructing Believable Environmentの勉強1: Introducing Global Illumination

Global Illuminationって何でしたっけ?

度忘れしちゃいました。

Indirect lightingの事でした。壁が赤いと壁に当たった光も赤くなってその光を浴びた物質もすこしだけ赤くなるやつです。

あれ。Ray Tracingとの違いは?

このビデオ[1]でくわしく解説されていました。

そう言えばこのビデオ、昔見てました。その時かなり勉強になった事を思い出しました。

<Introduction to Global Illumination>

このTutorialは建築家がUE4を使用する時に考慮しなければならない光の加減にフォーカスしています。

Global illuminationには2種類あります。Baked Global Illuminationと Dynamic Global Illuminationです。

<Understanding Lightmass - Baking Checklist

Light map にBakeするためにはMobilityがStaticである必要があります。

Stationary はIndirect lightの情報だけlight map にBakeします。

UV mapについての説明もありました。「2.1 Becoming an Environment Artist in Unrealの続き」の「Light map」で勉強した事と同じです。

Lightmapの自動生成についての説明もほとんど同じでした。

唯一の違いは、Apply Changeは真下についているのをクリックしていました。

f:id:kazuhironagai77:20210418235502p:plain

こっちのTutorialでは

Min Lightmap ResolutionとLight Map Resolutionについて値を同じにするとだけ述べています。

f:id:kazuhironagai77:20210418235521p:plain

名前は同じですし、こういう解釈もありなんですね。

そう言えば、もしMin Lightmap Resolutionの値がLight Map Resolutionの値より大きくなった場合はどうなるんでしょうか?

試しにLight Map Resolutionの値を64にしてみたんですが、イスの色が青味がかる以外の変化はみられませんでした。

f:id:kazuhironagai77:20210418235555p:plain

<Quiz1

もうクイズ。と思ったら2問しかありませんでした。満点でした。

<Intro to Lightmass

Lightmassについてです。色々とLightmassが何かについて解説していますが、LightmassはLightmapへのBakeをする事を指しているみたいです。

<Visualizing Lightmass

Lightmass以外の影響を消した3D viewportの作成方法についてです。

Lighting onlyにセットします。

f:id:kazuhironagai77:20210418235647p:plain

次にScreen Space Ambient Occlusionのチェックを外します。

f:id:kazuhironagai77:20210418235705p:plain

Exposureの設定でGame Settingを外します。

f:id:kazuhironagai77:20210418235723p:plain

Game Settingになっていると光具合が動的に変化してしまうので光具合にブレが生じてしまいます。

Bloomのチェックも外します。

f:id:kazuhironagai77:20210418235741p:plain

Bloomって何してるんでしたっけ?

WikipediaのBloom (shader effect)[2]によると強く光っている部分がはみ出して回りをぼやかす事を指しているようです。

もっと分かり易い説明がありました。UE4DocumentationのBloom[3]です。

f:id:kazuhironagai77:20210418235805p:plain

もうそのままです。

以上です。

ちょっと疑問が沸いてきたんですが、ここで紹介しているやり方はこの人が考えた方法なんでしょうか?それともEpic games社の技術者からやり方を聞いたんでしょうか?これで完全にLightmap以外の光の影響が消えているのかそれともParameterで操作出来る限界なだけでLightmap以外の効果もまだ残っている状態なんでしょうか?

よく分かりません。

別にこのTutorialの作者がそうだと言っている訳ではないですが、Designerの人の中には、ロジックが全く通じない人が居て、言っているそばから言った内容と180°違う事をする人がいます。まるで出来損ないのアニメの主人公のようにです。

もう少し解説がほしいですね。

ちょっとここで一端中止にしておきます。

もし続ける価値がある場合は来週、勉強します。

3.Widget内のBPの整理

もう、1カ月以上前の話なので、BPでどんな整理をしていたのか忘れてしまいました。

Blogを見直しましたが、はっきりとは書かれていません。

Blogを見直していて思い出したのですが、BeginPlay関数で変数にGame ModeとGame InstanceをAssignし、その変数からGame ModeとGame Instanceにアクセスすると、BPが格段に見やすくなる事を発見したはずです。それでそれを元に整理したはずですが、その辺の記述が全くありません。

今週はその辺から直してみます。

3.1 Combat_Itemウィジェットの整理

Combat_Itemウィジェットですが、Parent Widget変数やItem変数を繰り返し呼び出しています。

f:id:kazuhironagai77:20210418235851p:plain

Parent Widget変数やItem変数の呼び出しは一回にしてRe-route ノードを使用します。

f:id:kazuhironagai77:20210418235909p:plain

こんな感じで整理しました。

整理している内にProgramが動かなくなったら大変なので、テストして動作確認もしておきます。

このWidgetは戦闘で使用するアイテムを選択した時にそのアイテムを使用する対象者を選択するためのボタンを表示する機能が実装されています。

ここがきちんと動くように確認します。

f:id:kazuhironagai77:20210418235926p:plain

使用するアイテムを選択します。

f:id:kazuhironagai77:20210418235944p:plain

使用する相手を選択します。

f:id:kazuhironagai77:20210419000013p:plain

セリフの今まで通り表示されています。

f:id:kazuhironagai77:20210419000038p:plain

この部分のセリフはちょっと不自然ですね。後で直します。

普通に動いていますね。大丈夫でしょう。

念のためにOnClicked_ButtonItemにBreak pointを付けて確認して見たら、

f:id:kazuhironagai77:20210419000055p:plain

この画面から動かなくなってしまいました。

f:id:kazuhironagai77:20210419000111p:plain

Break pointを付けた時だけ発生するこの現象もバグの一種と考えるべきなのでしょうか?

良く分かりませんね。

一応、原因だけ追究しておきます。

通常の場合だと、アイテムを選択した時点で、そのアイテムの効能を表示しているWidgetは消えています。

f:id:kazuhironagai77:20210419000129p:plain

カーソルをアイテム名が表示されているボタンに乗せた時に以下の実装で、Combat_DisplayToolImageウィジェットを表示させています。

f:id:kazuhironagai77:20210419000146p:plain

このWidgetが消える前にアイテム名が表示されているボタンをクリックしているから今のバグが発生しているはずです。

直してみます。

ボタンをクリックした時も、このWidgetが消えているかどうか確認して消えていない時は消すようにします。

まず、このWidgetを変数にassignします。

f:id:kazuhironagai77:20210419000209p:plain

この変数がwidgetを保持している時、ClearするためのCustom Eventを作成します。

f:id:kazuhironagai77:20210419000226p:plain

このEventをボタンをクリックした時も呼び出す事にします。

f:id:kazuhironagai77:20210419000241p:plain

勿論、カーソルがボタンから外れた時も呼び出します。

f:id:kazuhironagai77:20210419000258p:plain

これでBreak pointでDebugしている時でも、Combat_DisplayToolImageウィジェットが消えるはずです。

テストします。

f:id:kazuhironagai77:20210419000313p:plain

Debug中ですが、既にCombat_DisplayToolImageウィジェットは消えています。

その後、アイテムを使用する相手を選ぶと、読みましたボタンが表示され普通に戦闘を続行出来ました。

f:id:kazuhironagai77:20210419000329p:plain

出来ました。

3.2 Itemウィジェットの整理

今度はItemウィジェットを整理します。

このItemウィジェットは、道具屋で買い物をする時に表示される商品ボタンと、Pause 画面でアイテムを使用する時に、所持アイテムとして表示されるアイテムボタンを表すWidgetです。

f:id:kazuhironagai77:20210419000400p:plain

道具屋で買い物をする時に表示される商品ボタンです。

f:id:kazuhironagai77:20210419000417p:plain

Pause 画面でアイテムを使用する時に、所持アイテムとして表示されるアイテムボタンです。

f:id:kazuhironagai77:20210419000434p:plain

在庫表と表示されていますが、道具袋の中身と言う意味です。ここも直しておきます。

Itemボタンをクリックした時の実装です。

f:id:kazuhironagai77:20210419000452p:plain

上が、Pause画面でItemを使用した時です。Itemの種類に応じてHPやMPを追加します。その後で、RPGGameInstanceBP内のItemsから使用したItemを消去します。

下が、道具屋でItemを買った時です。Itemの値段に応じて所持金が減ります。その後で、RPGGameInstanceBP内のItemsに購入したitemを追加します。

カーソルをボタン上に置いたときの実装も改善しました。このやり方はCombat_Itemウィジェットの時と全く同じです。

f:id:kazuhironagai77:20210419000509p:plain

テストします。

先ず道具屋で、アイテムボタン上にカーソルを乗せた時です。

f:id:kazuhironagai77:20210419000527p:plain

Display Item Tool Imageウィジェットがきちんと表示されています。

回復薬を買いました。金貨が5減って、道具袋に回復薬が追加されました。

f:id:kazuhironagai77:20210419000544p:plain

今度は道具屋を出て、Pause画面から道具を使用します。

Pause画面から道具袋を開きます。

f:id:kazuhironagai77:20210419000602p:plain

ダークイーサーを使用します。

f:id:kazuhironagai77:20210419000618p:plain

ダークイーサーが道具袋から消え、KUMOのMPが20無くなりました。

イーサーを使用します。

f:id:kazuhironagai77:20210419000636p:plain

MPが20回復しましたが、イーサーが道具袋から消去しました。

出来ているようです。

3.3 Target Characterウィジェットの整理

以下の様に整理しました。

f:id:kazuhironagai77:20210419000700p:plain

このウィジェットは戦闘でアイテムを選択した際に、そのアイテムの使用する相手を選択するためのボタンです。

テストします。

ゴブリンとの戦闘で回復薬、ダークイーサー、イーサーをKUMOに使用しました。

全部のアイテムがKUMOに対して指定した効果を示しました。

f:id:kazuhironagai77:20210419000715p:plain

多分OKです。

3.4 Weaponウィジェットの整理

このWidgetはPause画面で武器を装備する時に、所持している武器や防具を表示するボタンです。

更に、武器屋で、武器や防具を売ったり買ったりする時にも使用します。

現状は以下のように実装されています。

ある程度は整理されていますが、Game ModeやGame Instanceはあちこちで呼び出されています。

f:id:kazuhironagai77:20210419000738p:plain

整理します。

f:id:kazuhironagai77:20210419000754p:plain

正直、あんまり見やすいとは言えないですね。

やっぱり、一つのボタンに沢山の機能、Pause画面で所持している武器や防具を表示するボタンでそのボタンを押す時と装備出来る機能と、武器屋でこのボタンを押すと武器や防具を売ったり買ったりできる機能をつけてしまったからでしょうね。

この辺は考える必要がありますね。

一つのボタンに沢山の機能を詰めるだけつんで使い回すのか、それとも機能毎に、たとえ見た目は一緒でも、別のボタンを作成するのか?どちらが機能的に有利なんでしょうか?

テストします。

武器の売り買い、装備(剣盾、弓矢の両方)を試しましたが特に問題はありませんでした。

f:id:kazuhironagai77:20210419000814p:plain

3.5 PickupItemウィジェットの整理

ここからは直したBPの実装部だけ表示します。

f:id:kazuhironagai77:20210419000835p:plain

3.6 PauseEquipmentウィジェットの整理

f:id:kazuhironagai77:20210419000856p:plain

3.7 Inn_welcomeウィジェットの整理

f:id:kazuhironagai77:20210419000921p:plain

3.8 WeaponShopSellウィジェットの整理

f:id:kazuhironagai77:20210419000942p:plain

3.9 Widget 整理まとめ

これである程度複雑なBPの実装をしている全部のWidgetを整理しました。

この整理の方法を編み出した時は、これしかないと思うくらいの整理の方法だったのですが、一カ月たってから見直して見るとそんなにスゴイ訳でもありませんでした。

4.Map1からLandscape4にWarp出来るようにする。

折角ImportしたLandscape4にMap1からワープできるようにします。

以下のActorを作成しました。

f:id:kazuhironagai77:20210419001009p:plain

このBox内にPlayerが操作するキャラが侵入するとワープ出来る仕組みです。

実際はこのBox内に入ると以下のWidgetが開くようにします。

f:id:kazuhironagai77:20210419001024p:plain

「ワープします。」と選択するとLandscape4へワープします。「止めます。」を選択するとそのままです。

実装も以下のものだけです。

f:id:kazuhironagai77:20210419001040p:plain

テストします。

f:id:kazuhironagai77:20210419001058p:plain

以下のUIが表示されました。

f:id:kazuhironagai77:20210419001356p:plain

「ワープします。」を選択します。

Landscape4にワープしました。

f:id:kazuhironagai77:20210419001413p:plain

これだけだとちょっと物足りないですね。

もう少し考えます。

5.Landscape4で戦闘出来るようにする。

兎に角、簡単に作成します。その後で、徐々に直していこうと思います。

5.1 戦闘の準備

まずは、モンスターを静的に配置しました。

f:id:kazuhironagai77:20210419001446p:plain

この時点で画面がグルグル動いて3D酔いします。

思い出しました。カーソルを常に表示しておかないとこの現象が起きる事を。

先にカーソルを表示させます。

やり方を見るのに、Map1のLevel BPを開く必要があります。

でもMap1のBPを開いたらLandscape4のLevel BPが開けません。2つのLevel BPを同時に開くにはどうすれば良いでしょうか?

調べます。

UE4 Answer HubのHow do I open multiple Level Blueprints at the same time?[4]にやり方が書いてありました。

f:id:kazuhironagai77:20210419001506p:plain

そうこれ。

今まで、何度もやっていてこの方法で沢山のLevel BPを同時に開いて編集していました。

多少、裏技的な気もしますが、試してみましょう。

Map1のLevel BPで作成した変数、MyGameModeを検索します。

f:id:kazuhironagai77:20210419001522p:plain

Map1にあると検索結果が出て来ました。

この結果をクリックします。

Map1が開きました。

f:id:kazuhironagai77:20210419001537p:plain

Landscape4のLevel BPを開きつつ、Map1のLevel BPも開く事が出来ました。

これです。Show Mouse Cursor if Not関数です。自分で作成して名前を忘れてしまいました。

f:id:kazuhironagai77:20210419001552p:plain

この関数内の実装が、結構複雑でこの関数内の実装通りの手順でやらないと問題が発生したはずです。

今回は無難にこの関数をそのまま使用しましょう。

ついでに、BGM、Game Instance、Game ModeそしてThird Person Characterの変数も作成しているのでこれもコピーします。

f:id:kazuhironagai77:20210419001608p:plain

f:id:kazuhironagai77:20210419001616p:plain

以下の様に成りました。

f:id:kazuhironagai77:20210419001632p:plain

テストします。

f:id:kazuhironagai77:20210419001649p:plain

普通に動いています。

BGMが聞こえます。

5.2 戦闘出来る様にする。

試しに戦闘をしてみましょう。

f:id:kazuhironagai77:20210419001710p:plain

あれ。近づいても戦闘が始まりません。

どうしてでしょう?

分かりました。

MonsterはPlayerが操作するキャラがbox内に侵入するとRPGGameModeBPにあるEvent DispatchersであるCombat Beginを呼びます。

f:id:kazuhironagai77:20210419001728p:plain

このCombat BeginはBindしていないので、呼ばれても何もしません。

Combat BeginのBindは、Map1でしていました。以下にその実装部を示します。

f:id:kazuhironagai77:20210419001753p:plain

f:id:kazuhironagai77:20210419001801p:plain

これをLandscape4でも作成する必要があります。

このやり方はActorとLevel BPは直接、データのやり取りは出来ないですが、間にGameModeBPのEvent Dispatchersを挟むとActorとLevel BPでやり取り出来てしまうと言う秘策でした。

すっかり忘れていました。

この部分の実装をそのまま使用します。

f:id:kazuhironagai77:20210419001824p:plain

解説します。

時間を記録する変数です。戦闘から戻って来た時に、何時も朝になっていたら大変ですので、戦闘の始まった時間をGame Instanceに記録しておきます。

f:id:kazuhironagai77:20210419001847p:plain

Landscape4はまだGood Skyを組んでいないので、この部分は今回は何もしません。

場所を記録する変数です。戦闘から戻って来た時に何時も最初の場所になっていたらユーザーは発狂します。

f:id:kazuhironagai77:20210419001903p:plain

同様に向きを記録する変数です。戦闘から戻って来た時に何時も同じ向きになっていたらかなり使いづらいです。

f:id:kazuhironagai77:20210419001917p:plain

思い出してきました。

この向き、幾らここで指定してもPlayer Startの向いている方向に向き直してしまって直すのが大変でした。

最終的にはPlayer Startを消す事で解決しました。

f:id:kazuhironagai77:20210419001932p:plain

今回は、向きまでは関係ないので、無視しておきます。

最後にBattle Field Mapにワープします。

f:id:kazuhironagai77:20210419001947p:plain

これだと、戻ってこれませんね。Map1に戻ってしまいます。

LocationをMap1の最初の発生場所にセットしておきます。

f:id:kazuhironagai77:20210419002005p:plain

向きもMap1の最初の発生と同じにします。

f:id:kazuhironagai77:20210419002020p:plain

これでテストします。

戦闘マップには移動しました。

f:id:kazuhironagai77:20210419002044p:plain

何かエラーが出ています。

f:id:kazuhironagai77:20210419002058p:plain

死んでしまった。

f:id:kazuhironagai77:20210419002115p:plain

予想外でした。武器も魔法も持っていなかった。

後、Z軸も間違っていまいした。

f:id:kazuhironagai77:20210419002128p:plain

NavMeshはMap1のNavMeshのサイズと位置を変更したのでその事を指していると思われます。Map1を開いてBuildします。

Buildしたら以下の警告が出ました。

f:id:kazuhironagai77:20210419002146p:plain

LandscapeのLODを見たら、-1にセットされています。

f:id:kazuhironagai77:20210419002201p:plain

良く分からないですね。

後で調べます。

もう一回テストします。今度は武器を装備してきました。

f:id:kazuhironagai77:20210419002217p:plain

普通に戦闘出来ました。

戦闘に勝利して戻ってくると

f:id:kazuhironagai77:20210419002233p:plain

神官、道具屋、武器屋の三人のNPCがいません。

あれ、バグったと焦っていたら、

f:id:kazuhironagai77:20210419002255p:plain

後ろにいました。

取りあえず、ここまでは成功としましょう。

5.3 戦闘終了後に、同じMapに戻って来れる様にする。

まず戦闘終了後に、必ずMap1に飛ぶ理由は、RPGGameModeBPでそう実装しているからです。

f:id:kazuhironagai77:20210419002317p:plain

ここに戦闘前のマップに戻るようにセットすれば、戦闘終了後に、同じマップの同じ場所に戻って来れるはずです。

RPGGameInstanceBPに、戦闘前のマップのマップの名前を保存するための変数、MapNameBeforeBattleを作成しました。

タイプは取りあえずNameにしました。

f:id:kazuhironagai77:20210419002333p:plain

はい。

戦闘終了後、RPGGameInstanceBP のMapNameBeforeBattleに書かれているマップに戻るようにRPGGameModeBPで実装し直しました。

f:id:kazuhironagai77:20210419002348p:plain

新しいLevelを開いた時、以下のコードをevent begin playに実装する事でRPGGameInstanceBP のMapNameBeforeBattleにmapの名前を記録します。

Map1とLandscape4のLevel BPに実装しました。

f:id:kazuhironagai77:20210419002413p:plain

これで、戦闘が終わったらもとのLandscapeに戻るはずです。

Landscape4で戦闘してみました。

f:id:kazuhironagai77:20210419002430p:plain

Landscape4に戻って来てます。

戻ってきていますが、場所が最初にワープした所です。

5.4 戦闘終了後に、同じMapの同じ場所に戻って来れる様にする。

理由が分かりました。

RPGGameModeBPの以下の箇所でPlayerが操作するキャラの発生場所を指定してますが、開いているLevelがLandsape4の場合、戦闘後でもワープでも同じ個所を指定しています。

f:id:kazuhironagai77:20210419002456p:plain

直します。

RPGGameInstaceBPにBoolean変数であるBackFromBattleFieldを作成します。

f:id:kazuhironagai77:20210419002511p:plain

戦闘画面に飛んだらBackFromBattleField変数をTrueにセットするようにします。

f:id:kazuhironagai77:20210419002536p:plain

戦闘が終り元のマップに戻って来た時に、BackFromBattleField変数がTrueならば、戦闘前の場所へ戻るようにします。

f:id:kazuhironagai77:20210419002600p:plain

何故か前の実装ではMap1はDefaultで指定されていたのでそこも直します。

f:id:kazuhironagai77:20210419002617p:plain

これでlandscape4内で戦闘した場合でも、戦闘が終わったら元の場所に戻ってくるはずです。

ただし、Landscape4ではMonsterは静的に生成しているので、全く同じ場所に戻ってきたらまた戦闘が始まってしまいます。

それを避ける為に少し戻る位置をずらしておきます。

f:id:kazuhironagai77:20210419002639p:plain

テストします。

Landscape4で戦闘を終了したらLandscape4の戦闘した位置から200cmx軸側にずれた位置に戻って来ました。

f:id:kazuhironagai77:20210419002658p:plain

大成功ですが、200cmだと本当にモンスターの隣でした。500cmに直しておきます。

念のために、Map1でも戦闘してみましたが、Map1の時の普通に元の場所に戻って来ました。

f:id:kazuhironagai77:20210419002715p:plain

一応出来ました。

今週の予定は終わってしまったので別な事を時間がある限りやっていきます。

6.Warp Spotの改良

Warp Spotを作成しましたが、色々な点が酷いです。

f:id:kazuhironagai77:20210419002742p:plain

まず、近づくとどこからでもWidgetを表示します。

f:id:kazuhironagai77:20210419002805p:plain

単に後ろを通っただけでもWidgetを表示します。

しかもWidgetを表示したまま移動できます。

f:id:kazuhironagai77:20210419002822p:plain

直していきます。

6.1 NPCの復習

NPCとの会話は上手く作成出来ていたはずです。

それを利用して直します。

NPCに近づくと(!!)が光ります。

f:id:kazuhironagai77:20210419002843p:plain

光っている状態の時にEを押すとWidgetが開きそのNPCと会話出来ます。

f:id:kazuhironagai77:20210419002910p:plain

会話中はキャラを動かす事は出来なくなります。

6.2 (!!)の表示

イキナリ、Widgetを表示するのではなく(!!)を表示します。

Warp Spotを改良するよりNPC_Personを改良した方が簡単そうです。

f:id:kazuhironagai77:20210419002943p:plain

f:id:kazuhironagai77:20210419002950p:plain

NPC_Personをduplicateして以下の様に改良しました。名前はWarpSpot_NPCとしました。

f:id:kazuhironagai77:20210419003006p:plain

とりあえずInstanceをMap1に配置し、そのInstanceの設定は以下のようにしました。

f:id:kazuhironagai77:20210419003025p:plain

近づくと(!!)が光ります。

f:id:kazuhironagai77:20210419003043p:plain

後ろから近づいても(!!)が光るだけになりました。

f:id:kazuhironagai77:20210419003058p:plain

6.3 職業の作成

NPCは職業によってどのWidgetを開くかを決定します。

UE4C++のRPGGameModeにNPCが成れる職業の一覧があります。

f:id:kazuhironagai77:20210419003118p:plain

ここにWarp Gate Keeperを追加します。

うん。Warp SpotよりWarp Gateの方がカッコイイですね。Warp GateとWarp Gate Keeperで統一します。

f:id:kazuhironagai77:20210419003137p:plain

追加しました。

Buildして一回、UE4Editorを閉じます。再起動します。

ThirdPersonCharacterのWarpGatekeeperに以下のコードを追加します。

f:id:kazuhironagai77:20210419003200p:plain

テストします。

(!!)が表示されている状態でEを押すと、Warp用のWidgetが表示されました。

f:id:kazuhironagai77:20210419003215p:plain

f:id:kazuhironagai77:20210419003223p:plain

Set Game PausedとSet Input Mode Game And UIを使用しているので、Widgetが開いている間はキャラは全く動けません。

ワープを選択するとLandscape4に移動しました。

f:id:kazuhironagai77:20210419003240p:plain

かなり良くなりました。

7.まとめと感想

今週はまだ時間がありますが、キリが良いのでここで終わりにします。

今週は、

  • Environmental artist用のTutorialとしてBecoming an Environment Artist in Unrealの残りとConstructing Believable Environmentの最初の章であるIntroducing Global Illuminationを途中まで勉強しました。
  • WidgetBPのコードを読みやすいように整理しました。
  • Map1からLandscape4にWarp Gateを使用する事で移動出来るようにしました。
  • Landscape 4でモンスターと戦闘が出来るようにしました。

来週は、

  • バグの直し
    • 戦闘中にアイテムを使用した時のセリフの直し
    • Map1でBuildするとLandscape_0 instead mesh…と警告される
  • Effectの勉強
  • Effect(魔法陣)をWarp Gateに追加する。
  • Landscape4にもっとモンスターを配置する。
  • Landscape4からMap1に戻るためのWarp Gateを作成する。
  • 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する。
  • Map1の家の影が真っ暗な理由をConstructing Believable Environmentで勉強したGlobal Illuminationと絡めて勉強する。

などをやろうと思います。

8.参考文献(Reference

  1. Gamers Nexus. (2019, February 28). Faking RTX Global Illumination vs. RTX | 100% Ray-Traced Game, Pt 1 [Video]. YouTube. https://www.youtube.com/watch?v=CuoER1DwYLY
  2. Bloom (shader effect). (2020, December 31). In Wikipedia. https://en.wikipedia.org/wiki/Bloom_(shader_effect)
  3. Epic Games. (n.d.-a). Bloom. Unreal Engine Documentation. Retrieved April 18, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/PostProcessEffects/Bloom/index.html
  4. Epic Games. (n.d.-b). How do I open multiple Level Blueprints at the same time? - UE4 ANSWERHUB. UE4 ANSWERHUB. Retrieved April 18, 2021, from https://answers.unrealengine.com/questions/792583/how-do-i-open-multiple-level-blueprints-at-the-sam.html

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する  マップの作製 Part 5

f:id:kazuhironagai77:20210411224752p:plain

<前文>

<Matt Gaetz氏とアジア人への迫害について>

米国下院議員であるMatt Gaetz氏の児童買春疑惑は大変なスキャンダルですが、Foxニュースを代表とする宗教右派の人達から、彼に対する批判は全く聞かれません。宗教右派の人達は、アニメの絵にすらケチつける位、児童買春に対して厳罰を求めていたのですから、今回のスキャンダルには責任もって対処して貰いたいです。

しかし、残念な事ですが、宗教右派の人達は、自分たちの仲間が行ったと思われる児童買春疑惑を追及する代わりに、アジア人を迫害する事に熱心な様です。今、アメリカ国内におけるアジア人への暴行件数はウナギ登りです。

勿論、このアジア人への迫害には、韓国系と黒人が仲が悪い傾向があるとか、中華街からコロナが流行ったなどの根拠の無い噂などの理由もありますが、根本は宗教右派がFOX NEWSを使って流行らせた手法「事実じゃない事を、さも事実であるかのようにうそぶいて、だから差別や暴行しても良いとの論調に持っていく。」が主な原因です。

私は昔から主張していましたが、Foxニュースを代表とする宗教右派の連中が嘘を言っているのは全てのアメリカ人が知っていたのです。知っていたのですが、それによる被害者が自分達でないから娯楽として受け入れていたのです。それが今回、コロナや連邦議会での暴動によって初めて自分達に害が及ぶ可能性が出て来たので、宗教右派を切り捨てる事に決定したのです。

大体、キリスト教自体が、罪を犯してしまった自分を悔いてその罪を背負って生きる。と言う人間の内面の問題を扱った宗教なので、人間の外面を扱う政治問題に介入する時点で、その組織がカルト化している証拠でしょう。潰されても仕方ないと思います。

罪を犯してしまったと言えば、嘘をついている事は結構、罪深く感じます。しかし彼等にはそれが無かったのは何故なんでしょうか?

多分ですが彼らが通う教会で「嘘をつく事をキリストが望んでいる。」と洗脳していたんでしょうね。それで嘘をつく事に対して無感性になってしまったんでしょうね。

そう言えば、今、日本でもネトウヨとかjアノンとか呼ばれている一団がいます。彼らは、PCR検査は無駄と主張したり、特定の政治団体の人(例えば、先週出て来たSidney Powell氏)を嘘をつきまくって擁護したりし、又その逆に非難していますが、彼らもまたカルト化した宗教団体の信者なんでしょうか?

そんな気がします。

Matt Gaetz氏の児童買春疑惑について興味を持ったせいで、最近、Redditばっかし読んでいたんですが、何で全てのアメリカ人が、Foxニュースを代表とする宗教右派の連中が嘘を言っているの知っていたのか分かりました。彼らが嘘をついているのは何となく、彼らの顔や彼らの話を聞いている人の表情から推測出来たのですが、一つ一つの具体的な問題に対してどこまでが本当で、どこから嘘なのかまでは私には分かりませんでした。アメリカ人が一つ一つの嘘を見抜けたのはRedditで全部のニュースのトピックについて徹底的に議論しつくしていたからだったんです。

Matt Gaetz氏の児童買春疑惑についてもあらゆる角度から議論されていて大変勉強になりました。こんだけ一つのニュースに対して、みんなで議論したら嘘ならたちまちばれる訳です。

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

<本文>

1.今週の予定

今週もLandscapeの勉強と作成を行います。以下の事を行います。

  • Displacement mappingの実装
  • 針葉樹用の緑と沼用の地面のMaterialの追加
  • 沼の整理
  • ゲーム内のlandscapeの作成。

今週でLandscapeの作成は終わらせられるように頑張ります。

2.Displacement mappingの実装

Displacement mapping を実装します。

2.1 Displacement mappingの勉強

取りあえず、Plane上でDisplacement mapping をやってやり方を完全に理解します。

Tutorialを探したのですが、これと言うヤツは見つかりませんでした。その中でこのTutorial(Easily Set Up Displacement Maps in Unreal Engine using Quixel Bridge)[1]が一番簡潔に、MegascansのDisplacement mappingの使用方法を説明していました。しかし途中でPolygonを増やしたplaneを作成するためにCinema 4Dを使用しています。この部分はBlenderで置き換える必要があります。

その後でlandscapeのDisplacementを作成します。取りあえず見つけたTutorialがこれ(How to Use Megascan Displacement for Landscapes in Unreal Engine 4)[2]です。

Blender からUE4にMeshをexportするのはどうしましょう?私はBlender2.8以降の新しいバージョンのやり方は知りません。このTutorial([New] Blender To Unreal Plugin!)[3]がBlenderからUE4へMeshをExportするやり方を説明していました。ざっと見た感じでは詳しく解説していそうです。

今のBlenderのバージョンを調べたら2.92が最新みたいです。昔2.80をdownloadした後、全く勉強していません。

Meshをsubdivideする方法さえ分かればそんな勉強する必要はないと思いますが、どうしましょう?この機会にBlenderの使用方法も勉強しましょうか?勉強するなら、2.92を入れた方が良いんでしょうか?

Tutorial([New] Blender To Unreal Plugin!)[3] ではBlender 2.83 を使用していました。ここで使用しているAdd-onであるBlenderToolが2.80に対応していれば、特に何もしなくても良いかもしれません。まあ最新のBlenderをここでDownloadしても別に良いですけど。

2.2 Easily Set Up Displacement Maps in Unreal Engine using Quixel Bridge[1]の勉強

先にこのTutorialを途中までやってから考えます。

使用しているTextureですが、MegascansからではなくGameTexture.comからBridgeにImportしてそれを更にUE4にexportしていました。

f:id:kazuhironagai77:20210411224910p:plain

そのやり方は前のTutorialを見てね。って。

あー。

凄い分かり易いと思ったのに。

しょうがないですので、前のTutorialである、Converting Your Favorite Render Engine Materials for Unreal Engine[4]を見たら、最初の5分で滅茶苦茶分かり易く説明されていました。例に使用されていたのはRd-Textures社からのdownload方法ですが、多分同じでしょう。

これなら出来そうです。

f:id:kazuhironagai77:20210411224932p:plain

あれ、無料じゃないの。

f:id:kazuhironagai77:20210411224946p:plain

フェエエー。

この人がTutorialを作成した時はFreeになっている。

f:id:kazuhironagai77:20210411225003p:plain

今はPremiumです。

ちょっと考えます。

他の会社のTextureをQuixel BridgeにImportしてそれをUE4にExportする方法は試してみたいです。

これがFreeなのでこっちで試してみます。

f:id:kazuhironagai77:20210411225019p:plain

Downloadしました。

f:id:kazuhironagai77:20210411225033p:plain

Quixel Bridgeを開きます。

f:id:kazuhironagai77:20210411225046p:plain

Converting Your Favorite Render Engine Materials for Unreal Engine[4]ではZipの状態でImportするよりは、開いてImportした方が良いと言っていますが、

面倒なのでImport Zip Filesでやってしまいます。

f:id:kazuhironagai77:20210411225100p:plain

f:id:kazuhironagai77:20210411225108p:plain

となっています。

f:id:kazuhironagai77:20210411225124p:plain

四角で囲ったMrao.pngだけImportしませんね。これは何なんでしょうか?

Metalness-Roughness-Ambient Occlusionの略だそうです。となるとこれもImportする必要がありますね。

以下の様に変更しました。

f:id:kazuhironagai77:20210411225139p:plain

Importします。

2kでUE4にexportします。

f:id:kazuhironagai77:20210411225155p:plain

普通に出来ました。

と思ったら、Tutorial([New] Blender To Unreal Plugin!) [3] でEnable Displacementにチェックを入れてからImportしろと言っています。

f:id:kazuhironagai77:20210411225214p:plain

更に、Quixel BridgeでもDisplacementにチェックが入っているかを確認しろとあります。

f:id:kazuhironagai77:20210411225232p:plain

もう一回Importし直しました。

Material instanceを開くと以下の様になっています。

f:id:kazuhironagai77:20210411225254p:plain

サンプルの様な銀ピカではないですね。

それはともかく、

以下のDisplacement Amountの値を変化させればDisplacementが起きるそうです。

f:id:kazuhironagai77:20210411225311p:plain

だいたい8くらいから以下の様に飛び出してきました。

f:id:kazuhironagai77:20210411225327p:plain

以上でした。

これはこれで知らなければならない事なのですが、Displacement mappingの実装 (implementation) についての解説、つまりBPの書き方についての解説が全くなかったです。

このTutorialでも述べられていましたが、MegascansからTexture をUE4にExportする時にMegascansがDisplacement mappingを実装したMaterial とそのInstanceを作成してくれるので、BPを敢えて触る必要はないからです。

これは、そのMaterial Instanceのパラメーターを調節して最適値を見つける事が仕事であるdesignerにとっては適切な勉強範囲ですが、ゲーム制作でEngineerになるためにUE4を勉強しているProgrammerにとっては正しくないです。UE4を使用したゲーム制作でEngineer を名乗るためには、UE4におけるDisplacement mappingの実装方法を知る必要があります。

ちょっと考えます。

後、おまけですがMaterialの実装を変更してもっと銀色にしてみました。

元のMaterialの実装を見てみたらMetalnessのoutputにRPGを使用していました。

f:id:kazuhironagai77:20210411225347p:plain

新しいMaterialを作成してMetalnessにR、RoughnessにGを接続しました。

f:id:kazuhironagai77:20210411225403p:plain

銀色に光りました。

f:id:kazuhironagai77:20210411225426p:plain

2.2 Displacement mappingのBP内における実装について

考えた結果、判明したんですが、確かにUE4におけるDisplacement mappingのBPの実装  (implementation) そのものについては勉強出来ませんでしたが、それ以外でUE4でDisplacement mappingを使用するために必要な事は全て勉強出来ました。

もう一つ大事な事を忘れていたのですが、先週、Displacement Mappingについて自分でまとめていました。

この内容を読み直してみたら、displacement mappingの実装 (implementation) 方法について書いていました。

これを復習します。その後で、Megascansが提供しているMaterial内でどのようにDisplacement mappingが実装されているのかを確認してみます。これで多分、UE4におけるdisplacement mappingの実装方法について勉強出来ると思います。

2.2.1 先週のBlogにおけるDisplacement mappingのまとめ

先週のblogにおけるDisplacement mappingは簡単でした。

MaterialのOutputは以下の様になっています。

f:id:kazuhironagai77:20210411225502p:plain

この中でDisplacement Mappingに必要なのは、World Displacement とTessellation Multiplierです。

この二つを使用するためには、以下の事をする必要があります。

f:id:kazuhironagai77:20210411225521p:plain

World Displacementはverticesの位置を移動させます。Tessellation MultiplierはLandscapeの表面のポリゴンの量をどれくらいにするかを指定します。

のでWorld Displacementの値を変化させます。

f:id:kazuhironagai77:20210411225608p:plain

Displacement Mappingが出来ました。

2.2.2 World Displacement とTessellation Multiplierについて

ちょっと古いですが公式のDocumentでWorld Displacement [5]とTessellation Multiplier [6]が解説されていました。

World Displacementについてですが、

f:id:kazuhironagai77:20210411225636p:plain

と書かれています。

Tessellationってポリゴン化する事でしょう?Tessellation Verticesってどういう意味なんでしょうか?ポリゴン化した後のVerticesを動かすと言う事なんでしょうか?

このサイト (What is Tessellation in computer graphics )[7] によると

f:id:kazuhironagai77:20210411225701p:plain

Tessellationとはポリゴン化するだけではなく、ポリゴンを更に細かく分割する行為も含まれるようです。

この意味から推測するとTessellation Verticesは、ポリゴンを更に細かく分割した際に生成された頂点を指すと思われます。

最初はポリゴン化した後のVerticesをTessellation Verticesというのではないかと予測しましたが、どっちが正しいのでしょうか?

What is Tessellation in computer graphics [7] のDragonseel氏の解答にほとんど答えが書かれていました。

彼の解答によるとTessellationはTessellation Control Shader, Tessellation Primitive Generation, そして Tessellation Evaluation Shaderの3つのShaderで行われるそうです。

そんなShaderは知りません。初めて聞きました。

それぞれのStageでは、

  • Tessellation Control Shaderでは、頂点を更に細かくするために、細分化のタイプと新しく作成する頂点の数を指定します。
  • Tessellation Primitive Generationでは、Tessellation Control Shaderで指定した条件で実際に細分化します。この過程はHardwareが勝手にやる為Programmerは関与出来ません。
  • Tessellation Evaluation Shaderでは、細分化した際に発生した新しい頂点を呼び出して色々な事をしますが、どのようにポリゴン化するのか、とその呼び出した頂点の位置を指定したりもします。

が行われるみたいです。

はい。

分かりました。

順番が逆になってしまいますが、Tessellation MultiplierがTessellation Control Shaderにおけるポリゴンの細分化の条件を指定して、World DisplacementがTessellation Evaluation Shaderにおける細分化した際に発生した新しい頂点の位置の指定を担当していると考えると辻褄があいます。

となるとTessellation VerticesはTessellation Evaluation Shader内で呼び出されるTessellation Primitive Generationで新しく作成された頂点を指しているはずです。

もう一度、公式のDocumentのWorld Displacement [5]を読み直してみると

f:id:kazuhironagai77:20210411225742p:plain

Meshのベースの頂点ではなくて…とわざわざ述べています。

やっぱりこの文章からもTessellation VerticesはTessellation Evaluation Shader内で呼び出されるTessellation Primitive Generationで新しく作成された頂点を指していると考えられます。

はい。

ところでTessellation MultiplierがTessellation Control Shaderにおけるポリゴンの細分化の条件を指定できるならBlenderで予め細かくしたplaneを作成してUE4にimportする必要もないんじゃないでしょうか?

ムム…。

検討してみましょう。

ですがその前にMegascansが提供しているMaterial内でどのようにDisplacement mappingが行われているのかを確認します。

2.2.3 Megascansが提供しているMaterialのDisplacement mappingについて

以下の様な実装になっていました。

f:id:kazuhironagai77:20210411225809p:plain

MF_DisplacementノードのHeight(s)がどうなっているのか次第ですね。

以下の様になっていました。

f:id:kazuhironagai77:20210411225830p:plain

私が先週適当に作成したのか以下のヤツです。

f:id:kazuhironagai77:20210411225850p:plain

最初の掛け算の部分は、50のConstantを賭けているのがDisplacement Amountに変更されただけでほぼ同じです。Megascansの方はその後で、Displacement Amountを2で割った値を引いています。更にVertexNormalWSをかけています。

そう言えば、公式のDocumentのWorld Displacement [5]でもVertexNormalWSを掛けていました。

f:id:kazuhironagai77:20210411225913p:plain

VertexNormalWSって何の値なんでしょうか?

VertexNormalWSの公式のDocument [8] を見てみました。

f:id:kazuhironagai77:20210411225938p:plain

World座標における頂点の法線のデータみたいです。

しかし超大事な事をその後で言っています。この値はvertex shader内で実行される場合のみ使用出来ますと。

となると、以下の部分の計算はVertex Shader内で行っているはずです。

f:id:kazuhironagai77:20210411225958p:plain

ここで頂点の法線で掛けている訳ですからこの時点で頂点以外のDisplacement mappingの値は消えてします訳です。

つまり、先程考えていたTessellation VerticesにDisplacement mappingの値を直接パスする事は出来ないと言う事になります。

勿論、UE4のMaterialの使用方法を極めれば出来るのかもしれませんが上記のような組み方では無理でしょう。

ただしTessellation Verticesの分割具合とDisplacement mappingの変化を見ると、

以下の様にTessellation VerticesがBaseのVerticesと同じ時は、

f:id:kazuhironagai77:20210411230020p:plain

全くDisplacementが起きていませんが、

f:id:kazuhironagai77:20210411230039p:plain

以下の様にTessellation VerticesがBaseのVerticesより沢山生成された場合は、

f:id:kazuhironagai77:20210411230058p:plain

Displacementが起きています。

f:id:kazuhironagai77:20210411230123p:plain

BaseのVerticesの法線のみがDisplacementのデータを持っていてこんな結果になるんでしょうか?

実際はTessellation Verticesの法線とDisplacementのデータを掛けているんじゃないんでしょうか?と思いました。

直接、Shader code見れば何か分かるかもと試してみましたが以下の量のShaderが表示されました。

f:id:kazuhironagai77:20210411230141p:plain

流石に、今の私ではこれを読んで理解するのは無理です。

これはあきらめます。

最後にですが、私が先週作成したDisplacement mappingの実装にVertexNormalWSを掛けた所、

以下の結果が、

f:id:kazuhironagai77:20210411230157p:plain

こんな風になりました。

f:id:kazuhironagai77:20210411230211p:plain

Displacementの高さ以外の軸に対する値が0になったみたいです。

2.3 Tessellation Multiplierの使用方法について

厳密に言えばTessellation Multiplierを使用する目的は、Meshの分割をカメラからの距離に応じて指定するもので、Displacement Mappingとは違います。しかしLandscapeにDisplacement Mappingを使用する時は、必ずTessellation Multiplierも指定する必要があるので一緒にここで勉強します。

公式のDocumentのTessellation Multiplier [6]で解説されていますが、今まで勉強した以上の情報は書かれていません。

以下にMegascansから提供されたMaterialの実装部分を示します。

f:id:kazuhironagai77:20210411230234p:plain

3つのparameterがあります。Distance Offset, Distance Fade, そしてTessellation Multiplierです。

まずこれらのParameterの意味を調べます。

以下の様なセットを作成しました。

f:id:kazuhironagai77:20210411230251p:plain

これでParameterをいじって配置してある銀色の球のmeshの変化を見ようと思います。

まずは何もしていない状態です。

f:id:kazuhironagai77:20210411230307p:plain

Distance Offsetを1000まで上げました。

f:id:kazuhironagai77:20210411230321p:plain

最初の球のmeshが細かくなりました。

数字を挙げると奥の球のMeshも更に細かくなりました。

Offsetと言う名前から考えても、この数字が高くなるとMeshが細かくなり始める位置がカメラにもっと近づくのではないでしょうか?多分ですが。

次はDistance Fadeの値を変化します。

500から5000に変えました。

f:id:kazuhironagai77:20210411230336p:plain

これも最初の球のMeshが更に細かくなりました。Distance Offsetの時と違い、次の球のmeshも少しだけ細かくなっています。

距離によってMeshの細かさが減少しますが、その減少の割合を操作するParameterみたいです。数値が大きい程減少する割合が小さくなるみたいです。

最後はTessellation Multiplierです。これは見なくてもMeshの細かさを調節するParameterと予想出来ます。

初期値からTessellation Multiplierの値を変えたら、何も変化しませんでした。

良く考えたら、Tessellation Vertices がbase のmeshと同じなら分割の数をいくら増やしても0*(分割の数)なので変化ないのは当たり前でした。

以下の条件でやってみます。

f:id:kazuhironagai77:20210411230353p:plain

Tessellation Multiplierの値を2にしました。

f:id:kazuhironagai77:20210411230410p:plain

明らかに頂点の分割が細かくなっています。

此処まで理解したのでもう一回以下の式を参考にして考えてみます。

f:id:kazuhironagai77:20210411230425p:plain

Distance Offsetの値を凄く高くすると、Subtractで値がマイナスになりDivideでDistance Fadeがどんな値でもマイナス。よってSaturateで0に補正され1-xでは1となるはず。

ので、Distance Offsetの値がある程度以上の大きくなると全ての球のメッシュの分割が同じ様に起きると考えられます。

実際は、

f:id:kazuhironagai77:20210411230444p:plain

Distance Offsetの値を幾ら大きくしても近いmeshの方が細かく分割されています。

うーん。分からない。

How to Use Megascan Displacement for Landscapes in Unreal Engine 4 [2]を見たら、完璧に説明されてました。

2.4 How to Use Megascan Displacement for Landscapes in Unreal Engine 4 [2]で学ぶTessellation Multiplierの使用方法について

このTutorialで説明されていた通りに説明します。

まずDistance fadeですが、カメラのある位置からどれくらいの距離まで、Meshを細分化するかを決定します。

以下の例ではDistance fadeの値が5000です。

f:id:kazuhironagai77:20210411230507p:plain

Distance fadeの値を10000に増やしました。カメラから更に遠くのMeshまで細分化されています。

f:id:kazuhironagai77:20210411230522p:plain

Distance Offsetはこの細分化の距離を更に遠くに伸ばします。

f:id:kazuhironagai77:20210411230539p:plain

正直、Distance fadeとの違いが分かりません。

最後にTessellation Multiplierですが細分化の割合を細かくします。

f:id:kazuhironagai77:20210411230554p:plain

これは前から分かっていました。

Distance OffsetとDistance fadeの違いが分かりました。

Distance Offsetを3000、Distance fadeを0にした場合です。

f:id:kazuhironagai77:20210411230611p:plain

Meshの細分化のされ具合が距離に全く影響されていません。

一方で、Distance Offsetを0、Distance fadeを5000とした場合、

f:id:kazuhironagai77:20210411230626p:plain

Meshの細分化のされ具合が距離よって変わっています。

Distance Offsetを1000、Distance fadeを5000とした場合、最初の1000の部分は全て均等に細分化され、その後、距離に応じて細分化が減少しています。

f:id:kazuhironagai77:20210411230650p:plain

はい。完璧に理解しました。

Distance Offsetについてですが、何で球のmeshで試した時は距離に応じてmeshの細分化が変化したのでしょうか?

f:id:kazuhironagai77:20210411230711p:plain

多分ですが、meshの細分化はLODなどの別の要素の影響もあると思います。

その結果、球のmeshのこの条件では上手く出なかったのでしょう。

2.5 How to Use Megascan Displacement for Landscapes in Unreal Engine 4 [2]で解説された重要な点について

<Displacement Amountの正しい値の見つけ方>

Bridgeからmaterialを選択して3Dを表示させます。

f:id:kazuhironagai77:20210411230738p:plain

そのイメージと同じ位のデコボコになるようにDisplacement Amountの値を調節します。

f:id:kazuhironagai77:20210411230752p:plain

<Landscapeに今回の方法でTessellationをする場合の注意>

LandscapeにかかるTessellationはMaterial Instanceからだけではなく、LandscapeのLODからも影響されます。

LODからの影響を無くしたい場合は、LODのMax LODLevelの値を0にセットします。

f:id:kazuhironagai77:20210411230814p:plain

更にTessellationのTessellation Component Screen Sizeを0.01、Use Default Falloffのチェックを外します。

f:id:kazuhironagai77:20210411230830p:plain

こんな感じです。

f:id:kazuhironagai77:20210411230846p:plain

Materialの設定を変えないとDisplacement mappingはLandscapeを一枚の大きなタイルとしてみなすそうです。

その設定は、MaterialのTessellationにあるCrack Free Displacementです。これのチェックを外します。

f:id:kazuhironagai77:20210411230902p:plain

結構重要な情報が説明されていました。

2.6 LandscapeにDisplacement mappingを実装します。

それでは実装します。

まずLandscapeに使用しているMaterial instanceの元のMaterialである、Landscape4のTessellationのD3D11Tessellation ModeをFlat Tessellationに変更します。

f:id:kazuhironagai77:20210411230931p:plain

Landscape4では3つのMaterial functionが使用されています。

f:id:kazuhironagai77:20210411230945p:plain

まず、一番使用面積の大きいMF_GroundにDisplacement mappingを追加します。

MF_Displacementを使用する事にしました。

f:id:kazuhironagai77:20210411230959p:plain

Displacement TextureをMF_DisplacementのHeight(s)につなげます。

f:id:kazuhironagai77:20210411231014p:plain

UVsにつなげるTexCoordのサイズが分かりません。取りあえず、

f:id:kazuhironagai77:20210411231030p:plain

と繋げました。

Tessellationが効いているのは確認出来ますが、

f:id:kazuhironagai77:20210411231047p:plain

値を弄っても全く変化しません。

f:id:kazuhironagai77:20210411231111p:plain

別なMapにMF_Groundのみを使用したMaterialを作成してLandscapeに適用して確認します。

f:id:kazuhironagai77:20210411231127p:plain

f:id:kazuhironagai77:20210411231138p:plain

普通に効いています。

Landscape4に直接、MF_Displacementを追加してみます。

f:id:kazuhironagai77:20210411231205p:plain

今度はLandscape4_Instの値から操作出来ました。

f:id:kazuhironagai77:20210411231222p:plain

良く分かりませんが、Landscape4の場合はMF_GroundだけにMF_Displacementが在る場合は効かないようです。

Play画面から確認しようとしたら、8000枚位のShaderをCompileし直す必要があると出て来て、5分位ずっと計算しています。

f:id:kazuhironagai77:20210411231241p:plain

足が浮いています。

f:id:kazuhironagai77:20210411231255p:plain

うーん。

Displacementを切っても浮いていました。

f:id:kazuhironagai77:20210411231311p:plain

Displacementは関係なかったです。

以下の条件でマイルドにしました。

f:id:kazuhironagai77:20210411231331p:plain

f:id:kazuhironagai77:20210411231339p:plain

f:id:kazuhironagai77:20210411231349p:plain

一応出来ました。

後は負担がどれくらいなのかをAssessmentしたいです。

2.7 Displacement mappingの実装についてのまとめ

一応、Displacement mappingの実装が出来ました。出来ましたが結構な問題や分からない事は山積みですので、後で見直す時に忘れない様に、ここにまとめて置く事にします。

  • MF_Ground用のDisplacement mappingLandscape全体に使用している。
  • Displacement mappingのコストが分からない。
  • Characterの足が浮いている。

Displacement mappingの理論でも以下の部分は良く分かりません。

  • World Displacement に繋ぐノードでVertexNormalWSを使用しているが、これらはVertex shaderで実行されるのかそれともTessellation Evaluation Shaderで行わるのか不明。
  • Materialから生成したShaderのコードが複雑すぎて読めない。

頂点を沢山持つPlaneをImportしてDisplacement mappingを試す必要なくなったので、[New] Blender To Unreal Plugin! [3]は勉強する必要は無くなりました。しかしBlenderの新しいVersionも勉強する必要があります。それも考えておきます。

3.針葉樹用の緑と沼用の地面のMaterialの追加

3.1 沼の作成

以下の部分が沼です。

f:id:kazuhironagai77:20210411231457p:plain

今は、地面がむき出しですが、沼用の新しいMaterial functionを追加してここにPaintしようと思っています。

f:id:kazuhironagai77:20210411231515p:plain

沼用のMaterialをMegascanからimportしました。

f:id:kazuhironagai77:20210411231534p:plain

上記のTextureを使用したMaterial Functionを作成します。

MF_Groundを複製してTextureだけ交換しました。

f:id:kazuhironagai77:20210411231551p:plain

Texture SamplerのSampler sourceの設定がShard:Wrapになっているかの確認も行いました。

f:id:kazuhironagai77:20210411231620p:plain

Landscapeに使用しているMaterial、Landscape4に先程作成したMF_Swampを追加しました。

f:id:kazuhironagai77:20210411231637p:plain

一回、何かをBPに追加するたびにShaderがcompileを始めて、4000~7000位のShaderがCompileするまで待たなくてはいけないのですが、これって普通なんでしょうか?

後、Landscapeが完成したらCompileにこんな時間はかからなくなるのでしょうか?

以下のようにPaintしました。

f:id:kazuhironagai77:20210411231657p:plain

Parameterを調整します。

f:id:kazuhironagai77:20210411231720p:plain

良いんじゃないでしょうか?

実際にPlayしてみました。

f:id:kazuhironagai77:20210411231737p:plain

良い感じです。

このLayerに枯れ木をFoliageとして追加します。

Foliage4のLandscapeGrassOutputにSample’Swamp’を接続します。

f:id:kazuhironagai77:20210411231759p:plain

更にLandscape Grass Type、Swamp_Foliageを作成して

f:id:kazuhironagai77:20210411231832p:plain

f:id:kazuhironagai77:20210411231844p:plain

LandscapeGrassOutputにセットします。

f:id:kazuhironagai77:20210411231904p:plain

以下の様になりました。

f:id:kazuhironagai77:20210411231924p:plain

枯れ木の数を減らして、サイズを大きくします。

最終的に更に2種類枯れ木を追加して以下の様になりました。

f:id:kazuhironagai77:20210411231947p:plain

Play中の画面です。

f:id:kazuhironagai77:20210411232011p:plain

大変重いです。

3.2 Componentの削除

一々Compileするたびに3000枚のShaderをCompileしていて大変、イライラします。

以下のlandscapeから要らないComponentを削除します。少しはCompileにかかる時間が短縮するでしょう。

f:id:kazuhironagai77:20210411232125p:plain

あんまり削れませんでしたが、一寸はマシになるでしょうか?

f:id:kazuhironagai77:20210411232157p:plain

テストして気が付いたんですが、Foliageで生成した木とは衝突しません。

f:id:kazuhironagai77:20210411232219p:plain

どう直せばいいんでしょうか?

このサイト[9]の解答を見ると無理みたいですね。

f:id:kazuhironagai77:20210411232239p:plain

なるほど。

もう十分勉強したのでCh4に戻って本番用のLandscapeを作成します。

4.ゲーム内のlandscapeの作成。

4.1 Height mapからLandscapeをImportする

久しぶりにCh4_3を開きました。

Map1を以下に示します。

f:id:kazuhironagai77:20210411232313p:plain

ここに前節で作成したLandscapeとほぼ同じ物を作成したいと思います。

まず、前に作成したLandscapeを消します。

f:id:kazuhironagai77:20210411232335p:plain

これは予想外でした。こんなにLandscape小っちゃかったんですね。

やっぱり別なMapにします。

となると先程作成したMapを丸ごとExportすればいいんじゃないでしょうか?

f:id:kazuhironagai77:20210411232408p:plain

出来ました。

こっちはこっちで別なLandscapeを作成しましょう。

f:id:kazuhironagai77:20210411232425p:plain

5.Map1Landscapeの作成

以下の様な地形を作成します。

f:id:kazuhironagai77:20210411232453p:plain

上の地形を元に以下の様なLandscapeを作成しました。

f:id:kazuhironagai77:20210411232512p:plain

Landscape4で使用したMaterialでPaintしました。

f:id:kazuhironagai77:20210411232532p:plain

Play中の画像です。

f:id:kazuhironagai77:20210411232551p:plain

6.Environmentの勉強

今週は思っていたよりも早く予定した内容が終わってしまったのでUE4 の勉強をする事にします。

2021-03-22のブログで以下のTutorialは光に関するものだから勉強しませんでした。

  • Becoming an Environment Artist in Unreal
  • Constructing Believable Environment

久しぶりにCH4_3を開いてPlayしたらcharacterの陰影の付き方が別のProjectと違うような気がします。ちょっと気になるのでUE4におけるLightingを先に勉強する事にします。

2021-03-22のブログを見ると、Landscapeの作成が終わったら以下の事をやると述べていました。

  • Widget内のBPの整理
  • Effectの勉強と作成

これは来週やります。

BlenderからUE4にExportするTutorialについては新しいBlenderの使用方法を別に勉強しないといけないので後に回します。

6.1 Becoming an Environment Artist in Unreal

< Introduction to Environment Art >

このコースで何が勉強出来るのかを説明しています。この説明を聞く限りあんまりLightingはやらないみたいです。後かなり初心者向けみたいです。まあ、軽い気持ちで映画でも見る気分で見て行きましょう。

<Department Interactions in Development

Environmental artistがゲーム制作に関して何を担当するのかを説明しています。

  • PropとAssetの作成。
  • Textureの作成。
  • Materialの作成。
  • Level Artistとの密接な連携
  • AssetのCollision、LODs、そしてLightmappingの作成。
  • Level制作に必要なパーツの作成

と説明されています。

これを見ると「Unreal Engine 4 で極めるゲーム開発」で述べられている職種は、少なくともUE4を使用したゲーム開発では一般的な概念のようです。

後、Lightingに関してはLight Mapの作成ぐらいしかここでは述べられていませんね。

<Names and Terminology

ここではゲーム制作で使用される専門用語の内、Environmental artistが知っておかなければならない用語とその意味が紹介されていました。

ここで、面白いのがこの用語の説明がArtist向けな所です。

例えば、C++のProgrammerがBuildについて説明するならば、Compile+linkingと言うでしょうが、ここではBuildとはVersion、特に最新のVersionを指していると説明されています。私も最初は、それはBuildで作成されたCode(のVersion)でBuildじゃないでしょう。と思ったんですが、ArtistにCompiler と Interpreterの違いかを説明したって彼らには必要ない事ですし、こっちの説明のほうが分かり易く、かつ実用的です。

これで思い出したのが、化学における有機、無機の違いと意識高い系の人のおける有機、無機の違いです。化学を勉強する人にとって有機、無機の違いは炭素原子を中心に構成されている分子かどうかですが、意識高い系の人にとっての有機、無機の違いは農薬を使用して栽培されているかどうかです。

<Setting Up Your Folders

作成したFileやFolderの整理の仕方についてです。

以下にFileの名前の付け方の例を紹介しています。

f:id:kazuhironagai77:20210411232703p:plain

今度はTextureの種類についての名前の付け方です。

f:id:kazuhironagai77:20210411232720p:plain

これは直ぐに実行しましょう。大変分かり易いです。

Quiz 1

Mipについて間違えてしまいました。

うーん。

Mipmapって色んなサイズのtextureを準備してそれぞれを距離に応じて使い分ける事でしょう。何で間違いだったんでしょうか?

Scale Prep for Unreal Usage

1 unreal unitが1 cmであると明言されていました。

更に単位の設定方法について説明されていました。

Project Setting -> Editor -> Appearance -> Distance/Length でCentimetersにセットされています。

f:id:kazuhironagai77:20210411232756p:plain

XYZ軸についてです。UE4ではz軸が上を向いています。(これについては昔、このブログで相当調べました。)

Pivotについてです。Pivotはmeshの中心点の事ですがmeshによって底の中心だったり底の右端だったりします。

Using the Grid and Snapping Tools

Gridとは何かについての解説です。

その中で以下のToolの使用方法について説明しています。

f:id:kazuhironagai77:20210411232829p:plain

いますが、

f:id:kazuhironagai77:20210411232848p:plain

この升目上のチェックを外すと設定が100になっていても自由に動かせる事についての説明がありませんでした。

これって結構重要だと思うんですがどうでしょう。

Mouseの真ん中のボタンを押しながらDragすると距離が測れるそうです。

やってみます。

f:id:kazuhironagai77:20210411232915p:plain

おお。出来ました。

これは中々良い事を学びました。

この距離を示す白線の始点と終点の位置も

f:id:kazuhironagai77:20210411232934p:plain

によって強制されていますね。自由に位置を選択したい場合は升目上のチェックを外すと出来ます。

Texture Settings, Density and Exporting

Textureについての解説です。

Base、Normal、 Metalness、 Roughness、Ambient occlusionそしてChannel Packedについての説明です。

いつも思うんですが、PBRを説明するのにこのBase、Normal、 Metalness、 Roughnessの4つのTextureが必要であるRendering方法とすると非常に分かり易くなります。

ここでの説明も非常にスッキリしていて短時間で本質が理解出来る仕組みになっています。

Textureのサイズについてですが、UE4は最大で8192x8192ですが、4096x4096以上を使用するのはかなりレアな場合だそうです。

2021-03-28のブログで、

f:id:kazuhironagai77:20210411233003p:plain

と述べていますが、この辺の確証が得られましたね。

Texture density についてですが、そのTextureのsizeではなくそのtextureのsizeとそのtextureが張られるmeshのサイズで決まるそうです。

以下の様にです。

f:id:kazuhironagai77:20210411233025p:plain

これってTextureをMeshに貼りつける時にかなり大切ですよね。あんまり細かいTextureを小さな面に貼っても誰も気が付かないですし。

Texture densityを可視化する機能とかあるんでしょか?

Importing Meshes and Textures Into Unreal

FBXをUE4にImportする時に、表示される以下のヤツの中で大切な項目の説明を行っています。

f:id:kazuhironagai77:20210411233052p:plain

BlenderからStatic meshをImportする時にいつも無視していました。

ここで勉強してしまいましょう。

f:id:kazuhironagai77:20210411233113p:plain

MeshをImportする時に一個だけとは限りません。この項目はどのMeshに対しての設定をするのかを示します。

f:id:kazuhironagai77:20210411233134p:plain

Skeletal Meshかどうかです。

f:id:kazuhironagai77:20210411233158p:plain

ここにCheckを入れておくと最低のCollision(多分以下に示したようなタイプ)は生成してくれるそうです。

f:id:kazuhironagai77:20210411233231p:plain

f:id:kazuhironagai77:20210411233239p:plain

Importする時に幾つかのAssetを同時にImportしていますが、それを一つのMeshとしてImportするそうです。

幾つかのAssetを同時にImportって例えばイスをImportする時に背もたれとか足を別々のAssetで作成しているんでしょうか?

それともイスとテーブルを同時にImportしてそれを一つのMeshにする事を指してるんでしょうか?

現状の私の3Dの知識では今一意味が分かりませんでした。

f:id:kazuhironagai77:20210411233303p:plain

ここの二つの項目、かなり力を入れて解説しているんですが、今一良く分かりません。

カーソルを上に乗せたら詳しい説明が表示されました。

Normal Import Methodは

f:id:kazuhironagai77:20210411233319p:plain

と書かれています。

つまりFBXは元々、頂点に対してか、その頂点が作成したポリゴンに対してかは分かりませんが、法線の値を保持しています。それをそのまま使用するか、もしくはImportした頂点のデータからUE4側で法線の値を計算し直すのかを聞いてるようです。

Normal mapに対して聞いている可能性もない訳ではありませんが、今の所それは不明です。

Normal Generation Methodは

f:id:kazuhironagai77:20210411233334p:plain

Meshの法線を計算するのにMikkTSpace tangent space generatorを使って計算せよ。と指定しています。

となるとFBXは元々保持している法線の値は頂点に対してと言う事になりそうですね。

MikkTSpaceなんてどっかで聞いた事がある言葉です。しらべればすぐに分かるでしょう。

このサイト(Tangent Space Normal Maps)[10]に詳しい解説がありました。

このサイトを読むとつまり、tangent space normal mapの作り方と戻し方を同じ方法でやらないと値が変わってしまう事やorder dependencyなどの問題があり、それらの問題をMikkTSpaceでやると避ける事が出来る。と言う事のようです。

そういう解釈でもう一回説明を聞いたら、そんなような事を説明していました。

f:id:kazuhironagai77:20210411233420p:plain

f:id:kazuhironagai77:20210411233428p:plain

これってXYZ軸の変換の事でしょうか?

f:id:kazuhironagai77:20210411233458p:plain

f:id:kazuhironagai77:20210411233509p:plain

こっちは単位の変換みたいですね。

f:id:kazuhironagai77:20210411233541p:plain

f:id:kazuhironagai77:20210411233549p:plain

ImportしたMeshにMaterialが無い時にどうするかを聞いています。

Tutorialの解説では、ほとんどのゲーム制作でUE4内で新しいMaterialを作成するそうです。

f:id:kazuhironagai77:20210411233605p:plain

f:id:kazuhironagai77:20210411233615p:plain

これは解説そのままですね。

これでFBX import optionの解説はお終いです。

正直、カーソルを分からない項目の上に合わせるのが一番分かり易いと分かりました。

次はImportしたTextureの設定についてです。

f:id:kazuhironagai77:20210411233633p:plain

圧縮の方法についての選択ですが、Base Colorとそれ以外ではそれぞれ最適なやり方が違います。

f:id:kazuhironagai77:20210411233656p:plain

これは流石に知っています。Base colorの時はチェックしてそれ以外は外すはずです。

f:id:kazuhironagai77:20210411233729p:plain

ここはImportしたFileがどこからImportしたのかの記録です。

f:id:kazuhironagai77:20210411233744p:plain

OpenGL用に作成されたNormal mapを使用する時にチェックします。これは2021-03-28のブログでも勉強しました。

結構勉強になりました。

Quiz 2

満点でした。でしたけどgrid snapping option valuesが何をいっているのか分からなくてこのブログを読み直して回答しました。

Blockouts and Stand-in Meshes

Blockoutとは仮のアセットでLevel上に取りあえず配置してLevel artistが全体のイメージが掴めるようにするためのものです。

Blockoutの例として紹介されていた地下鉄のドアですが、私には完成品に見える位の質でした。

ここは正直何を勉強すべきなのか良く分からないです。

Collison Setup

Collison用のmeshの作成方法についての解説でした。

Polycount, Optimization and Draw Calls

最適化についてです。

Polycountとは使用しているポリゴンの数です。少ないほど良いです。

Draw CallはRenderingのためにGPUやCPUからTextureを呼び出す回数を指しているようです。説明を聞きましたがこれ以上の理解は出来ませんでした。GPUに一端Textureやmeshのデータを渡してGPU内だけで呼び出すならそんなに負担にならないんじゃないの?と思ったんですがその辺をDraw Callが数えてるのか分かりません。

Draw Callの数を減らすためにはUE4のRenderingを理解したProgrammerが必要で、ArtistはDraw callを減らす事が最適化につながる事を理解する事と

  • Meshの数を減らす事
  • Materialの数を減らす事
  • 同じmaterialを使用しているMeshは結合できないか検討する事

だそうです。

LODについてです。

LODはアセットがカメラから遠くの時にmeshの数が少なる事だそうです。LODについてしっかり勉強した事ないので、どうやって実現しているのか全く分かりません。

MeshのLOD Settingから作成していました。

f:id:kazuhironagai77:20210411233835p:plain

更にReduction Settingでポリゴンに使用されてる三角形の数を減らす事も出来ます。

f:id:kazuhironagai77:20210411233851p:plain

カメラからの距離でどのLODを使用するかはUE4が自動で設定してくれるそうです。

以下のチェックを外すとその自動化が止まるそうです。

f:id:kazuhironagai77:20210411233907p:plain

自分で設定する時は以下のScreen Sizeで指定するそうです。

f:id:kazuhironagai77:20210411233919p:plain

Meshに使用されるMaterialの数が増えるほどDraw callも増えるそうです。LOD2などの遠くでのみ使用さるMeshのMaterialの数はLOD0より少なくする事も考えるべきだそうです。

かなりLODについて勉強になりました。

Quiz 3

満点でした。

Footprintって何ですかと一瞬なりましたが、解答読んだら理解出来ました。

Basic Material Creation and Application

Materialの作成方法についての実演でした。

大体知っている事でしたが、TextureSampleのSampler TypeにそのTextureがどのタイプが表示されているのかを示しているそうです。

f:id:kazuhironagai77:20210411233945p:plain

GameTexture.comからBridgeにImportしたMrao.pngですがLinear Colorにセットされていました。

f:id:kazuhironagai77:20210411234010p:plain

これってMASKをセットすべきですよね。

Material Masters and Instances

Material Instanceの作り方を実演しています。

Master Materialは一つのProjectで2,3個しか作らないと言っていますが本当なんでしょうか?

時間が無くなってしまいました。

今週はここまでとします。

7.まとめと感想

今週は、

  • Tessellation Multiplier を使用したDisplacement mappingの勉強と実装
  • Landscapeの沼の作成
  • 作成したLandscapeGame用のProjectMigrate
  • Game用のProject内で新しくLandscapeを作成
  • 時間が余ったのでEnvironment artist用のTutorialを勉強

を行いました。

来週は、

  • Environmental artist用のTutorialの続き
  • Widget内のBPの整理
  • Map1からLandscape4にWarp出来るようにする。
  • Landscape4で戦闘出来るようにする。

を行います。

8.参考文献(Reference

  1. (2021b, January 2). Easily Set Up Displacement Maps in Unreal Engine using Quixel Bridge [Video]. YouTube. https://www.youtube.com/watch?v=f7q7btWDYOc
  2. MR3D-Dev. (2020, November 23). How to Use Megascan Displacement for Landscapes in Unreal Engine 4 [Video]. YouTube. https://www.youtube.com/watch?v=uTKap2aJbI8
  3. Smart Poly. (2020, July 28). [New] Blender To Unreal Plugin! [Video]. YouTube. https://www.youtube.com/watch?v=PNGAoKhrBls
  4. (2021a, January 1). Converting Your Favorite Render Engine Materials for Unreal Engine [Video]. YouTube. https://www.youtube.com/watch?v=5vpDFGJEsNw
  5. Epic Games. (n.d.-a). 1.11 - World Displacement. Unreal Engine Documentation. Retrieved April 11, 2021, from https://docs.unrealengine.com/en-US/Resources/ContentExamples/MaterialNodes/1_11/index.html
  6. Epic Games. (n.d.-b). 1.12 - Tessellation Multiplier. Unreal Engine Documentation. Retrieved April 11, 2021, from https://docs.unrealengine.com/en-US/Resources/ContentExamples/MaterialNodes/1_12/index.html
  7. E., A., & D. (2016, February 9). What is Tessellation in computer graphics. Computer Graphics Stack Exchange. https://computergraphics.stackexchange.com/questions/2018/what-is-tessellation-in-computer-graphics
  8. Epic Games. (n.d.-c). Coordinates Expressions. Unreal Engine Documentation. Retrieved April 11, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Materials/ExpressionReference/Coordinates/index.html?utm_source=editor&utm_medium=docs&utm_campaign=rich_tooltips#vertexnormalws
  9. Epic Games. (2015, August 6). Landscape grass & collision. Unreal Engine Forums. https://forums.unrealengine.com/development-discussion/content-creation/50736-landscape-grass-collision
  10. MikkTSpace.com. (n.d.). Tangent Space Normal Maps. Retrieved April 11, 2021, from http://www.mikktspace.com/

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する  マップの作製など Part 4

f:id:kazuhironagai77:20210404222701p:plain

<前文>

Sidney Powell氏と匿名掲示

良くニュースとか洋物のドラマで聞く司法長官はthe United States Attorney generalでSidney Powell氏の前職であるUnited States Attorneyは連邦検事だそうです。

連邦検事がどれくらい凄いのか、法律にも権力にも疎い私は全く分かりませんが、良く洋物のドラマや日本のニュースに出て来る司法長官と一字しか違わないのだから、結構凄い地位だと思います。

そんな凄い職に就いていたSidney Powell氏ですが「2020の大統領選挙は投票の集計をする機械を作っている会社(Dominion社)が不正を働いているからトランプ氏が負けた。」とメディアで言いまくっていたら、とうとうDominion社から訴えられてしまいました。

そしたら彼女「私が言っているのは全て冗談で、それはみんな分かってる。もしそれが分からないヤツがいたら、そいつはとんでもないアホ。」と主張し始めました。

この発言は、右派、左派を問わずアメリカ人のほとんどが激怒、もしくは失笑する発言だったんですが、10年以上アメリカで暮らした私からすると、その激怒や失笑しているアメリカ人に対して「白々しい偽善者たち」と言う気持ちになります。

前にも書きましたが、宗教右派たちが主張する内容が全部嘘なのは全てのアメリカ人が知っています。知っていますが、メキシコの国境に壁を作った時や、日本を含むアジアにアメリカでは使用が禁止されている発癌性の農薬を使用したフルーツを販売した時は、アメリカ人全員が笑って見過ごしていたんです。ところが今回、コロナウィルスや議会の暴動で自分達に直接危害が及ぶ事が分かると、途端に宗教右派たちを叩き始めました。

しかし今回、ここで書きたいのはその話ではなく、この彼女の発言と日本の匿名掲示板についてです。

このニュースが日本の匿名掲示板で紹介された時「彼女はそんな発言していない。嘘を書くな。」と一貫して訂正してくる人達がいて、そのスレを読んでいるほとんどの人が本当はSidney Powell氏はそんな発言していないんだ。と信じてしまったんです。

私も信じてしまいました。

後で英語のニュースサイト見てたらSidney Powell氏が嘘をついていた事を認めたと書かれていて「えっ」となりました。

いくら匿名掲示板といえどもニュースを紹介しているサイトですから、そこに書かれている内容がある程度の事実を保証する義務があると思いますが、そう言う事は野放しみたいですね。

ここで皆さんに質問です。

  1. 皆さんは匿名掲示板といえどもニュースを扱う限りは、そこに書かれている内容に対してある程度の事実を保証する義務があると思いますか?
  2. もしその義務があるとすれば、それはそのサイトを運営する会社ですか?それともそこに文章を書き込む人達ですか?

私はこう考えています。

まず1に対してですが、ニュースと名乗っている以上、その内容に対してある程度の事実を保証する義務はあると思います。もしくは「ここで書かれている事はすべて嘘です。信じないで下さい。」と前もって書き込んでおく必要があると思います。そう言えば、昔はこの匿名掲示板、似たような警告が書かれていた気がします。

2に対しては、匿名で文章が書ける以上、その書かれた内容が事実である事を保証する義務はそのサイトを運営する会社にあると私は思います。

その辺のカルトに嵌っているおばちゃんが癌患者に「この水飲めば癌も治る。」と言ってもほとんどの人は信じないでしょう。しかしどっかの大学病院の先生が言ったら、ほとんどの人はひょっとしたら治るかもしれない位は思います。このように誰が発言したのかはその内容の信ぴょう性に対して大きく影響します。それを敢えて隠している訳ですから、その責任はサイトを運営する会社にあると私は考えます。

はい。

実はこの上記の議論と全く同じ議論がアメリカでも今行われています。

1については、先程のDominion社がFox Newsに対してもSidney Powell氏と同様の訴訟を起こしています。

その時にFox Newsは「我々は娯楽を提供しているのでそれが事実である事を保証する義務はない。」みたいな返答をしています。幾ら何でもNewsですからね。事実を伝える必要がないのならNews番組を名乗って良いんでしょか?と批判の嵐に晒されています。

2についてですが、アメリカ議会は今回の連邦議会での暴動の責任の一端がSNSの運営会社にあると激怒しています。

これに対してFace bookは全ての責任は発言した人、Face bookの責任は書いた記事がネットで読める様にする事である。と真っ向から対立しています。Googleは訳わからん事言って議員を煙に巻こうとして失笑を買ってしまいました。Twitter社はSNSの運営会社にも責任の一端があったと最初から認める発言をして株を挙げました。

この議論がどう転んでいくのか分かりません。しかし近い将来、匿名や偽名では、ネットに投稿出来なくなる気が私はしています。

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

<本文>

1.今週の予定

以下の事をやっていこうと思います。

  • Landscapeの直し
  • 先週勉強したTutorialの続きをやる
  • Foliageの改善(Cull Distanceの使用)
  • 水の追加
  • Projectに使用する実際のLandscapeの作成

後、今週からReferenceを別に作成しようと思います。

UE4を業務で使用している人で、英語の資料(YouTubeのTutorialも含む)が読めない人はいないと思いますが、膨大な英語圏の資料から質の高いものを見つけるのはかなり時間がかかります。「英語圏の資料は全く見ない。」のも一つの手かもしれませんが、UE4において英語圏の資料は質、量、共に日本語の資料を圧倒していますので、そんな習慣を付けてしまうと近い将来、必ず詰んでしまいます。

私のBlog内に引用した資料の一覧が有ると、それ自体がある程度の質を保証した英語圏の資料集なので一から探す手間が省けます。

また最近の私のブログの質はかなり向上して来ているので、私のブログで引用した資料と言う事で引用された側にもメリットがあるはずです。

ので引用した資料はReferenceを作成する事で明確にします。

2.Landscapeの直し

先週作成したMaterialには何か所か直したい所があります。

  • Material instanceを使用していないためパラメーターを調節するたびにCompileする必要がある。微調整が出来ない。
  • Displacement Textureが提供されているがこれの使い方が分からない。
  • 緑のTextureにもMacro variationDistance blendを使用する。
  • Distance BlendTextureのサイズの設定が逆だったかもしれない。

2.1 Material instanceを使用する。

先週勉強したTutorial [1]でパラメーターの微調整を実際のLandscapeを見ながらおこなっていました。

f:id:kazuhironagai77:20210404222902p:plain

これはかなりsmartなやり方です。早速真似しようとしたら出来なかったんです。

その理由ですが、先週Materialは作成したのですが、そのMaterial からMaterial instanceを作成しませんでした。

Materialを直接使用するとParameterを変える毎にCompileする必要があり、とても実際のLandscapeを見ながら微調整なんて出来なかったです。

Material Instanceを使用する理由はParameterの値だけが違う同じ方法で作成したMaterialらを一括で管理出来る事だと思っていたのですが、それプラス3d viewportから直接、そのmaterialを実際に使用しているActorを見ながらCompileなしでParameterの調整が出来る事でした。

目から鱗の体験でした。

先週作成したMaterialからMaterial instanceを作成します。

f:id:kazuhironagai77:20210404222919p:plain

しました。

これにParameterを追加していきます。

あれ。既に大量のParameterが存在しています。

f:id:kazuhironagai77:20210404222935p:plain

元のMaterialにParameter なんて一個もないんですが? 

f:id:kazuhironagai77:20210404222952p:plain

なんと、使用しているMaterial function内のParameterも自動で追加してくれてありました。

f:id:kazuhironagai77:20210404223006p:plain

となるとほとんど既に完成していました。

Distance blendに使用しているConstantをparameterに変換してテストしてみます。

f:id:kazuhironagai77:20210404223022p:plain

以下の様に設定を変更しました。

f:id:kazuhironagai77:20210404223039p:plain

Start Offsetを-1000から-2000に変更します。

f:id:kazuhironagai77:20210404223056p:plain

Blendが始まる箇所が遠くになっています。

Blend Range resultの値を100から100000に変更します。

f:id:kazuhironagai77:20210404223111p:plain

淡いブレンドに変化しました。

実際の状態で見てみます。

f:id:kazuhironagai77:20210404223126p:plain

うーん。

よーく見るとタイルが見えるんです。

Dirt far、 dirt nearの二つのParameterを追加する事で、使用しているTextureのサイズもMaterial instanceから調整出来る様にしました。

Farを0.02、nearを0.05で以下のような地面になりました。

f:id:kazuhironagai77:20210404223142p:plain

これならタイルタイルしていませんね。

実際のplay画面です。

木の葉のサイズが人の頭位になってしまってますね。

f:id:kazuhironagai77:20210404223157p:plain

うーん。

変えました。

f:id:kazuhironagai77:20210404223219p:plain

これぐらいでどうでしょうか?

f:id:kazuhironagai77:20210404223235p:plain

遠くに使用するTextureはサイズを変えるだけでなくTextureそのものも変えた方が良い気もします。

Material Instanceを作成する事で、compileなしかつ3d view portを見ながら微調整を行えるようにすると、体感的ですが1000倍位精度高く調整できる気がします。

今回はこの事が確認出来たので良しとしましょう。

2.2 Displacement Textureが提供されているがこれの使い方が分からない

Mega ScanからdownloadしたTextureにはすべてDisplacementと名付けられたTextureが付いています。

f:id:kazuhironagai77:20210404223259p:plain

f:id:kazuhironagai77:20210404223306p:plain

f:id:kazuhironagai77:20210404223315p:plain

これの使い方が分かりません。

調べます。

色々なサイトをつまみ読みしていたら概要が分かったのでまとめます。

まず3D graphics にはDisplacement Mappingという技術があります。

Normal mappingでは偽の法線を作成する事で疑似的な凹凸を表現しますが、Displacement Mappingでは頂点をDisplacement mapに沿って実際に移動させる事で本当の凹凸を作成します。実際に凹凸を作成するのでnormal mappingに比べて段違いでリアルな表面を作成出来ますが、これを可能にするためには沢山の頂点が必要になので、かなり高コストなmappingです。

UE4における使用方法ですが、それなりに説明しているサイトは何個かあるのですが、バッシと理論と実践を簡潔に説明している所は無かったので自分で理解した範囲でまとめておきます。

まずMaterialのTessellationのD3D11Tessellation ModeをFlat TessellationかPN Trianglesにセットします。

f:id:kazuhironagai77:20210404223333p:plain

するとWorld DisplacementとTessellation Multiplierが入力出来る様になります。

f:id:kazuhironagai77:20210404223350p:plain

Tessellation Multiplierは頂点の数をどれくらい増やすかを決めるための入力のようです。参考にしたサイトの多くは、カメラの傍は細かく頂点を増やして、ある程度から遠くは元のままの頂点にしたりしていました。

World Displacementはどれくらい頂点をずらすかを指定するための入力のようです。高さのみ変化するのかxyz方向全てに変化するのかは不明です。

試しに以下の様にdisplacement mapをWorld Displacementに繋げてみると、

f:id:kazuhironagai77:20210404223406p:plain

以下の様に球の形状が変化しました。

f:id:kazuhironagai77:20210404223421p:plain

今回は、

  • Displacement mappingが何であるか
  • UE4Displacement mappingを使用するために最低限必要な手順

が判明したので、ここで一端中止します。

この後、

  • この技術がどのくらい必要か
  • 使用するためのコスト
  • この技術を正しく理解し正しく使用する為に必要な勉強時間

などを考えてみて継続するか決めようと思います。

2.3 緑のTextureにもMacro variationやDistance blendを使用する

先週、Macro variationやDistance blendはDirtにしか追加しなかったのでこちらにも追加します。

緑のTextureはM_Ground_GrassをそのままMaterial functionに変更したものでMaterialの実装がDirtとは全く違っていました。

以下の三か所を見ると、先週やったMacro variationとはやり方が少し違うものの、既にMacro variationを実装していると考えられます。

f:id:kazuhironagai77:20210404223509p:plain

f:id:kazuhironagai77:20210404223516p:plain

f:id:kazuhironagai77:20210404223525p:plain

更に、距離を変化させてもタイルタイルしてる箇所は見られないばかりか、スムーズなTextureの切り替えが行われています。

f:id:kazuhironagai77:20210404223541p:plain

f:id:kazuhironagai77:20210404223557p:plain

以下の部分が、Distance blendとは違うやり方で、スムーズなTextureの移行を担当しているようです。

f:id:kazuhironagai77:20210404223613p:plain

以下の部分が遠距離のTextureを担当し

f:id:kazuhironagai77:20210404223628p:plain

以下の部分が近距離を担当してるようです。

f:id:kazuhironagai77:20210404223645p:plain

よって緑のTextureにMacro variationやDistance blendを追加する必要はないと判断しました。

しかし全部理解出来たわけではありません。

以下の部分は何をやっているのか良く分かりません。

f:id:kazuhironagai77:20210404223659p:plain

分かりました。

上記の近距離担当は合っていましたが、遠距離担当は、上記で遠距離担当と思っていたやつと近距離担当を遠距離のMacro VariationでLerpしたものでした。それが最初のLerpです。次のLerpは近距離担当と遠距離担当をカメラからの距離などで混ぜる通常のDistance blendをやっています。

f:id:kazuhironagai77:20210404223714p:plain

これは何をしたいんでしょうか?2.25倍にして0.25で引いて、0から1でClampして?

良く分からないのでグラフにしてみました。

f:id:kazuhironagai77:20210404223732p:plain

  • Lerpはy=25x - 0.25で計算しました。
  • Clampは0以下は0、1以上は1、それ以外はそのままで計算しました。

上記の計算が合っている前提ですが、元の値が0.2未満の場合はもっと黒くなって、0.2以上の場合は白くなる。更に0.6以上ならば真っ白になると言う事でしょうか?全体的に言うと白くなっていると言う事みたいですね。

2.4 Distance BlendでTextureのサイズの設定が逆だったかもしれない。

いつも混乱するので確認します。

f:id:kazuhironagai77:20210404223824p:plain

上のTexCoordのUV値は共に1、下のTexCoordのUV値は共に2です。となると数字が大きくなるほど、Textureは小さくなるみたいです。

Dirtは近距離のTexCoordのUV値は1、遠距離のTexCoordのUV値は0.1なので遠距離の方のTextureが大きくなっています。

遠距離のTextureは大きくするのが正しいので合っています。

3.先週勉強したTutorialの続きをやる

How to INSTANTLY TEXTURE your landscapes in UE4 - Unreal Engine tutorial[2]とThe Secret to Realistic Landscapes in Unreal Engine - UE4 Tutorial[3]を勉強します。

3.1 How to INSTANTLY TEXTURE your landscapes in UE4 - Unreal Engine tutorialを勉強する。

崖用に新たなTextureを追加していました。Rough Rock Wallと言う名前らしいです。

Mega Scanで探しましたが見つかりません。

しょうがないので、似たようなTextureを探していたらありました。

f:id:kazuhironagai77:20210404223855p:plain

あれ、と思ってもう一回、Rough Rock Wallで検索したんですが、検索に引っかかる沢山のTextureの一つとしてこれも出て来ますが、沢山の全く違う名前のTextureと共にしか表示されません。何でなんでしょう?

Importしました。

f:id:kazuhironagai77:20210404223909p:plain

今までは、Mega Scanの方で提供されているMaterialとこのTutorialの合成的なMaterialを作成してそれをDirtとして使用したり、緑の部分はStarter Kitに提供されているMaterialをそのまま使用したりしていました。

今回の崖の部分のMaterialはこのTutorial通りに自分で作成してみようと思います。

3.1.1 崖のMaterialの作成

まず基本のMaterialを作成します。名前はMF_Cliffと名付けました。

f:id:kazuhironagai77:20210404223934p:plain

M_Landscapeに追加しました。

f:id:kazuhironagai77:20210404223949p:plain

Landscape、PaintのTarget Layersを見るとCliffが追加されています。

f:id:kazuhironagai77:20210404224004p:plain

Layerを作成してTextを塗ってみましょう。

f:id:kazuhironagai77:20210404224019p:plain

うわ。絶望的なくらい、タイルタイルしています。直せるんでしょうか?

Macro varianceを追加します。

f:id:kazuhironagai77:20210404224035p:plain

一寸はマシになりました。

f:id:kazuhironagai77:20210404224052p:plain

唐突に思いついたんですが、Macro Varianceのコントラストを下げるために0.5をかけています。この値を変化させたらもっとリアルになるかもしれません。

試してみました。

f:id:kazuhironagai77:20210404224108p:plain

青味がかってちょっとリアルになっている気がします。

f:id:kazuhironagai77:20210404224124p:plain

確認のために真っ赤に設定してみました。

f:id:kazuhironagai77:20210404224147p:plain

f:id:kazuhironagai77:20210404224157p:plain

真っ赤になっていました。

この値はParameterにしてInstanceから調節出来るようにすべきですね。

CliffのMacro Contrastとしてparameter化しました。

f:id:kazuhironagai77:20210404224213p:plain

Distance blendを追加します。

f:id:kazuhironagai77:20210404224229p:plain

凄いスパゲッティコードです。理解しているから読めますが、前もって知識がないとこのコードから何をしているのかを推測するのはかなり大変でしょう。

もっと良い整理方法があるかもしれませんがこのまま行きます。

Parameterも後でInstanceから調整出来る様に作成しました。

f:id:kazuhironagai77:20210404224243p:plain

こんな感じです。

f:id:kazuhironagai77:20210404224258p:plain

流石にTextureがデカすぎですが、タイルタイルしているのは消えています。

近づくとBlendingの酷さや、近距離でのタイルタイル感が全く消えてないのが分かります。

f:id:kazuhironagai77:20210404224312p:plain

後でMaterial Instanceから調整します。

今回は手動でペイントしますのでParlinノイズの部分はパスします。

3.1.2 Tutorial の続き: Texture Sample

一口メモみたいですが、全てのTexture SampleのSampler SourceをShared: Wrapにセットする必要があるそうです。

f:id:kazuhironagai77:20210404224332p:plain

その理由は色々なMaterialを一か所にペイントするとEditorがクラッシュしてしまうからだそうです。しかもこれが原因でクラッシュした時は、UE4は何故クラッシュしたのかを教えてくれないそうです。

Sampler Sourceがそもそも何をするのか不明なのですが、Google先生に聞いても解答を表示してくれません。

途方に暮れてカーソルをSampler Sourceに合わせたら以下の説明文が表示されました。

f:id:kazuhironagai77:20210404224347p:plain

こんな丁寧な説明が出て来るのならどこかでしっかり解説されているはずと探したら

公式のAPISampler Sourceの説明[4]がありました。

f:id:kazuhironagai77:20210404224402p:plain

「Text検索のためのSamplerがどこから来るのかをコントロールします。」今一意味が分かりませんね。

Remarkを読んだらカーソルを乗せた時に出て来た時の説明と全く同じ文章でした。

何となくですが、分かりました。

SamplerSourceはTexture Sampleそのものか、もしくはTexture SampleのTextureをどこに保持するかを決定するためのParameterみたいです。

f:id:kazuhironagai77:20210404224424p:plain

Texture assetを選択した場合、UTexture Addressing settingに保持します。その場合、Sampler slotを消費するため16枚のTextureしか使用出来ないみたいです。

Shard: WrapかShard: Clampを選択した場合は、global samplerに保持されるため、SM5(意味不明)の場合、16枚以上のTextureでも使用出来るみたいです。

それではShard: WrapとShard: Clampの違いは何なのかですが、

見つかりません。

全然探しても出て来ません。

途方に暮れてたら、カーソルを乗せたらまた出て来ました。

f:id:kazuhironagai77:20210404224444p:plain

Clampの方です。

f:id:kazuhironagai77:20210404224500p:plain

違いはWrapがwrap addressingを使用して、Clampclamp addressingを使用するだけのようです。

このWrap addressingとClamp addressingは何となくですがDirect Xの用語のような気がします。

調べたらこのサイト[5]に解説がありました。

UV座標の範囲は通常は0から1ですが、それ以上や以下も指定できます。指定した場合ですが、Wrap addressingはTextureのイメージを繰り返し表示するそうです。Clamp addressingは0以下は0の時の値、1以上は1の値を表示するそうです。

そう言えばOpenGLにも同じ機能がありました。

先程使用した十字のTextureを使用して試してみます。

f:id:kazuhironagai77:20210404224517p:plain

まずTexCoordに3を賭けてサイズを3倍にします。

そしてShared:Wrapにセットします。

f:id:kazuhironagai77:20210404224532p:plain

結果は、

f:id:kazuhironagai77:20210404224547p:plain

十字のTextureのイメージが繰り返し使用されました。

次に

f:id:kazuhironagai77:20210404224600p:plain

変更しました。

f:id:kazuhironagai77:20210404224613p:plain

0と1の値が繰り返し…。

ウーン。1の値が繰り返し使用されているようですが、座標が…。左上が0なんでしょうか?

確認のために1引いてみました。

f:id:kazuhironagai77:20210404224637p:plain

結果です。

f:id:kazuhironagai77:20210404224655p:plain

間違いないですね。左上が0ですね。そして0以下は0の値がずっと使用されている事も確認出来ました。

そう言えば、OpenGLを勉強している時、このTextureに移動、回転、拡大縮小の計算をすると、どうしても自分が予想した結果と違うイメージが出来る時があってかなり悩んだのを思い出しました。

その時の結論は「座標を撮影しているカメラをイメージしてそのカメラが移動、回転していると仮定すると予測通りになった。」でした。

このTexCoordに対して移動、回転、拡大縮小をした場合のTextureの変化も後で調べてみます。

もうSampler Sourceに関しては理解出来ました。クラッシュする理由である「色々なMaterialを一か所にペイントする」とは多分ですが、Texture sampleを16種類以上使用した場合と言う事でしょう。

後、使用している全てのTexture sampleのSampler sourceの設定を、Shared:Wrapに変更しました。

3.1.2 Tutorial の続き: World Aligned Blend

崖のような角度が急な所は計算で見つけて、自動でPaintしたいそうです。そのために使用する関数がWorld Aligned Blendだそうです。

以下の様にして使用するそうです。

f:id:kazuhironagai77:20210404224719p:plain

Tutorialと同じ値をSlop SharpnessとSlop BiasにセットしてAlphaをBase Colorに繋げました。

以下の様な結果になりました。

f:id:kazuhironagai77:20210404224742p:plain

f:id:kazuhironagai77:20210404224751p:plain

Alphaの代わりに、w/Explicit Normalを使用しました。

f:id:kazuhironagai77:20210404224823p:plain

Tutorialではこっちを使用していますが、場合によっては元のalphaの方が良いかもしれません。

Blend Material Attributesを使用して実際のTextureを表示します。

f:id:kazuhironagai77:20210404224846p:plain

Tutorialとはやり方が違いますがこれでも大丈夫でしょう。

以下の結果になりました。

f:id:kazuhironagai77:20210404224902p:plain

うーん。自分でpaintするより綺麗な気もします。実際に使用するかどうかは後で考えます。

TutorialではLayer Blendに新しいLayerを作成してそこに繋げていましたが、全部Layerを新しく作成し直していました。自動でPaintを作成する時は良いですが、時間をかけてPaintしたDataが消えてしまったらかなりショックです。

上記でw/Explicit NormalよりAlphaを使用した方が良いかもと述べましたが、TutorialによるとAlphaの値を直接、Blend Material Attributesのalphaに接続しても使えないそうです。

World Aligned Blendのalphaの値を使用するためには、MatLayerBlend_Standardを使用する必要があるそうです。

MatLayerBlend_Standardを使用する必要があるのではなく、MatLayerBlend_Standardを改良する必要がありました。

3.1.3 MatLayerBlend_Standardの改良

MatLayerBlend_Standardの改良方法をまとめます。

まずコピーを作成します。UE4から提供されている関数を直接改良してはいけません。

f:id:kazuhironagai77:20210404224923p:plain

NormalのAlphaだけ別なInputから取るようにしました。

f:id:kazuhironagai77:20210404224938p:plain

以上です。

3.1.4 Tutorial の続き: World Aligned BlendのAlpha値を使用

改良したMatLayerBlend_Standardを以下の様に接続します。

f:id:kazuhironagai77:20210404224959p:plain

World Aligned Blend のalphaを改良したMatLayerBlend_Standard のAlphaにつなげます。w/Explicit Normalを先程作成したAlpha_Normalに接続します。Blend Material Attributes のAにつなげていたノードをBase Material (MA) Blended Materialに接続します。Blend Material Attributes のBにつなげていたノードをTop Material (MA)につなげます。最後に改良したMatLayerBlend_StandardのOutputをBlend Material AttributesのOutputがつながっていた所につなげます。

結果です。

f:id:kazuhironagai77:20210404225024p:plain

大体何をやっているのか分かりました。

何をやっているのか大体分かると、逆に何でWorld Aligned Blend のalphaでblend出来ないのかが分からなくなります。

分からない時は、分からないヤツにカーソルを乗せてみる。です。

f:id:kazuhironagai77:20210404225041p:plain

Reentrant expressionと書かれています。どういう意味なんでしょうか?

まずProgramming 一般の用語としてReentrant Functionがあるそうです。(正直に告白しますと、知らなかったです。)

このサイト[6]に分かり易い解説がありました。

簡単に説明すればその関数を使用中に別なTaskがその関数を別な目的で使用しても結果が変化しないように作成された関数の事のようです。

うん。それってThread Safeの事?

はい。実は違います。

そこでWikipediaのReentrancy (computing)[7]の解説です。

このサイト「何個か問題がある」と警告が出ているので一端読んだ後、評価を保留にしていたんですがThread SafeとReentrancy (computing)の違いについて簡単で分かり易い具体例が示してあります。

この違いを理解した上で最初のサイト[6]では簡潔にReentrancy (computing)では、Thread Safeと違い、基本的にOne Threadの時代の話でhardware からの割り込みやrecursionなどの場合を想定していると結論づけています。

つまり関数の使用中にhardware からの割り込みやrecursionなどでその関数を別な目的で使用しても実装の結果が変わらないと言うのがReentrant Functionと言うわけです。

Reentrant Function を達成するためには、

  • Global 変数やstatic 変数は使用しない。
  • 関数内のコードは変化しない。
  • Reentrant が保証されていない別な関数は呼ばない。

などの条件を満たす必要があるそうです。

Reentrant expressionに戻りますが、Reentrant expressionと言う表現はUE4でしか使用されていないみたいです。Googleの検索で出て来た結果から推測すると、Reentrancyが保証されない時にReentrant expressionと言っているみたいです。

となると以下の事が考えられます。

  1. World Aligned Blend alphaの計算には、何らかのglobal 変数を使用している。
  2. そのglobal 変数はBlend Material Attributesの計算で値が変わる。
  3. よって、その値が変わったglobal 変数を使用して残りのWorld Aligned Blend alphaを計算する必要がある。
  4. 勿論、正しい値は出てこない。

あくまで推測ですが、そのglobal 変数とはPixel Normal WSでしょう。そしてそのPixel Normal WSの値はBlend Material Attributes内でnormalの計算を行っている時に書き変えられているのでしょう。

3.1.4 Tutorial の続き: 岩と草の間にDirtを追加

これは軽く説明されているだけなので今回はスキップします。

3.1.5 How to INSTANTLY TEXTURE your landscapes in UE4 - Unreal Engine tutorialを勉強してみて

結論を端的に言えば、このTutorialは崖の部分のPaintを行っただけです。

しかしそのやり方が超正統派のPhoto-realistic renderingに則っており、かつ細部における独自の工夫がUE4のMaterialの機能を完璧に理解していないと出来ない方法によってなされているため、最高Levelのtutorialに仕上がっています。

この作者、この若さでここまで出来るのですから、いわゆる天才でしょう。

この作者が作成するTutorialは全てチェックする価値があると思いました。

3.2 The Secret to Realistic Landscapes in Unreal Engine - UE4 Tutorial を勉強する。

Specular Channelの値をTextureのBase Colorに沿って半分にしました。そしてFresnel反射を利用してSpecular Channelの値を下げる箇所と下げない箇所を分けました。

Tutorial通りにやろうと思ったら、緑のMaterial Functionは元のままだし、Dirt は実装が変形し過ぎていまして、簡単には実装出来ない事が分かりました。

どうせ何回かはLandscapeを作成し直すのでその時にこれを実装する事にしました。

4.Foliageの改善(Cull Distanceの使用)

Cull DistanceはLandscape Grass type内で設定出来ました。

f:id:kazuhironagai77:20210404225202p:plain

更に3種類の草を追加しました。

f:id:kazuhironagai77:20210404225219p:plain

f:id:kazuhironagai77:20210404225226p:plain

f:id:kazuhironagai77:20210404225233p:plain

サイズを全部小さくしました。

f:id:kazuhironagai77:20210404225247p:plain

結果です。

f:id:kazuhironagai77:20210404225304p:plain

結構PCが音立てて計算しています。

負担が大きいのでしょうか?

5.水の追加

UIWS Water ManagerとUIWS Water Body を追加しました。

f:id:kazuhironagai77:20210404225328p:plain

こんな感じです。

f:id:kazuhironagai77:20210404225344p:plain

UIWS Water Body を使用しているので、何もしなくても波紋が出来ています。

f:id:kazuhironagai77:20210404225403p:plain

海です。

f:id:kazuhironagai77:20210404225420p:plain

今回はこれで十分です。

6.作成したLandscapeの直したい所

これで実際のProjectのlandscapeを作成使用と思いましたが、結構直したい個所があるのでもう一回だけ練習します。直したい個所を具体的に言うと

  • Landscapeの手直し
  • Material (緑、地面)の作成
  • Foliage の直し

です。

6.1 Landscapeの手直し

川沿いの土手の部分のmeshが荒く、滑らかさが失われています。

f:id:kazuhironagai77:20210404225509p:plain

f:id:kazuhironagai77:20210404225516p:plain

山のメッシュに捻じれた部分があります。

f:id:kazuhironagai77:20210404225534p:plain

f:id:kazuhironagai77:20210404225542p:plain

6.2 Material (緑、地面)の作成

How to HIDE Texture REPETITION in Unreal Engine[1]に書かれていたやり方で草と荒れ地のmaterialを作り直します。

Specular Channelの調節を最初から追加してプラスチック感を減らします。

6.3 Foliageの作成

Foliageの違和感が凄すぎます。違和感の原因を自分で考えると

  • 木がない。
  • 草の生え方が奇妙
  • 花がない。

が考えられます。

更にFoliageに関して言えば、以下の様なPluginもあるのでそれの活用も考えたいと思います。

f:id:kazuhironagai77:20210404225613p:plain

7.Landscapeの作成、もう一度

7.1 Landscapeをexportして修正

海の部分を深くします。

f:id:kazuhironagai77:20210404225640p:plain

もう一度Importします。

f:id:kazuhironagai77:20210404225656p:plain

上記の陸地と海の底の境目をスムーズにします。

f:id:kazuhironagai77:20210404225713p:plain

出来ました。

素早く楽にやるコツはCamera speed を6にセットする事です。

f:id:kazuhironagai77:20210404225727p:plain

今度は川を直していきます。

f:id:kazuhironagai77:20210404225750p:plain

更に全体的におかしい所を直します。

7.2 Materialを作成します。

土から作成します。

Base, roughness, normalで基礎を作成しました。

f:id:kazuhironagai77:20210404225810p:plain

こんな感じです。

f:id:kazuhironagai77:20210404225828p:plain

正直言ってこのTextureでは、あまり目立ちませんが、近づくとタイルが見えます。

f:id:kazuhironagai77:20210404225844p:plain

Macro variationを追加します。

f:id:kazuhironagai77:20210404225900p:plain

f:id:kazuhironagai77:20210404225908p:plain

正直このTextureにdistance blendingが必要とは思えませんが、以下のスクリーンショットを見ると少しはタイルタイルしていますので一応作成します。

f:id:kazuhironagai77:20210404225925p:plain

しました。

数値を適当にいじってみましたがあんまり差が出なかったです。

f:id:kazuhironagai77:20210404225943p:plain

後、並べ方を変えて見ました。

f:id:kazuhironagai77:20210404230015p:plain

少しは見やすくなったと思います。

Specular channelを調整します。

有りです。

f:id:kazuhironagai77:20210404230045p:plain

無しです。

f:id:kazuhironagai77:20210404230103p:plain

実装部です。

f:id:kazuhironagai77:20210404230118p:plain

有りと無しを比べると有りが圧倒的に良いですが、それでもまだプラスチックみたいです。もう少し下げてみます。

0にしました。正直0でも違和感ないですし、地面が光っているよりリアルに近い気がします。

f:id:kazuhironagai77:20210404230155p:plain

Play中の画面です。

f:id:kazuhironagai77:20210404230215p:plain

もう少し地面がデコボコしているとリアルな気がします。Displacement mappingを追加するか、Landscapeで地面に微妙な凹凸を形成したいです。

Landscapeから小さな凹凸を付けてみました。

滅茶苦茶リアルに感じます。見た目もリアルですが、移動するとデコボコの地面を走っているため、画面が微妙に上下します。それがリアル感を出しています。

f:id:kazuhironagai77:20210404230233p:plain

Landscapeから地面をもっとボコボコにしてみました。

f:id:kazuhironagai77:20210404230249p:plain

ちょっとデコボコ過ぎました。

f:id:kazuhironagai77:20210404230307p:plain

直します。

f:id:kazuhironagai77:20210404230321p:plain

うーん。やっぱりDisplacement mappingもあった方がよさそうです。ですがDisplacement mappingの勉強を今からやるのはちょっときついので来週にします。

7.3 海を作成します。

川や池、沼地の場所を先に把握したいので海を先に作成します。

こんな感じです。

f:id:kazuhironagai77:20210404230346p:plain

こっちの川がまったく水が流れていないので直します。

f:id:kazuhironagai77:20210404230402p:plain

水は流れる様に成りましたが崖の部分のMeshがグチャグチャです。

f:id:kazuhironagai77:20210404230420p:plain

直します。

f:id:kazuhironagai77:20210404230501p:plain

出来るだけ直しました。

f:id:kazuhironagai77:20210404230520p:plain

湿地帯を作って行きます。

f:id:kazuhironagai77:20210404230537p:plain

微調整を行います。

f:id:kazuhironagai77:20210404230553p:plain

正直しない方が良かったかもしれません。

7.4 崖を追加します。

地面をMaterial Functionにします。

f:id:kazuhironagai77:20210404230613p:plain

崖のMaterial Functionは3.1で作成した物をそのまま使用します。

更に3.1のTutorialで習ったWorld Aligned Blendのalpha値を使用した崖のPaintを使用しました。

f:id:kazuhironagai77:20210404230629p:plain

こんな感じです。

f:id:kazuhironagai77:20210404230651p:plain

近づくとこんな感じなので微調整をします。

f:id:kazuhironagai77:20210404230730p:plain

Material Instanceから微調整して、近距離では以下の様、

f:id:kazuhironagai77:20210404230747p:plain

遠距離では以下の様に、

f:id:kazuhironagai77:20210404230805p:plain

設定しました。

7.5 緑(草)のMaterial を追加します。

Starter KitにあったM_Ground_Grass を元に作成した、緑(草)のmaterialですが、見直したら、黄色と緑のParlin noiseなんかも使用していてまだ理解出来てない箇所がありました。のでそのまま使用する事にします。

f:id:kazuhironagai77:20210404230840p:plain

一生懸命自分で塗りました。

f:id:kazuhironagai77:20210404230859p:plain

7.6 Foliageを追加します。

これを使います。

f:id:kazuhironagai77:20210404230921p:plain

以下のMaterialを使用しました。

f:id:kazuhironagai77:20210404230937p:plain

f:id:kazuhironagai77:20210404230944p:plain

f:id:kazuhironagai77:20210404230951p:plain

f:id:kazuhironagai77:20210404230959p:plain

こんな感じに仕上がりました。

f:id:kazuhironagai77:20210404231016p:plain

今週はこの辺で止めておきます。

残りは来週やります。

8.まとめと感想

今週は、先週作成したLandscape の直し、先週やり残した2つのtutorialの勉強、そしてもう一度、新しいLandscapeを作成しました。

Landscape の直しでは以下の事をやりました。

  • Material instanceの作成。Material instanceを作成するとCompileしなくてもparameterの値を変えられるので3d view portを見ながら微調整が出来る。非常に便利。
  • Displacement Mappingについて。来週もっと勉強してLandscapeに使用する予定。
  • M_Ground_Grassの実装についての勉強。M_Ground_GrassStarter kitに付属のmaterial だか、実装方法が複雑で色々な機能が不明瞭な形で実装されている。(Macro varianceDistance blendingPerlin Noiseなど)

先週、やり残した2つのTutorialでは以下の事を勉強しました。

  • Texture SampleSampler Sourceについて
  • World Aligned Blendを使用して崖を見つける方法について
  • World Aligned Blendalpha値を使用する方法とReentrant expressionについて
  • Cull Distanceを使用する事で、Foliageの表示される範囲を自然かつPCに負担のないようにする方法について
  • UIWSを使用して水を表現。

もう一度、新しいLandscapeを作成した時に使用した機能です。

  • Specular Channelの値をあえて変更する。
  • Interactive Open world foliageを使用。

UE4のmaterialはC++でもShader 言語でも書けずBPを使用する事を強制される割に、3d Graphicsの数学と知識を総動員しないと理解出来ない、見た目とその難しさが真逆の分野と言う事が分かりました。更にmaterialの最適な値を見つけるためには実際の3D画面を見ながら細かい微調整が必要であり、芸術性が大きく要求される分野でもあります。

来週は以下の事をやろうと思っています。

  • Displacement mappingの実装
  • 針葉樹用の緑と沼用の地面のMaterialの追加
  • 沼の整理
  • ゲーム内のlandscapeの作成。

以上です。

今週も疲れました。

8.参考文献(Reference

  1. Unreal Sensei. (2020a, August 7). How to HIDE Texture REPETITION in Unreal Engine - UE4 Tutorial [Video]. YouTube. https://www.youtube.com/watch?v=yCRzOdo4b68
  2. Unreal Sensei. (2020b, August 8). How to INSTANTLY TEXTURE your landscapes in UE4 - Unreal Engine tutorial [Video]. YouTube. https://www.youtube.com/watch?v=mP8eHwVEA0o
  3. Unreal Sensei. (2020c, August 10). The Secret to Realistic Landscapes in Unreal Engine - UE4 Tutorial [Video]. YouTube. https://www.youtube.com/watch?v=UIycCZl4lYE
  4. Epic Games. (n.d.). SamplerSource. Unreal Engine Documentation. Retrieved April 4, 2021, from https://docs.unrealengine.com/en-US/API/Runtime/Engine/Materials/UMaterialExpressionTextureSample/SamplerSource/index.html
  5. Mocrosoft, White, S., Satran, M., & Koren, A. (2017, February 8). Texture addressing modes - UWP applications. Microsoft Docs. https://docs.microsoft.com/en-us/windows/uwp/graphics-concepts/texture-addressing-modes
  6. (2018, April 26). Reentrant Function. https://www.geeksforgeeks.org/reentrant-function/
  7. Wikipedia contributors. (2021, February 4). Reentrancy (computing). Wikipedia. https://en.wikipedia.org/wiki/Reentrancy_(computing)