UE4の勉強記録

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

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成するMonster Zoneの作成 Part 4

f:id:kazuhironagai77:20210613195339p:plain

<前文>

子音+Lの音

Minimal Pairによる英語の発音聞き取り練習アプリを制作しています。

凄い効果があります。例えばThの場合です。THはFやSとペアを組みますが、ああこの音がThなのかと一瞬で分かります。そして一端分かったら決して忘れません。

しかしどうしても成果が出ないPairもあります。

それが子音+Lと子音+Rのペアです。PlayとPrayのペアみたいなやつです。全く区別がつかないと言うわけではなく、その場で二つの単語を聞き比べながらこの単語はどっちでしょうか?とクイズを出すと必ず正解出来ます。つまり音の違いは誰でも認識出来ています。所が次の日になると、音の違いが分からなくなってしまいます。

この子音+Lの音について新情報が入りました。

子音+Lの時のLの音ってLight LとDark Lのどっちだと思いますか?

私は頭ごなしにLight Lと思っていました。

正解は、半々だそうです。

子音+Lの時にMのような音が聞こえる時があります。この長年の謎が解明しました。子音+Light Lの時にはMに近い音が聞こえるんです。子音+Dark Lの時はM のような音は全くしません。

後、ラリルレロの音が全く聞こえない時もあります。例えばFlyの発音が、フイに聞こえる場合です。この発音を始めて聞いたときあまりに酷すぎると思いました。完全にフイと言っています。これでLかRか分かる訳ないです。

でもこの謎も解明しました。元々、Dark Lはウのような母音のような音がします。のでF + Dark Lがフに聞こえたんです。このフの音はFuやFooとは全く違うウの音なんでFLと分かる訳です。

それでも分からない部分は沢山ありますが、まあ一歩前進したのは間違いないです。

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

<本文>

1.今週の予定

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

  • Niagara Cascadeについて
  • 先週の改良点の直し
  • Monster Zone の更なる作成

2. Niagara の勉強

今週は先週、勉強したRibbonをもう一回やり直します。

先週、Reviewで横や上からEffectを眺めるとparameterとEffectの関係が結構良く分かる事に気が付きました。それで先週勉強したCreate a Ribbon Effect in Niagara [1]の勉強をやり直す事にしました。

2.1 先週の復習

先週、勉強した内容を復習して分からなかった事をまとめます。

f:id:kazuhironagai77:20210613195525p:plain

飛行機雲の作り方はまだ分かりませんね。後、花火の導火線を作成するのにRibbon Effectは丁度いいかもしれません。

Spawn Burst Instantaneous ModuleのParameterについて考察しています。

f:id:kazuhironagai77:20210613195551p:plain

ところが、後でSpawn Rate ModuleのSpawn Rate がCascadeのSpawn ModuleにあるBurst Listと同様の働きを担当しているんではないのか?の疑惑が出て来ます。

f:id:kazuhironagai77:20210613195610p:plain

これが「先週、分からなかった事1」です。

次の疑問ですが、Emitter State ModuleのLife Cycle Modeの値についてです。

f:id:kazuhironagai77:20210613195641p:plain

先週の結論では、

f:id:kazuhironagai77:20210613195656p:plain

となりましたが、それだとDefaultでSelfにセットされている理由が分かりません。「先週、分からなかった事2」です。

Torus Location Module のTours Modeについてです。

ToursとRingのどちらかが選択出来ます。

f:id:kazuhironagai77:20210613195716p:plain

この辺ももう少し具体的な違いが知りたいですね。

後、勿論、横や上からEffectを眺めて違いを確認します。これは「先週、分からなかった事3」にします。

そしてTorus Location Module のUPositionです。

f:id:kazuhironagai77:20210613195736p:plain

UPosition自体の意味も良く分かりませんが、以下に示した様なParticleとかEmitterなどのParameters自体が何なのか良く分かっていません。

f:id:kazuhironagai77:20210613195753p:plain

これらは「先週、分からなかった事4」です。

そしてAcceleration Force Moduleについてです。

f:id:kazuhironagai77:20210613195811p:plain

これは「先週、分からなかった事5」になります。

以上でした。

2.2 Niagara Moduleの解説について

Cascade には以下に示した様に、Particle System Reference [2]に全てのModuleについての解説が載っています。

f:id:kazuhironagai77:20210613195845p:plain

これと同じものがNiagaraにもあるはずです。まずそれを探します。

直ぐに見つかりました。Niagara Visual Effects [3] にありました。

NiagaraはModule毎ではなくGroup毎にまとめてありました。

f:id:kazuhironagai77:20210613195901p:plain

2.3 「先週、分からなかった事1」

<Spawn Burst Instantaneous ModuleのSpawn Rate Parameterについて>

Spawn Burst Instantaneous ModuleはEmitter Update Groupに属しています。

f:id:kazuhironagai77:20210613195928p:plain

Emitter Update Group [4] を見てみましょう。

f:id:kazuhironagai77:20210613195947p:plain

あれ、これだけ。

これではSpawn Burst Instantaneous ModuleのそれぞれのParameterがどんな働きをしているのか分かりませんね。

では、自分で実験してみるしかなさそうですね。

Niagara Emitter からDirectional Burstを選択して新しいEmitterを作成します。

f:id:kazuhironagai77:20210613200008p:plain

以下に示したようなeffectが表示されています。

f:id:kazuhironagai77:20210613200025p:plain

一秒毎に、ParticleがBurstされています。

Emitter State ModuleのLoop Durationが1.0にセットされてるからでしょうか?

f:id:kazuhironagai77:20210613200043p:plain

Emitter State ModuleのLoop Duration を9秒に変えてみます。

Timelineが9秒まで移動してからLoopするようになりました。

f:id:kazuhironagai77:20210613200115p:plain

勿論、ParticleがBurstされるのは9秒毎になりました。

f:id:kazuhironagai77:20210613200131p:plain

TimeLineの矢印が0.00を指す時にParticleがBurstしています。

これって?

試しに、Spawn Burst Instantaneous ModuleのSpawn Timeを5秒にセットしてみました。

f:id:kazuhironagai77:20210613200147p:plain

はい。今度はTimeLineの矢印が5秒を指した時にParticleがBurstしました。

f:id:kazuhironagai77:20210613200202p:plain

これがSpawn Burst Instantaneous ModuleのSpawn Timeの意味ですね。

解決しました。

<Spawn Rate ModuleのSpawn Rateについて>

Emitter Update Group [4]には以下の様な解説がされています。

f:id:kazuhironagai77:20210613200226p:plain

これだけでは良く分かりませんが、実際に試してみたら意味が分かりました。

まずSpawn Rate ModuleはSpawn Burst Instantaneous Moduleに付随して作動するModuleではないです。全く関係のない独立したModuleした。

Spawn Rate ModuleのSpawn Rate を1にセットすると

f:id:kazuhironagai77:20210613200244p:plain

1秒に1回、一個のParticleを放出しています。

今度は、Spawn Rate ModuleのSpawn Rate を5にセットします。

f:id:kazuhironagai77:20210613200300p:plain

1秒間に5回、つまり20秒に一回、1個のParticleを放出しています。

これがSpawn Rate ModuleとSpawn Rateの機能でした。

2.4「先週、分からなかった事2」Emitter State ModuleのLife Cycle Modeの値について

Life Cycle Modeの値がSystemの方が計算は速くなるそうです。それならばDefaultでもSystemにセットするはずです。なぜdefaultではSelfにセットされているのでしょうか?

今の時点ではこれを調べる手段がないですね。

これは諦めます。

と思ったらCreate a Ribbon Effect in Niagara [5] のEdit the Emitter Update Group Settingsの2にそのものズバリの説明がありました。

f:id:kazuhironagai77:20210613200327p:plain

良く読んでおけば良かったです。

2.5「先週、分からなかった事3」Torus Location Module のTours Modeについて

Torus Location Module のTours Mode はToursとRingのどちらかが選択出来ます。その違いについて調べます。

上から見てみます。

Torusの場合です。

f:id:kazuhironagai77:20210613200351p:plain

Ringの場合です。

f:id:kazuhironagai77:20210613200408p:plain

Torusの場合の方が大きい位の違いしか分かりません。

2.6「先週、分からなかった事4」Parametersについて

以下にParametersの要素の一覧表を示しています。これらが何なのかが分かりません。

f:id:kazuhironagai77:20210613200430p:plain

調べます。

UE4 - Niagara Parameters [7] に少しだけ解説がありました。

まずここに書かれているParameterは既に作成されているParameterで使用中か、これから使用されるモノだそうです。

以下に示したLockのiconですが、意味は編集したり、値を変更したり出来ないとの意味だそうです。

f:id:kazuhironagai77:20210613200450p:plain

以下に示した数字の部分は参照されている回数だそうです。

f:id:kazuhironagai77:20210613200507p:plain

後、それぞれのParameterの意味が分かれば良いですが。

ParticlesのParameterはカーソルを乗せるとそのParameterの機能が解説されています。

f:id:kazuhironagai77:20210613200526p:plain

EmitterのParameterはカーソルを乗せても何も表示されません。

もう少し経ったらEmitterのParameterの解説も表示されそうですね。これは待つ事にしましょう。

ただし、UPositionに関しては完全に理解出来ました。

f:id:kazuhironagai77:20210613200545p:plain

f:id:kazuhironagai77:20210613200552p:plain

上記の説明のようにRingの場合はCircle状のPositionを示しています。そしてParameterはAgeなので0から9秒の間のFloatを示しているはずです。それが以下のCircleの円周上の位置を示しているはずです。

f:id:kazuhironagai77:20210613200612p:plain

2.7「先週、分からなかった事5」Acceleration Force Moduleについて

Particle Update Group [7] に以下の説明がありました。

f:id:kazuhironagai77:20210613200640p:plain

この説明を見る限り単なる加速度ですね。

CGHOW氏のAll Forces Modules in UE4 Niagara Explained [8] にも簡単な説明がありました。

f:id:kazuhironagai77:20210613200658p:plain

f:id:kazuhironagai77:20210613200705p:plain

Captionのマイナスが切れてしまいましたが、‐980cmをZに追加すれば重力と同じになると説明しています。

やっぱり加速度を追加しているようです。

2.8 Ribbon Emitterについて

一つ大切な事に気が付いたのでここに書いておきます。

UE4のVirtual Effectは全てParticle で作成されているはずです。そのParticleにTextureを貼り付けたのがSprite、Static MeshをはりつけたのがMeshです。ではRibbon Emitterは何をParticleに貼りつけてんでしょうか?

分かりません。

しかしこれはarticle Effectの理論からUE4VFXを理解するためには解明する必要があります。

後で調査しましょう。

3. Cascadeの勉強

今週はContent ExampleにあるGPU Particle with Velocity Cone Moduleに使用されているModuleについて勉強します。

f:id:kazuhironagai77:20210613200740p:plain

f:id:kazuhironagai77:20210613200748p:plain

最初の二つのEmitterはGPU Spriteを使用していますね。最初の二つのEmitterのModuleの多くは+が付いていますがこれはGPU Spriteに関係しているのでしょうか?

Velocity Cone Moduleは先週散々勉強したので、今週はパスしますが、出来た当時は結構な大発明だったんでしょうか?

3.1 Sphere Emitterを調べる

順番は逆ですが最後のSphere Emitterから見て行きます。

f:id:kazuhironagai77:20210613200810p:plain

綺麗なEffectです。どうやって作成しているのでしょうか?

いろいろ試したら分かったのですが、この色はMesh Material Moduleで作成されています。

f:id:kazuhironagai77:20210613200827p:plain

f:id:kazuhironagai77:20210613200833p:plain

このModule、Materialに属するModuleですが、

f:id:kazuhironagai77:20210613200849p:plain

Particle System Reference [2] に載っていません。

f:id:kazuhironagai77:20210613200904p:plain

ので解説が見つかりません。

このModuleに関する疑問は、Required Module内にMaterialを指定する箇所があるのに更にMaterialを指定している所です。

f:id:kazuhironagai77:20210613200919p:plain

Mesh Dataの場合はMesh Material Moduleで別に使用するMaterialを指定する必要があるんでしょうか?

以下の様なMesh Particleを放出するEmitter を作成しました。

f:id:kazuhironagai77:20210613200934p:plain

f:id:kazuhironagai77:20210613200943p:plain

Mesh Material Moduleを追加します。

f:id:kazuhironagai77:20210613201017p:plain

Materialには以下の青色をセットしました。

f:id:kazuhironagai77:20210613201040p:plain

球が青くなりました。

f:id:kazuhironagai77:20210613201102p:plain

今度はRequired ModuleのMaterialに同様の青をセットしました。

f:id:kazuhironagai77:20210613201124p:plain

球に色は付いていませんね。

f:id:kazuhironagai77:20210613201139p:plain

どうしてこうなったんでしょう。

残りのModuleは全部知っているヤツですね。

3.2 Particle Emitterを調べる

以下にGPU Spriteを使用したParticle Emitterを示します。

f:id:kazuhironagai77:20210613201159p:plain

+のサインの意味が分かりませんね。GPU Spriteの場合+を使用しないといけないのでしょうか?

GPU Spriteを使用したParticle Emitterを作成してみました。

f:id:kazuhironagai77:20210613201213p:plain

別に+サインがModuleの名前の隣に現れたりはしていません。

色々調べたんですが分かりません。

調べている内に以下のtutorial(Introduction to Cascade [9] )を見つけました。

f:id:kazuhironagai77:20210613201230p:plain

公式のTutorialでContent Exampleで紹介されているEffectについての解説と作成方法を説明しています。

数年前にこのTutorialにある牛のおもちゃが落下するEffectを作成した事があったのですが、存在自体すっかり忘れていました。今、見直すとModuleの使用方法の解説は詳しくそれなりに勉強にはなります。これからはこのTutorialも参考にする事にします。

ただ全てのVideoのTutorialに言える事ですが、何故、その関数や機能、UE4のVisual Effectの場合ならそのModuleを使用するのかについての理論的な解説はこのTutorialもほとんどないです。

これは重大な問題なのでここで時間をとって詳しく解説します。

Programmingならば大体以下の手順で(ソフトウェアを)制作します。

  1. 作りたいソフトウェアの目的、機能、UIなどを紙の上でまとめます。
  2. こうやったらそのソフトウェアが作成できるとだろうと言う簡単な設計図を作ります。
  3. 試しに作成します。
  4. 出来なければ2に戻って設計図を直します。
  5. 出来たらテストします。
  6. バグが発見されたら直します。
  7. 全部直したら完成です。

UE4のEffectだって根本的にはProgrammingなのですから大体は上記の手順で作成が進みます。だからEffectのTutorialだってその手順を示すべきなんです。しかし何故かEffectに限らずUE4のTutorialは既に完成した設計図が何故か手元に最初からあります。しかもその設計図にはどのNodeやら変数やらEffectの場合はModuleを使用するのかまでしっかり書かれています。それをどうやって組み立てるのかだけしか教えません。まるでプラモデルでも組み立てているかのようです。

その様なTutorialからは何も学べないと言うのではないですが、設計図の作成方法を学ばなければ自分で新しく何かを作成する事は出来ません。

いろいろ弄っていたら+が表示されているModuleは、どちらかを選択しても両方が一辺に選択される事に気が付きました。

f:id:kazuhironagai77:20210613201304p:plain

これが+の意味なのかもしれません。

試してみましょう。

Linking modules within cascade [10]によると

f:id:kazuhironagai77:20210613201336p:plain

で出来るそうです。

出来ました。

f:id:kazuhironagai77:20210613201355p:plain

Sphere emitterの隣に新しいEmitterを作成してMesh Material Moduleを上記の方法でLinkしました。

+のサインが表示されています。

4. Monster Zoneの改良について

先週、Landscape4上に配置している全てのMonsterを倒してみました。その結果、色々直しが必要な個所が見つかりました。

以下にそれをまとめます。

  • Start画面の部屋がStarter Kitで作成されているのでFantasy感が薄い。
  • 戦闘後にLevelが上がった場合、一言「Levelが上がりました。」としか表示されません。勝利ポーズを変更してもっと細かい情報(攻撃力がどれくらい上昇したのかなど)を報告するようにします。
  • Monsterがたまにアイテムを落とすようにします。

更に、以下の改善点が述べられています。

  • 途中から凄い退屈になった。戦闘しても勝てるのが分かっているから作業感が半端じゃない。
  • 戦闘画面に移る時に、後ろからモンスターに襲われるときと、自分からモンスターの後ろを襲うとき、は普通の戦闘と同じ始まり方で良いのかと思った。
  • もっと戦闘にメリハリが欲しくなった。途中までは戦闘も楽しかったが、戦闘しても勝てるのが分かっているからつまらなくなる。
  • 一端倒したモンスターが絶対復活しないので帰りは楽だった。
  • バグらしいバグはなかった。のでその点は良かった。
  • 地面が明かる過ぎると思いました。

以下にそれぞれの改善方法について検討した内容を示します。

<Start画面の部屋がStarter Kitで作成されているのでFantasy感が薄い>

BeffioのMedieval KingdomのStatic meshを使用して作り直します。

f:id:kazuhironagai77:20210613201451p:plain

<戦闘後にLevelが上がった場合>

一言「Levelが上がりました。」としか表示されません。

勝利ポーズを変更してもっと細かい情報(攻撃力がどれくらい上昇したのかなど)を報告するようにします。

Levelが上がると以下のパラメーターの値が上昇します。

f:id:kazuhironagai77:20210613201512p:plain

更に魔法を覚える事もあります。

これらを一つ一つ文章で報告します。

例えば、

  • 最大HPが1上がりました。
  • 最大MP1上がりました。
  • 攻撃力が1上がりました。
  • 防御力が1上がりました。
  • 幸運が1上がりました。
  • 魔法、炎()を覚えました。

のようにします。

<Monsterがアイテムを落とすようにします。>

偶に、倒したMonsterがアイテムを落とすようにします。

そう言えば、武器は拾えるように以下に示したBPを前に作成しました。

f:id:kazuhironagai77:20210613201554p:plain

f:id:kazuhironagai77:20210613201603p:plain

f:id:kazuhironagai77:20210613201612p:plain

がアイテムは忘れていました。

PickUpItem WidgetでもItemを拾った場合は実装していません。

f:id:kazuhironagai77:20210613201633p:plain

以下のFalseの時の実装の事です。

f:id:kazuhironagai77:20210613201649p:plain

アイテムの獲得方法ですが、単に戦闘終了後に貰えるのではなく、以下の様なのを考えています。

戦闘終了後、アイテムが貰える場合は、9体ある像のどれかに一回だけ話せるようになります。

f:id:kazuhironagai77:20210613201707p:plain

天使の像です。

