＜前文＞
英語の勉強で気を付ける事
何回もここで書いていますが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倍マシだと言う事を理解して下さい。
それでは今週の勉強を始めます。
＜本文＞
１．今週の予定
先週の予定通り以下の事を行っていきます。
- バグの直し
- 戦闘中にアイテムを使用した時のセリフの直し
- Map１でBuildするとLandscape_0 instead mesh…と警告される
- Effectの勉強
- Effect（魔法陣）をWarpGateに追加する。
- Landscape4にもっとモンスターを配置する。
- Landscape4からMap1に戻るためのWarpGateを作成する。
- 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する。
- Map1の家の影が真っ暗な理由をConstructing Believable Environmentで勉強したGlobal Illuminationと絡めて勉強する。
後、先週のLightingの勉強で途中で投げ出してしまったんですが、何を学んだのかをもう一回まとめ直します。
２．先週の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を見ると
と説明してあったとまとめてありました。
最初からあれですが、明るさと光の色はLight mapに記録と逆に記憶していていました。この先週のBlogが間違って記録してしまったのかはたまた私の記憶が間違っているのか？ちょっと確認します。
あってました。
先週、書き忘れていますが、Stationary lightはmoveable objectに対して光を追加出来るそうです。
Constructing Believable Environmentにおける説明です。
こちらももう一度tutorialをチェックします。
Understanding Lightmass - Baking Checklistのところです。
はい。言っていました。
後、先週の時点では曖昧な理解しかしていなかったんですが、Lightとobjectの両方にStatic、Stationary、そしてmoveableがあります。ここで解説されているのは両方ともLightの事です。この事について先に考察します。
以下に示した様にDirectional lightとCubeそしてその影を移すPlaneのみを配置したLevelを作成します。
まずObjectがStaticでlightがStatic、Stationary、そしてmoveableの場合を試します。
Object: Static、Light: Static
Cubeを動かすとCubeの影は動きません。Cubeの影がBakeされている証拠です。
Object: Static、Light: Moveable
Cubeを動かすとCubeの影も付いて行きます。Cubeの影がBakeされていない証拠です。
Object: Static、Light: Stationary
Constructing Believable Environmentの解説だとIndirect lightのみBakeされるとあります。Cubeの影はDirect lightから生成されているのでCubeを動かしたら影も付いてくると言う事でしょうか？
げっ。影が二つ出来ました。
どういう事？
ちょっと慌てましたが、Becoming an Environment Artist in UnrealにあるStationary Lightingの説明にしっかり解説されていました。
要するに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について動きます。
Object: Moveable、Light: Static
Objectの影が消えてしまいました。予測通りです。
Object: Moveable、Light: Moveable
動かす前から影の付き方が違うような気がしますが、動かします。
Objectと影は一緒に動きます。
Directional lightが動かない場合はこの方法は高コストすぎます。
やっぱりそうでした。
今度はCubeそのものの影、いわゆる陰影でいう陰の部分についての考察です。
Stationary Lightingでは以下のような淡い灰色です。
Moveable lightingでは
真っ黒になってしまいます。
調べたのですが、なぜこの違いが出るのか分かりませんでした。
考えられるのはConstructing Believable Environmentにおける説明であった
です。
つまり、Directional lightの光が地面に当たって反射してCubeの陰の部分を照らしています。それをStationary Lightの場合はLight mapにBakeしているのかもしれません。
この仮説を検証するために地面を赤くしました。
すると、
Cubeの陰の部分も赤くなりました。地面から反射した光がCubeの陰の部分を照らしているのは間違いないですね。
図らずも先週の疑問の答えも判明しましたね。
Directional LightがMoveableなのでObjectは地面からの反射光を受ける事が出来ずに陰の部分が真っ暗になってしまうわけです。
しかしこれって問題もあるんじゃないでしょうか？
CubeがMoveableの場合、地面の色が違う場所に移動する可能性があります。その時、既にCubeに地面からの反射光をBakeしていたらその色を保持したまま移動してしまいますよね。
試してみます。
あれ。Bakeされていないじゃん。
どういう事？
ああ、分かっちった。
これは語弊があるかもしれないので仮説として説明します。
Constructing Believable Environmentの説明、
が間違っているんですよ。
いいですか。
まずIndirect lightの情報だけLight mapにBakeするなら、
この実験で影がBakeされる訳がないんです。
このBakeされた影はDirectなLightの情報ですから。
更にIndirect なlightがBakeされるなら
これも起きるはずはないです。Cubeのオレンジ色は地面からのIndirectな光の反射の影響なんですから。
この二つの実験結果は、Constructing Believable EnvironmentのStationary lightingの説明である「Indirect lightの情報だけLight mapにBakeする」に矛盾します。
Stationary lightingは先程私が導いた結論、Directional lightが動かない状態のゲームで、キャラの陰影は最大限に表示しつつコストは、Directional lightをMoveableにセットしたよりも低くするために開発されたModeなんです。
それだけ理解すればいいんです。
３．バグの直し
3.1 戦闘中にアイテムを使用した時のセリフの直し
先週見つけた問題ですが、戦闘中にアイテムを使用した際に、要らない事を報告しすぎています。
HPが回復した時でMPに変化が無い時は、MPについての報告は要らないですし、逆もまたしかりです。
3.1.1 セリフの実装部の流れを確認する。
まずこのセリフがどのように実装されているかの確認をします。
戦闘中にアイテムを使用すると
Use Item in Combat関数が呼ばれます。
Use Item in Combat関数の実装部は以下の様になっています。
このクラスの変数finishedDesicionがTrueにセットされます。
するとこのクラスの関数、MakeDecision()が呼ばれた時にTrueを返します。
この関数はGameCharacterクラスのMakeDecision()関数から呼ばれています。
この関数がTrueを返すとRPGGameModeクラスのReportMakeDecision()関数が呼ばれます。
RPGGameModeクラスのReportMakeDecision()関数のFunction Specifier の一つがBlueprintImplementableEventなので、BP内で実装しています。
RPGGameModeBPクラスのEvent Report Make Decisionを見ると
以下のセリフを表示しています。
GameCharacterクラスのMakeDecision()関数は同じクラスのTextFinishTyping()関数が呼ばれることによりTrueを返します。
ちなみにText Finish Typing()関数はRPGGameMode() クラスのTextTypingDone()関数から呼ばれます。
TextTypingDone()関数は、この関数のFunction Specifierの一つがBlueprintCallableなのでBPから呼ばれます。
RPGGameModeBPクラスを見ると、TextTypingDone()関数はEvent Confirm Button is Clickedが発動すると呼ばれています。
Event Confirm Button is Clickedは、CombatUIウィジェットの読みましたボタンがクリックされると発動します。
結局、CombatEngineクラスのTick()関数内のdecisionMade変数がTrueになるので、以下の部分のコードが実行され
PhaseがActionに移行します。
Action内では最初にGameCharacterクラスのBeginExecuteAction()関数が実行されます。
GameCharacterクラスのBeginExecuteAction()関数内では、RPGGameModeクラスのReportBeginExecuteAction()関数が実行されます。
RPGGameModeクラスのReportBeginExecuteAction()関数のFunction Specifierの一つがBlueprintImplementableEventなので実装はBP内で行われます。
RPGGameModeBPのReportBeginExecuteAction()をみると
以下のセリフを表示し
アニメーションをplayしています。ただしItemの使用はアニメーションが無いため、結局何もしていません。
それとは別に以下のコードも実行されています。
TestCombatActionItemクラスのBeginExecuteAction()関数の実装部をみると
GameCharacterクラスのReportDamgeHPtoRPGGameModeBase()関数などが呼ばれています。
実装部を見ると、RPGGameModeクラスのReprotCharacterHPisDamaged()関数などが呼ばれています。
RPGGameModeクラスのReprotCharacterHPisDamaged()関数などのFunction Specifierの一つはBlueprintImplementableEventなので実装はBP内で行われています。
RPGGameModeBPクラスのReportCharacterHPisDamagedなどをみると
以下の実装部で問題のセリフを表示していました。
かなり遠回りしましたが、戦闘中のアイテムを使用した時の実際のコードの執行のされ方が確認出来ました。
3.1.2 MPやHPの変化が0の時はセリフを表示しないようにする。
TestCombatActionItemクラスのBeginExecuteAction()関数内で以下の関数がよばれています。ItemHPかItemMPが0の場合は
ItemHPかItemMPが0の場合はこれらの関数を呼ぶのを止めれば、MPやHPの変化が0の時はセリフを表示しないように出来ます。
以下の様に改良しました。
これで、ItemHPかItemMPが0の場合はこれらの関数を呼ぶのを止めるはずです。
Buildします。
UE4C++をいじるのは久しぶりです。ちょっと緊張します。
成功しました。
一応、UE4editorも再起動させます。
それではテストしてみます。
まずは回復薬を使用します。
MP云々は表示されなくなりました。成功です。
次にダークイーサーを使用します。
こっちもHPは表示されません。
最後にイーサーを使用します。
はい。この場合も不必要なHPについての報告はありません。
出来ました。
3.1.3 MPやHPがMaxまで上昇した場合とそれ以外で分ける。
まず思ったのはダークイーサーを使用した時のセリフが
しか説明していないにも関わらず不自然じゃないんです。
ので「Maxまで上がりました。」を無くしてしまいます。
以下の様にしました。
これで良い気がしています。
理由が分かりました。
「ほど」と表現しているからです。「ほど」と断定を避けているので絶対20回復した訳ではありませんから、何となく不自然じゃないんです。
これでOKですね。
3.2 Map１でBuildするとLandscape_0 instead mesh…と警告される
以下の警告が表示されます。
UE4 Answer HubのLandscape Error after build in Lighting Results [1]によると
と書かれています。
言っている事は分かりましたが、これってStatic lightingじゃなくすれば全部解決するんじゃないでしょうか？試してみます。
3.2.1 Static lightingを外す。
配置してあるLightを全部調べたのですが、Static lightingにセットされているのはSky lightのみでした。取りあえずStationaryに変えてみます。
赤くなってしまいました。
あれ。赤いけど地面からの反射光がキャラに反映されています。
ひょっとして、Cubemapに何もセットしていないからでしょうか？
Cubemapをセットしてみます。
きれいな反射光が付きました。
家も多少は明るくなりました。
やっぱり影になっている方は真っ暗です。
思い出しました。夜が明る過ぎる時はCubemapを外せ。みたいな事がGoodskyのFAQに書かれていたんです。
確かに夜は明る過ぎます。
Goodskyの説明書をもう一回読んでみます。
そんな事は書いてませんでした。
理由は分からないですが、兎に角あるときSky lightのCubemapを外してしまったようですね。
それは兎も角として
の警告は全く消えませんでした。
良く分かりません。
3.2.2 Landscape 4_FoilageやSwamp_Foliageに使用されているMeshのLODを変更する。
正直言って、LODについてどうやって整理されているのかまだ良く分かっていないんです。
のでどこをいじればLower LODが独自のLightmapをサポートできるのかまだ分かりません。
Static meshのLODPickerのCustomをチェックすると
LOD1などが現れます。
これで良いのでしょうか？それともこの現れたそれぞれのLODに何かを指定する必要があるのでしょうか？
使用しているStatic mesh全てのLOD PickerのCustomにセットしましたが警告は変わりませんでした。
うーん。
もう少し簡単な条件でLandscape Grass Outputを使用しないと原因が絞れないですね。来週やります。それまでにどういう条件で問題を絞れるのかを考えておきます。
現状の問題は、
- Static lightingは使用していないのに警告は消えない。
- Landscape Grass Outputに使用しているGrassのStatic meshのLOD1が良く分かっていない。
です。
まあ、今回は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がなさそうです。
Niagara Visual Effects [3]です。
こっちは逆に全部初心者向けみたいですね。
紹介文だけ読みましたがかなり面白そうです。
このゲームに使用するかどうかは別にしてもちょっと勉強する分には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集みたいなのがあったのですが圧巻の一言です。
試しに実際のTutorialの動画を見たのですが、この人の英語、滅茶苦茶聞き取りにくいです。でも字幕が在るので理解出来ない事はないでしょう。
早速、一個間違えて覚えていた事が分かりました。NiagaraもParticle systemの一つで、今まで使用していたParticle SystemはCascadeと呼ぶそうです。つまりUE4には2種類のParticle systemがあってCascadeとNiagaraとなります。
よし決めました。今週はNiagaraを勉強します。そしてParticle Systemそのものについても勉強します。ただしこのゲームは4.24で作成しているので、このゲームのEffectはCascadeで作成します。
4.2 Niagara Overviewを勉強する
公式のdocumentのNiagara Overview [6]を勉強します。
最初の文章から当たり前のようにVFXと言っていますが、私VFXの意味を知りません。
調べたら元々は、映画などの編集技術の一つでCGを使って行う特撮の事を指すみたいです。その技術が3Dのゲーム内で燃え盛る炎や、煙、あるいは魔法の効果などを表現するために逆輸入され、そこで大発展しました。その事により3D Graphics における一分野としてのVFXとしてまとめられるようになったみたいです。
VFXはvisual effectsの略だそうです。Vがvisualを指すのは分かりますが、Effectsが何でFX何だと思ったら、Eを取ったffectsの発音がアメリカ英語だからtを発音しないんでfecs ≒FXだからでした。Factsがファックスに聞こえるヤツと同じです。
ここまで理解してもう一回最初の文を読んでみると
UE4にはVFXを作成するための機能としてCascadeとNiagaraの２つが用意されています。と言う意味だったんですね。
Niagaraの特徴としてデザイナー (Technical Artist) がProgrammerの助けを借りなくても機能の追加が出来るようになっているそうです。
うーん。
この機能の追加が何を示してるのかまだ分からないですが、Particle の移動の計算とか、そのParticle に貼りつけたTextureのイメージに対する光の屈折の計算とかなんでしょうか？
Technical ArtistってProgrammingが出来るデザイナーの事ですよね。
UE4におけるBPの実装は、Script ProgrammingをProgrammer以外の人にも可能にした事で、すごい可能性を広げたんだと思うんです。それ以前はC++でゴリゴリProgram 書ける人しかUE使えなかったと思うからです。
しかしここで見逃してしまった問題もあると私は思っています。
それはProgrammerの種類です。
- C++でゴリゴリProgrammingかけてそれこそGame Engineそのものを自作出来るレベルの人
- C++は使えないけどそれより簡単な言語なら使える人
- 物理や工学の専門家で、微分方程式で表される物理現象を数値解析で解く事が出来る人
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は４つのComponent（System、Emitter、Module、Parameter）で構成されているそうです。ざっと読んだ感じではSystemの中にEmitterがあり、Emitterの中にModuleがあって、そのModule内でScriptのような物が書けて、データはParameterを使用して保持する。みたいです。
＜Niagara Stack Model and Stack Groups＞
上から順に実行されるらしいです。
＜Templates and Wizards＞
こんなTemplateやWizardが用意されています。と言う説明でした。
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を時間軸で管理してると説明されていました。
３つのComponentの役割分担がはっきり分かりました。
何で、Niagara Overviewの方はこういう分かり易い事全然説明してくれていないの？と思って見直したんですが、一応それなりには説明していました。
例えばModuleの所ではGraph内でCustom HLSLを使用するとか、SystemではTimelineを管理するとかです。
しかし、NiagaraはUE4を使う全ての分野の人達が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を使用するために必要なMeshとMaterialの作成方法
- NiagaraのEmitterとSystemを使用して簡単な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をコピーして
名前を変えて使用する事にします。
Materialも作成します。
どうしてこのような実装に至ったのかの説明が全くありませんでした。
あー。やっぱり錬金術師系戦士の必要性に全く気が付いてないですね。
＜Create the Effect＞
さすが、4.26。FXを見たらNiagaraに関するBPが表示されました。
Niagara Systemを選択したら
が表示されました。
Niagara Overviewでこの図の説明がされていましたが、こんなに早く必要になるとは思っていませんでした。
ちょっと読んで来ます。
まず、Systemを作成する時はこの４つのOptionから選択しないといけないそうです。Emitterの種類にはTemplateと今までに自作した物の2種類があるみたいです。その両方を表示してくれるのが最初のOption、Templateだけ表示するのが2番目、自作のemitterだけ表示するのが3番目、何も表示しないのが4番目の様です。
一番目を選択します。
凄い。Templateに色々なEmitterが表示されています。
Tutorialに書かれている通りにSimple Sprite Burstを選択して終了します。
作成されたSystemを開くとYouTubeのTutorialで見たのと同じEditorが表示されました。
System内に保持されるEmitterと言う表現がありますが、このEmitter SettingとかEmitter Spawnなどがそれに当たるんでしょうか？
後、Stack Paradigmで表されると言う事は、
- Emitter Setting －＞ Emitter Spawn －＞ Emitter Update ―＞ Particle Spawn －＞Particle Update ―＞Event Handler ―＞ Render
の順で実行されると言う事でしょうか？
Rendererの設定はTutorialに書かれていた通りに作成しました。
MaterialのFacing ModeがVelocityと言うのは何を指すのでしょうか？
ここは良く分かりません。
分からない時は、カーソルを乗せて見る。です。
Meshのカメラに対する向きの決定方法だそうです。
はい。分かりました。
球を使用しているので私のMeshの場合は意味ないかもしれません。Tutorialが敢えて水分子みたいなのを使用しているのもここを強調するためかもしれませんね。
こっちの説明がないんですが、これは4.26から付いた新しい機能なんでしょうか？
＜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の機能の説明が表示されました。
要するにtick()関数ですね。
Tutorialをよく読んだらEmitter State moduleと書かれていました。Emitter StateがModuleなんですね。
Tutorialの指示に従って以下のParameterの値を変化させました。
Tutorialではそれぞれの変数が何を指しているのかの説明は無かったんですが、カーソルを乗せたら、以下の説明が出て来ました。
かなり詳しく解説されています。今回は読みませんが読んだらどんな機能の調節をするのか理解出来そうです。
Moduleの調節ってBPみたいなのはないんでしょうか？
何か想像していたのとはちょっと違いますね。
＜＜Particle Spawn Settings＞＞
以下のようにTutorialの指示通りに作成しました。
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を追加する方法が良く分からなくて凄く時間がかかりました。
が一応出来ました。
＜テストします。＞
想像の100倍くらいデカイ球が生成されています。
Particle SpawnのInitial Particleの以下の設定部分を１から0.1、2から0.2 に変更してみました。
今度は大きさ的にはイイ感じです。
でもまず透明感が全くないですね。
後、何で足元に自然に発生するような設定になっているんですかね。
ちょっと時間がなくなってしまったのでここで中止しますが、このTutorial最初の印象と大違いでかなり勉強になります。
来週はもう少しかんばります。
以下の箇所は来週やります。
- Effect（魔法陣）をWarp Gateに追加する。
- Landscape4にもっとモンスターを配置する。
- Landscape4からMap1に戻るためのWarp Gateを作成する。
- 地図のワープ機能とLandscape4をどうやって絡めていくのかを検討する。
５．まとめと感想
今週は、
- 先週のLightingの復習
- バグの直し
- 戦闘中にアイテムを使用した時のセリフの直し
- Map１でBuildするとLandscape_0 instead mesh…と警告される事の検証
- Effectの勉強
- Niagaraの勉強
を行いました。
来週は、
- Map１で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
