＜前文＞
中学生の時から本があると読まずにいられない性分だった私は立花隆氏の本をほとんど全部読んでいました。
残念だったのは立花隆氏を知ったのは渡辺昇一氏よりずっと後で、逆だったら田中角栄の裁判について10倍くらい面白く読めたと思う事です。
渡辺昇一氏の著作は一貫して白黒はっきりつける結論至上主義に対して、立花隆氏の著作は科学的な手順や思考にこそ真実があると言うスタンスで、その結果、結論が常識外れだとしてもそれはそれで受け入れるみたいな手順至上主義みたいな所がありました。
この二人が田中角栄の裁判を巡って大喧嘩したと聞いた時は「それは絶対面白いだろう。ぜひその時の事を知りたい。」と思いましたが実際に読んだらあんまり面白くなかったです。渡辺昇一氏の田中角栄の裁判に関する本はその時は既に読んでいて、立花隆氏の田中角栄氏に関する本を後から読んだんですが、正直、立花隆氏の臨死体験の面白さを10としたら1か2ぐらいしか面白くなかった記憶があります。
今は全く本を読まなくなりました。本当の理由は分かりませんが、多分ネットの発達で知識人に価値が無くなったからだと思います。
これはネットの影響を示す一例ですが、Tax havenをtax heavenと勘違いした知識人の方が居ました。直ぐにその間違いはネットに広まってしまい、その話を聞いた私はその人の話を一切信じなくなりました。一瞬でその人の知識人としてのブランドが崩壊してしまったんです。
その代りにネットの中に今まで知識人達が担当していた部分、日本人の知識欲を満たしたり、日本の針路についての助言を行う別な人達が現れました。
あいつ等は軽い！と読書好きな人からは怒られるかもしれませんが、その軽さこそがこのネット社会で生き残る秘訣だと私は思います。今のネット社会で間違いを指摘されない事は不可能です。間違いを指摘されてしどろもどろにうろたえる事が駄目であって、直せば良いんです。直したら更に良くなるだけです。彼らは自分の間違いを直す事を全く恐れません。また最初からある程度間違える事も計算していて間違えたらすぐに修正出来る様に準備しています。
そんな中で私が今一番注目しているのが元プロレスラーの前田日明氏です。彼の主張する下剋上の思想「大義があれば下剋上は正しかったし今も正しい。」はこれからの日本の未来を決める思想になる可能性があります。
彼の主張する下剋上の思想を簡単に言えば、我々はみんな日本丸に載ってる乗員ですが、船長が余りにもアホな行動をしたら船が沈んでみんな死んでします。だからそんな船長はみんなで監禁してもっとまともな人に船長になってもらう。と言う言われてみれば当たり前の考え方です。しかしこの考え方、とても悪い事のように今の我々は教わっています。これが間違っているっと前田日明氏は主張してるわけです。
戦国時代の様に明日侵略されて死ぬかもしれない時代ではアホな領主の下に付いたらすぐに死んでしまいます。そんな時代は下剋上は必要悪として当たり前だった。しかしそれは戦国時代のような特殊な時代のみに通じる常識なのか？実は下剋上はいつの時代でも通じる当たり前の事で、今の我々がそれが悪い事であると洗脳されているだけなのかもしれない。
この思想はネットで叩かれて直ぐに死んでしまうかもしれません。しかしもし5年も生き延びる事が出来れば日本の未来への活路を開くための日本人の意識転換の一歩になるかもしれない気がしています。
と言うのは「上がサボっているから俺もサボる。」と言う考えに捕らわれるとみんながサボりだし、結果的に仕事の質が指数的に落ちていくからです。製品の段階ではもう競争にならない位の低品質になってしまいます。
そして日本の大部分が今このスパイラルに陥っているように見えます。
ここで下剋上の思想が一般化すれば「上がサボっているなら俺が取って代わる。」となるから仕事の手を抜く事はありません。むしろチャンスが到来したともっと仕事を熱心に行うようになります。更に自分が仕事の手を抜くとこんどは部下に取って代わられるため今のように上がサボっているから俺もサボろうとはならないからです。
つまりその結果「上がサボっているから俺もサボる。」と言う負のスパイラルから抜け出せるようになる訳です。
それでは今週の勉強を始めます。
＜本文＞
１．今週の予定
今週は以下の事をやっていきます。
- Niagaraの勉強の続き
- Cascadeの勉強の続き
- RPGの直し
- PickUpItemクラスにItemを追加
- Monsterがアイテムを落とすようにします
- Warp Passの作成
- Landscape4にgood skyを追加
全部は無理かもしれませんがやれるだけやっていきます。
２．Niagaraの勉強
今週もRibbon Renderingについて勉強します。
2.1 Ribbon Renderingの仮説
先週、Ribbon Renderingは以下の様にRenderingしているのではないのかと説明しました。
ただしこのやり方でRibbon Renderingを説明しているTutorialはひとつもありません。世界で私だけです。ので論理的な破たんがない事をしっかり確認しておきたいです。
まずLife timeとSpawn Rateの関係で一個のRibbonしか生成されない場合です。
Ribbonは必ず長方形になります。
横軸の長さはLife TimeとRibbon Systemの先頭が移動するスピードで決定されます。
次にLife timeとSpawn Rateの値を大きくして一個以上のRibbonが生成される場合です。
この場合は存在しているRibbon全体に対して一枚のMaterialが貼られます。
以下のScreenshotの様にです。
のでLife timeとSpawn Rateの値を大きくして沢山のRibbonが生成されるようにすると以下の図の様に円周上に沿ったイメージを作成する事も出来ます。
しかしある程度の時間が経つと最初のRibbonのLife timeが尽き消滅します。しかしそれと同時に新しいRibbonも生成されます。
するとRibbon全体の長さは一定になります。
2.2 Ribbon Renderingの仮説の検証
Life timeとSpawn Rateの関係で一個のRibbon しか生成されない場合、本当に長方形のRibbonしか生成されないのか確認します。
以下の条件で試してみます。
Life Timeが0.5秒ですので一個のRibbonの寿命は0.5秒になります。
そしてSpawn Rateは1.0にセットしたので、1秒間に1個のRibbonが生成されます。
これなら一個のリボンしか生成されません。本当に長方形になるのか試してみます。
テストします。
？？？
出来ません。Ribbonが一個も生成されないです。
あれ？
色々試しましたがRibbonの寿命が次のRibbonが生成される前に尽きる場合は絶対に生成されません。
しかし以下の条件のように最初のRibbonの寿命が尽きる前に新しいRibbonが生成される場合はRibbonを見る事が出来ます。
上記の条件だとRibbonの寿命は1秒で、Ribbonは0.5秒毎に生成されます。
上記の条件だと常に2個のRibbonが生成されます。この場合だと長方形になります。
うーん。
閃きました。以下に説明します。
2.3 Ribbon Renderingの仮説の改良
Initialize Ribbon Moduleで生成されるのは幅の情報を保持するParticleだけなんです。
以下のようなイメージのParticleです。
これが一個しか生成されない時はRibbonは作れません。ので何も表示されません。
もしこれが2個以上生成される場合はそれぞれのParticleを繋いでRibbonを生成する事が出来るのでRibbonが生成されます。
以下に示した赤い部分がRibbonになります。
この考え方でもRibbonが最初はどんどん長くなるのに、ある程度の時間が過ぎるとRibbonの長さが変わらなくなるのも説明出来ます。
まずこのParticleが2個以上ある場合です。
以下の様に沢山あると仮定します。
この場合以下の様なRibbonが生成されるはずです。
一番右端のParticleのLife Timeが尽き消滅します。
しかし左端に新しいParticleが誕生します。
のでTotalの長さは同じになります。
つまりInitialize Ribbon Moduleで生成されるのは面ではなく辺だったんです。
2.4 Ribbon Renderingの新たな仮説の検証
今度の仮説は合っていると思いますが少し検証してみましょう。
Particleが３つ作られる条件でRibbonを作成してみます。
はい。
＜テスト1＞
最初のテストは横に引っ張っります。
まず観察します。
①最初に現れたRibbonです。
②直ぐにその上を覆うように横に拡張したRibbonが現れます。
③次に現れるRibbonはサイズは前のRibbonと同じですが位置が左にずれています。
これを何回も繰り返して、④左端につくと横のサイズが小さいRibbonが発生します。
⑤そして更に横幅の小さいRibbonが発生します。そしてRibbonは消滅します。
改良した仮説によると①の状態は以下の様になっていると考えられます。
2個目のParticleが生成され最初のRibbonが生成された状態です。
②の時は更にもう一個のParticleが生成されます。のでNiagara Systemが一定の速度で左に移動しているならばRibbonの横幅は大きくなります。
③の時は最初に生成されたParticleが消滅します。しかしそれと同時に新しいParticleが生成されます。
ので長さが一定で左に移動するRibbonが生成されます。
④の状態です。
左端のParticleはNiagara systemが停止したために隣のParticleに非常に近い場所で生成されています。
ので３つのParticleがある状態ですが、Ribbonは前より短くなります。
最後の⑤の状態です。
Niagara systemが停止したため新しいParticleが作成される事はありません（あるのかもしれませんが前と同じ位置で作成されるためされないのと同じ事になります）。
これによって前の④より更に短いRibbonが生成されます。勿論この後でRibbonは消滅します。
横に伸びた状態は完璧に説明出来ていますね。
＜テスト2＞
今度はNiagara Systemを回転させてみました。
①やはり最初に作成されるRibbonは長方形でした。
これは実は中々見つからなかったです。最初のRibbonから丸くなっていたらオカシイと思って徹底的にコマ送りにして探しました。そうしてやっと見つけました。
②次のRibbonが生成された時です。
かなりいびつな形をしています。
③その次のRibbonが形成された時です。
完全な扇形になっています。
④ほぼ同じ大きさの扇形で移動しつづけています。
⑤Niagara Systemの移動が終了すると扇が小さくなります。
⑥最後に長方形になって消滅します。
はい。それでは検証していきます。
先ず①の状態です。
今度は円を描くようにNiagara Systemを移動させましたのでParticleが円周上に生成されているはずです。
以下に示したのはそのポンチ絵です。
もし上図のような状態で二つのParticleがRibbonを作成すると2点でも扇型、もしくは台形型になるはずです。
しかし実際はParticleが2点の時は長方形が作成されています。
それはこのParticleはRotationの情報は持っておらず、単に2点間を結んだ線をRibbon Widthで広げたと考えると辻褄が合います。
ただし実際の計算でどんなAlgorithmが使用されているのかが分からないと実際の所は分かりませんね。その近似式を使うと2点の時は長方形、3点以上の時は扇形になるのかもしれませんし。
その近似曲線の計算方法が分からないのでこれ以上ここで追及するのは無駄な気がします。ので一端ここで中止します。
私が想像していたのは3点のParticleが生成された場合は以下のようなRibbonが生成され、
生成されるParticleが増えると以下に示した様なもっとスムーズなRibbonが生成される
と思っていましたが実際は、3点のParticleが生成された時点で
きれいな曲線を描いています。
これはRibbon を作成する段階でCatmull–Clark subdivision surfaceのようななんらかの近似曲線を使用していると言う事です。
2.5 Ribbon Renderingで作成してみる。
まあ完璧とは言えませんがかなりRibbon Renderingについて理解は深まりました。
この知識を元にオリジナルのRibbon Renderingを作成してみようと思います。
以下のイメージを使用してみます。
Materialは以下の様に組みました。
Niagara Systemの設定は
にしてみます。
うーん。文字を使用するのはどうでしょうか？
これで試してみます。
字ははっきりと読めますね。良いんじゃないでしょうか。
白色を追加した方が黒や赤がはっきり見えると思ったんですがあまり関係ないというか透明にした方が見やすそうですね。
昔の漫画の効果線の様な感じを出してみました。
横に伸ばされるので丸いほうが線が滑らかかもしれません。
これで試してみます。
今週はここまでにしますが色々なイメージを試すだけでも結構勉強になります。
３．Cascadeの勉強の続き
Intro to Cascade: Creating a Beam Emitter | 07 | v4.2 Tutorial Series | Unreal Engine [1]の続きをやっていきます。
3.1 InterpolationとSheetについて
先週、Interpolation とSheet を使用してBeamを曲げました。でもこれらのParameterの機能は調べませんでしたのでそこから始めます。
Interpolationについては直ぐに理解出来ました。
0です。
１です。
２です。
３です。
４です。
５です。
つまりTargetとSourceの2点間の間を直線で繋ぐのに何個の頂点を追加するかを示してます。
公式のDocumentであるBeam Type Data [2]によると
と書かれています。
成程、SourceやTargetで示したTangent、つまり傾きを満たす最大限の角度を
正確に表すためには
の数が多ければ多い程良い訳ですね。
ただしDistributionのConstantのZの値が具体的に何を表しているのかは分かりませんね。
角度を表しているなら45度を代入したら円になるはずですよね。
しかし実際は明らかに楕円形をしています。
Sheetについてですが、公式のBeam Type Data [2]によると
と書かれています。
まずSheetが具体的に何を指しているんでしょうか？
恐らくですがMaterialを貼り付ける面の事をSheetと呼んでいるんでしょう。
例えばNiagaraのRibbonの場合なら以下に示した図なら赤い部分がSheetに当たり、
SpriteならParticleに貼りつけるMaterialを表示するための面がSheetになると思われます。
Beamの場合はSheetをTargetとSourceの間に作成してその上にBeamのMaterialを貼っていると仮定すると上の公式の説明がなんとなく理解出来ます。
Beamを上から眺めてSheetの数によってBeamの見た目が変化するかを見てみます。
0の時です。
0なら何も表示されないのではと思いまいしたがBeamが表示されています。なんででしょう？
１です。
0と変わってないですね。
良く見ると真ん中で捻じれていますね。そのせいで途中から裏側が映し出されています。裏側にはなにも表示されていないので透明になっているんですね。
２です。
真ん中に5本の筋がみえるようになりました。Sheetが一枚足されたのでしょう。ただしこの角度からは新しく足されたSheetに貼られたBeamの絵を見る事は出来ませんね。
３です。
両端にひし形のイメージが追加され更に真ん中の線が左右対称の複雑な形状に変化しました。
ただしこの視点からみてBeamのイメージで消えている部分が見えるように成る事はありませんでした。
順調にSheetの数は増えていると考えられます。
4です。
少しだけRibbonの消えている部分に絵が描かれるようになりました。
5です。
あんまり変わっていないですね。
6です。
イメージの見えていなかった部分のBeamがかなりはっきり見える様になりました。
10です。
ほぼ左右対称になりました。
まあ、全部が理解出来た訳ではありませんが、Sheetの枚数はBeamがどの角度から見ても消える箇所がないようにするまで増やす。と考えるべきでしょうね。
BeamをLevel上に配置したら色々な角度から観察してもしBeamの一部が消えているならばSheetの数が足りないと言う事です。
3.2 BeamのRenderingについての考察
具体的にどうやってBeamをRenderingしているのかがまだ良く分かっていません。ずっと分からないままかもしれません。
BeamのRenderingでよく分からないのが、以下のイメージです。
このRibbonを中心として180度カメラを回します。今、手前に来ているリボンの付け根の部分に注目して下さい。
180度、このRibbonを中心にしてカメラを回しました。
本来なら前のRibbonに隠れて見えないはずの部分が見えています。遠近感が滅茶苦茶です。
もしParticleを飛ばし、その上に板を貼ってその板を繋げたモノをSheetと名付けて、そのSheetの上に絵を描いているだけならこんな破たんは起きないと思われます。どうやって実際のRenderingが行われているのは現状では全く不明です。
はい。Smileちゃんの出番です。
Sheetは１にセットしています。
これを見ると一枚の大きなSheetがSourceとTargetを両端として作成されているようにです。
今度は真横から見てみます。
例え真横から見ても前半分はカメラ側を向いて後ろ半分はカメラの反対側を向いています。
逆向きになっても同じです。
所が上から見ると、今度は逆になっています。奥半分のSheetがカメラ側を向いて手前の半分のSheetはカメラの反対側を向いています。
かなり強引な構図ですが真下から見てみました。
真下から見た時は、前半分はカメラ側を向いて後ろ半分はカメラの反対側を向いています。普通です。
以下にカメラをBeamの上に移動した時のSheetの変化を示します。
分かりました。
根元の部分に注目して下さい。Sourceから一番最初のInterpolateまでの面は常にカメラに向かって正面を向いています。それ以外のSheetはその面の捻じれにつられて面がカメラに向いたり、カメラの逆側を向いたりしています。
では、Sheetが2枚になったらどうでしょうか？
Sheetがお互いに90度に交わるように重なっています。勿論、Sheetの数は2枚になっています。
ああ、分かった。
Beam Type Data [2]で言っていた事の意味が分かりました。
Sheetが一枚の時は以下の様に単に一枚のSheetが作成されます。
Sheetが2枚の時は以下のようにお互いに垂直に交わるように作成されます。
ここからは想像ですが、Sheetの数が3になったらお互いが60度の角度を保つように生成されるはずです。
試してみます。
大体60度っぽい角度で3つのSheetが交差しています。
別な角度で見てみました。どう見ても60度でしょう。
はい。Sheetについても完璧に理解出来ました。
それでですね。
奥にある部分が手前にRenderingされてしまう理由ですが、
分かりません。
どっかのParameterを弄ったら直るのかもしれませんし、もしかしたらバグかもしれませんね。
でもこれだけ分かれば十分です。
3.3 Intro to Cascade: Creating a Beam Emitter | 07 | v4.2 Tutorial Series | Unreal Engine [1]の続きをやる
ここまで理解出来ればBeamに関しては十分ですが、せっかくですのでこのTutorialは終わらせる事にします。
Beam categoryのNoise Moduleを追加します。
Noise ModuleのLow Freq Enabledにチェックを入れ、Frequencyを10にセットします。
このModuleは何を管理しているんでしょうか？
PreviewのBeamのイメージが以下の様になりました。
Noise RangeのDistributionの設定を以下のように変えると
以下に示した様にBeamの形状が微妙に変化し始めました。
Beam Data ModuleのMax Beam Countの値を3にセットします。
Beamの数が3本に見える様になりました。しかし実際に撮影すると1本しか見えません。
後は一個を除いて特に重要なポイントはなかったです。
のでBeam Data ModuleのMax Beam Countを少しだけ調べる事にしました。
Beam Type Data [2]には
と書かれています。
でもBeamだってSpawn RateとLife Timeで生成される数は決まるはずです。
その辺の関係を見てみます。
うーん。色々数字を弄って見たんですが良く分からないです。
最後の重要なポイントに行きます。
3.4 Distribution Float Particle Paramの具体的な使用方法について
このTutorialの最後にTargetの位置をBPやUEC++から指定出来ると言っていました。
そしてその具体的なやり方は前のUE4C++のTutorialで実際に紹介してあると言いました。
これって2021-05-24のブログで勉強した中で唯一、具体的な方法が分からなかったDistribution Float Particle Paramの使用方法についての説明の事じゃないでしょうか？
流石に今週はこれ以上Cascadeの勉強をする時間はないので来週調べる事にします。
４．PickUpItemクラスにItemを追加
4.1 Dropped Item Baseクラスにitemを追加する
最初にDropped Item BaseクラスがItemを表示出来るようにします。
その為には以下の関数にItem名とそのItemのMeshを追加する必要があります。
追加するItemはData Table、Itemsで管理されている以下の３つです。
以下の部分を追加しました。
テストします。
以下の設定にしました。
角度やサイズに不満がありますがちゃんと回復薬が表示されています。
イーサーの場合です。
ダークイーサーの場合です。
サイズと向きを直します。
Return Static Mesh Of Items関数に位置、回転、サイズなどのTransform情報を追加します。
武器とItemで別なTransform情報を与えるようにしました。
テストします。
とりあえずはOKでしょう。
4.2 Itemを拾えるようにする。
PickUpItemウィジェットを改良してItemも拾えるようにします。
以下にWidgetのイメージを示します。右端の落とし物の絵と属性は武器・防具専用のモノですのでこれをItem専用に直し必要があります。これは後で直します。
今回は、Itemを拾う部分の実装を追加します。
Get Data Table Row Weaponsを追加します。Data TableはItemsをセットします。
ここでItemの名前が正しいのかをチェックしています。
ItemsのData Tableは以下の様になっています。
次にRPGGameInstanceのArrayであるItemsに拾ったItemの名前を追加します。
ItemsはUE4C++のRPGGameInstanceクラスの変数です。
この辺のPlayerの操作するCharacterのDataを管理する変数は最終的には全部UE4C++側のGame Instanceクラスで管理すべきなんでしょうか？
やっぱり最近のゲームはこれらのデータは全部サーバーで管理しているんでしょうか？
正直、サーバー関連のProgrammingはあんまり興味がないんです。いや興味はあるんですがUE4ほどの興味は無いです。のであんまり勉強が進みません。
ただAWSにしてもFire baseにしてもお金はかかるはずでEpic Game社が提供しているサーバーは無料ですから、この辺に詳しくなったら結構なビジネスチャンスがあるのではとは思っています。
次は拾ったItemをLevel上から消すための関数です。
実装部が以下の様になっているんですがItem Nameが何のための変数だったのか忘れてしまいました。
RPGGameInstanceBPにあるItemSpawnDataの実際の要素を見ると
Nameには武器の日本語名、ItemNameには武器の英語名が記されています。
しかし武器のdata tableである Weaponsには
英語名はないんです。
あ、分かりました。
その武器の種類じゃなくてその武器そのものを示す名前がないとその武器だけをLevel上から消せなかったです。Item Nameはその武器個別の名前でした。
と言う事は
は武器の場合もItemの場合も同じであると考えれます。
となると残りのコードはWeaponのがそのまま使用出来ると考えられます。
これでどうでしょうか？
テストしてみます。
RPGGameInstanceBPのArrayであるItemSpawnDataに
回復薬のデータを追加します。
これで試してみます。
回復薬が地面に出現しました。
Eボタンを押すと以下の画面が表示されました。
このWidgetはこの後で直します。
「拾う」を押します。
Itemが消えました。
Pause画面を開きます。
道具袋の中に先程拾ったItemである回復薬がしっかり入っていました。
成功ですね。
4.3 PickUpItem ウィジェットのHUDを直す
以下に示した様に表示されるようにしました。
変更したのは以下の部分にBindしている関数です。
やり方は全部一緒でItemの場合の表示のためのコードを武器とは別に追加しただけです。
出来ました。
PickUpItemの直しは今週、一番大変な部分と思っていたんですが、結果的に凄い簡単に出来ました。
やっぱりこれは先週、調べるだけ調べておいたお陰です。理由は分かりませんが、直す箇所を調べるだけ調べておいて、1週間置いてから直すと凄く楽に直せるようになります。
調べて直ぐ直すのに必要な能力を知力:10、精神力:10、体力:4とすると調べるだけ調べるのに必要な能力は知力:3、精神力:3、体力:4ぐらいで1週間置いてから直すのに必要な能力も同じ位ですみます。
これは一見大したことのない発見のように見えますが実際はかなりの大発見です。
まず、普通の人の知力は2です。頭が良い人でも3です。
それを精神力で無理やりプログラミングに集中する事（つまりプログラミング以外の事は全部忘れる。）で倍の知性つまり6くらいに挙げます。更にコーヒーのようなカフェイン飲料や、砂糖の塊のようなお菓子や炭酸飲料を飲む事（つまり知力のドーピングです。）で無理やり8くらいに上げます。それでも10には足りないのでGoogle先生に頼って作成したいプログラミングに似たコードもしくはそのものズバリを探してきてそのコードを参考にする事（ちょっとだけカンニングする。）事で何とか知力:10の問題を解いていくと言う感じになります。
このやり方は大変な精神力が必要でもあります。知力を2倍にするための集中力を生み出すには高い精神力が必要だからです。前の日に早く寝て十分な睡眠時間を確保する事も必要になります。ちょっとだけと夜更かしすればその分の負担は次の日の朝に必ずかかって来ます。
所が、直す箇所を調べるだけ調べておいて、1週間置いてから直すと必要な能力は知力:3、精神力:3、体力:4ぐらいになります。まだ試した事はないですが、1週間でなく次の日でも同じ効果は出て来ると思います。
つまり、上記で述べた様な無理をする必要が全く無くなります。
普通で良くなります。負担がものすごく軽くなります。
実際の効率から見るとPair Programmingに匹敵するぐらいの発見だと思います。Pair Programmingのように有名に成る事はないでしょうが。一応名前だけ付けておきます。Preparation and Implementation Programmingと名付けました。
５．Monsterがアイテムを落とすようにします
はい。それでは今週も調べるだけ調べておきます。
Monsterがアイテムを落とすように作成すると言いましたが2021-06-13のブログで説明したように、実際は戦闘が終わった時に戦闘場に存在している9体の像のどれかに話しかける事でアイテムが貰える仕組みになります。
その時に一個問題があります。
戦闘後の勝利のポーズをPlay Animationで行っているためその後、Player の操作するキャラのAnim Classが外れてしまい、
以下に示したように、武器と防具が手から外れた状態になってしまっています。
このすぐ後に別なLevelに移動する場合は全く目立たないので問題なかったですが、この後に石像に話しかけるようなActionを取る場合、凄く目立ちます。直す必要があります。
これを来週やります。
名称は「戦闘勝利後のAnimationの直し」とします。
5.1 戦闘勝利後のAnimationの直しのための調査
まず、戦闘を勝利した後のAnimationの表示を実装している箇所をみます。
見つけました。
RPG Game Mode BPのEvent関数であるFight Over のPHASE Victoryの後です。
まず最初のノードです。
Monsterが分解・消滅するためのAnimationをPlay Animation ノードで実行しています。
Monsterはこの後消滅してしまうので、Play Animationノードを使用してAnim ClassにセットしてあるSkelSwordAni_Cが外れても問題ないです。
次は音楽をセットして流していますね。
Animationとは関係ない部分なので無視します。
次のノードでDispatcherであるCombat Over Victoryを読んでいます。
どんな実装がCombat Over Victoryにされているのか覚えていません。調べます。
Combat Field Mapで実装されていました。Event Stop BGMに繋がっていてBGMを止めます。
ここからPlayer の操作するキャラのAnimationの実装が始まります。
カメラの位置と角度を変えるノードです。
この機能を作成した時には、まだ戦闘用のLevelを作成していませんでした。のでキャラの撮影をするカメラの位置を指定する為には、キャラに対して行う必要がありました。今は戦闘用のLevelは完成しているのでカメラを別に設置する事も可能です。まあ直す必要は感じませんが。
次のノードは何かを消しています。
見たらCombat UIでした。
やっと勝利のポーズのAnimationの部分に来ました。
思ったより複雑で、まず武器を装備しているか聞いています。
武器を装備していなかった場合、Victory_noWeaponのAnimationが実行されます。
武器を装備している場合は、武器が弓矢かそれ以外かで分けられます。
弓矢の場合はVictory_BowAnimが実行されます。
それ以外の武器を装備していた場合はVictory_SwordShieldAnimが実行されます。
成程、この３つのAnimationをPlay Animationノードを使用して実行しているんですね。
分かりました。
この部分をMyThirdPerson_AnimBPに担当させる必要があります。
5.2 MyThirdPerson_AnimBPの復習
MyThirdPerson_AnimBPを復習します。
AnimGraphを開いて見ます。
Defaultを開きます。
うーん。
変数を見ると以下のモノがありました。
例えばWithWeaponですがBoolean変数で、以下に示した部分で赤く記した所の条件を担当しています。
こんな感じです。
この変数にどのようにアクセスして値を変更しているのかを調べれば、同じやり方で戦闘勝利後のアニメーションもMyThirdPerson_AnimBPに追加出来るはずです。
RPGGameModeBP内でMyThirdPerson_AnimBPのWithWeapon変数の値を変更している実装箇所を見つけました。
うん。
こんな簡単に出来るんですか。
MyThirdPerson_AnimBPに追加するAnimationに関しては先程、示したAnimGraphのDefault Stateの中身のノードの内、以下の3つにそれぞれのVictoryのポーズを付ければ良いです。
RPGGameModeBP内の勝利のAnimationは以下の部分を変更すれば良いだけです。
あ、Set Visibilityノードの後にあるSet Anim Instance Classノードを外す必要もありました。
以上です。
６．まとめと感想
今週は以下の事について勉強しました。
- Niagara SystemにおけるRibbonのRenderingについての考察
- Cascade SystemにおけるBeam のParameter、Interpolation pointとSheetについて
- RPGでItemが拾えるようにした。
- RPGで戦闘終了後の勝利のポーズのAnimationについての調査
を行いました。
今週はいつもの週より楽でした。多分、Preparation and Implementation Programmingのお陰です。
７．参照（Reference）
[1] Epic Games [Unreal Engine]. (2014, July 8). Intro to Cascade: Creating a Beam Emitter | 07 | v4.2 Tutorial Series | Unreal Engine [Video]. YouTube. https://www.youtube.com/watch?v=ywd3lFOuMV8&list=PLZlv_N0_O1gYDLyB3LVfjYIcbBe8NqR8t&index=8
[2] Epic Games. (n.d.). Beam Type Data. Unreal Engine Documentation. Retrieved July 4, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/TypeData/Beam/