f:id:kazuhironagai77:20210613201732p:plain

50%の確率でアイテムが貰えます。

裏切りの像です。

f:id:kazuhironagai77:20210613201749p:plain

25%の確率で特別なパスが貰えます。

像1です。

この像の名前は像1としか書かれていません。逃亡した奴隷の像とでも名付けます。

f:id:kazuhironagai77:20210613201807p:plain

50%の確率でHPを全快にしてくれます。

角の像です。

何ですかね。この名前のセンスは。せめて角のある人の像と名付けて欲しいですね。

f:id:kazuhironagai77:20210613201824p:plain

50%の確率でMPを全快にしてくれます。

頭蓋骨です。

f:id:kazuhironagai77:20210613201840p:plain

50%の確率でHPとMPを全回復します。しかし10%の確率で死にます。

以下の3体の像に関してはまだ何も考えていません。

f:id:kazuhironagai77:20210613201856p:plain

こんな感じで戦闘後のアイテムが貰えるようにします。

以下はそれ以外の問題点についてです。

  • 途中から凄い退屈になった。戦闘しても勝てるのが分かっているから作業感が半端じゃない。
  • 戦闘画面に移る時に、後ろからモンスターに襲われるときと、自分からモンスターの後ろを襲うとき、は普通の戦闘と同じ始まり方で良いのかと思った。
  • もっと戦闘にメリハリが欲しくなった。途中までは戦闘も楽しかったが、戦闘しても勝てるのが分かっているからつまらなくなる。

これらは一見別々な問題について語っている様で、同じ問題について論じています。戦闘の結果、勝利するのが100%予測出来るのでつまらなくなっているんです。

f:id:kazuhironagai77:20210613201934p:plain

最初の10回位までは戦闘も楽しいんです。何故かと言うと以下のサイクルが発生するからです。

  1. 何とか実力でモンスターを一体倒す。
  2. しかし次の戦闘に勝つための十分なHPとMPはない。
  3. たまたまLevelが上がる事でHPとMPが回復。次の戦闘も勝つ事が出来る。

今回の戦闘は勝てる。次の戦闘は勝てない。の状態で戦闘に勝ちます。しかし戦闘画面からLandscape4に戻ったら別なモンスターと直ぐに戦闘になります。そうなったら戦闘で負けて死にます。その予測がかなり濃厚になった時にLevelが上がる訳です。Levelが上がる事でHPとMPが回復して次の戦闘は勝てるように成る訳です。

これは楽しいです。

所が、LevelがMaxまで上がると今回の戦闘も勝てる、次の戦闘も勝てる状態になります。それがつまらなくなるんです。

それでこんな事を考えました。

今までWarpは無料で出来るように作っていました。これを有料にします。といってもお金ではありません。パスというアイテムが必要になります。Map1からLandscape4にWarpするにはパスが1枚必要です。みたいにします。このパスはお金では買えません。

戦闘に勝つとこのパスを手に入れられるようにします。

Levelが低い時は兎に角。HPとMPを回復させる必要があります。

f:id:kazuhironagai77:20210613201959p:plain

ので天使の像にお祈りして回復アイテムをもらう一択になります。

LevelがMaxになり回復アイテムがそんなに重要でなくなったら、裏切りの像でお祈りしてパスを集める戦略に変更出来ます。

f:id:kazuhironagai77:20210613202018p:plain

これで戦闘も退屈ではなくなるはずです。

となると最初にする事はMonsterを倒した時にアイテムが手に入るようにする事ですね。

<一端倒したモンスターが絶対復活しないので帰りは楽だった。

何時、Monsterは復活出来るのかを決めていませんでした。

以下の条件でMonsterは復活すべきです。

  • ワープをした時
  • 宿屋で寝た時
  • Saveした時
  • 夜になった時

縄張り内のMonsterを全部倒した場合、帰りは楽になります。でも夜になればMonsterは復活するので楽なのは一時だけです。いいと思います。

<地面が明かる過ぎる>

以下にLandscape4の地面を示します。

f:id:kazuhironagai77:20210613202052p:plain

確かに明るいです。

地面をもっと暗くする方法は幾つか考えられます。

まずはDirectional LightのIntensityを下げる方法です。

f:id:kazuhironagai77:20210613202108p:plain

次はSky Lightの以下のParameterを弄る事です。

f:id:kazuhironagai77:20210613202124p:plain

更にLandscape4はまだGood Skyを実装していません。Good Skyを実装して昼夜が出来たら、地面が明るすぎるのは朝の一時期だけになるかもしれません。

f:id:kazuhironagai77:20210613202144p:plain

まずはGood Skyを実装する事から始めます。

5. Monster Zone の更なる作成

残りのMonster Zoneの作成もしていきます。

f:id:kazuhironagai77:20210613202219p:plain

5.1 Monster Zone 4 の作成

やり方は先週作成したMonster Zone 3と全く一緒です。

先週、Monster Zone 3を作成した方法はマニュアル化出来ているはずなので、全く同じ方法でMonster Zone 4を作成してみます。

Block、Territory、Triggerを追加します。

f:id:kazuhironagai77:20210613202242p:plain

Monsterを静的に配置します。

f:id:kazuhironagai77:20210613202257p:plain

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

f:id:kazuhironagai77:20210613202316p:plain

Monsterを動的に生成するためにMonster Spawn DataをRPG Game Instance BPに作成します。

f:id:kazuhironagai77:20210613202331p:plain

この配列に先程、静的に配置したMonsterのデータを写します。

f:id:kazuhironagai77:20210613202346p:plain

このData TableからMonsterを生成するようにします。

Monster Zone ActorのGet Monster Spawn Data関数をMonster Territory Number が4だった場合にも対応できるようにします。

f:id:kazuhironagai77:20210613202402p:plain

これでMonster Zone 4のMonster は動的に生成されるはずです。

Monster Zone 4のMonster が倒された時にMonster Spawn Data Landscape 4-4のデータを書き変えるようにしましょう。

RPGGameBaseBPのRemove Defeated Monster関数にMonster Territory Number が4だった場合の対応を実装させました。

f:id:kazuhironagai77:20210613202418p:plain

これでMonster Zone 4 でMonsterと戦闘しても問題ないはずです。

ここまではMonster Zone 3の作成方法と一字一句同じやり方で出来ました。

しかしRemove Defeated Monster from Landscape4()関数の内容がかなり複雑になってしまいMonster Zone 4の実装にかなり時間がかかりました。

f:id:kazuhironagai77:20210613202437p:plain

先週は要らないと言いましたがやはりMonster Zone の部分は関数化する必要があります。後でやります。

テストします。

Block 4に侵入しました。

f:id:kazuhironagai77:20210613202506p:plain

Monsterが生成されています。

次にBlock 4から退散してみます。

f:id:kazuhironagai77:20210613202601p:plain

戦闘してみます。

f:id:kazuhironagai77:20210613202617p:plain

Monster Zone 4に発生するMonster 9匹を倒しました。特にバグが発生する事もありませんでした。

Block内に侵入したり退出したりを繰り返しました。

f:id:kazuhironagai77:20210613202634p:plain

これも大丈夫でした。

正し、死体になったMonsterが引きずられるように移動するバグはそのままです。これは後で直します。

5.2 Remove Defeated Monster from Landscape4関数の直し

Remove Defeated Monster from Landscape4 Helper関数を作成します。

f:id:kazuhironagai77:20210613202655p:plain

実装部は以下の様になっています。

f:id:kazuhironagai77:20210613202722p:plain

Remove Defeated Monster from Landscape4関数の実装部は以下の様になりました。

f:id:kazuhironagai77:20210613202740p:plain

正直あんまり綺麗になっていません。Switch 関数の場合にどうやってNodeを整理するかの正しい方法が分かりません。

取り敢えずこれでテストしてみます。

Monster Zone 1をテストしました。問題ないです。

Monster Zone 2もテストしました。問題ないです。

Monster Zone 3もテストしました。流石に飽きて来ました。全部のモンスターは倒しませんでしたが、多分問題なしです。

Monster Zone 4もちょっとだけテストしました。多分問題なしです。

5.3 Monster Zone 5、6、7 の作成

残りのMonster Zoneも作ってしまいます。

Monster Zone 5です。

f:id:kazuhironagai77:20210613202808p:plain

テストもしました。

f:id:kazuhironagai77:20210613202823p:plain

25体もMonsterがいるので最強装備で倒しました。バグはありませんでした。

Monster Zone 6です。

f:id:kazuhironagai77:20210613202856p:plain

21体のMonsterを全部倒しました。

f:id:kazuhironagai77:20210613202913p:plain

バグはなかったです。

Landscape 4の最後のMonster Zone であるMonster Zone 7を作成します。

f:id:kazuhironagai77:20210613202944p:plain

36体のモンスターを配置しました。

テストで全部倒しました。

f:id:kazuhironagai77:20210613203006p:plain

バグはなかったです。

これでMonster Zoneは完成です。

5.3 Monster Zone のバグの直し

今週は時間が無くなってしまったので来週やります。

6. まとめと感想

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

  • Niagara の勉強としてRibbon Effectの復習
  • Cascadeの勉強としてMesh Material Module、別々のEmitterにある二つの同じ種類のModuleをLinkする方法
  • Monster Zoneの改良というかこのゲームの改善すべき点に対する考察
  • 残りのMonster Zoneの作成

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

  • Niagara の勉強とCascadeの勉強
  • Monster Zoneのバグの直し
  • ゲームの改善点の直し

今週はやる気が出なくて、一日お休みしました。休んだらやる気が戻りましたが正直、二度とやる気が戻らないかと思って焦りました。やる気を維持する為には、良く寝る事と成果を吐き出せる場所がある事が大切と理解しました。

