＜前文＞
前文には日本人が誤解しているアメリカ、特に日本文化とキリスト教文化の違いから生じる誤解とその解決法について気が付く範囲ですが書いて置きます。
＜沈黙は金ではない！＞
先週、アメリカ人は専門家や上司の言う事を、日本人のように「自分では悪いと思っても会社の命令（専門家の意見）なので…」と言って無条件で聞く事はない。と述べましたが、じゃどうやって意思決定をしているのかと言うとこんな感じです。
ある大学発のベンチャーでゲームを制作しているとします。
ゲーム制作は順調に進み8割程度は出来て来ました。そしたら問題発生です。小さな修正をするたびにCompileするんですが、それに2時間もかかるようになってしまいました。小さな修正をするたびに2時間待たなければなりません。社長は発狂しています。
社長が発狂しながら断言します。「全部のPCのHDDをSSDに代える。」
みんな「えー」と絶叫です。
はい。ここからがとてもアメリカ的になります。
まず統計学の得意な社員がHDDでCompileした場合とSSDでCompileした場合の短縮した時間のデータを出来るだけ集めて、本当にSSDでCompileしたら速くなるのか検討します。
こんな感じでしょうか？
存在してるデータでSSDでCompileしたら平均で10分くらい速くなっている。
サンプル数が十分がどうかを検討するために逆の仮説「SSDに代えてもCompile時間は変わらない。」をDisproveします。
Student tで計算した結果、全部のSSDを変えた場合に平均で10分くらい速くならない確率は5%以下と出ました。
よって社長が言うように「全部のPCのHDDをSSDに代える。」とCompile時間の短縮に繋がる可能性は高いと。
みんな「オーッ」です。
すると今度は、会計が得意な社員が、これからCompileする回数と10分の短縮とProgrammerの時給を計算して、SSDの値段と比較してSSDを買い替えても得なのかどうかを経費の立場から意見を言います。
これもみんな「オーー」です。
はい。会社の雰囲気が変わって来ました。
即興で始まった非公式の会議ですが「Compileに2時間もかかる。」という会社存続の危機に対する解決策を検討すると言うとても重大な内容です。
ここで発言した社員は、社長からだけでなく他の社員からも出来るヤツと観られています。
こうなると「やべー。俺も何か発言しないと。」と結構焦って来ます。でも変な事を言うよりは黙っている方が良いかもしれません。
はい。皆さんがアメリカで仕事をしていてこんな状況になったらどんな発言をしますか？もしくは黙っていますか？
今回の例は、間違った回答をすると絶体絶命のピンチに陥る場面ではありませんが、日本文化的な対応をすると無能と誤解されてしまうケースです。
日本人がよくやる間違った対応をまず紹介します。
間違い１：調べて、自分なりの解答を見つけるが、取りあえず黙っておく。
例えば、今回の例でいうと、SSDとHDDにおけるCompileの時間の違いについてStack Overflowで調べたとします。
すると「SSDとHDDでCompileの時間の違いはない。」と書かれています。
ここで大抵の日本人は、SSDを買う方向で議論が進んでるという会社の空気を読んで黙ってしまいます。
いわゆる「雄弁は銀、沈黙は金」と言うやつです。日本文化だったらこれは100％正しいやり方です。
しかし、アメリカでこれをやると以下の理由で大変な無能と思われてしまいます。
- 議論に参加出来る専門知識が欠如している。
- リーダーシップが足りない。
- 会話に積極的に参加する意思がない。
最初の「議論に参加出来る専門知識が欠如している。」ですが、自分の専門分野の知識を元にどんどん発言しないと詰みます。アメリカでは自分の意見を言わないのは「意見を言えるほどの勉強をしていない。」と見なされます。本当に見なされます。学生ならばまだテストの点で挽回出来るかもしれませんが、実社会ではこういう場面での発言がその人の能力の評価に直結します。Incompetentの烙印を押されないためには、自分の専門の立場からの発言は必ずしなければなりません。
日本だと専門家が専門用語を交えて説明すると、結構社会的な地位のある人でも「小学生でも分かる様に説明しろ！」と叱責する人がいますが、アメリカではそんな必要はありません。どんどん専門用語を使って良いです。多少は合いの手を入れて「ここはProgrammer以外の人には馴染みないかもしれませんが」とか言っておけば十分です。
ただし結論だけは小学生にも分かるようにしないといけません。結論だけで十分です。
次の「リーダーシップが足りない。」ですが、日本では「出る杭は打たれる。」という諺に代表されるように、トップに立つと必ず潰されます。これはヨーロッパでも同じかもしれません。
しかしアメリカではリーダーは本当に特別なんです。
開拓時代の苦しい生活においては、優れたリーダーがみんなを正しい方向に引っ張って行かないと本当に村ごと全滅してしまったんです。だからリーダーを選ぶ時は、真剣です。これは小さい子供たちのグループでも同じで、自分たちのリーダーを選ぶ時は真剣です。そして一端、リーダーを選んだら、みんなはそのリーダーを補助するための全力を尽くしますし、リーダーはみんなを正しい方向に導くために全力で頑張ります。
そしてここが重要ですが、リーダーに選ばれた人は無条件でずっとリーダーでいられるわけではありません。失敗すればすぐにリーダーの地位から降ろされますし期限で交代する時もあります。
だからアメリカ人は無意識の内に常に次のリーダー候補を探しているんです。
発言しない人がリーダーに相応しいかどうかの判断は絶対に出来ません。
だから発言しないだけでリーダーシップが足りないと判断されます。そして会社でその判断を下されたら結構、致命的です。リストラの対象になります。
最後の「会話に積極的に参加する意思がない。」ですが、もはや村の一員とすら見做してもらえない他人の烙印を押されてしまいます。村の一員でないので大切な決め事の時にも呼ばれなくなりますし、困っていても助けても貰えなくなります。
間違い２：真剣に正しい解答を考えていて議論に参加しない。
日本だとウーンと唸りながら天を仰ぎみたりすると、真剣に考えていると受け取られますが、アメリカでこれやると無視してると受け取られます。
アメリカで相手の話を真剣に聞いてるというジェスチャーは一個しかありません。
相手の目を滅茶苦茶真剣に見つめて相手の話に合わせてうんうん頷く。これだけです。これ以外のジェスチャーは人の話を聞いていないとみなされます。
大体、アメリカでは、次の発言をする人はアイコンタクトで決めているんです。相手の顔見てなかったら何時発言出来るのかも分からないです。
更に言えば、アイコンタクトしていれば、特別に発言したい時は、人差し指を一寸上げるだけで十分です。
後、思い出したんですが、日本では人が喋ってる間に割り込んで話す人がいますが、アメリカでこれやると終りですから。小学生レベルの躾が出来ていないと思われます。会社なら直ぐ首です。
間違い３：会議の後で社長だけにこっそり自分の意見を言う。
これは私も聞いた話で本当の所は分からないですが、日本だと会議をやった後に、同じ派閥の人だけが集まってそこでもう一回会議を行う所があるらしいんです。外様の社員は形だけ会議に参加させるみたいな事何でしょうか？
このせいなのかどうか知りませんが、日本人には、会議の後で社長だけにこっそり自分の意見を言う人がいるらしいです。
私の経験の範囲ですが、これはケースバイケースで、その場にいる人を直接批判する内容ですがボスには絶対報告しておいた方が良い場合はOKです。
今回の例のように、別に他の人に隠す必要がない場合は、聞いてもらえない＋評価されない可能性が高いです。
これは一寸、アメリカにおける議論の前提を理解出来ればすぐに想像つきます。限られたリソースと時間の中から最適解を探すのが議論の目的なんです。後で結論が出てから自分の意見を言ったって何の役にも立ちません。
正解：兎に角、自分の意見を言っておく
Stack Overflowを調べた結果を発言しておくだけでもかなり好評価が付きます。その理由は間違い１で説明した内容の反対になるからです。
- 議論に参加出来る専門知識は十分持っている。
- リーダーシップがある。
- 会話に積極的に参加する意思ある。
と評価されます。
しかし社長が、そのStack Overflowの解答を読んで、実際の結果では統計的に有意な差が出ている。つまりこの理屈は間違ってる。と断言したとします。
それでも貴方の評価が悪くなる事はアメリカでは絶対にありません。
そしてStack Overflowの解答で二番目に評価されている解答が、実際にSSDを使用すると速くなっていると言う意見だとします。社長がほら見た事かと言うかもしれませんが、それでも貴方の評価は良いままです。
因みに私がそんな状況にいたら、最初のゲームを制作する前にUE4を使用する事を進めていますね。絶対に。
そして８割完成した時にもCompileの問題は起きていないはずです。だってUE4ならHot Reload機能がついていますから。
それでは今週の勉強を始めます。
＜本文＞
１．今週の予定
今週は以下の事をやります。
- Particle Systemの勉強
- RPGの作成
- Item Spawn Dataの複製
- Loading Screenの勉強の続き
- Good Skyの復習
２．Niagara : 今までの勉強の復習
今週は今まで勉強した内容を復習します。
来週から多分ですがCGHOW氏のTutorialを勉強する事にしますが、目的が曖昧なままだと着地点も曖昧になってしまいます。ので目的、何でVFXの勉強を始めたのかとか、もしっかり再確認します。
2.1 Blogの見直し
Blogを見直すと2021-04-26からParticle Systemの勉強を始めています。
それぞれのBlogから何を勉強したのかとか、何が目的で勉強していたのかなどを要約します。
- UEのParticle Systemについて全く理解していないので勉強する事にした。
- Niagara の方がCascadeよりも資料が多そうだか、24には試験的にしか付いていない。
- VFXとはVirtual Effect（視覚効果）という意味で、映画の撮影に使用するCGを指している。この技術で３Dゲームに使えるものが逆輸入された。
- UEで使用されるVFXはParticle Systemのみである。
- System、Emitter、Moduleについて漠然と理解。
- Material内で使用するParameter nodeの値をNiagara側のModuleで設定出来る事
- Module内でHLSLが使用出来る事とMaterialの関係やCustom HLSLとModuleをnodeを使用して作成出来る事の関係が分からなくて混乱しています。
- Houdiniについて少しだけ調べています。
- NiagaraのRenderingが、Sprite、Sprite(GPU) 、Mesh、Light、Ribbon、Steam、Sparks、そしてBeamである事について簡便ですが述べています。
- 複数のEmitterを一つのNiagara System内で扱っています。
- Moduleの継承について解説していますが、覚えていません。Moduleの継承ってなんでしたっけ。
- EmitterのIconの意味について解説しています。
- Emitterの塊は、ScriptもしくはStackと呼ぶ。
- Event とEvent Handlerについて勉強しています。
- Niagaraを勉強する目的が曖昧なまま勉強しているので今回の最終目的はNiagaraで花火を作成する事と宣言しています。しかも7月までに完成させると宣言してました。
- SpriteがParticleに面を貼り付けて作成される事を確認しました。
- Light ParticleとSpriteで発光させた場合の違い。Light Particleは回りを光らせる働きがある事について述べています。
- Mesh Particleの基本的な作成方法の勉強
- Mesh ParticleとLight Particleが併用出来る事の確認
- Mesh ParticleとSpriteの違いについて
- Audio Effects In Niagaraの基本についての勉強
- ModuleからModule Scriptを開く方法について
- 先週、良く分からなかったRibbon Renderingに使用されているModuleなどの機能について詳しく調べています。
- 正し、Ribbon のRenderingをどうやっているのかまではまだ理解していません。
- Cascadeですが、以下のMaterialをどうやって作ったのか調べていますが、結局不明だったと述べています。
これってどう見てもFresnel 関数ですよね。確認します。
元のMaterial名はM_ShapeMasterでした。
しっかりFresnelを使用していました。
- Ribbon RenderingがどうやってRenderingしているのかを調べています。
- 調べていますがBeam Rendering を使用して調べています。
- Bezier Curveについて勉強しています。この時、調べたせいかBezier Curveについての動画がYouTubeのお勧めに大量に表示されるようになりました。Bezier Curveについては完璧に理解しました。お腹一杯です。
- Component Renderingについて調べていますね。
- Ribbon Renderingにおける最初の仮説を以下のように表しています。
- 色々な絵をRibbonに貼りつけてVisual的な面白さを検討しています。
このEffectなんかもう少し精度を上げたら商用で売れそうです。こういうのを深堀りすべきかもしれませんね。
- 今度はBeam Effectについて調べています。
- Beam Renderingについて詳しく調べて結論らしきものが書かれていますが、私この辺の内容すっかり忘れてしまいました。後でもう一回勉強し直します。
- 今度はSmoke Effectについて勉強しています。
- Sub UVの使用方法が分からないので勉強すると言っています。
- 一応、Sub UVがAnimationを担当している事と、そのAnimationの再現方法について理解しました。
< 2021-07-25>
- Smoke Effectの続きを作成しています。
- その過程でNiagara Module Scriptの作り方も調べています。
- これ以上勉強する事がないのでContent Exampleからサンプルを見て次の勉強する内容を決めるとか抜かしています。
- CGHOW氏のTutorialと比較してCGHOW氏のTutorialの方が実践的な気がするのでそっちをやると言ってます。
- 池田 亘 著「HoudiniとUnreal Engine 4で学ぶリアルタイムVFX」を読んだ感想もここに書かれていました。
< 2021-08-02 >
- CGHOW氏のTutorialの内最初の一個目をやってます。
- 大量の蒸気を地面から発生させる方法を学びました。
- これからは応用編として炎、煙、雷、水、氷、魔法陣、雪、砂、風、光、闇、爆発、回復、状態異常や呪いなどの作成方法を勉強すると言ってます。
成程、この辺から目的がブレてるんですね。Niagaraそのものの勉強、Moduleの仕組みやNiagaraにしかない機能の勉強をしたいと言う気持ちと、ゲーム制作のために必要なEffectの作成方法を勉強したいという二つの目的が生まれてどっちつかずになってしまうわけですね。
< 2021-08-09 >
- CGHOW氏のTutorialの続きをやっています。
- CGHOW氏のTutorial ではLight Emitterを使用して雲を光らせていますが、それが出来ません。
はい。雲を光らせるのがこのTutorialの肝なのにそれが出来ないんです。しかも4.26で作成したサンプルがほしけりゃ10ドルで買え。と
これは、Niagaraの勉強の速度が非常に遅くなってしまいます。はい。
< 2021-08-16 >
- CGHOW氏のTutorialで全く別なNebulaの作成に挑戦してますね。もう炎、煙、雷などのゲームのEffectとか関係なしになっています。
- 今回のは、そこそこは作成出来たみたいで、分かり易いと書いています。
- ample Static Mesh ModuleやScratch Moduleの使用方法について学べたのでそれなりには役に立ったみたいです。
この辺は難しい所ですね。
炎、煙、雷などのEffectの作成方法について知りたいわけですが、そこは直接は教えてもらえない訳です。しかし自分の知らないModuleの使用方法は教えてもらえます。
< 2021-08-23>
- 前の週に始めて使用したModuleについて調べています。
< 2021-08-30>
以上です。
2.2 Niagaraの勉強における問題点
はい。
Niagaraの勉強が一寸詰まっている理由が完璧に分かりました。CGHOW氏のTutorialのせいです。CGHOW氏のTutorialをやると目的の達成度は60％とかになってしまいます。これでは出来たのかどうか分かりません。
そしてですね。私の勉強の経験から言うと60%しか理解出来ないものは危ういんです。簡単なものでも100％理解した方が上に詰めるんです。単純に言って60％の出来のものに60%の出来のものを積むと30％の出来になってしまいます。
フランス語のTutorialですが
Rimaye [ Assets and Tutorials - NIAGARA ]氏のTutorial [1]の方がまだ良いかもしれません。
試しに見てみましたが、フランス語全く分かりません。
凄い不安です。英語が分からない日本人の友達の気持ちがなんか分かりました。
あるいはContent ExampleのNiagaraを勉強すべきでしょうか？
Spriteの面は常にカメラに向いているのではなく自由に方向を変えられると言うTutorialですがパッと見ではどこでSpriteの面の方向を弄っているのか分かりません。
こういうのをキッチリ追及した方が勉強になる気がしますが、今の自分にそれが出来るでしょうか？
やっぱりCGHOW氏のTutorialも捨てがたいですね。60%しか出来なくても結構重要なModuleの使用方法なんかも教えてくれます。
ただしCGHOW氏のTutorialで勉強する時は、
- 目的は？
- 出来なかった事は？
- 学んだ事は？
- 目的は達成出来たのか？
- Tutorial通りに作れたのか？
- このTutorialの改善点について
を常にまとめる必要があります。
わかった。
CGHOW氏のTutorialが他の英語圏のTutorialと徹底的に違う点が。
生徒の意見を聞いて推敲しないんです。
まるで日本の先生のようです。
インド人と日本人は似ている。中国人とアメリカ人は似ている。と言う説がありますが、こんなとこでインド人と日本人が似ていたとは驚きです。
2.3 別なTutorialで勉強してみる
今週、Niagaraの勉強そのものをやらないのもあれなので、公式のYouTubeチャンネルであるUnreal EngineのBuilding advanced effects in Niagara | Unreal Engine [2]で勉強してみます。
このTutorialを勉強する目的は、ずばりCGHOW氏のTutorialとの違いを見極める事です。
このTutorialはNiagaraの機能では上級者向けである以下に示したEffectの作成を行いますが、
Niagaraの学習初心者が必ず躓くFXのどれを選択すれば良いのかから説明しています。
そしてそういうNiagara学習初心者は、兎に角、最後のNiagara Systemを選択しておけ。と言っています。
これってこのTutorialの学習者にとって大変重要な線引きをしていますよね。このFXからどれを選択すべきなのか分からない程度の知識しかない学習者に対してもこのTutorialは対応していますと。
ちなみに私がこの中からNiagara SystemかNiagara Emitterを選択出来るようになったのは、
- 公式のDocumentであるNiagara Visual Effects [3] にあるNiagara Quick Start [4]
- Niagara Visual Effects [3] にあるCreate a Sprite Particle Effect in Niagara [5]
- gameDev Outpost氏のUE4 - Introduction To Niagara [6]
の３つのTutorialから学んだ成果です。
今だとこの選択肢をどれくらい理解していでしょうか？
最初のNiagara Dynamic Input Scriptは多分、Scratch PadにあるDynamic InputsのAsset版だと思います。
次のNiagara Effect Typeは何なんでしょう？
試しに一個作成してみましたが
ちょっと意味が分かりません。
Niagara Emitterは勿論、Emitterを作成するためのものです。
Niagara Function ScriptはNiagara Systemで使用する関数を作成するものでしょうか？
Moduleとどう違うんでしょうか？
中身はこんな感じでした。
これもよく分かりません。
Niagara Module ScriptはModuleを作成するためのものでしょう。
Scratch Pat Moduleをasset化したものと同じだと思います。
Niagara Parameter CollectionとNiagara Parameter Collection Instanceはこれも多分ですが、MaterialにParameterを送るやつのNiagara版でしょう。
まあ、使い方は分かりませんね。
最後のNiagara Systemは、Niagaraの機能を一括で管理します。NiagaraでVFXを作成する時に必ず使用します。
こんな感じです。
しょっぱなから脇道に逸れました。
元に戻ります。
はい。Niagara SystemからNS_Spinning Particlesを作成しました。
以下の箇所のTrackを押す事で新しいEmitterをNiagara Systemに足せる事を簡単ですが説明しています。
その後で、Emitter内のそれぞれのCategoryがModuleを実行する事を説明しています。
出来ればここで、それぞれのCategoryは何をしているかの説明もしてくれると、その後でModuleを追加する時に何故そのCategoryに追加しないといけないのかも分かって良かったんですが、それは無かったです。
簡単に自分が知る限りで説明しておきます。（公式のDocumentであるNiagara System and Emitter Module Reference [7] を参考にしています。）
Emitter Settingsです。
ここはClassで言う所のConstructerです。Emitterが持つ変数に値をAssignします。
基本的にModuleを追加する事は出来ません。
Emitter Spawnです。
ここはEmitterが作成された時、一回だけ実行されます。
BPで言う所のEvent BeginPlayです。
ここにModuleをセットする事は出来ますが、このEmitterが作成された時に一回だけしか実行されないので、実際はModuleをこのSectionに追加する事はあまりありません。
次がEmitter Updateです。
ここはEmitterがUpdateするたびに実行されます。BPでいう所のTickです。
当然ですがここで、1秒間に何個のParticleを生成するとか、一回で何個のParticleを生成するとかを指定します。
その次がParticle Spawnです。
これはそれぞれのParticleで毎回Updateしたい特徴を指定する時に使用します。例えばParticleの色が時間によって変化させたい時はここで指定します。
さらにEffectでSprite以外の表現をする時（Ribbon、Beam、SubUVによるAnimation、MeshによるParticleなど）でParticleに対して特別な指定を毎回する必要がある場合はこのSectionで行います。
ここで分からないのはここでもForceの指定が出来る事です。
最後のSectionはRendererです。
このSectionはその言葉通りでどんなRenderingを行うのかを指定します。
Sprite、Mesh、Ribbonなどです。NiagaraではBeam RenderingはRibbon Rendererを使用して行います。
Light Rendererのように他のRendererと併用して行えるものも有りますが、通常は一個のRenderingしか選択出来ません。
こんな説明を追加して欲しかったです。
先に進みます。
Emitter Update CategoryにSpawn Rate Moduleを追加しました。
この部分の解説にSpawn Rateが1秒間に何回、Particleを生成するのかを指定している事を説明して欲しかったです。
なんと一秒間に400回もParticleを生成します。
今度はParticleを生成する場所を変更する事で実際は沢山のParticleが生成されている事を示します。
Particle Spawn SectionにSphere Location Moduleを追加します。
この結果、ViewportのImageが以下の様になり沢山のParticleが生成されている事が分かります。
所が、私が4.26のNiagaraで同じ事をやると以下のようになります。
こっこれは。私がCGHOW氏のTutorialを試した時もこれと同じ事が起きました。と言う事が私が思っている程CGHOW氏のTutorialも悪くないのかもしれませんね。
Particle Spawn Sectionに作成されているInitialize Particle Moduleの値を以下に示した様に変更してParticle のサイズを小さくしました。
大体、Tutorialの結果と同じになりました。
今度はこれらのParticleにForceを追加していきます。
最初はParticle Update SectionにVortex Force Moduleを追加しました。
Errorが表示されます。
これを修正するにはSolve Forces and Velocity Moduleの上にVortex Force Moduleを移動する必要があります。
これはそれぞれのModuleの役割を考えれば当たり前の話で、Solve Forces and Velocity Moduleで速度や力を計算するのに計算した後で速度や力の値を変更しても意味ないですよね。
Vortex Force Moduleについてですが要するに渦を作成するための力をそれぞれのParticleに追加してくれるModuleです。
上から眺めると一応渦を描いています。
はい。どうせなのでこのModuleを使用してForceをParticle Spawn Sectionにセットした場合と、Particle Update Sectionにセットした場合の違いを見てみます。
Particle Update SectionにVortex Force Moduleをセットした場合です。
Particle Spawn SectionにVortex Force Moduleをセットした場合です。
Particle Spawn SectionにVortex Force Moduleをセットした場合の方が、Particleが遠くまで広がっています。両方とも渦を描いていますが、Particle Update SectionにVortex Force Moduleをセットした場合の方が回転が強力です。
この結果から推測するとParticle Spawn SectionにVortex Force Moduleをセットした場合は、そんなものがあるのか分かりませんが、初加速度的な力の加え方をしていて、Particle Update SectionにVortex Force Moduleをセットした場合は継続的に加速度がかかっているいて所謂、等加速度運動の動きをしているようです。
私、力学はあんまり得意じゃないんでこの解釈で正しいのか分かりません。
この辺の解釈は力学の復習も兼ねてぼちぼち勉強していきます。
今度はParticle Update SectionにGravity Force Moduleを追加する事で、重力を追加します。
重力を計算するためのModuleをParticle Update Sectionにセットしていると言う事は、Particleに等加速度運動を強いる時はForce ModuleはParticle Update Sectionにセットすべきと言う事ですね。
それは兎も角としてParticleが真下に落ちるだけになってしまいました。
Gravity Forceのｚの値を‐30に変更します。
Particleの動きはこんなになりました。
最後にParticle Update SectionにPoint Attraction Force Moduleを追加します。
このModuleは中心に集まるようなForceをそれぞれのParticleに追加するModuleだそうです。
こんな感じになりました。
今度はColor ModuleをParticle Update Sectionに追加します。
こんな感じです。
今度は色の変化をParticleの寿命からParticleの中心からの距離に変更します。
を以下の様に変更しました。
こんな感じになりました。
Particles Positionは何となく意味が分かりますが、Simulation Positionは何を指しているのでしょうか？
Emitter Properties ModuleのLocal Spaceにチェックは付いていないので、Engine.Owner.Positionの値を返すみたいですね。そのEngine.Owner.Positionの値がなんなのか不明ですが？
あ、分かりました。このModule、中心の位置を返すんですよ。それで意味が通じます。Start Positionで現在のParticleの位置、End Positionで渦の中心の位置を指定して、その差の最大が400になるようにセットしているだけでしょう。
最後にRenderer SectionにLight Rendererを追加します。
それはいいんですが、Tutorialではなんの説明もなくLight RendererのUse Inverse Squared Falloffのチェックを外してしまいます。
調べます。
どうやらLightの減衰の計算を物理的に正しく計算するかどうかみたいですね。
どっちでもいいです。
地面が光ってますね。
因みにLight RendererのUse Inverse Squared Falloffのチェックを入れたらどうなるのかも確認してみました。
全く地面に光が写らなくなりました。
今度は今まで作成したNSは一端置いておいて、Robotが溶けるEffectを作成するそうです。
新しいNiagara Systemを作成しNS_DissolveEffectと名付けます。
Spawn Rate ModuleをEmitter Update Sectionに追加します。値は80000にします。
8万はCPUによっては負担になるかもしれないのでGPUでSpriteを管理するようにします。
Emitter Setting SectionのEmitter Properties ModuleにあるSim Targetの値をGPU Compute Simに変更してFixed Boundsにチェックを入れます。
何でGPUによるSpriteの時はEmitterの境界を指定しないといけないのかを説明しています。
その説明によるとGPU内でSpriteを計算するとEmitterのサイズをEngineは知る事が出来ないそうです。なので大体のサイズをEngine側に手動で教える必要があるそうです。
はい。
納得しました。
次にParticle Spawn SectionにInitialize Mesh Reproduction Sprite Moduleを追加します。
初めて使用するModuleです。
以下の解説がありました。
何を言っているのか良く分かりません。
公式のDocumentであるParticle Spawn Group [7] のInitialize Mesh Reproduction Spriteの説明も見ましたが、書いてある内容は全く同じでした。
唯一の違いは以下の警告が書かれていた点です。
うーん。読むしかないですね。
まず最初の文ですが、理想的なParticle の大きさやUVのサイズ、SpriteのAlignment（意味不明）などを決定するのにSkeletal Meshから適当に選んだ三角を使用します。とあります。
うーん。専門的過ぎます。私が知りたいのはこのModuleが何をするかなんで、Particle の大きさなどの決定方法はその後で余裕が出来た時に勉強するんで十分です。
例えば、Sphere Location Moduleだったら以下に示した様に、球の形にParticleを発生させるModuleです。とこのModuleの機能を一言で説明しています。
Initialize Mesh Reproduction Spriteの説明も何をするModuleなのかバッチと一言で説明してほしいです。
私が欲しい説明はModuleの機能についての説明で、そのModuleの細かい仕組みじゃないんです。
多分ですが、Initialize Mesh Reproduction Sprite Moduleの機能とは指定したMeshの形にParticleを発生させる事だと思います。ただしそうすると、Mesh Modulesである以下に示した他のModuleとの相違点とかが良く分からないです。
うん。取りあえずTutorial通りにやってみます。もしInitialize Mesh Reproduction Sprite Moduleに関する新たな情報が見つかったら、その時にまた勉強する事にします。
TutorialではPreview MeshにCrunchをセットしていますが、
このModelを持っていないのでSK_Mannequinを代わりに使用します。
こういう所をいい加減にやるから完成品の精度が落ちるんですね。
反省してやっぱりCrunchを探して見ます。
ありました。これをDownloadして使用する事にします。
Downloadして開いたらこんな感じです。
Skeletal MeshですがCrunchとなっていました。
Tutorialだと
となっていますので、少しだけ違いますね。
ViewportのImageが以下の様になりました。
Tutorialのは以下の様になっています。
数値を弄って少しだけTutorialの形状に近づけました。
このキャラクターに今作成したNSを追加します。
やり方を以下に示します。
Add Componentを押してNiagara Particle Systemを選択します。
するとNiagara System Assetが現れるのでそこにNS_DissolveEffectをセットします。
こんな感じです。
まあ、いいんじゃないでしょうか？
所がTutorialによるとこのやり方だと問題があるそうです。
以下に示したように、キャラの動きに合わせてParticleが動いてくれません。
これはこれで凄いじゃん。と単純に思ってしまいますが、Tutorialの目的には沿っていないんでしょうね。
自分のヤツで試してみましたが、同じでした。
何が起きているかと言うとそれぞれのParticleのVelocityがCharacterの動きに対して更新されないんです。
それを直すにはUpdate Mesh Reproduction Sprite ModuleをParticle Update Sectionに追加する必要があります。
そしてReview MeshにCrunchをセットします。
はい。
やりました。
Viewportに表示されるparticleが小さくなりました。
何でなんでしょう？
Level上に実際に配置したCrunchのImageです。
もっとParticleが合ってもいい感じですね。
これでParticleがキャラの動きについて行くのか確認します。
出来てますね。
はい。次の工程に入ります。
次はCrunchに実際に使用されているTextureをParticle Systemに使用する事で、Crunchの美しさを失わないでParticleを貼り付ける様にするそうです。
まず、Materialを複製します。
むむむ。私のVersionだと5種類のMaterialをCrunchは使用しています。
どれかを選んでDuplicate すれば良いんでしょうか？それとも全部Duplicateする必要があるんでしょうか？
分からないのでTutorialを一寸見てから考えます。
結論から言えばTutorialではCrunchのMaterialを元に以下のMaterialを作成しました。
そして元のMaterialが以下の物です。
所が私のVersionのCrunchのMaterialであるM_ Crunch _ Parentは以下の様になっています。
しかもこれがCrunchの一部に使用されているMaterialで他の場所には別なMaterialが使用されています。
なにをやっているのかさっぱり分かりません。
しかしですね。
Tutorialがやった事は、Niagara Mesh Reproduction Sprite UVs ノードのParticle Mesh UVsを全てのTexture SampleのUVsに繋いだこととNiagara Mesh Reproduction Sprite UVs ノードのModule Mesh NormalをNormal のTextureのRGBに掛けただけです。
M_ Crunch _ Parentを見ると
Decal Texture以外はNiagara Mesh Reproduction Sprite UVs ノードを繋げる訳です。
試してみる価値はあります。
M_ Crunch _ ParentをDuplicateしてやっています。
Normal のUVsにNiagara Mesh Reproduction Sprite UVs ノードのParticle Mesh UVsを繋げます。
更にNiagara Mesh Reproduction Sprite UVs ノードのModulate Mesh NormalsとNormalのRPGを掛けた値をNormalとして返します。
更に、以下のTexture SampleにもNiagara Mesh Reproduction Sprite UVs ノードと繋げます。
Decal TextureはTexCoord[1]を使用しているのでそのままにしておきました。
それをNS_DissolveEffectのRender SectionにあるSprite RendererのMaterialにセットします。
こんな感じです。
実際のLevel上ではこんな感じです。
Tutorialではこんな感じです。
Tutorialでは顔は灰色、体は緑色のようにきちんと色分けされて表示されていますが、私のは、全部の色が混じっています。
出来てないですね。
しかしこれ以上の解決策もないのでこれで続けてみます。
更にTutorialでは二つの問題点、
- Spriteが四角な事
- Spriteが常にカメラを向いている事
を述べています。
拡大してみると私のも四角になっていて常にカメラ側を向いています。
この常にカメラ側を向いているのは簡単に直せるそうです。
Sprite Renderer ModuleのAlignmentとFacing Modeの値を以下の様に変更するだけだそうです。
すると
Meshに沿ってSpriteの面が貼られています。
これで出来るのはParticle Update SectionでUpdate Mesh Reproduction Sprite Moduleがあるからだそうです。
うーん。成程。
今度は、Spriteを丸くします。
Tutorialを見ると以下のコードをOpacity Maskに繋いでParticle ColorのRPGをEmissive Colorに繋いでいます。
それのやり方が分からないので以下の様にしてみました。
Tutorialの結果を見るとこんな感じです。
私のはこんな感じでした。
出来ている？
今度は色を表示させます。
Particle Spawn Sectionの
Initialize Particle ModuleのColor を黒にします。
色が表示されました。
此処の理屈は全く分かりません。
近づいて見ると確かにSpriteが丸くなっています。
流石にもうNiagaraをやっている時間ではなくなってしまいました。残りは来週やります。
2.4 別なTutorialをやった感想など
公式のTutorialを途中までやったわけですが、やっぱりしっかりと生徒の事を考えた作りになっています。4.26になってCrunchのMaterialが変更された点を除けば、ほとんどTutorialの言っている事は分かりました。分からない部分でもTutorialの指導通りに付いて行く事は出来ました。
CGHOW氏のTutorialでもありましたがVersionの変化によってやり方が変わってしまうのは、仕方ない事なのかもしれません。
結論は来週、このTutorialを終えてから考えます。
３．Cascade: 今週の続き
今週はNiagara に時間を使い過ぎたのでCascadeの勉強はお休みします。
４．Item Spawn Dataの複製
Item Spawn Dataは先週、検討した結果、元に使用しているStructに新しい要素を追加する事で、色々なMapに生成するItemを一括で管理する事にします。
その後で、RPGGameInstanceにあるItem Spawn DataにMap1とMap1_Test、更にLandscape4用に分けたSpawn するItemのDataを追加します。
次にそれぞれのLevel BPに配置されているSpawn Items 関数を改良してそのMapに必要なMonsterだけSpawnするようにします。
Pick up Item WidgetのRemove Picked Item()関数も改良が必要です。
この関数はItemをPlayerが操作するキャラが拾った時にItemを消します。
先週、この関数の検討する事を忘れていました。
あと改良が必要な場所は、
Priest_Welcome WidgetでSaveをする時
Start Menu WidgetからLoad する時
の２か所です。
4.1 StructであるItem Spawn Dataの書き変え
それではStructであるItem Spawn Dataを書き換えます。
先週の検討では、Structに要素を追加すると一回Editorがクラッシュしますが、再起動すればそのStructを使用しているArrayはデータを失わずに新しい要素も追加されていました。
試します。
LevelNameを追加しました。
Editorを再起動してStructのItem Spawn Dataを開きます。
前に追加した要素であるLevelNameは存在しています。
今度はRPGGameInstanceを開きます。
なにこれ？
LevelNameの下にIsWeapon、ItemName、そしてMemberVer_20 があります。
更にItemNameにMap1が指定されています。
もう一度StructのItem Spawn Dataの要素を確認します。
うわ、追加したLevelNameの下にもっと沢山の要素がありました。
しかも個々のデータがDefault値に変更されています。
せめて前のDataのScreen Shotをとっておくべきでした。
痛恨のミスです。
大体の値を入れて見ました。
Map1_TestのLevel BP内で使用している関数、Spawn Itemsの実装を直します。
取りあえずこれでテストしてみます。
Start Menu WidgetがCompile出来ないとErrorが出ました。
直しました。
指定した位置に武器とItemが生成されています。
これでは見にくいのでStructのItem Spawn Dataを直します。
後、最後のMemberVer_20が何をしているのか不明なのでそれも調べます。
調べた結果MemberVer_20は何もしていませんでした。消します。
Structの並びは以下の様にしました。
またRPGGameInstanceのItem Spawn DataのDataが消えています。
そらそうだ。
でも焦っても仕方ないです。ゆっくり直していきます。
直しました。
BPの見た目もそれなりですが綺麗にしました。
4.2 それぞれの関数の直し
＜Pick up Item WidgetのRemove Picked Item()関数の変更＞
最初から直っていました。
＜Priest_Welcome WidgetでSaveをする時＞
これは直す必要無かったです。
＜Start Menu WidgetからLoad する時＞
これも勝手に直っていました。
これで全部直したはずです。
テストします。
Itemを拾おうとしたら拾えません。更にItemのイメージなどの詳細も表示されていません。
Errorがこんなに。
直します。
Errorの理由が分かりました。Dropped Item Base BPで変数NameとItem Nameが同じDataを保持してるだけだったのでItem Nameに統一してNameは消去しました。
しかしPickup Item WidgetでDropped Item Base BPからNameの値にアクセスしていました。それがErrorを起こしました。
Dropped Item Base BPで変数Nameを消す前にこの変数を使用している箇所を検索でチェックはしましたが、Widgetはその検索から外れていたようです。
Errorが表示されている箇所が全部直しました。
今度はItemの説明が絵入りで説明されています。
今度は装備するために装備画面を開いたら武器の名前が表示されていません。
されるときもあります。
なんで？
あっ。
Itemの発生位置を確認するために静的に配置したDropped Item Base BPを消すのを忘れていました。
全く同じ位置に二つの別々なdataを持つDropped Item Base BPが配置されていました。
JoJoを読んでいた時に、全く同じボートを二つ重ねて戦う敵がいてそれの何が強いのかと不満に思った事が昔ありました。しかし全く同じBPが2個重なっていた今回のErrorは直すのが本当に大変でした。
本当に強敵でした。
SaveやLoadの時も確認します。
回復薬だけ拾った状態でセーブしました。その後、ゲームを終了して新しいゲームを開始しLoadしました。
回復薬だけ無くなっています。
出来ています。
4.3 それぞれのLevelでSpawn するItemが変更出来る様にする
Map1_TestのLevel BPのSpawn Items関数に以下のコードを追加しました。
Map1_TestのみにItemがSpawnするようにしてテストします。
結果です。
出来ていますね。
あ。
大きなバグを一個見つけてしまいました。ItemのSpawnを武器の種類の名前で管理していましたが、それぞれの武器に固有の名前をつけないとその種類の武器が全部消えてしまいます。
こんな風に短剣(小)が３つ配置されていたとします。
一個だけ短剣を拾います。
これをすると別なmapに移動して戻って来た時に全部のItemが消えるはずです。
テストします。
やっぱり全部消えていました。
５．バグ直し
このバグを直すためには、Dropped Item Base BPの全てのInstanceに固有の名前が必要になります。
またStructのItem Spawn Dataを直す必要があります。
それぞれのInstanceの固有の名前は、Own Nameにします。
と言う事はまたDataが消えてしまうわけです。
今度はここにDataを記録しておきます。
Item Spawn Dataを使用している全てのBPとWidgetをチェックしていきます。
5.1 Item Spawn Dataを使用している全てのBPとWidgetのチェック
＜Pickup Item WidgetのRemove Picked Item関数＞
消去するItemのDataをItem Spawn Dataから探している所です。
現状ではItem Nameを比較していますが、Own Nameを比較する必要があります。
＜Priest Welcome WidgetのSet Item Spawn Data関数です。＞
Item Spawn Dataの中からSaveしなければならないDataをCopyしています。
これは変更する必要はありません。
＜Start Menu WidgetのChange Item Spawn Data in Game Instance関数＞
これはSaveしたDataをGame InstanceのLoadする時に使用する関数でItem Spawn Dataの管理をしています。
これも変更する必要はありませんね。
＜Map1 Level BP の Spawn Items 関数＞
これはMap1を開いたときにItemを生成する関数です。
これも特に変更する必要はありませんね。
＜Map1_test Level BP の Spawn Items 関数＞
これはMap1と全く同様の関数なので変更する箇所はないです。
はい。これで全部調べ終わったと思ったら違いました。
Dropped Item Base BPにもOwn Nameを保持する変数が必要になります。
そうする事でPickup Item WidgetのRemove Picked Item関数がDropped Item Base BPに新しく追加する変数、Own Nameにアクセス出来るはずです。
確認します。
Pickup Item WidgetのRemove Picked Item関数で使用しているDropped Item Base BPのObjectであるMy Dropped Itemを追っていきます。
この変数はPickup Item Widgetを作成した時に値をAssignされています。
なのでThird Person Character BPでこのWidgetを作成する所を調べます。
なんとGame Mode BPの値をパスされています。
このGame Mode BPの値がいつAssignされるのかを調べたら、Third Person Character BPのTrigger Box内にPlayerが操作するキャラが侵入した時でした。
となるとPickup Item WidgetのRemove Picked Item関数は、Dropped Item Base BPに新しく追加する変数、Own Nameにアクセス出来ますね。
本来なら来週直しますが、今週はあんまり進まなかったのでこれもやる事にします。
5.2 直し
StructのItem Spawn Dataに新しい要素であるOwnNameを追加します。
今度は、ここでUE4Editorを閉じずにRPG Game Instance BPを開きCompileしてSaveします。
するとRPG Game Instance BPのItem Spawn Dataの値が以下の様に変化しました。
あれ。
Dataを失う事なく新しい要素の追加に成功してます。
うーん。何で今回は成功したんでしょうか？
それぞれのItemに名前を付けていきます。
出来ました。
不安なので一回、UE4Editorを再起動します。
RPG Game Instance BPのItem Spawn Dataの値は変更した状態のままです。出来ています。
Dropped Item Base BPにOwn Name変数を追加します。
Map1_Test Level BPのSpawn ItemでDropped Item Base BPのInstanceを動的に作成する時に
Own ItemのDataをパスします。
＜Pickup Item WidgetのRemove Picked Item関数＞
Dropped Item Base BPのInstanceにassignされたMy Dropped Item 変数からOwn Nameのデータを取り出してRPG Game Instance BPにあるDataと比較するようにします。
＜Start Menu WidgetのChange Item Spawn Data in Game Instance関数＞
これは変更する必要はありませんが念のため確認しておきます。
線が外れていたので直しました。
＜Map1 Level BP の Spawn Items 関数＞
これは先程直しました。
＜Map1_test Level BP の Spawn Items 関数＞
こっちも直していました。
テストします。
Map1に短剣(小)が3本配置されています。
一本だけ拾いました。
銀河鉄道に乗ってLandscape4に行って帰って来ました。
同じ種類の武器が全部消える事はなく拾ったItemだけ消えています。
出来ました。
5.3 Storyの作成
これでMap1とMap1_Testが分割出来ました。これからテストする時はMap1_Testで行い、RPGの方がMap1で制作していきます。
６．Loading Screenの勉強の続き
6.1 先週の勉強の確認
Load Stream Levelノードの使用方法については完全に理解しました。Sub LevelつまりStream Levelの使用方法も大体理解出来ました。
Level Streaming Volumeを使用する場合は良く分かりません。これは今週勉強します。
Load Stream Levelノードを使用したLoading Screenの勉強も今週勉強します。HTF do I? Loading Screens using Level Streaming in Unreal Engine 4 [8]を勉強します。
6.2 Level Streaming Volumeを使用する場合
公式のDocumentであるStream Sublevels with Level Streaming Volumes [9] を勉強します。
後、Unreal Engine JPのTutorialで「猫でも分かる UE4を使ったゲーム開発 超初級編 #8 タイトルからゲームメインへのレベル遷移を作ってみよう！」[10] の1:25頃から実際にLevel Streaming Volumeを使用したStream LevelのLoad方法の実演がありました。
私はあんまり日本語のUEのTutorialは見ないんですが、内容がそのものズバリだったのと、YouTubeのお勧めにしつこく登場したので見たらかなり良かったです。
先週、以下に示した様に「View Port（View Pointと書いていますがView Portの事です。）内にLevel Streaming Volume が一寸でも入ったらStream Levelが生成される。」と書きましたが、
この動画をみるとカメラ自身がLevel Streaming Volume内に侵入した時に初めてStream Levelが生成されるようです。ここは良く確認します。
6.3 Stream Sublevels with Level Streaming Volumes [9] を勉強します。
< Level Streaming Scenario >
Sun Temple projectを使用して説明するとあります。私はLevel Streaming Volumeの設定の仕方さえ理解出来れば良いので、敢えて同じProjectでやる必要は感じないですが、一応このProjectを探して見ます。
ありました。
無料なのでもらっておきます。
試しに開いて見たらTutorialと全く同じです。
これを使用して勉強する事にします。
公式のDocumentに載っている写真と同じ位置を見つけました。
ここまではこの先のpatio（中庭？）が見えないのでpatioをStream Levelに入れておいて
Playerがこの辺に来たらLevel Streaming Volumeを起動させてpatioが生成されるようにするそうです。
と書かれていますが、Persistent Levelしかないです。
＜Streaming In Levels with Volumes＞
うーん。やっぱり先週作成したヤツでやります。
これのStream_2（床が配置されている）をLevel Streaming Volumeで起動させるようにします。
Tutorialでは
と書かれているので、Level Streaming VolumeをPersistent Levelに配置します。
Tutorialに以下の様に書かれていました。
と言う事はやっぱりcameraのViewにLevel Streaming Volumeが入った時じゃなくてCameraそのものが入った時に発動するみたいですね。
以下の図のLevelsの右側にあるオレンジ色になっている箇所をクリックするそうです。
こんな画面が表示されました。
あれ、TutorialのImageと全然違います。TutorialのImageは以下に示した様になっています。
あ、分かりました。Stream Levelの方を選択しています。
Stream_2を選択しました。Tutorialと同じ画面が出て来ました。
Streaming VolumesにElementを追加します。そこに先程作成したLevel Streaming Volumeをセットします。
Level のセットはこれで終わりだそうです。
最後に、先程セットしたLevel Streaming VolumeをLevel画面から選択してDetail画面にあるStreaming UsageをSVB Visibility Blocking on Loadに変更します。
これで出来ているそうです。
試してみます。
現れませんね。
色々試したんですが理由が分かりません。
「猫でも分かる UE4を使ったゲーム開発 超初級編 #8 タイトルからゲームメインへのレベル遷移を作ってみよう！」[10] でCameraがLevel Streaming Volumeに入っていなくてStream Levelが中々読み込まれなかったので、同じ理由かと思って以下に示したようにLevel Streaming Volumeをかなり大きくしたんですが駄目でした。
ほとんど諦めかけてた時に、たまたま空を眺めたらStream_2 に配置してあるFloorが写りました。
どうやらLevel Streaming Volumeの高さが足りなくてCameraがBoxに入っていなかったみたいです。
Level Streaming Volumeを高くしてみました。
今度は普通にStream_2がLoadされました。
6.4 Level Streaming VolumeとCameraについて
Particle SystemのGPUのBoundsはカメラの視界にBoundsが入ったらEffectを生成します。
これと同じ様にLevel Streaming Volumeも、カメラの視界にLevel Streaming Volumeが入ったら指定されたStream LevelをLoadするなら意味分かります。
が、なんでCameraがLevel Streaming Volumeに入った時にStream LevelをLoadする理由があるでしょうか？それならPlayerが操作するキャラがLevel Streaming Volumeに入った時で良いでしょう。
Level Streaming Volumeを作成する時に、最初は「カメラの視界にLevel Streaming Volumeが入ったらStream LevelをLoadする。」となってたのを誰かが間違えて「カメラがLevel Streaming Volumeが入ったらStream LevelをLoadする。」に変わっちゃったんじゃないでしょうか？
これってバグだと思います。
6.5 HTF do I? Loading Screens using Level Streaming in Unreal Engine 4 [8]を勉強します。
もうLevel Streamingの方法は十分理解したので今度はLoad Stream Level ノードを使用したLoading Screenの作成方法について勉強します。
軽くどんな感じなのか見たら、結構複雑です。
これは動画みただけじゃ再現するの無理じゃないか？と思ったらSource Codeが公開されていました。
ただしSource CodeのVersionが4.9になっています。取りあえずこのSource CodeをDownloadして開けるか試してみます。
4.9をInstallしてSource Codeを開いて見ます。
開けました。このコードを参考にしながらやってみます。
まず、以下のLevelを使用しています。
Persistent Levelには以下のStream Levelが追加されています。
Persistent LevelのBPは以下のようになっています。
この辺から作ってみます。
＜準備編：Start ButtonのあるWidgetまでの作成＞
Persistent LevelですがSource Codeを見るとAnimated Loading Persとなっていました。
更にSource Code ではAtmospheric Fog、BP Sky Sphere、Directional Lightが追加されていたのでそれも追加します。
Source Code では空は青いですが、私のは真っ赤です。
調べるとSource Code ではBP Sky SphereのDirectional Light ActorにDirectional Lightがセットされていました。
BP Sky SphereのDirectional Light ActorにDirectional Lightをセットしました。すると
空が青くなりました。
この辺の設定は全然理解していません。後で勉強する必要がありますね。
次にPersistent LevelのBPを作成します。
はい。いきなり来ました。Load Stream Levelノードです。先週、Streaming Levelをしっかり勉強したお陰でこのノードが何をやっているのかしっかり理解出来ます。TutorialではこのノードからAnimated Loading Splash Screen を呼び出しますが、まだAnimated Loading Splash Screenを作成していないので、作成してから呼び出せるようにします。
次のノードであるRemote Eventはどんな機能を持っているんでしょうか？初めて見るノードです。
こんな説明されてました。
これだけだと良く分からないですね。TutorialでEvent Nameに記載されている名前はLoad Splash Screenとなっています。これってEventじゃなくてLevel名でしょう？
Source CodeのAnimated Loading Splash ScreenのLevel BPを開いたらなんとEvent Load Splash Screenがありました。
うーん。成程。やっとPersistent Levelで何をやっているのかが分かりました。
Load Stream Levelノードでstream LevelであるAnimated Loading Splash Screenを作成して、それが終了した途端にAnimated Loading Splash Screen BPにあるEvent Load Splash Screenを実行するわけです。
でもこれだったらAnimated Loading Splash ScreenをOpen Levelノードで開いて、Animated Loading Splash ScreenのEvent Begin PlayでEvent Load Splash Screenを実行してもそんなに差がない気がします。
私が言いたい事は、ここではLoad Stream Levelノードの機能であるBackgroundでLevelをLoadする事が生かされていません。
多分、次のLevelでLoad Stream Levelノードを使用してBackgroundでLevelをLoadするんでしょう。取りあえずTutorialと同じのを作成していきます。
Animated Loading Splash ScreenをAnimated Loading PersのStream Levelとして作成しました。
Source Codeで確認するとAnimated Loading Splash ScreenはAssetを全く持っていないLevelでした。あるのはEvent Load Splash Screenだけです。
Load Splash Screenの実装部はかなり色々な事をやっていますが、順番に実装していきます。
まず最初にUMG‐Splash Screen Widgetを開いています。
UMG‐Splash Screen Widgetを見ると以下のImageをTextとImageで作成しただけのwidgetでした。
これと同じ物を作成します。
全く同じ物を作成しても面白くないので少しだけ変更しました。
はい。ここまで出来ました。
次です。
Animated Loading Main MenuをLoadしています。
このAnimated Loading Main MenuもAssetを何も持たないLevelでした。BPを開くと二つのEventだけが実装されていました。
Animated Loading Main MenuのBP内の２つのEventは一端置いておいて、ここまでTutorialと同じ物を作成してみます。
Stream Level、Animated Loading Main Menuを作成します。
このStream LevelをAnimated Loading Splash ScreenのBPからLoad Stream Levelノードを使用して呼び出します。
Animated Loading Splash ScreenのEvent Load Splash Screenの続きを追っていきます。
先ほど表示したWidgetを外しています。これも実装します。
次はRemote EventでLoad Main Menuを呼び出しています。
これも実装してしまいましょう。
しました。
では、一端、Animated Loading Splash ScreenのEventであるLoad Splash Screen Eventの作成は停止して、Animated Loading Main MenuのEvent Load Main Menuの作成をします。
またWidgetを作成しています。正直こんなに複雑にする必要はない気がしています。どうなんでしょうか？完成したら見直してみます。
この部分だけ作成したらWidget、UMG Main Menuを作成します。
まだUMG Main Menu WidgetがないのでErrorが表示されています。
UMG Main Menu Widgetを作成します。
こんな感じのDesignです。
それぞれのButtonに実装されている機能はこんな感じです。
え。Game Instanceに新しい変数も作成しているの？
しかもやっとここからLoading する訳ですか。
ううん。
UMG Main Menu WidgetのDesign部分だけ作成しました。
Animated Loading Main Menu のCreated Widgetに今作成したUMG Main Menu Widgetをセットします。UWidgetのタイプもUMG Main Menu Widgetに変更しました。
Source code のAnimated Loading Main Menu の続きを見ると以下の実装をして終わっています。
これは単純にCursorによるUIの操作のための実装ですね。
これも実装します。
これでAnimated Loading Main Menu の実装が終わりました。
なので、Animated Loading Splash ScreenのEventであるLoad Splash Screen Eventの作成に戻ります。
最後にUnload Stream Levelノードを追加するだけでLoad Splash Screen Eventの実装は終わりました。
どうなっているのか全体像が分からなくなってしまったので最初から見直します。
Animated Loading Persistent Levelの実装部です。
Load Stream LevelノードのLevel NameにLoadするLevelが指定されていませんでした。Animated Loading Splash Screenをセットします。
Remote Event NodeのEvent NodeにもLoading Splash Screenをセットします。
次はAnimated Loading Splash Screen BPのLoading Splash Screen Eventをチェックします。
この部分はSource Codeと全く同じに作成されていました。
このEvent はLoad Stream LevelでAnimated Loading Main MenuをloadしてEvent Load Main Menuを実行します。
この部分も完全にSource Codeと同じになっています。
ここまででテストしています。
あれ、何も表示されません。
Load Stream LevelのMake Visible After Loadにチェックを入れるのを忘れていました。
もう一度テストします。
Animated Loading Splash Screen LevelのLoad Splash Screen Load Eventが実行され以下のWidgetが表示されました。
今度はLoad Splash Screen Load Event からAnimated Loading Main MenuがLoadされLoad Main Menu Eventが実行されました。
Load Main Menu EventでWidget UMG Main Menuが開かれ以下のUIが表示されました。
はい。
ここまでは出来ていました。問題なのは肝腎のBackgroundによるLoading Screenの作成がこれからな所です。
HTF do I? Loading Screens using Level Streaming in Unreal Engine 4 [8]も見直しました。5分過ぎまでの説明部分が今までやった所と見事にシンクロしていました。
＜本編：Start Buttonの実装＞
Widget UMG Main MenuのStart ButtonがクリックされるとまずGame InstanceをAnimated Loading Game InstanceにCastしています。
となると最初にAnimated Loading Game Instanceを作成する必要があります。
Source CodeのAnimated Loading Game Instanceを見るとName タイプのLevel To Load変数が追加されただけのようです。
これを作成します。
Project SettingのMap and ModeのGame Instance ClassにAnimated Loading Game Instanceをセットします。
Animated Loading Game Instanceが出来たので、Widget UMG Main MenuのStart Button のOn Click Event にCast 部分を追加します。
更にLevel To Load変数の値を以下の様にセットします。
これはセットしただけでは何とも言えませんね。
＜本編２：Interfaceの追加によるEventの作成＞
以下に示したようにAnimated Loading Map1もAnimated Loading PersistentのStreaming Levelではあります。
次のノードが以下の様になっています。
しかしLoad Next Streaming Levelを呼び出せません。
これが理由かどうか分かりませんが、Source CodeのLoad Next Streaming Levelには以下の印がついています。
よく見たらUMG to Level BPというInterfaceをImplementしていてそのInterface内にLoad Next Streaming Level Eventがあるみたいです。
公式DocumentのBlueprint Interface [11] を参考にしてInterface、UMG to Level BPを作成します。
中を開いてFunction名をLoad Next Streaming Levelに変更します。
以上です。
更に公式DocumentのImplementing Blueprint Interfaces [12]を参考にして作成したInterface、UMG to Level BPをAnimated Loading Main MenuにImplementします。
むむむ、
そしたらInterfaceの項にこの関数が表示されるようになりました。
ここでLoad Next Streaming Levelを選択したままMouseを右クリックすると
Implement Eventが表示されます。
それを選択すると、とうとうEvent Load Next Streaming Levelが表示されました。Source CodeのLoad Next Streaming Level Eventと同じ様に右上に謎のIconが付いています。
更にEvent GraphにもEvent Load Next Streaming Levelが表示されました。
今度はWidget UMG Main MenuのStart Button でLoad Next Streaming LevelをCall出来るようになりました。
以下のコードを追加して本当にWidget UMG Main MenuのStart ButtonからAnimated Loading Main MenuのEvent、Load Next Streaming Levelが呼び出せるのか試してみます。
Start Buttonを押したら以下の文が表示されました。
出来ています。
＜本編３：InterfaceからのEventを使用する事で、LevelとWidget間の連絡が出来る様にする＞
何でInterfaceからEventをわざわざ作成するのかと思ったらWidgetから直接Level内のEventを呼び出す事が出来ないからなんですね。
分かりました。
今回のケースはStream Levelが変わるんですが、そうなるとGame Modeはどうなるんでしょうか？
Stream Levelが変わる度にGame Modeも新しく読み込まれたりするんでしょうか、それともPersistent LevelにセットされたGame Modeのみが実行されてStream Levelの切り替えの時はGame Modeには何の影響もないんでしょうか？
そう言えばHTF do I? Loading Screens using Level Streaming in Unreal Engine 4 [8]のコメント欄に
と書かれていました。
もしGame Modeがそのままならば、Game ModeにEvent Dispatcherを作成してWidgetからGame ModeのDispatcherを読んで、そのDispatcherの実装部をLevel BP内で行う方法でもWidgetからLevel BPのEventを呼び出せた気がします。
時間があったらこの方法で同じ事が出来ないか試してみます。
もしこの方法でも出来るのならどっちが効率良いのかについても検討したいです。勿論、時間があったらですが。
＜本編４：Event Load Next Streaming Levelの実装＞
Source CodeのEvent Load Next Streaming Levelの実装の最初の部分です。
Animated Loading Loading ScreenをLoad しています。Animated Loading Loading Screenはまだ作成していません。
Source CodeのAnimated Loading Loading Screenを見ると、Assetを全く持たないStream Levelで以下のEvent のみが実装されています。
それではAnimated Loading Loading Screenを作成します。
Animated Loading Loading ScreenのBPにEvent Load Loading Screenも作成しました。（実装はしていません。）
そしてEvent Load Next Streaming Levelの実装の最初の部分を追加します。
Animated Loading Loading ScreenのEvent Load Loading Screenの実装は後でするとして、Animated Loading Main MenuのEvent、 Load Next Streaming Levelの実装を先にやってしまいます。
実装の残りを以下に示します。特に新しい事はやっていないのでそのままCopyしてしまいます。
Animated Loading Main Menu LevelからAnimated Loading Loading Screen LevelのEventのAccessは、Stream Levelから別なStream LevelのEventへのAccessなのでRemote Event ノードで可能です。
これだけ似たような名前があるとSpell Missが心配です。後でErrorが出たらSpell Missを最初にチェックする事にします。
＜本編５：Animated Loading Loading ScreenのEvent Load Loading Screenの実装＞
Streamの名前はLoading Loading Screenですが、Eventの名前はLoad Loading Screenなんですね。ややこしいです。
それは兎も角、Animated Loading Loading ScreenのEvent Load Loading Screenの実装をします。
Source Codeの最初の部分です。
UMG Loading Screen Widgetを作成します。
Source Codeをみるとこんな感じです。
BPには何も実装されていません。
こんな感じに作成しました。
Circular Throbberは初めて使用するWidgetです。
Throbberって初めて聞く単語だったので意味を調べたら、Loading Iconって出て来ました。そのものずばりですね。
Circular Throbberのサイズや色の調整方法が分からなかったのでSource Codeの値を参考にしました。
Source Codeの値を参考にしましたが、弄っている内に大体の意味は分かりました。
Widgetが完成したのでAnimated Loading Loading ScreenのEvent Load Loading Screenの実装の続きをやっていきます。
出来ました。
次の部分の実装をみます。
ここでGame Instanceに保存したLevel名を使用するんですね。このままCopyします。
残りの部分を実装します。
Remote Event 関数でAnimatedLoadingMap1のEventであるLoad Levelを呼んでいますが、もしGame Instance のLevel to LoadがAnimatedLoadingMap1じゃない時はどうするんでしょうか？
因みに、AnimatedLoadingMap1のLoad Levelでは以下のコードが実装されています。
AnimatedLoadingMap2を見たら、実装内容は全く違いましたが同じ名前のEventがありました。
このTutorialではAnimatedLoadingMap1かAnimatedLoadingMap2しか呼ばないのでこのやり方で良いのかもしれませんね。
後、一番最後のノードでAnimated Loading Screenと指定されていますがそんなLevelはないですし、このEventが実装されているLevel BPを閉じるのが目的なはずですからAnimated Loading Loading Screenが正しいと思います。
こんな感じになりました。
Tutorialの解説を見ると、実際のゲームではLoad するStream Levelの数が10や20になる場合もあってそれにも対応出来るように実装されている事が分かりました。
＜Remote Eventについての考察＞
Remote Event ノードは今回初めて知ったんですが、これかなり面白い機能ですよね。
Polymorphismの機能に似ていますが、同名のEventなら全く別なLevelからでも呼び出せる所が違います。
Polymorphismにはコードを簡易にする機能がある代わりに実際のDataが継承したどのクラスのメンバー関数を使用しているのか分かりにくくする欠点もあります。しかし現実問題としてPolymorphismを使用しないでコードを書く事は不可能な訳です。このRemote Event ノードの機能は、そんなPolymorphismの欠点を補える可能性を感じました。
＜AnimatedLoadingMap1の作成＞
流石に時間が無くなってしまったので残りは来週やる事にします。このTutorialは今週中に終わらしたかったんですがどうやってももう無理です。
Tutorialの10:36の所までやりました。
７．Good Skyの復習
当然、来週以降やる事になります。
８．まとめと感想
時間がもうないのでまとめもなしです。
９．参照（Reference）
[1] Rimaye. (n.d.). ð¨ UE4 - Niagara VFx Tutorials [ Stylized ] ð FR voice - English Explanations ð¨. YouTube. Retrieved September 5, 2021, from https://www.youtube.com/playlist?list=PLvYJUGYt8abH6GK8d6zGjaMLiFgqvmV-s
[2] Epic Games [Unreal Engine]. (2020, May 27). Building advanced effects in Niagara | Unreal Engine [Video]. YouTube. https://www.youtube.com/watch?v=syVSRDQxrZU
[3] Epic Games. (n.d.-e). Niagara Visual Effects. Unreal Engine Documentation. Retrieved September 5, 2021, from https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Niagara/
[4] Epic Games. (n.d.-d). Niagara Quick Start. Unreal Engine Documentation. Retrieved September 5, 2021, from https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Niagara/QuickStart/
[5] Epic Games. (n.d.-b). Create a Sprite Particle Effect in Niagara. Unreal Engine Documentation. Retrieved September 5, 2021, from https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Niagara/HowTo/SpriteEffect/
[6] gameDev Outpos. (2020, July 30). UE4 - Introduction To Niagara [Video]. YouTube. https://www.youtube.com/watch?v=VEG-Xp92cBk&list=PLomQNLPOWtzYXU_pRIUVVEV9uY7bjENZ5&index=1
[7] Epic Games. (n.d.-f). Particle Spawn Group. Unreal Engine Documentation. Retrieved August 31, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/EmitterReference/ParticleSpawn/
[8] Wadstein, M. [Mathew Wadstein]. (2015, October 31). HTF do I? Loading Screens using Level Streaming in Unreal Engine 4 [Video]. YouTube. https://www.youtube.com/watch?v=QJVn2mW67YQ
[9] Epic Games. (n.d.-g). Stream Sublevels with Level Streaming Volumes. Unreal Engine Documentation. Retrieved September 5, 2021, from https://docs.unrealengine.com/4.26/en-US/BuildingWorlds/LevelStreaming/HowTo/StreamWithVolumes/
[10] Epic Games [Unreal Engine JP]. (2020, August 28). 猫でも分かる UE4を使ったゲーム開発 超初級編 #8 タイトルからゲームメインへのレベル遷移を作ってみよう！ [Video]. YouTube. https://www.youtube.com/watch?v=7ianEtjiWVI&list=PLr_Cbd4sUDTzbVjg1Bsm5s_21uPQ4xHLx&index=8
[11] Epic Games. (n.d.-a). Blueprint Interface. Unreal Engine Documentation. Retrieved September 3, 2021, from https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScripting/Blueprints/UserGuide/Types/Interface/
[12] Epic Games. (n.d.-c). Implementing Blueprint Interfaces. Unreal Engine Documentation. Retrieved September 3, 2021, from https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScripting/Blueprints/UserGuide/Types/Interface/UsingInterfaces/