7. 参照(reference

[1] Epic Games. (n.d.-a). Create a Ribbon Effect in Niagara. Unreal Engine Documentation. Retrieved June 13, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/HowTo/RibbonEffect/

[2] Epic Games. (n.d.-f). Particle System Reference. Unreal Engine Documentation. Retrieved June 13, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/

[3] Epic Games. (n.d.-e). Niagara Visual Effects. Unreal Engine Documentation. Retrieved June 13, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/

[4] Epic Games. (n.d.-c). Emitter Update Group. Unreal Engine Documentation. Retrieved June 13, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/EmitterReference/EmitterUpdate/

[5] Epic Games. (n.d.-b). Create a Ribbon Effect in Niagara. Unreal Engine Documentation. Retrieved June 13, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/HowTo/RibbonEffect/

[6] gameDev Outpost. (2020, September 17). UE4 - Niagara Parameters [Video]. YouTube. https://www.youtube.com/watch?v=7Nally9pWq4

[7] Epic Games. (n.d.-g). Particle Update Group. Unreal Engine Documentation. Retrieved June 13, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/EmitterReference/ParticleUpdate/

[8] CGHOW. (2021, March 19). All Forces Modules in UE4 Niagara Explained [Video]. YouTube. https://www.youtube.com/watch?v=iW867tJ93lU

[9] Unreal Engine. (n.d.). Introduction to Cascade | v4.2 | Unreal Engine. YouTube. Retrieved June 13, 2021, from https://www.youtube.com/playlist?list=PLZlv_N0_O1gYDLyB3LVfjYIcbBe8NqR8t

[10] Epic Games. (n.d.-d). Linking modules within cascade - UE4 AnswerHub. UE4 ANSWER HUB. Retrieved June 13, 2021, from https://answers.unrealengine.com/questions/407178/linking-modules-within-cascade.html

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

f:id:kazuhironagai77:20210606234824p:plain

<前文>

先週、なんで突然、直前まで書いた文章を消したのかと言うと、日本語学習にPitchの勉強は必要である派と必要ない派のディベートを見てて、日本語の文法について私見を述べた場合、日本語でこんな理性的な議論に発展する可能性は0だと思ったからです。違う意見の持ち主からディベートを持ちかけられるなら大歓迎ですが、単なる罵詈雑言を浴びるだけなら書かない方がましだと思いました。

だから消しました。

勿論、英語なら必ずディベートになる訳ではなく、むしろ英語の方が喧嘩になる事は多い位です。特に原理主義(Fundamentalism)の色が濃いアメリカでは、答えが最初から決まっている人達が結構いて、その人達はどんなに科学的な証拠を見せても聞く耳持たないです。一番分かり易い例が中絶の議論で、中絶は絶対駄目という原理主義者(Fundamentalist)は結構いて、中絶に関しては全くディベート出来ない事が多いです。どれくらい聞く耳持たないかと言うと、中絶を実行する医師の経営する病院を爆破したり、医者を殺害したりしています。

私の住んでいた所は結構田舎だったので、中絶は絶対駄目という原理主義(Fundamentalism)な人はそこそこいました。理由を聞くと大抵聖書に書いてあると答えます。聖書に書いてあっても例外もあるでしょう。と私なんかは思って大学の友達に聞いたら、例外を認めないから彼らは原理主義者(Fundamentalist)って呼ばれているんだ。と教えてくれて非常に納得したのを覚えています。

所が、最近になってRedditを見るようになって知ったんですが、聖書には中絶を勧める文章がいっぱいあるそうです。それを知った時何それと思いました。

更に、中絶反対する人でも嫁以外の女性を妊娠させた時や高校生で彼女を妊娠させた時なんかは、なりふりかまわず中絶を進めてくる話も知りました。アメリカでは生まれた子供の養育費は生物学的な父親が負わなくてはいけないのと、もしそれが出来ない場合は刑務所行きになるからだそうです。

日本語で語る分には、こういう中絶のようなアメリカではSensitiveで非常に気を使って話さないといけない話題でも、命の危険を感じずに軽く語る事が出来ます。こういう話題をここですべきと再確認しました。

逆に、日本語でこれを言うと語弊があるなとか、波風を立てる可能性がある話題は英語で日本人に見つからない所で議論すればいいんです。

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

<本文>

1.今週の予定

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

2.Unreal Engine 5について

ちょっとだけUE5について調査します。調べても私のPCのスペックでは動かないと思うので悲しくなるだけかもしれませんが。

2.1 必要とされるスペックについて

当然どのくらいのSpecのPCが必要なのかがまず知りたいです。UE5 Specと打ち込んだら一番最初に以下の記事が出て来ました。

Unreal Engine 5 is now in Early Access for developers – download the Valley of the Ancients tech demoによるとUE5そのものではなくそのデモ(The Valley of the Ancient demo)を実行するのに必要なスペックは

f:id:kazuhironagai77:20210606235258p:plain

だそうです。最低基準すら私のPCでは満たしていません。

流石にハードの値段について疎い私でも、今Video Cardが品薄になって価格が暴騰している事は知っています。新しいPCを購入するにしても最速でも年末か、もしかしたら来年になるかもしれません。

それまではUE5はお預けです。

2.2 UE5についての公式ホームページの情報をみる

UE5の公式のホームぺ―ジ [2]から見てみます。

f:id:kazuhironagai77:20210606235347p:plain

01は何について語っているのか曖昧で良く分からないのでスキップします。

02でNaniteとLumenについて語っていますね。この二つの言葉はよく聞きます。意味は知りませんが。

この辺から見てみます。

f:id:kazuhironagai77:20210606235415p:plain

Naniteはどうやら、広大かつ精密なLandscapeをUserがなんの工夫もしなくてもそのまま扱える機能のようです。以下の説明によると

  • Poly Count やDraw Call
  • 詳細をNormal mapにBakeする事
  • 手動でLODsを描く事

などの作業を大量に消去する事で達成してるそうです。

f:id:kazuhironagai77:20210606235513p:plain

ふーん。ですね。

Lumenについてです。LumenはRay Tracingの一種だと思っていたんですが、YouTubeのビデオでLumen vs. Ray Tracingみたいなのがあったので違うのかもしれません。その辺が良く分かりません。

以下の説明によると、最初にDynamic global illuminationと書かれています。と言う事は動いている物体にもGlobal illuminationが働くって事なんでしょうか?

f:id:kazuhironagai77:20210606235532p:plain

2021-04-26のブログの実験ですが、Directional lightの設定をMoveableにすると以下の様に床からのGlobal illuminationが全く働かないので影が真っ黒になってしまいます。

f:id:kazuhironagai77:20210606235620p:plain

Lumenだとこういう設定でも影が真っ黒にならないんでしょうか?試してみたいですね。

説明文を更に読み込んだら、以下に示したようにはっきりと太陽の角度の変化と書かれていました。

f:id:kazuhironagai77:20210606235654p:plain

もうこれは99%以上の確率でDirectional lightの設定をMoveableしてもGlobal illuminationが働くでしょう。

おーっ。

かなり興奮して来ました。

更に説明を読み込んだら、Light mapでしていた細かい設定とかも要らなくなるみたいですね。

建築関係でUE4を使用している人達には朗報なんでしょうか?それともLight mapでやっていた微妙な設定が出来なくなってしまうんでしょうか?その辺も興味あります。

次はOpen Worldsについてです。

以下の説明によるとWorld Partition Systemが採用されているそうです。

f:id:kazuhironagai77:20210606235717p:plain

World Partition Systemに関しての色々な機能が紹介されていますが、一人で作っている私には直接の影響はあんまりない機能かもしれません。

Animationについてですね。

f:id:kazuhironagai77:20210606235736p:plain

色々な機能が紹介されていますが、UE4のAnimation自体良く理解していない私には正直どう凄くなっているのか分かりません。UE4のAnimatorなら大興奮の内容なのでしょうか?読んでもポカーンて感じです。

MetaSoundsについてです。

ここは結構興味あったところなんですが、UE4と比べてどう変わったんでしょうか?

f:id:kazuhironagai77:20210606235801p:plain

これもこれだけ読んだだけじゃ何も分かりませんね。

Editor workflowについてです。これはEditorのViewportが大きくなっている事についての解説みたいです。

f:id:kazuhironagai77:20210606235820p:plain

ちょっとだけUE5を紹介するVideoで見たんですが、使用感が凄い快適みたいです。UE4でもストレスフリーでほとんどの機能が使用出来るのに更に使い易くなったらどうなるんでしょう。日常のストレスの発散のためにUE5を触る様になるかも知れませんね。

後重要なのはFAQにあった以下の解答です。

f:id:kazuhironagai77:20210606235840p:plain

4.24じゃ互換性もないのか。うーん。

2.3 英語圏のUE5のコメントを見る

今まで引用させてもらった沢山のUE4のTutorialを参照(reference)にまとめてあります。全て英語圏からの引用です。折角ですのでその人達がUE5に対してどんなコメントを出しているのか見てみようと思います。

<Why Unreal Engine 5 is a BIG DEAL [3]

Why Unreal Engine 5 is a BIG DEAL [3] はUnreal Sensei氏のUE5に対する簡単な解説です。

f:id:kazuhironagai77:20210607000010p:plain

5分の短い動画ですがLumen、NaniteとBridgeそしてEditorについてコメントしています。

LumenはRay Tracingじゃないんですね。そんな気もしていましたがこの動画ではっきりしました。

Naniteの解説では、Naniteは一言で言えば動的なLODと言っています。これは分かり易い例えと思いました。NaniteはStatic meshにしか使用できない事も説明していました。デモでRobotがSkeletal meshで動いているじゃん。と思う方はこの動画を見て下さい。何でRobotにNaniteが効いているのかしっかり解説されています。この解説は他のTutorialでは全く聞いた事がないです。Unreal Sensei氏は本当にびっくりするぐらい頭良いです。

<Tech Art Aid氏のUE5についての動画>

Tech Art Aid氏はHierarchical Instanced Static Meshの使用方法を私に教えてくれた貴重なTutorial (UE4 Optimization: Instancing [4])です 。3年近く全く動画を上げていなかったんですが最近また動画を上げるようになったみたいです。

UE5についてTesting UE5 Lumen Real Time Lighting & Limitations // Unreal Engine 5.0 Early Access [5] とTesting UE5 Nanite Meshes & Limitations // Unreal Engine 5.0 Early Access [6] を上げていました。

f:id:kazuhironagai77:20210607000059p:plain

Tech Art Aid氏本人が言っていますが、このビデオはTutorialではなく本人もほとんど初めての状態で試したものです。のであんまり綺麗にはまとまっていません。色々、興味深い事を発見したり考察したりしていますが、私が今のほとんど理解していない状態でそれをここでまとめると、間違ってまとめそうなので止めておきます。

それよりも驚いたのは私ずっとTech Art Aid氏はインド人と思っていました。Polandの人みたいです。全然関係ないですがTwo Minute Papers [7]の人もずっとインド人と思っていました。実際はHungaryの人でした。

<MR3D-Dev

私、この人のTutorial、何時見たのか全く覚えていないんですが、参照(Reference)に名前がありました。LandscapeのDisplacementのやり方をこの人の動画で勉強したんでした。念のためにチェックしたらUE5 についての動画を2つほど挙げてありました。

Unreal Engine 5 First Impressions [8] とHow to Use Data Layers in Unreal Engine 5 (Dark Realm Access) [9] です。この人の動画も試しに使ってみたという感じでした。

f:id:kazuhironagai77:20210607000128p:plain

<CGHOW

この人は、Niagara のtutorialを沢山作成していて、いずれ参考にする時のために参照(reference)に記録していたんでした。UE5に関して既に5本の動画を上げています。どうせ他の動画と一緒だろうと思って、一番最初のUE5の動画、Unreal Engine 5 Early Access | First Reaction [10] を見たらUE5のNiagara systemについての動画でした。

f:id:kazuhironagai77:20210607000153p:plain

ほおおっ。と思わず声を上げる所でした。

こういう独自の観点からUE5へのコメントを上げるのはかなり興味深いです。

UE5のNiagaraは、私が見た限りではUE4Niagaraと全く同じみたいです。

残り4つのvideoはUE5でNiagaraを使用したsample映像などでした。はっきり言って凄いです。この人の動画でNiagaraは勉強する事にします。

参照(Reference)にある人でUE5の紹介をしている人達は以上でした。

3.Niagaraの勉強

今週は先週出来なかったCreate a Ribbon Effect in Niagara [11] の勉強をします。

3.1 Ribbon Effectの目的

Ribbon Effectって正直一番要らないEffectと思っていました。

f:id:kazuhironagai77:20210607000235p:plain

Effectとしてはっきり言ってしょぼいです。アニメの必殺技でこんなエフェクトだったらそのアニメを見るの止めます。それで勉強するのも最後の方になってしまったんですが、以下の解説がありました。

f:id:kazuhironagai77:20210607000256p:plain

飛行機雲みたいなEffectを作るためにはRibbon Emitterが必要って書かれています。Ribbon Effectってそんな目的のために作られたんですか。知らなかった。これは重要ですね。やる気が出て来ました。

<Create System and Emitter

FX -> Niagara System -> New system from selected emitters -> Simple Sprite Burst を選択します。

f:id:kazuhironagai77:20210607000346p:plain

おお、Sprite Burstが選択されています。先週、Cascadeで勉強した所ですね。実装方法もちょっとだけ見ておきます。

その前に作成したNiagara Systemに名前だけ付けます。

f:id:kazuhironagai77:20210607000424p:plain

以下の様になっていました。

f:id:kazuhironagai77:20210607000500p:plain

Spawn Burst Instantaneous ModuleのParameterは以下の様になっています。

f:id:kazuhironagai77:20210607000521p:plain

Cascade のSpawn BurstのParameterは以下の様になっています。

f:id:kazuhironagai77:20210607000541p:plain

単純に比較するとNiagaraのSpawn Burst Instantaneous ModuleはCount Lowに対応するParameterがありません。となるとNiagaraのBurst Moduleでは作成するParticleの数をある範囲内のRandom な数には出来ないと言う事でしょうか?

<Change Renderer

Sprite Rendererを消去してRibbon Rendererを追加します。

f:id:kazuhironagai77:20210607000610p:plain

Ribbon RenderingのMaterialにDefault Ribbon Materialをセットします。

f:id:kazuhironagai77:20210607000633p:plain

NS_RibbonをLevel内にセットします。

f:id:kazuhironagai77:20210607000702p:plain

まだ何も見えません。

<Edit the Emitter Update Group Settings

Emitter Update GroupのEmitter State ModuleのLife Cycle Modeの値をSystemに変更します。

f:id:kazuhironagai77:20210607000733p:plain

このDocumentにLife Cycle Modeについての説明がありました。

f:id:kazuhironagai77:20210607000753p:plain

でもLife Cycle Logicって何を指しているのかが分かりません。

Parameterの機能が分からない時はカーソルを乗せるに限ります。

f:id:kazuhironagai77:20210607000817p:plain

成程、Emitter の寿命の計算をEmitter自身にさせるか、そのEmitterを持っているNiagara Systemに計算させるかを決めているでした。

でもそれってどう違うの?と新たな疑問が出て来ます。そしたらその疑問に対する答えも書いてありました。

大体の場合、Niagara systemに計算させた方が最適化されて速くなるそうです。

でもそれなら何でDefaultではSelfにセットされているんでしょう?

やっぱりまだ腑に堕ちませんね。

Emitter Update GroupにSpawn Rate Moduleを追加します。Spawn Rate ModuleのSpawn Rateの値を100にセットします。

f:id:kazuhironagai77:20210607000843p:plain

Spawn Rateの意味は、これまでの勉強で良く分かっていますが、Spawn Burst Instantaneous ModuleのSpawn Timeがその役割を担当していると思っていました。

f:id:kazuhironagai77:20210607001009p:plain

Spawn Timeは何をしているのか不明ですね。

f:id:kazuhironagai77:20210607001038p:plain

<Edit the Particle Spawn Group Settings

今度はParticle Spawn Groupの設定を変更します。

まずParticle Spawn Group 内のInitialize Particle Moduleを消去します。

f:id:kazuhironagai77:20210607001104p:plain

Initialize Ribbon Moduleを追加します。

f:id:kazuhironagai77:20210607001124p:plain

以下に示したように、Parameterの値を変更します。

f:id:kazuhironagai77:20210607001228p:plain

今度は、Particle Spawn GroupにTorus Location Moduleを追加します。

f:id:kazuhironagai77:20210607001306p:plain

Torus とはドーナツ形状の事です。WikipediaのTorus [12]によるとTorusは以下の式で定義されます。

f:id:kazuhironagai77:20210607001323p:plain

そして使用しているParameterの定義は、以下のようになっています。

f:id:kazuhironagai77:20210607001340p:plain

これらのParameterの値をTorus Location Moduleで指定するのでしょうか?

Torus Modeの値をTorusからRingに変更しました。

f:id:kazuhironagai77:20210607001437p:plain

TorusからRingに変更するとどう違うんでしょうか?

f:id:kazuhironagai77:20210607001457p:plain

うーん。分からん。でももしかすると生成されたRibbonの形状から判明するかもしれません。

Ringは以下の様な形状です。

f:id:kazuhironagai77:20210607001548p:plain

Torusは以下の様な形状でした。

f:id:kazuhironagai77:20210607001614p:plain

Ringの方がバラケ具合が小さいですね。

Large RadiusとTorus Distribution Modeの値を変更しました。

f:id:kazuhironagai77:20210607001633p:plain

Large Radiusは上記のTorusの式におけるRの事なんでしょうか?何か違う気がします。

UPositionの値をParticle Ageに変更します。

f:id:kazuhironagai77:20210607001659p:plain

UPositionは何を担当しているParameterなのでしょうか?

f:id:kazuhironagai77:20210607001716p:plain

分からん。

Documentに何か解説は載っていないかとみていたら、UPositionに追加するParameter、ageはParticleのageではなくEmitterのageを使用していました。直します。

f:id:kazuhironagai77:20210607001735p:plain

EmitterのAgeに変更した途端に綺麗なRingが現れました。

f:id:kazuhironagai77:20210607001752p:plain

何でParticleのAgeの時は何も表示されなかったのか?と思ったんですが、良く考えたらParticleは生成してないですね。

UPositionの機能についてはDocumentの方では以下の説明がありました。

f:id:kazuhironagai77:20210607001811p:plain

良く分かりませんね。Floatを返しているんですから、数字を入れたら何かヒントが分かるかもしれません。実験してみましょう。

0、0.1、0.5、0.9、1、100などの数字を代入してみました。

f:id:kazuhironagai77:20210607001831p:plain

全くRingが現れません。

うーん。これも意味が分からん。

Emitterのageがどんな値を返しているのか分かれば、もう少し分かるんですがPrint  Stringみたいな機能はないんでしょうか?

今回は諦めるしかありませんね。私のParticle Systemの理解が進んだ時に、おのずと明らかにされるでしょう。

最後にAdd Velocity from Point Moduleを追加しました。

f:id:kazuhironagai77:20210607002003p:plain

加えた途端にRingがきれいな渦巻きを描き出しました。

f:id:kazuhironagai77:20210607002021p:plain

上から見るとこんな感じです。

f:id:kazuhironagai77:20210607002037p:plain

Velocity Strengthの値を50にしました。

f:id:kazuhironagai77:20210607002057p:plain

渦が小さくなりました。

f:id:kazuhironagai77:20210607002118p:plain

このModuleの機能は分かりました。

説明のために一端、Add Velocity from Point Moduleを外します。

大きさを統一するためのちょっと見にくいですがPreview全体を表示します。以下に表示されているのが現在のRingの大きさです。

f:id:kazuhironagai77:20210607002145p:plain

もう一度、Add Velocity from Point Moduleを追加します。

f:id:kazuhironagai77:20210607002214p:plain

はい。Ringの半径が時間に沿って増大しています。

今度は、Velocity Strength の値を100から50に変更します。

f:id:kazuhironagai77:20210607002232p:plain

f:id:kazuhironagai77:20210607002240p:plain

はい。Ringの半径の増大率が前の半分くらいになっています。

うん。これは上から見ると結構、それぞれのParameterの機能の意味が分かりますね。

今週はもうそんなにこれだけに時間を費やす事は出来ないので来週、もう一回やりますか。そうしたらParameterの機能の80%位は解明出来そうですし。

<Edit the Particle Update Group Settings

Scale Color Moduleは要らないので消します。

Acceleration Force Moduleを追加します。更にAccelerationのZの値を-200にセットします。

f:id:kazuhironagai77:20210607002306p:plain

こんな感じになりました。

f:id:kazuhironagai77:20210607002322p:plain

はい。このmoduleの機能を理解するためにまた横から見てみます。

f:id:kazuhironagai77:20210607002338p:plain

重力がかかって物体が下に落ちていくのと同じですね。ぱっと見、上に登っているように見えましたが違いました。

はい解決。とはなりません。疑問が幾つかあります。

Acceleration Force Moduleですので加速度を足していると思われますが、Particle Update groupから呼ばれています。UpdateですからTickのように何回も呼び出されてるはずです。加速度を何回も足したら加加速度(jark)とか言うのになるんじゃないの?

加速度的に落下するためには、速度を足す必要があるんじゃないの?との疑問です。

これも来週考えましょう。

今週のNiagaraの勉強はここまでとします。

4.Cascadeの勉強

正直、もうCascadeの基本は理解したと思っています。それぞれのModuleのParameterで分からない所は沢山ありますが、それらの解答が簡単に見つかるとは思えません。

それで以下に示したCategory内のModuleについて勉強しようと思います。

f:id:kazuhironagai77:20210607002414p:plain

Particle System Reference [13] に詳しい解説があるはずです。

f:id:kazuhironagai77:20210607002432p:plain

Default Required and Spawn Modules [14]から見て行きます。

先週、調べていたUse Local Spaceについての解説もバッチしありました。

f:id:kazuhironagai77:20210607002451p:plain

なんで先週、突然公式のDocumentを見る事を忘れてしまったんでしょうね。

ただここで言っているIts parentが何を指しているのかが今一分かりません。このEmitterを持つParticle Systemの事なのかそれとも…。

流石にこれを上から読んで全部理解出来るとは思えません。

良い事思いつきました。Content ExampleのEffectのサンプルを開いてそのEmitter内で使用されているModuleを調べる事にします。

<CPU and GPU particles

f:id:kazuhironagai77:20210607002513p:plain

以下の様な実装になっています。

f:id:kazuhironagai77:20210607002536p:plain

Const Acceleration Moduleから見て行きます。

Acceleration Modules [15] によると

f:id:kazuhironagai77:20210607002553p:plain

と書かれています。何でCPU_particlesに使用されているんでしょう?

Vector Coneとはどんな速度を表しているんでしょうか?

f:id:kazuhironagai77:20210607002610p:plain

Velocity Modules [16] によると

f:id:kazuhironagai77:20210607002631p:plain

となっています。

成程、試してみます。

以下に示したEffectを作成しました。

f:id:kazuhironagai77:20210607002651p:plain

これにVelocity Coneを追加します。

f:id:kazuhironagai77:20210607002708p:plain

Velocity Coneの設定は以下の様にしました。

f:id:kazuhironagai77:20210607002732p:plain

Angle はDocumentによると0から1の間の値で設定しろとあります。のでMin 0、Max 1 で試してみました。

全然コーン状に広がっていないじゃん。と言うのが正直な感想です。

そしたらDocumentのVelocity の項目が以下の様な説明になっていました。

f:id:kazuhironagai77:20210607002750p:plain

と言う事はVelocityの値をもっと大きくすればコーン状になるはずです。

f:id:kazuhironagai77:20210607002806p:plain

なっていますね。

設定は以下の様にしました。

f:id:kazuhironagai77:20210607002824p:plain

コーンらしさを見るためにParticleの数を増やしてみました。

f:id:kazuhironagai77:20210607002843p:plain

確かに円錐(Cone)です。

Direction についてです。

以下の設定でテストします。

f:id:kazuhironagai77:20210607002913p:plain

f:id:kazuhironagai77:20210607002920p:plain

X軸に沿って広がる傾向が強いです。

今度は以下の設定に変えます。

f:id:kazuhironagai77:20210607002937p:plain

f:id:kazuhironagai77:20210607002946p:plain

今度はY軸に沿って広がっています。

大体、Cone Velocityの使用方法について理解出来ました。

サンプルの例だと、

f:id:kazuhironagai77:20210607003002p:plain

のような円錐を作成するのにCone Velocityは使用されていますね。

このサンプルの最後のModuleはInitial Locationです。

Initial Locationを使用する必要ないでしょうと思っていたら、GPUとCPUのEmitterの位置をずらすために使用されていました。

f:id:kazuhironagai77:20210607003022p:plain

それなら納得です。

こんな感じで勉強していけば、ほとんどのCascadeのModuleの機能と使い方について理解出来ると思います。この勉強をしばらく続けてみようと思います。

5.Cascade と魔法陣について

以下の様に変化する魔法陣を作成してみました。

f:id:kazuhironagai77:20210607003051p:plain

f:id:kazuhironagai77:20210607003058p:plain

f:id:kazuhironagai77:20210607003105p:plain

魔法陣自体はEmitterとModuleの機能を理解したら、作成方法自体は単純なので簡単に改良出来ました。

正し、以下に示した魔法陣がLandscapeにめり込んでしまう問題を直す事は出来ません。

f:id:kazuhironagai77:20210607003125p:plain

これを直すには、Decalを使用する必要があるそうです。Effectを勉強している最中に更にMaterialの勉強を始めると大変な混乱をする事になります。ので上記の問題はしばらくの間放置しておきます。

6.Monster Zoneの拡張

以下のNav Mesh Bound Volume にMonster Zoneを作成していきます。

f:id:kazuhironagai77:20210607003200p:plain

6.1 Monster Zone 3の作成

Trigger Box を2つ作成し、Block3 とTrigger3と名付けます。Nav Mesh Bound Volume の名前をTerriotory3に変更します。最後にMonster Zoneを追加して名前をMonster Zone 3とします。

f:id:kazuhironagai77:20210607003222p:plain

取りあえず、Monster を静的に配置します。

f:id:kazuhironagai77:20210607003251p:plain

以下のようになっていました。

f:id:kazuhironagai77:20210607003312p:plain

Monsterを動的に生成するためにMonster Spawn DataをRPG Game Instance BPに作成します。

f:id:kazuhironagai77:20210607003337p:plain

この配列に先程、静的に配置したMonsterのデータを写します。

f:id:kazuhironagai77:20210607003356p:plain

このData TableからMonsterを生成するようにします。

Monster Zone ActorのGet Monster Spawn Data関数をMonster Territory Number が3だった場合にも対応できるようにします。

f:id:kazuhironagai77:20210607003414p:plain

f:id:kazuhironagai77:20210607003422p:plain

これでMonster Zone 3のMonster は動的に生成されるはずです。

Monster Zone 3のMonster が倒された時にMonster Spawn Data Landscape 4-3のデータを書き変えるようにしましょう。

RPGGameBaseBPのRemove Defeated Monster関数にMonster Territory Number が3だった場合の対応を実装させました。

f:id:kazuhironagai77:20210607003447p:plain

これでMonster Zone 3 でMonsterと戦闘しても問題ないはずです。

テストします。

Block3に侵入しました。

f:id:kazuhironagai77:20210607003505p:plain

Monsterが生成されています。

次にBlock3から退散してみます。

f:id:kazuhironagai77:20210607003522p:plain

Monsterは全部破壊消滅しましたが、コメントにMonster Territory 1がCleanになりました。とあります。多分、Print Stringだけの問題とおもいますが一応確認します。

f:id:kazuhironagai77:20210607003542p:plain

そうでした。

セリフを直します。

f:id:kazuhironagai77:20210607003600p:plain

直しました。

今度は戦闘をしてみます。

戦闘から戻ってきたらMonsterが生成されません。

f:id:kazuhironagai77:20210607003618p:plain

直します。

問題が中々分からなかったんですが、分かりました。

以下の図で示した赤い部分はBlock3内部ですが、Trigger3の外です。極まれにこの部分にいても極端に端を歩いているモンスターと戦闘になる事があります。

f:id:kazuhironagai77:20210607003635p:plain

その時、Monster Territory Numberは0のままです。当然、戦闘から戻って来てもMonster Zone 3のモンスターは生成されませんし、戦闘で倒したMonster Zone 3のモンスターも消滅しません。

このバグはBlockが重なった時に発生するバグを直す時に一緒に直します。直し方のアイデアは既にあります。それを実行するだけで両方のバグを一遍に直せるはずです。

試しに、Trigger 3 の内部に侵入した後でMonsterと戦ってみました。

戦闘後は、普通にMonster が生成しています。

f:id:kazuhironagai77:20210607003652p:plain

全部のモンスターを倒してみました。

f:id:kazuhironagai77:20210607003711p:plain

特にバグは発生しませんでした。

7.Monster Zone のまとめなど

Monster Zoneを3つ作成しました。同じ物を繰り返す作成するのは楽ですが、潜在する問題やバグに築かずに進んでしまう可能性もあります。それらを避ける為に、一端ここでまとめる事にします。

7.1 発見されているバグ

今の所2つのバグが見つかっています。

<バグ1>

以下の図に示した条件の矢印の場所にPlayerの操作するキャラがいます。

f:id:kazuhironagai77:20210607003755p:plain

Playerの操作するキャラは、Monster Block 1内とMonster Block 2内に同時に存在しているのでMonster Zone 1のモンスターとMonster Zone 2のモンスターが発生します。

ただし、このキャラはMonster Territory 1 内にだけいるので、Monster Territory Numberは1と記録されます。戦闘になるのはMonster Block 1内のモンスターだけです。

モンスターと戦闘して元の位置に戻って来たとします。Monster Territory Numberは1と記録されているので、Monster Block 1内のモンスターだけが発生していてMonster Zone 2 のMonster は発生しません。

この場合、Playerの操作するキャラは、Monster zone 2をモンスターと戦闘する事なく進行する事が出来ます。

<バグ2

Block内に侵入していますが。Territory内には侵入していない時。理論的には戦闘になりませんが、現実はまれに戦闘になる事があります。

以下の図で示した赤い部分に、Playerの操作するキャラが居た場合です。

f:id:kazuhironagai77:20210607003820p:plain

この赤い箇所で戦闘になった場合、Monster Territory Numberは0のままなので、戦闘から戻って来てもMonster は生成されません。

7.2 発見されているバグの対策方法について

対策方法のアイデアは既にあります。Monster Territory Number以外にMonster Block Number と言う整数のArrayをRPG Game Instance BP内に作成する事です。そして戦闘後、このMapに戻って来た時は、生成するMonsterはMonster Territory NumberからではなくMonster Block Numberから生成すれば良いです。

7.3 全部のモンスターと戦闘してみる

Monster Zoneの全てのモンスターを生成させて戦闘した事はありません。バグが見つかるかもしれませんし、何か改良点が見つかるかもしれません。

久しぶりにStart画面からやって見ます。

f:id:kazuhironagai77:20210607003855p:plain

雰囲気は良いんですが、建物や家具に使用している素材がStarter kitの物なのでFantasy感が薄いです。

「新しく始める」をクリックします。

Map1に移動しました。

f:id:kazuhironagai77:20210607003919p:plain

因みにMap1には昼と夜があります。Good Skyで作成しました。

f:id:kazuhironagai77:20210607003936p:plain

ここからLandscape4にワープして戦闘をします。戦闘をしますが、今のままだでMonsterと戦闘すると負けてしまいます。武器を装備させます。

武器屋で武器を買い装備しました。

f:id:kazuhironagai77:20210607003953p:plain

ワープします。

f:id:kazuhironagai77:20210607004012p:plain

ワープしてLandscape4に移動したら、直ぐに戦闘になりました。以下のスクリーンショットは戦闘後に取った物です。

f:id:kazuhironagai77:20210607004030p:plain

戦闘画面でモンスターを倒した時ですが、Levelが上がっているにも関わらず、一言で終わっています。

f:id:kazuhironagai77:20210607004049p:plain

読み逃してしまっています。

Levelが上がった時は勝利ポーズを変更して、もっと細かい情報を報告するようにします。

後、monsterがアイテムを落とす場合も作成します。勿論後でですが。

崖に近づくと、Monsterが発生しました。

f:id:kazuhironagai77:20210607004109p:plain

崖があるのでMonsterと戦闘にはなりませんが、緊張感が生まれます。

Monsterを倒すために崖を遠回りして進行していると、大量のモンスターが発生しました。

f:id:kazuhironagai77:20210607004143p:plain

全滅させます。

LevelがMaxまで上昇してしまったので戦闘が終了してもStatusが回復しません。一端Map1に帰ります。

宿屋に泊まります。

f:id:kazuhironagai77:20210607004327p:plain

道具屋で回復薬とイーサーを買います。

f:id:kazuhironagai77:20210607004344p:plain

回復薬のイメージの絵だけ異常にレベルが高いですね。

f:id:kazuhironagai77:20210607004406p:plain

戦闘中に魔法を使用する時です。

f:id:kazuhironagai77:20210607004424p:plain

戦闘中にアイテムを使用する時です。

f:id:kazuhironagai77:20210607004442p:plain

ボタンが何故か小さくなっています。

戦闘が終わってHPを回復させようとしたらMHPが分かりません。

f:id:kazuhironagai77:20210607004500p:plain

戦闘しまくって島の端までやって来ました。海と島が見えます。見えますが殺風景です。

f:id:kazuhironagai77:20210607004534p:plain

その後、何体かのモンスターを倒したら、とうとうモンスターが居なくなりました。

f:id:kazuhironagai77:20210607004555p:plain

7.4 全部のモンスターと対戦してみて

「7.3 全部のモンスターと戦闘してみる。」で述べた以外の感想を以下に記します。

  • 途中から凄い退屈になった。戦闘しても勝てるのが分かっているから作業感が半端じゃない。
  • 戦闘画面に移る時に、後ろからモンスターに襲われるときと、自分からモンスターの後ろを襲うとき、は普通の戦闘と同じ始まり方で良いのかと思った。
  • もっと戦闘にメリハリが欲しくなった。途中までは戦闘も楽しかったが、戦闘しても勝てるのが分かっているからつまらなくなる。
  • 一端倒したモンスターが絶対復活しないので帰りは楽だった。
  • バグらしいバグはなかった。のでその点は良かった。
  • 地面が明かる過ぎると思いました。

8.まとめと感想

今週は以下の事について勉強しました。

  • Unreal Engine 5について
  • Niagara Ribbon Emitterについて
  • Cascade Vector Cone Moduleについて
  • Monster zoneの追加
  • Monster zone のバグ出し
  • Monster zone の問題点について

来週は、以下の事についてやります。

  • Niagara Cascadeについて
  • Monster Zoneの改良について
  • Monster Zone の更なる作成

以上です。

9.参照(Reference

[1] L, S. & tsa. (2021, May 26). Unreal Engine 5 is now in Early Access for developers – download the Valley of the Ancients tech demo. Tsa. https://www.thesixthaxis.com/2021/05/26/unreal-engine-5-demo-valley-of-the-ancients-download-requirements-100gb/

[2] Epic Games. (n.d.). Unreal Engine 5 - Unreal Engine. Unreal Engine 5 - Unreal Engine. Retrieved June 6, 2021, from https://www.unrealengine.com/en-US/unreal-engine-5

[3] Unreal Sensei. (2021, May 27). Why Unreal Engine 5 is a BIG DEAL [Video]. YouTube. https://www.youtube.com/watch?v=HM1IZnRzVGQ

[4] Tech Art Aid. (2016, November 7). UE4 Optimization: Instancing [Video]. YouTube. https://www.youtube.com/watch?v=oMIbV2rQO4k&t

[5] Tech Art Aid. (2021a, May 27). Testing UE5 Lumen Real Time Lighting & Limitations // Unreal Engine 5.0 Early Access [Video]. YouTube. https://www.youtube.com/watch?v=OqDIkQWOyDk

[6] Tech Art Aid. (2021b, May 27). Testing UE5 Nanite Meshes & Limitations // Unreal Engine 5.0 Early Access [Video]. YouTube. https://www.youtube.com/watch?v=X6hbxOyDZWk

[7] Two Minute Papers. (2009, August 31). Two Minute Papers [Video]. YouTube. https://www.youtube.com/c/K%C3%A1rolyZsolnai/featured

[8] MR3D-Dev. (2021b, May 27). Unreal Engine 5 First Impressions [Video]. YouTube. https://www.youtube.com/watch?v=6uBmdLOMTK0

[9] MR3D-Dev. (2021a, May 27). How to Use Data Layers in Unreal Engine 5 (Dark Realm Access) [Video]. YouTube. https://www.youtube.com/watch?v=4O4t0BXcuwE

[10] CGHOW. (2021, May 26). Unreal Engine 5 Early Access | First Reaction [Video]. YouTube. https://www.youtube.com/watch?v=wELlkE0vI-c

[11] Epic Games. (2021, June 6). Create a Ribbon Effect in Niagara [Video]. Unreal Engine Documentation. https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/HowTo/RibbonEffect/

[12] Torus. (2021, May 26). In Wikipedia. https://en.wikipedia.org/wiki/Torus

[13] Epic Games. (n.d.-c). Particle System Reference. Unreal Engine Documentation. Retrieved June 6, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/

[14] Epic Games. (n.d.-b). Default Required and Spawn Modules. Unreal Engine Documentation. Retrieved June 6, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Required/

[15] Epic Games. (n.d.-a). Acceleration Modules. Unreal Engine Documentation. Retrieved June 6, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Acceleration/

[16] Epic Games. (n.d.-e). Velocity Modules. Unreal Engine Documentation. Retrieved June 6, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Velocity/

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

f:id:kazuhironagai77:20210530223811p:plain

<前文>

最近、Minimal Pairのアプリを作成している関係で、独学ですが音声学について勉強する機会が多くなっています。その関係で、日本語の音声学についてのかなり質の高い解説が見つかったりします。

例えば、私は2020-12-20のブログで日本語の「う」の発音がVowel Chartの分類において正しくないのではないのか?と述べています。

f:id:kazuhironagai77:20210530223850p:plain

そしたら、複数の日本語の音声学を解説したサイトで日本語の「う」の音は人によって、あるいは関西と関東で違うと書かれていました。

本当はここからそのサイトで解説されていた言語学、特に日本語の文法についての私見について述べようと思って、実際一回書いたのですが、千に一つかもしれませんが、日本人について日本語で批評する話は、自分の望まない炎上が起きる可能性がある事に気が付きました。ので全部消しました。だから今週の前文はなしです。

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

<本文>

1.今週の予定

今週は以下の事についてやっていきます。

  • NiagaraCascadeの勉強の続き
  • Monster Zoneのテストの続き
  • Instance EditableとUE4C++おけるEditDefaultsOnly、EditInstanceOnlyとEditAnywhereの関係についての確認
  • Particle systemの勉強方法について
  • On Actor End Overlapから退散する時に戦闘中か、そうでないかについての確認方法は、Monster Name in FightingがNoneでない事で確認した方が効率が良い件について
  • Monsterを倒した後で、DataTableの設定を変える時のコードの変更
  • 魔法陣の直し

うーん。取りあえずやっていきますか。

2.Niagaraの勉強

先週、花火を作ろうと決めたのですが、試しに作成したら何か違うものが出来ました。

f:id:kazuhironagai77:20210530224003p:plain

それで花火のサイトを調べました。そしたら凄く詳しく花火について解説されていて、これは本格的に勉強しないと分からないなと思いました。

でもそのためにNiagaraの勉強を中断する訳にもいかないので、

f:id:kazuhironagai77:20210530224025p:plain

Audio Effects In Niagara [1]とCreate a Ribbon Effect in Niagara [2]を今週は勉強します。その後で花火についての勉強をします。

1.1 Audio Effects In Niagara [1]を勉強する

<Using the Play Audio Module

one-shot sound effectならPlay Audio Moduleを追加すべきとあります。One-shot soundってどんな音なのと調べたらLoopしない音の総称だそうです。

Content Examples Projectにサンプルがあります。と書かれていたので見てみます。

f:id:kazuhironagai77:20210530224058p:plain

すっごい色んな音がします。想像の10倍くらい凄いです。

Ctrl+Eを押して該当するNiagara Systemを開きます。

Play Audio Moduleがありました。

f:id:kazuhironagai77:20210530224128p:plain

Play Audio Moduleを選択してDetailをみると、まだ実験中と書かれていますね。

f:id:kazuhironagai77:20210530224145p:plain

使い方としてはModuleとして足すだけのようです。

この方法で音を出す場合は、Volume やPitch、そして音の場所は例えParticleが動いても変える事は出来ないそうです。

最も簡単ですが最も融通が効かないやり方だそうです。

<Using the Play Persistent Audio Module

Persistent の名称から推測するに、それぞれのParticleのIDをKeep出来る様にしておいて、それぞれのparticleにアクセス出来るようにしていると思われますがどうでしょうか?

f:id:kazuhironagai77:20210530224211p:plain

惜しい。

発生したそれぞれの音に対してのIDをKeepしているそうです。

それぞれの音のIDをkeepしているので、音のPitchやvolumeをPlay中に変更出来るのがPlay Audio Moduleとの違いだそうです。

ただし、その使い方のPlay Audio Moduleより難しくなるそうです。

Play Persistent Audio Module とUpdate Persistent Audio Moduleの二つを使用する必要があります。

Content Examples Projectのサンプルを見ると以下の様になっていました。

f:id:kazuhironagai77:20210530224231p:plain

このDocumentの説明によれば全てのPersistent Audio Module のAudio Playerは同じaudio player data interfaceである必要があるそうです。

Content Examples Projectのサンプルも同じ名前になっています。

f:id:kazuhironagai77:20210530224252p:plain

ただこのAudio Playerの実際のDataがどこにあるのかは分かりません。

分かりました。

Emitter Spawnにありました。

f:id:kazuhironagai77:20210530224311p:plain

中身は以下の様なParameterがありました。

f:id:kazuhironagai77:20210530224326p:plain

このDocumentで使用されている図と比較すると少し違います。

f:id:kazuhironagai77:20210530224347p:plain

しかも公式のDocumentではそれをDouble Clickすると以下の様なBPが開けるとあります。

f:id:kazuhironagai77:20210530224406p:plain

うーん。このNiagara SystemにおけるBPは使用してみたいです。みたいですがこのDocumentを読むだけでこれを使用出来る様になるのは無理そうですね。

1.2 UE4 - Niagara Audio - Part 1 - Play Audio [3]を勉強する

はい。困った時はYouTube先生に頼ります。Niagara のAudioに関するTutorialありました。しかもgameDev Outpostの作成したTutorialです。信頼出来ます。

UE4 - Niagara Audio - Part 1 - Play Audio [3]を勉強します。

Niagara Emitter -> New Emitter from Template -> Emptyで新しいEmitterを作成します。

f:id:kazuhironagai77:20210530224429p:plain

あれ。NE_と普通に名付けています。

2021-05-10のブログや

f:id:kazuhironagai77:20210530224448p:plain

2021-05-17のブログで

f:id:kazuhironagai77:20210530224539p:plain

gameDev OutpostはNiagara systemもNiagara EmitterもNS_で名付けている。と書き込んでいましたが間違っていました。実際はNiagara Emitterのprefixの場合はNE_を使用していました。普通に考えればこんなきちんとしたTutorialを作成する人(組織?)が別のクラスに同じprefixを使用する訳ないですね。

Emitter Update CategoryにSpawn Burst Instantaneous Moduleを追加しました。

f:id:kazuhironagai77:20210530224603p:plain

この辺は別にPlay Audio moduleの使い方とは関係ないですが、復習も兼ねてしっかりやる事にします。

以下の様になりました。

f:id:kazuhironagai77:20210530224621p:plain

追加したModuleを下に示します。

f:id:kazuhironagai77:20210530224640p:plain

Particle SpawnにPlay Audioを追加しました。

f:id:kazuhironagai77:20210530224659p:plain

ここからが本番です。

<Play Audio Explanation

この動画の1:48からPlay Audio ExplanationとしてPlay AudioのそれぞれのParameterの機能について簡単に説明しています。

f:id:kazuhironagai77:20210530224723p:plain

サラッと説明していますが、これって凄い大事な内容なんじゃないでしょうか?

その中で、他ではあまり聞けない所だけここにまとめました。

f:id:kazuhironagai77:20210530224743p:plain

Concurrencyは最適化のために使用します。最適化をしない時は何もセットしなくて良いみたいです。

f:id:kazuhironagai77:20210530224804p:plain

どんな条件の時に、このPlay Audioにセットされた音をPlayするかを決める所だそうです。

今はそのものズバリPlay Audioがセットされていますが、Play Audioがセットされた時はどんな条件なんでしょうか?このParameterを使いこなすためには、もう少し情報が必要です。

f:id:kazuhironagai77:20210530224856p:plain

一つのParticleに対して一回だけ音をPlayするかどうかだそうです。

f:id:kazuhironagai77:20210530224916p:plain

音の発生する位置を指定するParameterだそうです。この設定だとParticleの位置から発生します。

f:id:kazuhironagai77:20210530224938p:plain

どのCoordinateを使用するかを決定します。

f:id:kazuhironagai77:20210530225008p:plain

WorldとLocalは分かりますがSimulationはどんな座標系なんでしょう?

f:id:kazuhironagai77:20210530225027p:plain

Pitch、Volume、Start Timeの値を設定します。

ここまでがParameterの解説でした。大変勉強になりました。

また実際の作成に戻ります。

f:id:kazuhironagai77:20210530225046p:plain

Sound To Playに音をセットしました。TutorialではCompile Start Cueをセットしていますが、万が一このProjectでCompileする事があると紛らわしくなるので別な音を付けました。

今度はどんな音がしてるのかの確認をします。

しかし、音は実際にLevelに配置しないと聞こえないそうです。なのでNSをこのEmitterから作成します。ちゃんとPrefixはNS_としました。

f:id:kazuhironagai77:20210530225107p:plain

それをLevel上に配置します。

f:id:kazuhironagai77:20210530225138p:plain

音しません。

Play状態でも確認しましたが音しません。

f:id:kazuhironagai77:20210530225200p:plain

はい。Tutorialでしっかり説明されていました。

Play AudioはDefaultではFalseにセットされているため、音を発生するためにはそれをTrueに変える必要があるのだそうです。

Niagara Emitterを開きます。

Window->ParameterでParametersを表示させます。

f:id:kazuhironagai77:20210530225217p:plain

f:id:kazuhironagai77:20210530225224p:plain

->Particle Attributeを開くとplay Audioがあります。

f:id:kazuhironagai77:20210530225245p:plain

CursorをPlay Audioに乗せるとPlay AudioはBoolean型と表示されます。

f:id:kazuhironagai77:20210530225302p:plain

これを使用します。

DragしてPlay Audioの上に配置します。

YouTubeというか動画は、こういう時本当に便利です。文章だけでどんな風にDragするのかを説明するのは非常に難しいですが映像を見せれば一発で理解出来ます。

f:id:kazuhironagai77:20210530225321p:plain

Set Particle Play Audio を選択するとBoolean型のParameterがありました。

f:id:kazuhironagai77:20210530225337p:plain

Trueにしました。

f:id:kazuhironagai77:20210530225355p:plain

凄い音がしています。

最後にCollisionした時に音が出る様にします。

これは結果だけ載せようとしたら、結構重要な内容を教えていましたのでやっぱり全部記録します。

Collisionした時に音を出すためには、まずCollision moduleが必要です。

f:id:kazuhironagai77:20210530225419p:plain

Particle Update CategoryにCollision moduleを追加しました。

Play Audio ModuleのParameterであるPlay AudioにCollision 関連のParameterをセットするためには、

f:id:kazuhironagai77:20210530225453p:plain

Play Audio ModuleをCollision Moduleの下にセットする必要があります。

f:id:kazuhironagai77:20210530225511p:plain

しました。

今度は、PlayAudioにCollisionValidをセットします。

f:id:kazuhironagai77:20210530225528p:plain

Set Particle PlayAudio をTrueに戻すのも忘れずに行います。

f:id:kazuhironagai77:20210530225554p:plain

テストします。

Particleが地面にぶつかった時に音が一回だけ鳴りました。

f:id:kazuhironagai77:20210530225621p:plain

Particleが地面にぶつかるたびに音が鳴るようにします。

Play Audio ModuleのPlay Once Per Particleのチェックを外します。

f:id:kazuhironagai77:20210530225638p:plain

地面にぶつかる度に音がするようになりました。

f:id:kazuhironagai77:20210530225655p:plain

以上でした。

Play Audio Moduleについてかなり色々分かって来ました。

<Play Persistent Audio Module について>

UE4 - Niagara Audio - Part 2 - Play Audio Continued [4]でPlay Persistent Audio Moduleの分かり易い使い方を教えてもらえると思っていたら、このTutorialもPlay Audio Moduleの使い方についてでした。流石に今の私のレベルでサンプルコードから正しいPlay Persistent Audio Moduleの使い方を判明させるのは無理です。

それで、分かるところだけ自分で試してみようと思います。

まずBPの開き方です。

f:id:kazuhironagai77:20210530225721p:plain

これModuleだったら何でも開けます。

試しにPlay Persistent Audioをdouble Clickしてみます。

f:id:kazuhironagai77:20210530225741p:plain

以下のBPの実装が開きました。

f:id:kazuhironagai77:20210530225802p:plain

2021-04-26 のブログでNiagara Key Concepts [5]の4つの原則について勉強しました。その一つを以下に示しました。

f:id:kazuhironagai77:20210530225838p:plain

この内のStack Paradigmは以下に示したようないつものヤツなので

f:id:kazuhironagai77:20210530225905p:plain

見慣れてはいます。しかしもう一方のGraph Paradigmは見た事ないので、実際に自分で触る日は来ないんじゃないのかなと思っていました。

そしたらModuleをdouble ClickするだけでGraph Paradigmにaccess出来る事が分かってなんか拍子抜けです。

今度は、Play Audio ModuleをPlay Persistent Audioに変えてみました。

f:id:kazuhironagai77:20210530225927p:plain

Update Persistent Audioを使用しなくても音は聞こえますね。音を途中で変化させる時だけUpdate Persistent Audioが必要なんでしょうか?

Play Persistent Audioのparameterは以下の様になっていました。

f:id:kazuhironagai77:20210530230009p:plain

所が、Content ExampleのPlay Persistent AudioはAudioの部分がないです。

f:id:kazuhironagai77:20210530230028p:plain

やっぱりまだ理解出来ませんね。この辺で止めておきます。

流石に、Create a Ribbon Effect in Niagara [2]を勉強する時間はありません。これは来週勉強します。

2. 花火について

先週、花火を作ろうとして何か微妙に違う物が出来ました。その理由は花火をよく知らないからだと思い、花火について解説したサイトで勉強しました。その勉強した内容をここにまとめます。

ここで述べる花火は打ち上げ花火限定です。更に日本の花火についてだけです。

ハッキリ言ってアメリカの花火は繊細さがないです。音と火薬の匂いは凄いですが。芸術的な観点なら断然日本の方が上でしょう。

2.1 菊花火と牡丹花火

私がイメージした花火は以下の様に点が四方八方に飛び散るものでしたが、

f:id:kazuhironagai77:20210530230110p:plain

実際の花火は以下の様な線状の火花が飛び散るものでした。

f:id:kazuhironagai77:20210530230129p:plain

成程、これが違うのかと思ったら、花火のサイトを読んだら、私がイメージした花火もあって種類が違うそうです。

まず、花火が球状になるものを割物と呼ぶそうです。その中で火花が尾を引くタイプはそれが菊の花びらに似ている事から菊物、火花が尾を引かない物を牡丹物と呼ぶそうです。

球状じゃない花火もいっぱいありますがそれらの名称もあるんですか?とか菊、牡丹以外の種類もあるんですか?と調べてたら一気に時間を取られてしまいました。

別に花火についてのBlogではないのでそれらは後でまとめて簡潔な形にした状態で記録します。

2.2 花火とUE4

日本の花火は繊細でとても美しく、更に日本の情緒を表しています。

アニメやゲームのような新興の日本文化だけでなく、浮世絵や日本刀のような伝統的な日本文化も世界中で大人気です。それがいつまで続くのかは分かりませんが、はっきり言って今はバブル状態です。

しかし何故か今まで日本の花火は世界から注目を浴びて来ませんでした。でもこれから注目される可能性はかなり高いと思われます。

そしてCGで、日本の花火の美しさ、儚さ、繊細さを表現出来るのは、現状UE4だけでしょう。

ひょっとするとですが、Niagara Systemで日本の花火を作るのはとんでもないビジネスチャンスが埋まっているかもしれません。

3. Cascadeの勉強の続き

3.1 先週の勉強の続き

先週はSpawn ModuleのSpawn内のParameterの機能について勉強しました。

f:id:kazuhironagai77:20210530230223p:plain

今週はBurstについて勉強します。

3.2 Burstについて

まずいじって見ます。SpawnのDistributionをFloat ConstantにしてConstantを0にします。

f:id:kazuhironagai77:20210530230300p:plain

何も発生しなくなりました。

f:id:kazuhironagai77:20210530230322p:plain

今度はBurstのBurst List にElementを追加します。

f:id:kazuhironagai77:20210530230340p:plain

まだ何も発生しません。

Countの値を1にしてみます。

f:id:kazuhironagai77:20210530230358p:plain

お、発生しています。

f:id:kazuhironagai77:20210530230417p:plain

見にくいのでUnlitに変更しました。更にCountに100を代入しました。

f:id:kazuhironagai77:20210530230435p:plain

それではBurstのparameterの意味について検討してみます。

まずBurstとSpawnの違いですが、Bustは一辺にSpawnしてその後Intervalがあります。

f:id:kazuhironagai77:20210530230504p:plain

f:id:kazuhironagai77:20210530230512p:plain

Spawnは、Intervalがありません。後、一辺に沢山のparticleがSpawnする事もありません。

f:id:kazuhironagai77:20210530230533p:plain

SpawnとBurstを同時にやってみます。

f:id:kazuhironagai77:20210530230550p:plain

黄色がBurstです。Timeを0.96にする事でBurstにIntervalが在る事をはっきり分かるようにしています。

f:id:kazuhironagai77:20210530230618p:plain

水色がSpawnです。以下の条件にセットしました。

f:id:kazuhironagai77:20210530230644p:plain

こんな感じに成りました。

f:id:kazuhironagai77:20210530230659p:plain

遠くから見るとこんな感じです。

f:id:kazuhironagai77:20210530230716p:plain

うーん。今の時点では見た目は大きく変わらないですね。

公式のDocumentのDefault Required and Spawn Modules [6]を参考にしながらBurstのParameterの機能を調べます。

f:id:kazuhironagai77:20210530230735p:plain

InstantとInterpolatedの二つがあります。

f:id:kazuhironagai77:20210530230751p:plain

Default Required and Spawn Modules [6]には以下のように書かれていました。

f:id:kazuhironagai77:20210530230809p:plain

どっちでも関係ないのかもしれませんね。

次にBurst Listの要素のParameterであるCount、Count Low、Timeについてです。

f:id:kazuhironagai77:20210530230842p:plain

公式のDocumentの説明です。

f:id:kazuhironagai77:20210530230935p:plain

Countには最大値、Count Lowに最小値を入れる事でRandomな数Particleが生成されるようです。EmitterのLife time云々は良く分からないですが、TimeはBurstするIntervalを示しているはずです。

以下の条件で試してみます。

f:id:kazuhironagai77:20210530231009p:plain

生成されるParticleの数が、1,2,3,1になっています。

f:id:kazuhironagai77:20210530231026p:plain

生成されるParticleの数の範囲は[count low , count]になっていそうです。

Timeを0.01に変えました。

f:id:kazuhironagai77:20210530231043p:plain

0.95の場合です。

f:id:kazuhironagai77:20210530231101p:plain

変わっていませんね。良く分からないです。

Burst ScaleはSpawn のRate Scaleと一緒でしょう。ただ数字を変えているだけみたいです。

f:id:kazuhironagai77:20210530231117p:plain

試してみます。Constantの値を5にしました。

f:id:kazuhironagai77:20210530231207p:plain

5倍に増えていそうですね。

f:id:kazuhironagai77:20210530231223p:plain

Process Burst Listについてです。

f:id:kazuhironagai77:20210530231240p:plain

公式のDocumentの説明です。

f:id:kazuhironagai77:20210530231257p:plain

Process Spawn Rateと同じ機能ですね。

一応Burstについての機能もこれで分かりました。

4. 魔法陣の直し

もう少しCascadeの勉強をしたいですが、勉強だけに限られた時間を費やす訳にもいかないので、折衷案として魔法陣の直しをやる事にします。

f:id:kazuhironagai77:20210530231329p:plain

それぞれのemitterが保持するModuleの設定から見てみます。

f:id:kazuhironagai77:20210530231346p:plain

2番目のParticle Emitterのチェックをクリックして2番目のParticle Emitterを表示出来なくしました。

f:id:kazuhironagai77:20210530231402p:plain

以下のようなイメージになっています。

f:id:kazuhironagai77:20210530231417p:plain

随分緑色ですね。

それぞれのModuleを見て行きます。

まず、Lock Axis Moduleです。

f:id:kazuhironagai77:20210530231434p:plain

Z軸に固定されています。

f:id:kazuhironagai77:20210530231451p:plain

この意味全然分からなかったんですが、Spriteを勉強し直したら一発で理解できました。

Spriteの場合、particleに貼りつけたMaterialは常にCameraに対して正面を向くようになります。しかし時にはMaterialの向く方向は常に一定であってほしい場合もあります。この魔法陣の場合もそうです。

それを強制するmoduleがLock Axis Moduleだったんです。

うーん。

なんで最初からそう教えてくれないの?

一応、確認だけはしておきます。

サラのParticle Systemを作成します。

見やすいように以下の様な改良をしました。

f:id:kazuhironagai77:20210530231510p:plain

Lock Axis Moduleを追加してLock Axis FlagsにZ軸をセットします。

f:id:kazuhironagai77:20210530231527p:plain

f:id:kazuhironagai77:20210530231535p:plain

以下の様になりました。

f:id:kazuhironagai77:20210530231551p:plain

Materialの向きがカメラではなくZ軸に沿って向くようになりました。

やっぱり合っています

最後に公式のDocumentも確認しておきます。Orientation Modules [7]を見ると

f:id:kazuhironagai77:20210530231624p:plain

やっぱりそう書かれています。

次にSpawnを見ようとしたらその上にRequiredが在る事を忘れていました。

f:id:kazuhironagai77:20210530231644p:plain

勿論、無視して進むのもアリですが、先程のLock Axis Moduleの例の様に、Spriteが常にmaterialの向きをカメラに対して正面にしている事を知らないと、何をやっているのか意味不明になる場合もあります。つまり順序を違えて勉強しても無駄に終わる可能性が高いです。

うーん。しょうがないです。

Required ModuleのParameterを勉強します。

公式のDocumentはDefault Required and Spawn Modules [8] です。このサイトを参考にしながら勉強します。

f:id:kazuhironagai77:20210530231704p:plain

最初のこの3つは流石に知っています。Spriteに使用するMaterialとそのSpriteの発生位置並びに発生する角度の指定です。

Screen Alignmentです。

f:id:kazuhironagai77:20210530231721p:plain

文字通り解釈するなら画面に対してどの様に整列するかです。

Cursorを被せると以下のような解説が出て来ます。

f:id:kazuhironagai77:20210530231737p:plain

公式のDocumentでは以下の説明がありました。同じではないですね。

f:id:kazuhironagai77:20210530231757p:plain

でも言っている内容は大体同じですね。

やっぱりカメラに対してどの向きでMaterialを並べるかについて指定するParameterですね。

一応、読んで全く意味が分からない事はないですね。本当に分かっているのかはそれぞれの条件でテストする必要があります。でも今回そこまでやる必要はない気もしているのでここまでとします。

f:id:kazuhironagai77:20210530231817p:plain

この二つは先程のパラメーター、Screen Alignment でPSA_FacingCameraDistanceBlendを選択した場合に使用するパラメーターでしょう。

f:id:kazuhironagai77:20210530231837p:plain

Cursorを乗せたらそう解説されていました。

f:id:kazuhironagai77:20210530231856p:plain

Local Spaceを使用するかどうかを指定するparameterである事は分かりますが、別にWorld Coordinate を使用したって何も変わらない気がします。

でも確か魔法陣のTutorial、Magic Aura Effect - Particle System - [UE4 Tutorial] [9]でLocal Spaceを使用しないと駄目な理由を何処かで説明していた気がします。

見直して見ました。6:04辺りでLocal Spaceについて説明しています。

Local Spaceを使用するとParticle Systemの周りでImageを動かす時、Lagが生じないと言ってるみたいです。ただimageと言っていないでEmitterと言っているかもしれません。分かりませんね。

それでですね。

今、魔法陣のTutorial、Magic Aura Effect - Particle System - [UE4 Tutorial] [9]を見直したら、かなりの部分の説明の意味がすんなり理解出来るようになりました。

もう一回、Magic Aura Effect - Particle System - [UE4 Tutorial] [9]を作成し直した方がParticle systemの理解が進むような気がします。ので来週それをする事にしました。

今週はここまでとします。

5. Monster Zoneのテストの続き

先週、なんとかMonster Zone Actorを作成しましたがテストは不十分な状態で終わってしまいました。

f:id:kazuhironagai77:20210530231938p:plain

f:id:kazuhironagai77:20210530231948p:plain

今週は色々テストしてみます。

と思ったんですが、何をテストしたかったのかもう忘れてしまいました。先週のBlogを読んだんですがそこまでは詳しく記録していませんでした。

戦闘したり、Blockに侵入したり退散したりを繰り返したんですが、特に問題はありませんでした。

5.1 Monster Zoneのサイズを変える

それでMonster Zone2のサイズを変えて見ました。

f:id:kazuhironagai77:20210530232011p:plain

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

Block2に侵入したらMonsterが2体現れました。結構、ドキっとしました。

f:id:kazuhironagai77:20210530232029p:plain

2体のモンスターを倒してLandscape4に戻って来ましたが特に問題も起きませんでした。

f:id:kazuhironagai77:20210530232048p:plain

もっとモンスターを増やしてみます。

f:id:kazuhironagai77:20210530232116p:plain

以下の様な感じになりました。

f:id:kazuhironagai77:20210530232136p:plain

戦闘してみます。

全部倒しました。

f:id:kazuhironagai77:20210530232158p:plain

結構大変でした。

魔法の炎(小)を使用してMonsterを倒した時、カメラの位置が少し変な気がします。これは後で直します。

5.2 Block 1をMonster Zone 1に変更する。

以下の部分がBlock1でその中にあるNav Mesh Bound Volume がTerritory 1です。更にそのterritory 1と同じサイズのTriggerがTrigger1です。

f:id:kazuhironagai77:20210530232231p:plain

これをMonster Zone 1で置き換えます。

Landscape4のBPにあるBlock1やTrigger1のEventが発動しないようにします。

f:id:kazuhironagai77:20210530232248p:plain

戦闘から戻って来た時もLandscape4のBP からMonsterの生成は行わない様にします。

f:id:kazuhironagai77:20210530232308p:plain

今度はMonster Zoneを追加します。このMonster Zoneの名前はMonster Zone 1です。

f:id:kazuhironagai77:20210530232326p:plain

Block1、MonsterZone1などを追加します。

f:id:kazuhironagai77:20210530232346p:plain

Get Monster Spawn Data()関数を直します。

f:id:kazuhironagai77:20210530232404p:plain

以下の様に直しました。

f:id:kazuhironagai77:20210530232420p:plain

これでMonsterが発生するはずです。

テストしてみます。

f:id:kazuhironagai77:20210530232438p:plain

しています。戦闘なども試してみます。

戦闘は出来ましたが、バグが2つ発生しました。最初のバグは戻って来た時にモンスターが生成されません。次のバグはもう一度Monster Zone 1に侵入した時に倒したモンスターが復活していました。

確認のためにもう一度戦闘をしたら今度はバグは発生しませんでした。

f:id:kazuhironagai77:20210530232506p:plain

良く分からないです。

5.3 Monster Zoneのバグについて

そう言えば、以下の状態で戦闘から帰ってきた場合、playerの操作するキャラが居ないTerritoryにはMonsterが発生しないバグがありました。

f:id:kazuhironagai77:20210530232537p:plain

このバグの直し方のアイデアは既にあります。が下の全てのTerritoryをMonster Zoneで置き換えてから直します。

f:id:kazuhironagai77:20210530232556p:plain

6. Instance EditableUE4C++おけるEditDefaultsOnlyEditInstanceOnlyEditAnywhereの関係についての確認

先週、「7.Blue Printにおける変数についてのテスト」でBPの変数はPrivateの状態でもそれぞれのInstanceで別な値が取れる事が分かりました。前にUE4C++のEditDefaultsOnly、EditInstanceOnlyとEditAnywhereとBPのInstance Editableの関係についてまとめましたが間違っていました。のでここでもう一度検討して訂正したいと思います。

2020-10-11のブログに以下の様に書いています。

f:id:kazuhironagai77:20210530232630p:plain

うーん。これだけ読むと間違った事は言ってはいませんね。ここで私が述べているのは、

  • PublicにするとそれぞれのInstanceで初期値を別々にセット出来る。
  • 解説でもそれぞれのInstanceで編集可能

と言っているだけです。これと私が勘違いしていたPublicにしなくてもBPの変数はそれぞれのInstance毎に別な値を取れる事とは関係ないです。私が勘違いしていたPublicにしなくてもBPの変数はそれぞれのInstance毎に別な値を取れる事を加味しても、Publicにしなければ、それぞれのInstanceで初期値を別々にセットは出来ません。更にUE4の解説で私の主張は支持されています。「それぞれのInstanceで編集可能」と言っていますから。

ただその後で以下のような事を言っています。

f:id:kazuhironagai77:20210530232704p:plain

あれ。これも間違ってはいないですよね。

私が間違っていたのは、Privateにした時のBP変数の値が全てのInstanceで同じだと思っていた事です。一種のGlobal変数になると思っていました。これは間違っています。だからと言って私が上記で述べているBPの変数をPublicにする事はUE4C++でUPropertyのSpecifierのEditAnywhereと同じであるという主張との直接の関連はありませんから。

やっぱり理論的に物事を推し進めていると一個間違いが見つかってもそれで全部駄目になる事はないですね。かえって自説の強化につながる位ですね。

自分でやった事なのでこれ以上褒める事はしませんが、他人の業績でこんな結果になったら尊敬します。大変な成果です。

7. Particle systemの勉強方法について

Particle system、Cascade でもNiagaraでもどっちでも良いですが、明らかに正しい勉強手順があります。

それとParticle systemの勉強の最初で、本当にProgrammingが出来るDesigner、つまりTechnical artistでも勉強すれば使用できるようになるのかの問題があります。

今の所、私が勉強した範囲では、8割はTechnical artistでも出来るのかなという気がしています。それ以上はどうなんでしょうか?それはまだ分かりません。

今回のParticle systemの勉強方法に関しては、Technical artistでも出来る内容に関しての勉強方法についてです。

先週のblog

f:id:kazuhironagai77:20210530232738p:plain

と述べました。これが100%正しいのか現時点では分かりませんが、私自身はこれ以外の方法で勉強しても実際に自分でEffectを作成してみて、となったら何にも出来ない事態になる気がしています。逆に言えばこの方法で勉強すればProgramming が出来る、つまりBPは扱えるDesignerならば普通にVisual Effectの作成が出来る気がしています。

今週のCascadeの勉強でLock Axis Moduleについて勉強しました。「4. 魔法陣の直し」で詳しく述べていますが、3D GraphicsにおけるSpriteの仕組みを理解しないとLock Axis Moduleの機能も理解出来ません。

そしてSpriteの仕組みを理解するためにはParticle Systemについての理解が必要になります。

こんなの最初からその順番で教えてくれたら2時間もあれば理解出来ますよ。勿論、頭の良さには個人差がありますからBPの扱えるdesignerレベルの方ならと言う限定付きですが。

8. On Actor End Overlapから退散する時に戦闘中か、そうでないかについての確認方法は、Monster Name in FightingNoneでない事で確認した方が効率が良い件について

一体何を言っているのか全く分からないので、先週のblogを読み直してみたら思い出しました。

別なLevelに移動する場合でもTrigger box内にいる時は、On Actor End Overlap (Trigger) eventが呼ばれます。不思議なのは、逆は起きません。Player の操作するキャラが新しいLevelに移動して、その結果、あるTrigger box内で生成されてもOn Actor Begin Overlap (Trigger) eventは呼ばれません。

そのため、戦闘画面に移動する時に、On Actor End Overlap (Trigger) eventが呼ばれる時とそれ以外の、単にTrigger box1から退散した時にOn Actor End Overlap (Trigger) eventが呼ばれる時は別な対応が要求されます。

その判別をするのに、Monster ZoneのTrigerでは以下の黄色の枠で囲ったコードで判別しています。

f:id:kazuhironagai77:20210530232814p:plain

Monster ZoneのBlockでは特に判別はしていなくて戦闘画面に移動する時はIs Valid 関数でエラーにならないようにしているだけです。

f:id:kazuhironagai77:20210530232834p:plain

これをMonster Name in FightingがNoneでない事で確認した方が実装が楽になるのではないかと言う事です。

試してみます。

以下の様に変更しました。

f:id:kazuhironagai77:20210530232900p:plain

Play Animation nodeがエラーを発しているのは戦闘画面に移動した時にすでにMonster BP Actorが消去されているからです。戦闘画面に移動する時にはBranch以降のコードは実行しなければ問題起きないはずです。

何度か戦闘して問題ないみたいと結論づけようとしたらエラーが沢山出ていました。

f:id:kazuhironagai77:20210530232925p:plain

うーん。なんで?

Monster Zone 2のBlock内に侵入、退散を繰り返して見ました。

つまり以下のBranchの黄色の条件で試しました。

f:id:kazuhironagai77:20210530232943p:plain

何回やってもErrorは出ません。

あ。Monsterの名前がNoneのままでした。

直します。

あれ、名前ありました。

f:id:kazuhironagai77:20210530233001p:plain

色々試したら、このPlay Animation nodeがerrorを出す時は、Blockに侵入、退散を何回も繰り返しやる時に起きる事が判明しました。

ので、Is Valid?関数は戻しました。最終的には以下の様に成りました。

f:id:kazuhironagai77:20210530233020p:plain

BranchでMonster Name in FightingがNoneでない事は確認しているので、戦闘画面への移行が、少しだけ早くなっているはずです。それ以外は前と同じです。

一応テストしてみます。

Block2に侵入したり退散したりを何回も繰り返して見ました。

f:id:kazuhironagai77:20210530233040p:plain

Errorは起きませんでした。

以上です。

9. Monsterを倒した後で、Data Tableの設定を変える時のコードの変更

以下の部分に当たります。

確かに整理した方が見易いです。ですがこれが既に関数、Remove Monster From Landscape 4()内の実装なんです。敢えて直す必要があるのかちょっと悩んでいます。今週はもう時間もないですしちょっと止めておきます。

f:id:kazuhironagai77:20210530233111p:plain

もうTerritory 1ではなくMonster Zone 1なのでそこは直します。

10.まとめと感想

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

  • NiagaraCascadeの勉強
  • 花火について
  • Cascade と魔法陣について
  • Monster Zoneの拡張
  • 先週のバグの直しなど

です。来週は、今週の作業の続きをやって行きます。

今週はUE5が公開されてそっちに気が取られてしまいあんまり集中出来ませんでした。まあそういう時もありますね。

私のPCのVideo CardではRay Tracingも出来ないし、その他のスペック的にもUE5を使用するのは厳しそうです。UE5を使用する事になったら新しいPCを購入する事しかなさそうですが、現在のvideo cardの値段では新しいPCを購入する気には全然なれません。ので私がUE5に参入するのは早くても来年以降になりそうです。その間はUE5の動画を見て満足する事にします。

11 . 参考文献(Reference

[1] Epic Games. (n.d.-a). Audio Effects in Niagara. Unreal Engine Documentation. Retrieved May 30, 2012, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/HowTo/AudioEffects/index.html

[2] Epic Games. (n.d.-b). Create a Ribbon Effect in Niagara. Unreal Engine Documentation. Retrieved May 30, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/HowTo/RibbonEffect/index.html

[3] gameDev Outpost. (2021a, March 9). UE4 - Niagara Audio - Part 1 - Play Audio [Video]. YouTube. https://www.youtube.com/watch?v=zANHydk1J60

[4] gameDev Outpost. (2021b, March 11). UE4 - Niagara Audio - Part 2 - Play Audio Continued [Video]. YouTube. https://www.youtube.com/watch?v=f02hUUcCLGY

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

[6] Epic Games. (n.d.-c). Default Required and Spawn Modules. Unreal Engine Documentation. Retrieved May 30, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Required/index.html

[7] Epic Games. (n.d.-f). Orientation Modules. Unreal Engine Documentation. Retrieved May 30, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Orientation/

[8] Epic Games. (n.d.-d). Default Required and Spawn Modules. Unreal Engine Documentation. Retrieved May 30, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Required/

[9] UnrealCG. (2017, July 19). Magic Aura Effect - Particle System - [UE4 Tutorial] [Video]. YouTube. https://www.youtube.com/watch?v=PEb7ujDkP44&list=PLnfzvYOawOqArAASPfH5rOErJNnLkk7Fw&index=5

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する Monster Zoneの作成

f:id:kazuhironagai77:20210524004026p:plain

<前文>
パレスチナ空爆とSavage
アメリカで生活していると、結構、ユダヤ系の人と仲良しになる事は多いです。ただし、傾向としては積極的にはユダヤ系とは名乗らない人が多かったです。アメリカのクリスマスって日本の正月とほぼ同じで、みんな家で過ごすんですが、その時に家に帰らないので、ユダヤ系なのかと分かったりします。
そういうわけで、今回のイスラエルによるパレスチナ空爆みたいなニュースを、アメリカ人の友人と話題にする事は、非常にSensitiveで腫物を扱うような対応が必要になります。
単純に「イスラエル悪い」と言っていると、ユダヤ系の友人といつの間にか縁遠くなったりします。ユダヤ系の人は本当に絶妙な消え方をします。
だからと言って「イスラエル正しい」と、アクロバティックな擁護をすると、イスラエルの政策に批判的なユダヤ系のアメリカ人も、実は多くて、そのタイプだった場合、激高させてしまったりします。
本当なら触れないで過ごしたい話題ですが、これだけ大きなニュースになると触れない事もある種の意思表示になってしまいます。
そこでSavageの出番です。
野蛮と言う意味ですが、あまり非難的なニュアンスやネガティブな意味は無い気がします。アニメだとDragon ballベジータとか、進撃の巨人のリヴァイとかがよくSavageと言われています。Badassに近いニュアンスがある気がします。Badassは危ない奴と言う意味と、格好いい奴という二つの意味があって、オラついている感じの人を後腐れなく表現する時に使用出来てこれまた便利な単語です。ただし、今回のような国際問題について語る時に、おケツと言うのはちょっと問題ですのでSavageの方が相応しいと思います。
イスラエルはSavage。」位の感想なら、ニュースで見たままの感想なので、相手がどのタイプでも、縁を切られたり、激高される事はないと思われます。
それでは今週の勉強を始めます。

<本文>
1.今週の予定

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

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

2.Niagaraの勉強

もうちょっとだけVFXの勉強をします。
ただし、そろそろ手段が目的化し始めているので、目的をはっきりさせます。つまりこれ以上は勉強する必要がないラインを極めておきます。
「自分でVFXを作る。」
ハッキリ言うと最初からこれが目的でした。別にNiagaraでもCascadeでもどっちでも良いんですが、Tutorialをみてそのまま作成するのではなく、自分で最初から作成出来るように勉強を始めたんです。
何を作りますか?
花火。
花火を作ります。
これを目的に勉強します。
期限も決めます。7月までに完成させます。
花火を作成する事を踏まえて何を勉強するか今から決めます。

f:id:kazuhironagai77:20210524004434p:plain

Sprite Particleを使用するのかMesh Particleを使用すべきなのか?何を基準に決めるのでしょうか?分かりません。
Sprite Particleを使用する場合は、CPUかGPUを選ぶ必要があります。多分Eventを使用する事になるのでCPUで行きましょう。
次にParticle Lightを使用すべきかどうかですね。これは勉強しないと分かりませんね。
Beam やRibbonも必要かもしれません。

2.1 SpriteかMeshか?
UE4Niagara関連の記事でこれについて論じているサイトは見つかりませんでした。しかしVFX全般でSpriteやmeshは使用されているはず。と思い調べたらSprites vs Meshes [1] にSpriteやmeshの長所短所が説明されていました。

f:id:kazuhironagai77:20210524004649p:plain

うーん。
Spriteって2DゲームでTextureを貼る奴ですよね。
確かOpenGLでSpriteを勉強した時は、点にTextureを貼り付けた気がします。そのTextureが常にカメラの方を向いているんじゃなかったでしたっけ。この点自体は3D空間に作成したはずです。
もう忘れてしまいました。
そうだ公式のDocumentのCreate a Sprite Particle Effect in Niagara [2] を見れば何か書いてあるかも。

f:id:kazuhironagai77:20210524004754p:plain

ありました。
やっぱり、Sprite 自身は3d空間に生成され、そのSpriteにTextureがカメラに向いた状態で貼られている様です。
MeshもCreate a Mesh Particle Effect in Niagara [3] に説明があります。

f:id:kazuhironagai77:20210524004859p:plain

こっちはやっぱり単なるStatic Meshを使用しているんですね。
Spriteに比べると細部に渡って正確な表現が出来ると書かれています。
コストはどうなんでしょうか?
何となくですがSpriteの方が低コストで出来そうです。ネットを探してもこれに関する記述が見つからないので後でSpriteとMeshで全く同じEffectを作成して比較してみましょう。
機能的な違いとしてはSpriteはGPUで計算出来たり、Light particleを使用出来たりしますが、Meshはそう言う事は出来ないと言う事ですね。
ただこれだけだとSpriteを選択すべきかMeshを選択すべきかの基準は分かりません。
現状、分かる事はこれ位ですね。

2.2 Particle Light の勉強
Create a Particle Light [4] を勉強します。
最初の説明分を以下に示しておきます。

f:id:kazuhironagai77:20210524005021p:plain

この説明によるとParticleに発光する機能を追加する機能みたいですね。
ざっと全体を読むとLight Rendererを使用していますね。このDocumentではSprite RendererにLight Rendererを追加して使用していますが、Mesh Rendererの場合もLight Rendererを追加出来るのでしょうか?
更に疑問ですが、Material自体も発光出来ますよね。発光出来るMaterialを使用したparticleとはどう違うんでしょうか?
取りあえず、このDocumentをサラッとやってみて疑問点を書き出してみましょう。それからそれらの疑問点をどう解決するかを考えましょう。
以下のように出来ました。

f:id:kazuhironagai77:20210524005046p:plain

それでは疑問点を書き出していきます。
まず。Light Rendererが何をしているのかが分かりません。
以下にLight Rendererの設定を0にした場合を示します。
f:id:kazuhironagai77:20210524005109p:plain

f:id:kazuhironagai77:20210524005119p:plain

普通に光っていますよね。
今度は赤に光らせます。赤なら青とは違いLight Rendererが何をやっているのかが分かり易いはずです。

f:id:kazuhironagai77:20210524005143p:plain

うん。地面が赤くなっている。
キャラを近づけると、キャラは紫色になりました。

f:id:kazuhironagai77:20210524005205p:plain

分かりました。Light RendererはLight Actorと同じ働きを一つ一つのParticleでしているんです。
分かり易いように、全く光のないLevelを作成してこのVFXを配置します。
Light Renderの設定を0にしてみます。

f:id:kazuhironagai77:20210524005226p:plain

Particleは発光していますが、まわりの物質を照らす事はありません。地面や直ぐ側にいるThirdPersonCharacterは真っ黒なままです。
ここにLight Rendererを追加すると、まわりの物質を照らします。以下に示した例は赤だけ発光させています。

f:id:kazuhironagai77:20210524005507p:plain

f:id:kazuhironagai77:20210524005516p:plain

しかし何故紫色で発光しているんでしょうか?
どこかで青色も拾っているんでしょうね。
手に持って遊ぶ花火ならこの機能は大切です。一方で空に打ち上げられる花火の場合はこの機能は別に要らないですね。
Mesh Renderer にLight Rendererは追加出来るのでしょうか?
試してみます。

f:id:kazuhironagai77:20210524005545p:plain

何これ?
よく考えたらMesh Rendererについてキチンと勉強してませんでした。次はこれを勉強します。

2.3 Create a Mesh Particle Effect in Niagara [3] の勉強
Create a Mesh Particle Effect in Niagara [3] を勉強します。
出来ました。

f:id:kazuhironagai77:20210524005741p:plain

4.2で忘れていた事についてまとめます。
まずMaterialを追加する事を忘れていました。
MaterialはMesh RendererのOverride Materialsにチェックを入れて、かつ+を押す事でelementを追加する事で使用出来ます。

f:id:kazuhironagai77:20210524005801p:plain

次にRenderに元々あるSpriteを消す必要があります。

f:id:kazuhironagai77:20210524005822p:plain

更にParticle Spawn CategoryのInitialize Particle moduleのparameter、Sprite Attributesの値をUnsetにします。

f:id:kazuhironagai77:20210524005846p:plain

一方でMesh AttributesのParameterはUnsetから変えます。

f:id:kazuhironagai77:20210524005909p:plain

これらの手順がMesh particleを使用するために必要でした。

2.4 Mesh ParticleでLight Renderが使用出来るか試す。
このMesh ParticleでLight Rendererが使用出来るか試します。
まず2.3で作成したNSを光の全くないLevelに配置します。

f:id:kazuhironagai77:20210524005937p:plain

真っ暗です。
2.2でしたようにParticle SpawnのInitialize ParticleのColor ModeのColorのRの値を1から50に変更します。

f:id:kazuhironagai77:20210524010006p:plain

Spriteと違って発光する事はありませんでした。

f:id:kazuhironagai77:20210524010202p:plain

今度は、使用したMaterialにEmissive Colorを追加して発光させます。

f:id:kazuhironagai77:20210524010225p:plain

Particle SpawnのInitialize ParticleのColor ModeのColorと違う事を示すため緑にしました。

f:id:kazuhironagai77:20210524010250p:plain

今度は光っています。
これにLight Rendererを追加してみましょう。

f:id:kazuhironagai77:20210524010310p:plain

2.2でやったようにRadius ScaleとColor Addの値を変更します。

f:id:kazuhironagai77:20210524010332p:plain

結果です。
地面が赤くなっています。

f:id:kazuhironagai77:20210524010354p:plain

つまりLight RendererはMesh Particleと併用出来ると言う事ですね。

2.5 Mesh ParticleとSprite Particleの違いを示す。
以下の様なMaterialを作成しました。

f:id:kazuhironagai77:20210524010426p:plain

Sprite RenderingのMaterialにセットします。

f:id:kazuhironagai77:20210524010450p:plain

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

f:id:kazuhironagai77:20210524010514p:plain

これでも問題ないですが、端の黒い部分は絵を描くときに敢えて透明にしたので消したいですね。
そこだけ直します。
MaterialのBlend ModeをTranslucentにしました。

f:id:kazuhironagai77:20210524010537p:plain

f:id:kazuhironagai77:20210524010546p:plain

こんな感じになりました。

f:id:kazuhironagai77:20210524010631p:plain

Particleを見る角度を変えましたが、Materialは常にこっちを正面としています。

f:id:kazuhironagai77:20210524010655p:plain

上から見てもMaterialは正面を向いています。

f:id:kazuhironagai77:20210524010722p:plain

今度はMesh Particleを作成します。

f:id:kazuhironagai77:20210524010826p:plain

CubeにMaterialが貼られた状態でCubeがParticle として生成されています。

f:id:kazuhironagai77:20210524010847p:plain

2つを並べると違いが一目瞭然です。

f:id:kazuhironagai77:20210524010908p:plain

斜めから見た状態です。

f:id:kazuhironagai77:20210524010929p:plain

Shader Complexityも一応チェックしてみます。

f:id:kazuhironagai77:20210524010948p:plain

重なっていない部分はそんなに差がないように見えます。
1000個、Spriteを生成してみました。
FPSは4.20になりました。

f:id:kazuhironagai77:20210524011034p:plain

今度は、1000個、Meshを生成しました。
FPSは4.30でした。

f:id:kazuhironagai77:20210524011056p:plain

この結果だけではハッキリとは言えませんが、MeshとSpriteはコスト的には同じ位なのかもしれません。

2.6 ちょっとだけ花火を作成してみる。
以下に結果だけ示します。

f:id:kazuhironagai77:20210524011119p:plain

f:id:kazuhironagai77:20210524011128p:plain

f:id:kazuhironagai77:20210524011135p:plain

何か違います。

3.Cascadeの勉強

もうあんまり良いTutorialも見つからないので、何か自分で作成してみる事にします。
Particle systemを作成します。MyCascadeと名付けました。

f:id:kazuhironagai77:20210524011209p:plain

何を作るか以前に、サンプルに使用されているTextureが常にカメラに向かって正面を向いているのか分かりません。

f:id:kazuhironagai77:20210524011228p:plain

先程作成したSmileマークに変更します。
Spawn moduleのMaterialをSmile_Matに変更します。

f:id:kazuhironagai77:20210524011251p:plain

暗い。

f:id:kazuhironagai77:20210524011313p:plain

試しにBGCを明るい黄色にしてみましたが、Effect自体は真っ黒なままです。

f:id:kazuhironagai77:20210524011335p:plain

実際のPlay画面です。

f:id:kazuhironagai77:20210524011358p:plain

暗い事はないですね。
これは、Effectを作成する時はPreviewだけでなく実際のLevelに配置したEffectも見ながら作成すべし。という教訓ですね。
Unlitにしてみました。

f:id:kazuhironagai77:20210524011416p:plain

これは見やすい。
見やすいから絶対正しい訳ではないですが、これで行きます。
まず、生成されるParticleの量が多すぎますので、数を減らします。
生成されるParticleの量を管理しているのは、間違いなくSpawn moduleです。

f:id:kazuhironagai77:20210524011436p:plain

Spawn moduleを見てみます。

f:id:kazuhironagai77:20210524011453p:plain

Spawn、Burstの項がありました。
思い出して来ました。
Particleの生成方法にはSpawnとBurstの2種類があったんでした。その2つの違いが良く分からないと。前に勉強した時はそうでした。
Spawnの方の設定は以下の様に成っていました。

f:id:kazuhironagai77:20210524011520p:plain

RateのConstantが20にセットされていますが、1秒間に20個のParticleが生成されるのでしょうか?
Burstの方は、Burst Listが0ですが、この設定でもParticleの生成に、何らかの影響を与えているのでしょうか?

f:id:kazuhironagai77:20210524011558p:plain

分かりませんね。
取りあえず、SpawnのRateのConstantを5にします。

f:id:kazuhironagai77:20210524011626p:plain

生成さられるParticleの量が減りました。
今度は、SpawnのRateのConstantを1にしました。

f:id:kazuhironagai77:20210524011703p:plain

大体、1秒間に1個生成されている感じです。
そう言えば、Distributionについての詳しい説明が公式のDocumentにあったはずです。

f:id:kazuhironagai77:20210524011724p:plain

今こそそれを勉強しましょう。

3.1 Distributionの勉強
公式のDocumentのDistributions [5] を勉強します。
最初にDistributionの説明です。

f:id:kazuhironagai77:20210524011845p:plain

あれ。これParticleの勉強を始めたばかりの時に読みましたよね。あの時は五里霧中で勉強していたので何を言っているのか良く分かっていなかったです。今は違います。今、上記の文章を読むと以下の意味で言っていると分かります。
Distributionはある値を返す方法を指定します。以下の種類から選択出来ます。

  • 定数を返す。
  • 指定した2つの値の範囲からランダムな値を選び返す。
  • 指定したグラフから補間して計算した値を返す。
  • 指定したParameterから割り出した値を返す。

あれ、4つしか説明していませんね。
実際は以下に示した様に5種類あります。

f:id:kazuhironagai77:20210524011942p:plain

それは兎も角として、前回勉強した時、上記の説明で訳わからなくなったのは、シンプルにDistributionsの機能、値を返すと言う事の説明が無かったからです。その値の返し方に、4または5種類の方法があります。と説明されていれば初心者でも理解出来ました。
これは自慢じゃなくて確実に本当の事ですが、私、人に物を教えるのが滅茶苦茶、上手いです。多分、1万人に一人とかのレベルの才能があります。その私の才能が言っていますが、Distributionを説明するのに、値を返すと言うDistributionの機能を説明しなかったら誰も理解出来ないと。
今の時点で私の中でどのように初心者にParticle systemを教えるのかの最初の部分の構想が出来ています。

基礎編

  1. VFXとは何かについて(映画とCGを使用した特殊効果の関係からVFXが生まれた!)
  2. 3D GraphicsにおけるVFXの逆輸入とUE4VFX(Particle system)
  3. UE4におけるParticle system(Sprite、Emit、Moduleなど)
  4. Particleをコントロールする。(Distributionなど)
  5. 残りはこれから勉強する内容で今は不明。)

応用編

  1. 炎の作成方法
  2. 煙の作成方法
  3. 雷の作成方法
  4. 以下略

この方法で教えたら、多分、BPが使いこなせるデザイナーなら自在にParticle Effectを使いこなせるようになると思います。
ここは大切なので少し詳しく記録しておきますが、前の議論で出て来た、以下に示しているProgrammerの種類とは別な話です。

f:id:kazuhironagai77:20210524013236p:plain

といっても100%別な話ではありません。これについては後でまとめ直します。
<Distribution Baking>
以下のヤツの解説です。

f:id:kazuhironagai77:20210524013308p:plain

カーソルを乗せると以下の説明が出て来ました。

f:id:kazuhironagai77:20210524013328p:plain

FRawDistributionってなんでしょうね?この説明では兎に角、Trueにしておけと言う事みたいです。
Document に完璧な説明がしてありました。

f:id:kazuhironagai77:20210524013347p:plain

要するに、前もって計算しておいて、その結果を使用するのがCan be Bakedをチェックした場合です。
Edgeつまり端は前もって計算出来ないのでチェックを外す必要があるそうです。でも具体的にEdgeはどこを指すんでしょうね。
<Distribution Types>
FloatとVectorがあります。以上です。一応書いておきますが、Computer scienceにおけるVectorは2個以上の値を保持する場合全てを指します。物理系みたく2又3個の値に縛られる事はないです。
<Float Distributions>
Floatの場合に選択出来る、それぞれの方法についての解説です。
<<Distribution Float Constant>>
定数で返します。

f:id:kazuhironagai77:20210524013458p:plain

一番、分かり易いですね。
<<Distribution Float Uniform>>
最低値と最高値を指定します。その間の値からランダムに返します。

f:id:kazuhironagai77:20210524013536p:plain

これも分かります。1とか4とかの値がランダムに返されるだけです。
<<Distribution Float Constant Curve>>
これが分かりにくいやつ、第一弾です。これを選択するとPointsという項目が出現し、Elementを追加出来る様になります。
追加すると以下に示した様に、0、In Val、Out Val、Arrive Tangent、Leave Tangent、そしてInterp Modeの項目が出て来ます。

f:id:kazuhironagai77:20210524013641p:plain
このそれぞれの項目が何を指しているのか直観的に理解出来ません。
はい。そこで公式のDocumentの説明です。ここではCurveを以下のように定義しています。

f:id:kazuhironagai77:20210524013700p:plain

まず、1でグラフ上の2点を指定します。そして2でその間を曲線でつなぎます。曲線の引き方を指定するために3のTangent lineを使用しています。
うん。これは分かりますね。
しかし実際のParameterを見ると??となってしまいます。

f:id:kazuhironagai77:20210524013858p:plain

まず、上のグラフで1の値を示すParameterがIn ValとOut Valだそうです。In Valがx軸、Out Valがy軸の値を指しています。
でもそれだと一点しか表せないですよね。
となると色々な可能性が出て来ます。
例えば以下に示した関係が考えられます。

f:id:kazuhironagai77:20210524013920p:plain

でもこれだと最低でも要素は2個必要になるはずです。
分からんですな。
この場合、どうにかしてCurve editorに表示出来ないんでしょうか?そうすると非常に分かり易くなります。

f:id:kazuhironagai77:20210524014008p:plain

この説明みるとCurve Editorで調節出来そうですが?
もう一つ分からない箇所があります。
Tangent ですが-150から150の間となっています。

f:id:kazuhironagai77:20210524014027p:plain

これって具体的にどの角度なんでしょうか?
これも分かりませんでした。
今の所これ以上の情報がないので、Distribution Float Constant Curveに関してはここで調査は打ち切りです。
うーん。何か前も同じような事をやってここで中止したような気がします。デジャヴかも知れないですが。
ただ結局、普通の人で特別に細かい調整がしたい場合を除けば以下に示したような、

f:id:kazuhironagai77:20210524014110p:plain

①のような、直ぐに値が高くなってその後は徐々にしか値が上昇しない。②のように値はLinearで上昇する。③のように値は中々上昇しないが最後で急激な上昇をする。の3パターンの選択が出来れば十分な気がします。
<<Distribution Float Constant Curve パート2>>
本当に偶然なんですが、以下の白枠で囲ったアイコンがなんかグラフっぽいなと感じてクリックしてみました。

f:id:kazuhironagai77:20210524014148p:plain

そしたら、今まで、うんともすんとも言わなかったCurve Editorにグラフが表示されています。

f:id:kazuhironagai77:20210524014215p:plain

あれ。これ今迄の疑問が解けちゃう?
以下の様な設定にしてみました。

f:id:kazuhironagai77:20210524014238p:plain

グラフをみると

f:id:kazuhironagai77:20210524014255p:plain

出来てる。
ああっ。解ける。謎が解けます。
まず、Interp Modeの謎から解いていきます。
Point 0のInterp Modeを変えると何か影響するんでしょうか?LinearからCurve Autoに変えてみます。

f:id:kazuhironagai77:20210524014316p:plain

おお、カーブの形状が変わりました。

f:id:kazuhironagai77:20210524014336p:plain

上の図の予測は違っていましたね。要素1つまりPoint 1のIntra Mode(スペルも間違っていた。Interp modeでした)ではなく要素0のInterp modeによって変化しました。

f:id:kazuhironagai77:20210524014438p:plain

Curve Autoに変えた事でTangentの調整するためのバーも出現しました。

f:id:kazuhironagai77:20210524014508p:plain

今度はこのTangentの角度を変えてみました。

f:id:kazuhironagai77:20210524014529p:plain

あれ、Arrive TangentとLeave Tangentの両方の値が変わっています。

f:id:kazuhironagai77:20210524014559p:plain

うーん。これは?

公式の最大値である150も試してみます。

f:id:kazuhironagai77:20210524014618p:plain

こんな感じです。

f:id:kazuhironagai77:20210524014635p:plain

垂直ではないんですね。
Arrive TangentとLeave Tangentの値が同じなのは、Point 0からCurveが始まっているからかもしれないと思いPoint 0とPoint 1の間にもう一個Pointを作成してそのTangentを変化させてみました。

f:id:kazuhironagai77:20210524014656p:plain

この場合もArrive TangentとLeave Tangentの値は一緒でした。

f:id:kazuhironagai77:20210524014745p:plain

と言うかこれって微分しているだけじゃん。
あ。だからTangentなんだ。うーん。何でこんな簡単な事に今まで気が付かなかったんでしょう。
何か、Curve Editorで実際のCurveと比較できるようになったら一発で分からない事が全部分かるように成っちゃいましたね。
<<Distribution Float Uniform Curve>>
これも公式のDocumentで理論は理解できました。
以下の図の黄色の範囲からランダムな値が選ばれます。Distribution Float Uniformと違うのが範囲が時間によって変化する所です。

f:id:kazuhironagai77:20210524014826p:plain

だたし、これもそれぞれのParameterが何を言っているのか分かりません。

f:id:kazuhironagai77:20210524014853p:plain

しかしCurve Editorにグラフとして表示してみると

f:id:kazuhironagai77:20210524014910p:plain

全部分かります。
本当に拍子抜けする位簡単に全部のParameterの意味が分かります。
<<Distribution Float Particle Param>>
これは値をBPなどからコントロールする時に使用するみたいです。今回は関係ないのでパスします。
<Distributionのまとめ>
SpawnのRateに使用されているDistributionについて勉強しました。
今回の勉強で、ほぼ完全に理解する事が出来ました。その上でこれからParticle Systemを勉強する人が混乱しないように、学習に必要なポイントをここにまとめておきます。

  • Distributionは値を返す働きの事です。その上でどのように値を返すのかの選択が出来ます。
  • それぞれのDistributionのタイプの理論的な意味は、公式のDocumentであるDistributions [5]を見ると理解できます。
  • Distributionに使用するParameterの意味は、公式のDocumentであるDistributions [5]を読んでも理解出来ません。というか間違っています。正しい意味はCurve editorにCurveを表示させる事で理解出来ます。

3.2 その他の勉強した事
Distributionを調べている仮定で以下のものについても分かったので記録しておきます。
<Rate Scale>

f:id:kazuhironagai77:20210524015041p:plain

単にDistributionで返した値をRateの値に掛けているだけです。何故Rateだけで管理しないのかは分かりません。
<Process Spawn Rate

f:id:kazuhironagai77:20210524015114p:plain

Process Spawn RateがfalseだとSpawn ModuleがStackに積まれた場合、実行されなくなるそうです。

4.Block1の名称を決める。

先週、Landscape4のBlock1の設計方法の問題点や改善点について検討しました。その結果、一応考えられる問題点や、予想されるバグの解決方法などの対応策を実装する事が出来ました。

f:id:kazuhironagai77:20210524015157p:plain

しかしその後で、戦闘後、沼にワープする事があるバグを修復するに当たってBlock1とTerritory1のサイズを同じにすると、ゲームとして面白くもないし、親切でもない事が分かりました。

色々検討を重ねた結果、以下のようにTrigger boxを2個作成して、

f:id:kazuhironagai77:20210524015217p:plain

Trigger 1でモンスターの出現、Trigger2でTerritory内に侵入したと言うFlagを建てるようにしました。これで一応問題なく動いている事も確認しました。
しかし、今週改めて考えてみると、この新しく作成したBlock1、先週行った旧式のBlock1に対しての検討を行っていません。色々な問題点に対応出来るのかの検討をする必要があります。
しかし、検討する前に一つしなければならない事があります。
それは、このモンスターをSpawnするシステムの名称を考える事です。

f:id:kazuhironagai77:20210524015237p:plain

名称がなければこのような抽象的なEntityを表す事は大変難しいからです。
Area、Sanctuary、Village、House、Nestと色々考えましたがあんまりピンと来ません。
Zoneと言う名称はどうでしょうか?何かイイ感じがします。
Monster Zoneと名付ける事にしました。
Monster Zoneは以下の様な構成になっています。

f:id:kazuhironagai77:20210524015258p:plain

まず、Trigger1はBlock1と呼ばれています。この中に侵入するとMonsterが現れます。現れますが、Monsterがあなたを攻撃する事はありません。
Block1の中にはTerritoryがあります。このTerritoryは2つのComponentで構成されています。Trigger 2と Nav Mesh Bounds Volumeです。
Trigger2に侵入すると、RPG Game Instance BPのMonster Territory Number変数の数字を1に変更します。更にNav Mesh Bounds Volumeに侵入するとMonsterはあなたを攻撃してきます。
Monster Territory Number変数は、戦闘から戻って来た時に、その番号が表すTerritory内のMonsterを生成するために使用されます。

5.先週行った「モンスターの配置についての考察」の内容がこのMonster Zoneに対しても通じるのかについての検証

先週、Landscape4のBlock1の設計方法の問題点や改善点について検討した内容を見直しました。「5.モンスターの配置についての考察」、「6. モンスターの配置についての考察-その2」で考察した内容とその対策が、Monster Zoneに対しても通用するかどうかを検討します。

5.1 Trigger boxのサイズについての検討
これは、二つのMonster ZoneのTrigger 1が重なった状態でも正しく運用できるのかについてです。
<Pattern 1>Monster Zone1のBlock内にいながらMonster Zone2のBlock2に侵入した時

f:id:kazuhironagai77:20210524015409p:plain

<Pattern 2>Monster Zone1のTerritory内にいながらMonster Zone2のBlock2に侵入した時。

f:id:kazuhironagai77:20210524015521p:plain

<Pattern 3>Monster Zone1のBlock内にいながらMonster Zone2のBlockに侵入した時。

f:id:kazuhironagai77:20210524015610p:plain

これは先週のBlogの「8.2 Triggerを追加した場合の理論的考察」で既に考察されています。

5.2 Monster Territory Numberの値は常に正しく表示されるのか?
Monster Territory Numberは、数字を保持します。この数字はそれぞれのTerritoryに対応しています。戦闘後にLandscape4などの元々いたLevelに戻って来た時にこの変数に記録されている番号と対応するterritoryのモンスターが生成されます。
Pattern 1の場合、Monster Territory Number は0です。戦闘に遭遇する事はありません。ので0で正しいです。
Pattern2の場合、Territory 1に侵入しているためMonster Territory Number は1になります。戦闘後、このLevelに戻って来ますと、Territory 1のモンスターは生成されます。しかしBlock2に侵入しているのにTerritory2のモンスターは生成されません。されるべきですが。
はい。一つ目の、問題が見つかりました。
Pattern3の場合、Monster Territory Number は2です。戦闘後、このLevelに戻って来ますと、Territory 2のモンスターは生成されます。しかしBlock1に侵入しているのにTerritory1のモンスターは生成されません。
これも問題です。

5.3 Remove Defeated Monster from Landscape 4 () 関数について
これは戦闘後の話で、Monster Zoneを作成したとしても影響ないはずです。

5.4 戦闘画面に移動する場合もOn Actor End Overlap (Trigger box) が呼ばれている事について
<別なレベルに移動する時、必ずOn Actor End Overlap (Trigger box)は呼ばれるのか?呼ばれなかった場合はどうなるのか?>
はい。これが問題になるのは、戦闘に移行する時だけです。戦闘に移行する時は、Monster Zoneの場合も前となにも変わっていないはずなので同じで良いはずです。
<戦闘画面からBlock1内に戻って来た時に、On Actor Begin Overlap (Trigger box)は呼ばれるのか?呼ばれなかった場合、それぞれのParameterはどうなっているのか?>
呼ばれません。これもMonster Zoneに変更したからと言って何も変わりません。
<Block1内から移動する時、必ずMonster Name in Fighting 変数の値はNoneになっているのか?>
これも、Monster Zoneを作成しても変わらない事の一つです。Noneになっているはずです。
<Block1内から直接、Block2に移動した時はどうなるのか?>
これは、Monster zoneになった事でかなり複雑になった事の一つです。ただしこの検証は「5.2 Monster Territory Numberの値は常に正しく表示されるのか?」で既に行われています。

5.5 Territory 1に一端侵入した後に、Territory 1から逃走するとMonsterが消滅しなかった事について
これも既に検討されています。

5.6 Landscape4、Territory 1における戦闘
これも既に検討されています。

5.7 この章のまとめと感想
先週、Monsterの配置と生成で検討した内容を、もう一度Monster Zoneに対して検討する事は出来ました。ほとんどの質問は重複してたり、Monster Zoneに変わったとしても同じ結果になるものでした。
ほとんど唯一と言って良い発見したバグは、Pattern 2とPattern 3の場合、再生されるモンスターの内容が違っている事でした。

6.Monster ZoneのActor化

管理し易いようにMonster ZoneのActorを作成してみます。

6.1 Monster Zone クラスの考察
Monster Zoneをクラスとしたら何が必要か?どう作成するのが良いのかを考察します。
以下のような構成を考えています。

  • 今回はBPで試作して、それからUEC++にするかどうかを検討します。
  • Actorクラスを継承して作成します。
  • 追加するComponentは、Trigger box を2つ、Nav Mesh Bound Volumeを一つです。
  • 追加する変数は、Monster Zone Numberです。

他に必要な変数や関数があるかLandscape4をみて確認します。
<Trigger Box Blockに侵入した時>
一番外側のTrigger Box に侵入した時のEventです。Game Instance内にある指定されたDataTable通りのMonsterを生成します。

f:id:kazuhironagai77:20210524015930p:plain

実装部です。

f:id:kazuhironagai77:20210524020031p:plain

Monster CleanというBoolean 変数と、Monster Territory 1と言うMonsterBPタイプのArrayが使用されています。
<Trigger Box Blockから退散した時>
一番外側のTrigger Box から退散した時のEventです。退散の仕方は2つあり、一つは普通にBlockから脱出した場合です。二つ目は、Block内でモンスターと戦闘になり戦闘画面に飛ばされた時です。

f:id:kazuhironagai77:20210524020115p:plain

普通に退散した場合、Territoryに存在する全てのモンスターは分解・消滅のアニメーションをPlayします。
その後で、全てのモンスターはDestroy Actor関数によって消滅します。

f:id:kazuhironagai77:20210524020136p:plain

戦闘画面に飛ばされた時は、既にTerritoryに存在する全てのモンスターは消滅しているのでIsValid()関数によってアニメーションなどの実行は中止されます。
この部分で特別に使用されている変数や独自に作成された関数はありませんでした。
<Trigger Box Territoryに侵入した時>
内側のTrigger Boxに侵入した時です。RPG Game Instance BPクラスの変数、Monster Territory Numberの値を1にします。

f:id:kazuhironagai77:20210524020203p:plain

これだけです。
<Trigger Box Territoryから退散した時>
内側のTrigger Boxから退散した時です。通常に退散した時は、Monster Territory Numberの値を0に戻します。戦闘画面に移動した時はそのままです。

f:id:kazuhironagai77:20210524020228p:plain

Monster Zone クラスに必要な機能や関数、変数が大体分かりました。

6.2 Monster Zone クラスの構成
<変数>
以下の変数を作成します。
<<Monster Zone Number>>
タイプ:Int
コメント:このクラスのInstanceはそれぞれ独自の番号を持つ。RPG Game Instance BPに同じ名前の変数がある。戦闘開始時にその変数に値をパスする。
RPG Game Instance BPにある同じ名前の変数は、戦闘から戻って来た時にどのTerritoryのMonsterを生成するかと、戦闘勝利時にどのモンスター生成を管理するData Table群からどのData Tableを選択するのかを指定する働きがある。
<<Monster Clean>>
タイプ:Boolean
コメント:生成されたモンスターのActorが全て破壊されたらTrueになり、新しいMonsterが生成されるとFalseになります。
モンスターが破壊される前に新しいモンスターが生成されるのを防ぐために作成されました。
<<Monster Territory 1>>
タイプ:Monster BP(array)
コメント:生成したMonsterをassignしたarrayです。生成したmonsterを消滅し易くするために作成されました。
<関数>
使用している関数は一個だけです。
<<Spawn Monsters>>
Monsterをモンスター生成を管理するData Tableの情報を元に作成します。
以下に実装部を示します。

f:id:kazuhironagai77:20210524020346p:plain

<Event>
Eventは4種類です。
<<On Actor Begin Overlap(Block)>>
Monster を生成します。
<<On Actor End Overlap(Block)>
生成したmonsterを破壊します。
<<On Actor Begin Overlap(Territory)>
Monster Territory Numberの値を指定した値にセットします。
<<On Actor End Overlap(Territory)>>
Monster Territory Numberの値を0に戻します。

6.3 Monster Zone クラスの作成
色々、試しましたが、結構難しいです。以下の方法が他よりマシみたいです。
まずActor、Monster Zoneを作成します。

f:id:kazuhironagai77:20210524020535p:plain

正しcomponentにはなにも追加しません。

f:id:kazuhironagai77:20210524020559p:plain

その代わり変数として、BlockとTrigger、そしてTerritoryを追加します。

f:id:kazuhironagai77:20210524020625p:plain

BlockとTriggerはTrigger Boxです。TerritoryはNav Mesh Bound Volumeです。
それぞれInstance Editableにします。

f:id:kazuhironagai77:20210524020652p:plain

Level上に静的に配置されたTrigger BoxのInstance、2つとNav Mesh Bound Volumeのinstance、一つを以下にそれぞれセットします。

f:id:kazuhironagai77:20210524020716p:plain

この方法を採用する事で、以下の問題を解決できました。

  • Nav Mesh Bound Volume をBPで作成出来ない。(静的にも動的にも出来なかった。)
  • BP内でBlockとTriggerをcomponentとして追加するとそれぞれのInstanceでサイズが変更出来ない。

ベストな作成方法ではないでしょうが一応、作成するに当たって発生した問題は解決したのでこのやり方で試してみます。
更にMonster Zoneクラスに必要な変数を追加します。

f:id:kazuhironagai77:20210524020805p:plain

これらの変数はそれぞれのInstanceで値が変わります。ので

f:id:kazuhironagai77:20210524020827p:plain

にチェックを入れました。
これを入れればそれぞれのInstanceの値をバラバラに出来るのは知っていますがチェックしないと全てのInstanceで同じ値になってしまうのかどうかを忘れてしまいました。ちょっとそれを先に確認します。

7.Blue Printにおける変数についてのテスト

今までInstance Editableにチェックを入れない限り、変数の値は全てのInstanceで変化すると思っていました。

f:id:kazuhironagai77:20210524021008p:plain

最近、BPを頻繁にいじるようになってPrivateの変数でInstance毎に値を変える実装は簡単に出来る事に気が付きました。
それで、やっぱりPrivateの変数でも、それぞれのInstanceで違う値が取れるのではないのかと思いテストし直してみます。

f:id:kazuhironagai77:20210524021026p:plain

f:id:kazuhironagai77:20210524021034p:plain

以下の変数をPrivateで追加します。

f:id:kazuhironagai77:20210524021055p:plain

以下の実装をしました。

f:id:kazuhironagai77:20210524021115p:plain

Box内に侵入する毎にTest1Privateの値が1ずつ増加します。
このActorの二つのInstanceを並べました。

f:id:kazuhironagai77:20210524021155p:plain

これでテストします。

f:id:kazuhironagai77:20210524021214p:plain

5回、右のInstanceに侵入しました。Test1Private変数の値は5 になっています。
今度は左のInstanceに侵入します。

f:id:kazuhironagai77:20210524021239p:plain

Test1Private変数の値は1でした。
ああ。変数の値はそれぞれのInstanceで独立していました。UE4C++で、EditDefaultsOnly、EditInstanceOnly、とEditAnywhereの関係と

f:id:kazuhironagai77:20210524021255p:plain

は同じだとずっと思っていました。今週はもう時間がないので来週この問題をもう一度検討します。

8.Monster ZoneのActor化 : Part 2

「7.Blue Printにおける変数についてのテスト」の結果を踏まえて、Monster ZoneのActorを作って行きます。
変数のInstance editableの設定は以下のようにします。

f:id:kazuhironagai77:20210524021326p:plain

Territory、Block、TriggerそしてMonster Territory NumberはそれぞれのInstanceの値をEditorから操作する必要があるので、Instance Editableにします。Spawned MonstersとAllMonsterAreDeletedはEditorから操作する必要は全くないのでInstance Editableにはしません。
次に、いつもの変数を作成します。

f:id:kazuhironagai77:20210524021405p:plain

Eventの実装を行います。
<On Actor Begin Overlap(Block)>
最初にこのEventで使用する関数Spawned Monsterを作成します。
Spawned Monsterだと生成されたモンスターと言う意味で、間違いではないですが、この関数の機能は「モンスターを生成せよ。」の方がより実態を表していると思われるのでSpawn Monstersに変更しました。

f:id:kazuhironagai77:20210524021434p:plain

実際の実装は以下のように行いました。

f:id:kazuhironagai77:20210524021452p:plain

Monster Spawn Dataは後で作成します。
<On Actor End Overlap(Block)>
以下のように作成しました。

f:id:kazuhironagai77:20210524021517p:plain

All Monster Are Cleared変数にチェックが入っていません。
入れました。

f:id:kazuhironagai77:20210524021545p:plain

こういう細かいミスが原因で何時間もバグの修正に時間を取られるのは馬鹿らしいです。今見つかって良かったです。
<On Actor Begin Overlap(Territory)>
Monster Territory Numberをセットします。

f:id:kazuhironagai77:20210524021614p:plain

Monster Territory Numberは戦闘後にこのLevelに戻って来た時に生成するモンスター群を決定する働きも司っています。
そして「5.2 Monster Territory Numberの値は常に正しく表示されるのか?」で発見されたある条件において、生成するモンスター群が足りないバグは直していません。
このバグはMonster Zone Actorがきちんと作動する事を確認してから作成します。
<On Actor End Overlap(Territory)>
Territoryから退出した時の実装です。
やっている事は、Monster Territory Numberを0にセットしているだけです。

f:id:kazuhironagai77:20210524021651p:plain

戦闘画面に移動する時は、Monster Territory Numberを0にセットしたら意味が無くなるのでMonster Name in FightingがNoneでない事で確認しています。On Actor End Overlap(Block)でもこの方法を採用し他方が実行されるコードが少なくなる気がします。
これについても、Monster Zone Actorがきちんと作動する事を確認した後で検討します。

9.Monster Zone 2を作成する。

9.1 Monster Zone 2を作成する
「8.Monster ZoneのActor化 : Part 2」で作成したMonster Zone Actorのテストを兼ねて、Monster Zone 2を作成します。

f:id:kazuhironagai77:20210524021727p:plain

Monster Zone 2で対応しているActorは以下のモノです。

f:id:kazuhironagai77:20210524021746p:plain

f:id:kazuhironagai77:20210524021754p:plain

Monster Zoneの場所をはっきりさせるためにCubeを追加しています。
次に生成するMonsterのためのData Tableを作成します。
RPGGameInstanceBP内に以下のArrayを作成します。

f:id:kazuhironagai77:20210524021813p:plain

要素に一個だけモンスターを追加しました。

f:id:kazuhironagai77:20210524021859p:plain

作成したMonster Spawn Data をセットします。

f:id:kazuhironagai77:20210524021917p:plain

早速、バグが見つかりました。この個所を今作成したData tableに変更すると、全てのMonster Zoneで同じData Tableを使用しなければならなくなってしまいます。
それぞれのMonster ZoneのInstanceは別のData Tableを使用します。それが出来る様にコードを直します。
以下の方法で実装しました。
関数、Get Monster Spawn Data()を作成しました。

f:id:kazuhironagai77:20210524021937p:plain

Monster Territory NumberよりどのData Tableを使用するのかを指定する関数です。
この関数を使用して以下の様に実装しました。

f:id:kazuhironagai77:20210524021955p:plain

これでテストしてみます。
Block2に侵入しました。Monsterが生成されるはずです。

f:id:kazuhironagai77:20210524022013p:plain

されました。
Block2から退散しました。Monsterは分解消滅するはずです。

f:id:kazuhironagai77:20210524022031p:plain

しました。
今度はMonsterが分解消滅する前にもう一度、Block2に侵入します。

f:id:kazuhironagai77:20210524022050p:plain

Monsterが消滅してから新しいMonsterが生成されています。出来ています。

9.2 Monster Zone 2と戦闘
今度は戦闘に関してのコードを作成します。
Monster Spawn Data Landscape 4-1で調べて見ると2か所、戦闘に関連してDataTableを使用しています。

f:id:kazuhironagai77:20210524022126p:plain

最初の箇所は、戦闘終了後に、Landscape4に戻って来た時です。Trigger Box のOn Actor End Overlapは別なレベルに移動した時も発動するのに、On Actor Begin Overlapは最初からそのLevel内で生成された時は発動しません。
その問題を回避するために、Monster Territory Numberが0でない場合、つまり戦闘から帰還して生成される場所があるTrigger Box内の場合は、以下の部分で特別にMonsterを生成させています。

f:id:kazuhironagai77:20210524022331p:plain

同様の機能をMonster Zone 2に関して作成します。
正し、Monster Zoneは生成したモンスターの管理はLevel BPに任せずMonster Zone内で行っています。

f:id:kazuhironagai77:20210524022352p:plain

ので上記の機能は、Monster Zone内で作成します。
以下のように作成しました。

f:id:kazuhironagai77:20210524022411p:plain

細かい説明は省きますがこれで行けるはずです。
DataTableを使用している2番目の箇所は、戦闘後に倒したMonsterを記録する処です。
ここは全く同じ使用で、Monster Spawn Data Landscape 4-1をMonster Spawn Data Landscape 4-2に変更しただけです。

f:id:kazuhironagai77:20210524022432p:plain

以下に示した様に、DataTableだけ変更して他は全く同じ事を繰り返しています。

f:id:kazuhironagai77:20210524022450p:plain

これはもっと簡便な方法で実装出来るはずですが、今回は直しません。後で時間があるときに直します。
これでMonster Zone内で戦闘出来るはずです。テストしてみます。
戦闘のテストをするためにはMonsterの数を増やす必要があります。
一匹だけ足しました。

f:id:kazuhironagai77:20210524022509p:plain

これで試してみます。
Monsterが2体生成されています。一体だけ倒してみます。

f:id:kazuhironagai77:20210524022542p:plain

戦闘から戻って来ました。
Monsterは一体も生成されません。

f:id:kazuhironagai77:20210524022604p:plain

Monster Zone の以下の部分の設定がNoneになっていました。
直しました。

f:id:kazuhironagai77:20210524022627p:plain

もう一回テストします。

f:id:kazuhironagai77:20210524022645p:plain

今度はMonsterは一体だけ生成されました。
出来ました。
もう少しテストが必要ですが時間が無くなってしまいましたので今週はここまでとします。

10.魔法陣の改良

もう時間がないので今週は出来ません。
実際のPlay画面を見ると魔法陣が地面にめり込んで消えている部分があります。

f:id:kazuhironagai77:20210524022721p:plain

来週以降ですが、これも直します。

11.まとめと感想

今週は以下の事について勉強しました。

  • Niagaraの勉強をしました。
  • Sprite Renderer とMesh Rendererの違いについて
  • Light Rendererについて
  • 花火の作成について
  • Cascadeの勉強をしました。
  • Distributionsについて
  • Monster Zoneの作成をしました。
  • Monster Zone Classの構成
  • Monster Zone Actorの作成
  • 実際に作成したMonster Zoneのテスト

更にMonster Zoneの作成の途中で、Instance editableについて勘違いしていた部分が合った事にも気が付きました
来週は、

  • NiagaraCascadeの勉強の続き
  • Monster Zoneのテストの続き
  • Instance EditableとUE4C++おけるEditDefaultsOnly、EditInstanceOnly、とEditAnywhereの関係についての確認
  • Particle systemの勉強方法について
  • On Actor End Overlapから退散する時に戦闘中かそうでないかについての確認方法は、Monster Name in FightingがNoneでない事で確認した方が効率が良い件について
  • Monsterを倒した後で、DataTableの設定を変える時のコードの変更
  • 魔法陣の直し

などを行います。
多過ぎで直しきれない気がすでにしています。来週は直しだけでやる事にします。

12.参照(Reference)

[1] Codea Talk. (2012, July 23). Sprites vs Meshes. Codea. https://codea.io/talk/discussion/1378/sprites-vs-meshes
[2] Epic Games. (n.d.-c). Create a Sprite Particle Effect in Niagara. Unreal Engine Documentation. Retrieved May 23, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/HowTo/SpriteEffect/index.html
[3] Epic Games. (n.d.-a). Create a Mesh Particle Effect in Niagara. Unreal Engine Documentation. Retrieved May 23, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/HowTo/MeshEffect/index.html
[4] Epic Games. (n.d.-b). Create a Particle Light. Unreal Engine Documentation. Retrieved May 23, 2021, from https://docs.unrealengine.com/en-US/RenderingAndGraphics/Niagara/HowTo/ParticleLights/index.html
[5] Epic Games. (n.d.-d). Distributions. Unreal Engine Documentation. Retrieved May 23, 2021, from https://docs.unrealengine.com/en-US/Basics/Distributions/index.html

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