げーむ開発徒然日記~怠惰のために勤勉~

まばたきのポストプロセスマテリアル

2024-09-14T13:06:26+09:00

タイトル通りです。

概要

　以下のような、ホラゲー導入シーンでありがちなまばたきのマテリアル（Eye blink material）を作りました。

　調べても、メッシュを動かして作る方法など、私がやりたかったものとは異なる実装しか見つからなかったので自前で組みました。

　なお今回は、シーケンサーでパラメーターを変更する都合上、Material Parameter Collectionを用いましたが、勿論Scalar ParameterでもOKです。

作り方

新規マテリアルの作成

　コンテンツブラウザ右クリック＞「マテリアル」＞「マテリアル」で新規マテリアルを作成します。

　ポストプロセスとして使うので、作成したマテリアルの編集画面にて、下図のようにマテリアルを設定します。

マテリアルの組み方

　細かい説明は無しで、作り方を淡々と説明します。

　全体像は下図の通り。

　マスク部分の中身は下図の通り。Blink Valueというパラメータは、まばたきの度合いを0～1で指定する部分です。冒頭で述べた通り、Scalar ParameterでもOKです。

　また、SmoothStepではなくStepのほうを使えば、ぼんやりとしたまばたきではなく、カチっとしたまばたきにできます。

　PostProcessInput0に対して、作成したマスクを使って黒色（瞼に覆われている部分の色）で補間します。

　…以上。お役に立てば幸いです。

UIマテリアルでテキストなどをおもしろくする

2023-12-20T00:00:09+09:00

　この記事は、Unreal Engine (UE) Advent Calendar 2023の20日目の記事となります。

はじめに
フォントマテリアル
エフェクトマテリアル
- エフェクトマテリアルの準備と適用方法
  - 波打つような変形効果を与える
おわりに
参考

はじめに

　今回は、UE5のウィジェットで、テキストにエフェクトを加えたり、UIの部分的または全体にポストプロセス的にエフェクトを加えたりする方法を紹介します。

※使用したUEのバージョン：5.3

フォントマテリアル

　UE5のUIを作る際に使用するウィジェットには、フォントマテリアル（Font Material）というものがあります。これは、UTextコンポーネントなどで使用できます。テキストにアウトラインを付けたりするのは、フォントマテリアルを使わなくてもできるようになっておりますが、テキストにテクスチャを適用したり、変形したりといったちょっとしたエフェクト的なものを与えたい場合には、フォントマテリアルを使用することになります。

例）アウトラインにフォントマテリアルを割り当ててオーラ的な動きをつけたもの

フォントマテリアルの準備と適用方法

１）新規マテリアルを作成し、Material DomainをUserInterfaceにします。

　Blend Modeは通常のマテリアルと同様にOpaqueやMasked, Translucentなどが使え、出力が異なります。文字の一部を削りたいなどの場合はMaskedを使う必要があります。

　↓通常のマテリアルとは出力が異なる（Blend Mode = Translucentにしたもの）

２）次に適用方法ですが、ウィジェットにText，Editable Text，Rich Text Blockなどを配置して、詳細パネルから割り当てます。なお、テキスト本体および輪郭のフォントマテリアルは分かれており、それぞれにマテリアルを割り当てられるようになっています。

Textureで柄を付ける

基本

　以下のようにVertex Color（テキストカラー）にUEロゴのテクスチャを乗算したものを最終カラーに出力してみます。

　ウィジェットのテキストの詳細パネルには上記画像のように、テキストの色と透明度を設定する項目Color and Opacityがありますが、ここで設定した値がフォントマテリアルのVertex Colorとして使用されます。

[結果]

　テキストカラーは白にしているので、UEロゴのテクスチャがそのまま乗りました。

文字ごとにテクスチャで柄を付ける

　先ほどの例では、テクスチャがテキスト全体に収まるようにストレッチがかかっていましたが、文字ごとにテクスチャの柄を付けたい場合には、どのようにすべきでしょうか。Texture SampleにTex Coordを入力してみます。Indexを「1」にすることで、文字ごとの座標が取得できるようです。

[結果]

　各文字に対してテクスチャの柄が付けられました。

スクリーン空間にテクスチャで柄を付ける

　先ほどまでの例ではすべて、テクスチャにストレッチがかかってしまっています。これの回避策としては、ScreenAlignedPixelToPixelUVsを使う方法がありますが、名前の通りスクリーン空間にテクスチャが貼られるような形になるため、パターン柄でない限りは使いづらい方法です。

[結果]

　テキストの位置が変わっても、テクスチャの位置は変わりません。

テキストを動かす・変形する

テキスト位置をテキストカラーによって動かせるようにしてみる

　マテリアルの出力にあるスクリーン位置に入力を与えることでテキストを動かしたり、変形したりできます。

　試しに以下のようなマテリアルを組んでみました。

　画像のコメントにある通り、テキストの色が変わるとスクリーン位置も変わると予想できます。

[結果]

　予想通り、テキストの色によって位置が変わりました。

テキストを変形させる

　テキストを変形させるマテリアルを適当に組みました。

[結果]

　ふにふに動きます。ただし、四隅しか動かせません。

　↓動きを横方向に制限したもの

エフェクトマテリアル

　フォントマテリアルでは、テキストにエフェクトを与えられますが、RetainerBoxのEffect Materialを使うとUIの部分的または全体にポストプロセス的な加工をできます。これはおもしろくて、今回紹介する基本的なもの以外にもいろいろな活用方法があると思います。

エフェクトマテリアルの準備と適用方法

　まずは、ウィジェットにエフェクトを適用したい領域をRetainerBoxで形どります。

　次にフォントマテリアルと同様に新規マテリアルを作成し、Material DomainをUserInterfaceにします。

　RetainerBoxの詳細パネルのEffect Materialに、作成したマテリアルを割り当てます。Show Effects in Designerにチェックを入れるとUMGデザイナー上でエフェクトを確認できます。

波打つような変形効果を与える

　以下のようにマテリアルを組みました。

（注意）RetainerBoxのEffect設定にある"Texture Parameter"と同名のテクスチャパラメータをマテリアル内に用意する必要がありますが、テクスチャは何でも大丈夫です。

[結果]

　RetainerBox内の領域のみに波打つような効果が与えられました。

※UE5.3のバグだと思うのですが・・・背景部分が黒くなってしまっています。Blend ModeをAdditiveにしたら、透過できましたが、加算が入ってテキストカラーも変わってしまいました。

　もちろん、テキスト以外に画像やボタンなどにどれにでもエフェクトを与えられます。

おわりに

　以上、フォントマテリアルおよびエフェクトマテリアルの紹介でした。個人的に、フォントマテリアルは最初に載せた輪郭に適用したものは汎用性が高そうに感じました。

　また、エフェクトマテリアルはHUDに使ってBPとの連携でパラメータを動的に変更して…などで使うとおもしろいと思います。

　プロジェクトにマッチしそうなアイデアを見つけ、ぜひ使ってみてください！

参考

・[UE4]UI用マテリアルの「Screen Position」で遊ぼう｜株式会社ヒストリア

・UMGのフォントをアレンジ - みつまめ杏仁

【Houdini】スプラッシュ画面が表示されるだけで起動しない

2023-08-31T12:38:41+09:00

個人的備忘メモ

環境：Windows 11

Houdini 19.5.716（indie版使用）

概要

以前使っていたPCでも、新調したPCでも同様の問題が起きていた。

具体的には、ランチャーからの起動でも、直接houdini.exeを開いての起動でもスプラッシュ画面が表示されて数秒後に、スプラッシュ画面が消えるだけで結局起動しない。

その後、何度か試しても時々スプラッシュ画面が表示されるが同様に起動しない。

スプラッシュ画面が表示されない場合のほうが多く、青い読み込みの表示がマウスカーソルの横に出るだけである。

なお、原因を調べようとイベントビューアーを確認したところ、Windowsのntdll.dllというものに障害が発生とのことだったが、なぜなのかよくわからない。

調べたところ同様の事例がかなり多く報告されているのに対し、いまだに解決策が明確でない状況である。

今回は、調べても出てこなかった対策のひとつのメモとしつつも、同様の症状が出ている方の参考になれば幸いだと思ったので共有する。

もしこれで治った方がいれば、記事の下部にある★ボタンを押してくださると嬉しいです。

対策として試したこと

以下、効果がなかったことリスト。

・Windows再インストール⇒実際には行っていないが、新調しても発生したので意味がないと思われる

・Houdiniやライセンスサーバー再インストール

・Houdiniを管理者として実行

・ファイアウォール無効化

・DocumentフォルダにあるHoudini19.5のフォルダ削除

・ライセンスサーバーをサービスから再起動

効果があったもの（確実に有効かは不明）

・私の場合、どうもウイルスバスターが悪さをしているみたいだったので、以下の「コンピュータの保護設定」でhoudini.exeをスキャンの対象外に設定した。

※私が使用しているライセンスはIndie版だが、設定するのはhindie.exeではなくhoudini.exeで良いと思う。

これだけで、Houdiniが起動しないなんてことはなくなってしまった。ウイルスバスターでない方も、ウイルス対策ソフトを疑ってみるとよいかもしれない。

注意点

フォルダシールドの設定画面からも「許可するプログラムの一覧」という上記と似たような設定画面が出てくる。が、こちらは上記の設定とはまた別の設定であり、こちらにhoudini.exeを設定しても効果がなかった（上記の「コンピュータの保護設定」でhoudini.exeをスキャン対象外としても、以下の「許可するプログラムの一覧」には登録されない）。

【UE5】Proceduralなナンバープレートのマテリアルを組んでみる

2023-04-29T21:50:26+09:00

０．はじめに

　今回組んでみたのは、様々な組み合わせの番号や用途表示などに対応可能なナンバープレートのマテリアルです・・・というのはあくまで具体例で、実際のところやっていることを抽象的に言えば、

　「あるテクスチャの任意の範囲だけ」を「任意のモデルの任意のUV座標範囲」に合成するというものです。

　イメージはこんな感じ↓

　今回のナンバープレートの場合で言うと、何も書かれていない"更地"のナンバープレートに、数字や文字を合成していくイメージですね。

　この方法は、色々なことに使えると思います。例えば、

【例１】UV空間のほんの一部にしか発光する部分を持たないオブジェクトで、わざわざ4K解像度のベースカラーテクスチャのAチャンネルをエミッシブのマスクに使いたくない場合

　⇒今回の手法を使えば必要最低限のサイズ（64x64サイズなど）のエミッシブマスクを用意すればよくなります。

【例２】学校の教室のプレートや看板など、ベース部分を使いまわしたい場合

　⇒今回紹介するナンバープレートと同じパターンです。

　きっかけはGhostwire: Tokyoで車が様々なナンバーだったのを見かけたことです。最初はテキストレンダーコンポーネントでも仕込んであるかと思ったんですが、ちゃんと文字がプレート表面から盛り上がっている＝ノーマル情報があるんですよね。ただ、Ghostwire: Tokyoの車で使われている数字は完全にランダムではなく何らかの規則性はありそうな気がします。

１．実装例

　今回使用したUEはバージョン5.1.1です。

１－１．完成形

　以下の動画をご覧ください。

　付与した機能は色々ありますが、本記事で取り上げるのは以下の2つです。

①ナンバー（10-00～99-99）が、ランダム変化する

⇒１～３桁ナンバーには対応させていないのでご了承ください。そこまで難しいことではないですが、対応させるには別途改変する必要があります。

②手動でも設定可能にする

⇒今回は、①②を実現するため最終的にBP Actorにします。

１－２．用意するもの

・単純なアトラス化が施されたテクスチャ（合成したいもの）

※もちろんアトラス化されていないものでも大丈夫です（補足参照）。

　今回は、R+Gチャンネルに法線情報、Bチャンネルにマスク情報を持つテクスチャを用意しました（上から順にR+G+B，R+G，B）。

※ブログ用に作ったものなのですごく雑ですし、サイズも圧縮のことも何も考えていません。ナンバーって特殊なフォントだなあ…。

　単純なアトラス化と言っているのは「要素が等間隔に分割されているもの」を指しており、上のテクスチャはどちらも各数字が等間隔に配置されています。

Tips：

・必要な解像度は使用する自動車モデルに使われているテクスチャの解像度に合うようにすることを推奨します。

・３桁ナンバーなどに対応させる場合は「・」もテクスチャに含めないといけません。

１－３．マテリアルの作成

最初はBチャンネルのマスク情報を使って合成するための準備段階から始めるので留意ください！！

１－３－１．テクスチャの任意の範囲を切り取る

　まず最初に、冒頭で述べた

「あるテクスチャの任意の範囲だけ」を「任意のモデルの任意のUV座標範囲」に合成する

の、「あるテクスチャ（この例では、合成に使うテクスチャ）の任意の範囲」を切り取ることから始めます。

　エンジンに標準で用意されているFlipBookというマテリアル関数を使うだけでこれを実現できます。以下（紫色でコメントされた部分）をご覧ください。

　0123456789から3だけが切り取られています。上の画像では、Numberというパラメータに与えられた数字が切り取られるようにしています。

Tips：FlipBookは本来的には、エフェクトに使う連番テクスチャを入力して、Animation Phaseの値を変化させることでパラパラ漫画のようにアニメーションさせることに使うことが多いと思います。

１－３－２．任意のUV座標範囲を切り取る

　次は、

「あるテクスチャの任意の範囲だけ」を「任意のモデルの任意のUV座標範囲」に合成する

の、「任意のモデルの任意のUV座標範囲」を切り取ることを行います。

　こちらもエンジンに標準で用意されているTextureCroppingというマテリアル関数を使うだけでこれを実現できます。以下（茶色でコメントされた部分）をご覧ください。

　UpperLeftCorner(V2)およびLowerRightCorner(V2)という入力を与える必要があります。これは切り取りたいUV範囲の正規化座標となります。

１－３－３．ナンバーを合成したい場所に合わせてポジショニングとスケーリングする

　ここまでできたら、先ほどの１－３－１で得られた「切り取られたナンバー」を、合成したい範囲の大きさに合わせてポジショニングおよびスケーリングしていきます。

　厳密に言えば、「タイリングをした後に、必要な部分のみを残す」といったことを行います。

　以下のように１－３－２で使ったTextureCroppingのCrop UVsという出力を、FlipBookのUVsに与えてやると、FlipBookの出力にタイリングをかけることができます。

　次に、タイリングで作られる不要部分を除去するためには、Crop Maskという出力が、切り取られた範囲のマスク情報として使えます。

　それでは、以下のようにFlipBook（タイリングされたナンバー）から、不要部分をマスクで除去します。なお、途中でBチャンネルをマスクしているのは、Bチャンネルには文字部分のマスク情報があるため、Crop Maskと乗算することで、CropMaskにある範囲内かつ数字のみのマスク情報というのを作ることができるためです。最終出力はMaskedNumberというNamed Rerouteに格納しました。この情報を後々使いまわします。

１－３－４．カラー情報を合成する

　ようやくカラーや法線を合成する準備が整いましたので、まずはカラーから乗せていきますが、これは簡単です。ナンバープレートのベースカラーテクスチャに対して、先ほどのマスク情報を使ってLerpで合成するだけです。

１－３－５．法線情報を合成する

　まずは、合成する法線情報を作ります。以下のようにマテリアルを組みます。

　１－２で説明したように、今回用意したテクスチャはR+Gチャンネルに法線情報があるだけであってBチャンネルを再構築する必要があるため、DeriveNormalZを使って法線情報を再構築します。その後、ナンバー以外の部分はFlattenNormalによって平坦化し、強度調整用のFlattenNormalも別途配置します。

　あとは、BlendAngleCorrectedNormalsを使って、ナンバープレートのベースの法線マップに対して合成をかけます。

１－３－６．４桁ナンバーにする

　４桁ナンバーにするにあたって、まずはマテリアル関数化し、コンパクトにしました。

　マテリアル関数内の、TextureCroppingのところも少し変更しています。

　あとは、この関数を４桁分＝４つ配置して合成します。

　NumberSizeのパラメータのみ使いまわしています。さすがに若干コストが高くなります。とりあえずこれで一通りは完了です！あとはランダム化に対応していきましょう。

１－４．ランダム化への対応

１－４－１．Custom Primitive Data

　Material Instance Dynamics（MID）を使っても可能なのですが、今回はCustom Primitive Data（CPD）を使います。

　MIDではスカラーパラメータとベクターパラメータに加えて各種テクスチャパラメータなどを動的に変更可能なのに対し、CPDではスカラーパラメータとベクターパラメータしか扱えませんが、今回のケースではCPDで十分に対応できます。

　また、CPDのほうがドローコールを節約するうえで特に有効な手段ですので、CPDで対応できるものは積極的にCPDを利用したほうがよいです。これについては公式ドキュメントを一読しておくことを推奨します。

　マテリアル内のNumber_1～Number_4に、Custom Primitive Dataを使うように設定します。

　パラメータを選択した状態で、詳細タブからUse Custom Primitive Dataにチェックを入れて、Primitive Data Indexを指定します。

　今回は、Number_1～Number_4の順に、Primitive Data Indexに1～4を割り当てました。

１－４－２．Actorを継承したBPクラスを作成

　今回は、Actorクラスを継承したBP_LicensePlateMatTestを作成しました。この中のBP処理にてランダム化対応を実装していきます。

　あとはConstruction Scriptにて、それぞれのCustom Primitive Dataに0～9のランダムな値を与えてやるだけです。また、4桁の場合、先頭に0はこないので、先頭のみ1～9となるようにしています。

　ここまででランダムナンバーは終わりです！お疲れ様でした。次はオプション的なものですが、手動設定にも対応させていきます。

１－５．手動設定への対応

　すぐにできます。それぞれのナンバーに対応する変数と、手動で設定するかどうかを決めるbool変数を用意します（目玉マークが開いているようにすること）

　あとは以下のように、分岐処理を組んであげるだけです。

　レベル上で編集してみると、手動設定が機能していることを確認できます。

　おしまい！

補足

アトラス化されていないテクスチャを使用する場合

　切り取る必要がないということなので、FlipBookを使わずにTextureSampleを使用するだけです。

BP Actorにせず、単なるStaticMeshActorで実現したい

　ナンバーランダム化の柔軟性が落ち、手動設定機能も失われますが、以下のようにすればできます。この例では、シェーダー内でナンバーを自動で決めることによってBPで数値を変更しなくてもよくなっています。ただし、4桁全てをバラバラにするためには更なる工夫が必要です。

シェーダーコストを下げたい

以下のような対応で、多少は下がると思います。

・標準のFlipBookでは冗長なので、必要な計算だけを残したカスタムのマテリアル関数を作成しましょう。

・標準のTextureCroppingでは冗長なので、必要な計算だけを残したカスタムのマテリアル関数を作成しましょう。

・合成する部分の数が多いほどTextureSampleが増えたりとそれなりにコストも増加していきます。ナンバープレートの場合は、ナンバー4桁＝4つ以上は合成する部分が必要になりますが、それ以外はある程度妥協しましょう。FlipBook内でも、TextureCropping内でもTextureSampleが使われているので注意。

【UE5】EQSを使って遮蔽物によるインタラクションアイコンの表示・非表示を実装してみる

2022-12-17T21:20:19+09:00

本記事は、Unreal Engine (UE) Advent Calendar 2022の18日目の記事になります。

はじめに
- 完成形
- ウィジェットコンポーネントについて
実装
おわりに

はじめに

　本記事では、UEのEQS（Environment Query System；環境クエリシステム）を使って、アイテムピックアップ、ドア開閉などのインタラクション可能なオブジェクトのアイコンを遮蔽物の有無によって表示・非表示を切り替える機能を実装していきたいと思います。

※後述しますが、この方法、正直効果的ではないです。あくまで「EQSを使ってみた」だけのもので、利点は、実装がシンプルでわかりやすいくらいかなと思ってます（インタラクティブなオブジェクトにトレースなどの処理を書かなくて良いため）。プロトタイプや簡単なプロジェクトに使う分にはいいかもしれません。

　なお、今回使用したバージョンは5.1です。

docs.unrealengine.com

　上記の公式ドキュメントによれば「EQS のユースケースの例としては、最も近い体力のピックアップや弾薬を探したり、どの敵が最も脅威となっているのかを把握したり、プレイヤーが見える位置を見つけたりすることが挙げられます」と記載されており、EQSはUE標準のAIビヘイビアツリーなどと組み合わせることで様々な環境に対応可能なAIの作成に活用できるものですが、今回はあえてオブジェクトのアイコン表示に使ってみました。

完成形

　作成したものの完成形は以下のような感じ。

　インタラクション可能なオブジェクトが遮蔽物の奥に隠れている場合、アイコンが非表示になります。

　厳密に言えば、Querierとなるキャラクターのカメラ位置からインタラクティブなオブジェクトの原点位置との間に遮蔽物があるかどうかを見ています。この時点でなんとなく、最初に注意点として述べた理由がわかるかと思います。

ウィジェット コンポーネントについて

　インタラクティブなオブジェクトにアイコンを表示しようとした場合、ウィジェットコンポーネントをアクターに取り付けることが多いかと思います。

　そしてウィジェットの描画方法としては、

・スクリーン空間　⇒ワールド座標をもとにスクリーン座標に2Dウィジェットを描画

・ワールド空間　⇒ワールド座標に3Dウィジェットを描画

があります。

　ワールド空間であれば特に何もせずとも遮蔽物の奥のアイコンは隠れるのですが、

「カメラとの距離に応じて表示サイズが変わる」「3Dウィジェットのため3次元の向きを持つ（後ろから見ると反転して見える）」などといった挙動となります。

　反対に、スクリーン空間であれば上記とは逆で「カメラとの距離によって表示サイズは変わらない」「常に正面を向いている」といった挙動にはなりますが、遮蔽物の奥にあったとしても関係なしに画面に描画されます。

　このように、どちらの描画方法も一長一短ですが、今回のようなインタラクションアイコンや敵のHPバーなどといったものに対しては、一般にスクリーン空間での描画が適しています。

　しかし、繰り返しにはなりますがスクリーン空間への描画をそのまま使うと冒頭で示した動画のような、遮蔽によるアイコンの表示・非表示というのができません。仮にこれをBPのみで実装しようとすると、ちょっと面倒だったりします。

　このため、今回は上述のEQS機能のひとつである「プレイヤーが見える位置を見つけたりすること」を使ってサクッと簡単に実装していきます。

実装

準備

　使用するUEのバージョンによっては、プロジェクト内の[Editor Preferences (エディタの環境設定)] > [Experimental (実験的)] > [AI]セクションで、Environment Querying Systemをオンにする必要があります。UE5.1ではそもそも項目が見つからないはずです。

※画像は公式ドキュメントから引用

環境クエリの作成

　まずはコンテンツブラウザの右クリックメニューから環境クエリを作成します。

　作成されたアセットを開くと、ビヘイビアツリーのようなエディタ（クエリグラフ）が開きます。

　最初から置いてある、ルートノードからドラッグ操作で出てくる[Actors Of Class]を選択します。

　これは、GetActorsOfClassに近いものであって、詳細パネルから取得したいアクタークラスと、球状のサーチを行うかどうかなどを設定できます。

　今回は、BP_Interactableというクラスをサーチするので、先に作成し、以下のように[Searched Actor Class]に設定しておきます。

　Generate Only Actors in Radiusは、TrueであればSearch Radiusで設定された半径の球状の範囲内のSearched Actor Classオブジェクトをサーチします。Falseであればワールド全体からサーチします。

　Search Radiusは後ほどキャラクタークラスからクエリにパラメータを与えるため、Query Paramsにしておきます。

　Search Centerはサーチの中心位置です。デフォルトのEnvQueryContext_Querierのままでも大丈夫ですが、今回はカメラ位置を中心にしたいので、コンテンツブラウザ右クリックから[EnvQueryContext_BrueprintBase]を作成します。これによって、Querierの情報をもとにカスタムの位置情報などを作成できます。

　作成したらアセットを開き、Provide Single Location関数をオーバーライドします。これで、Querierの位置をキャラクター原点ではなくてカメラ位置にオーバーライドできます。

　これができたら、先ほどのSearch Centerに、作成したEnvQueryContextを設定します。

　次に、クエリグラフに戻ってActors Of Classノードを右クリックして[テストを追加]>[Trace]を選びます。

　Actors Of ClassノードにTraceという項目が追加されるので選択すると、詳細を設定できます。

　設定は以下のようにします。

　[Context]に先ほど作成したカメラ位置を使えるようにするEnvQueryContextを設定します。

　これで、このクエリを実行すると、

カメラ位置を中心とするSearch Radius半径の球内に存在するBP_Interactableオブジェクトを取得⇒取得された全てのBP_Interactableオブジェクトの原点位置からカメラ位置にトレースによって遮蔽物があるオブジェクトについてはクエリ終了後の最終的な出力から弾かれる。といった具合になります。

プレイヤーキャラクターの作成

　まずは、近くにあるBP_Interactableを検出するためのコリジョンコンポーネントを追加します。

※InteractableCollisonは詳細パネルから全チャンネルへの応答をオーバーラップにしていますが、インタラクティブなオブジェクトのみをオーバーラップ、他のアクターやコンポーネントに対しては応答を無視にするとなお良いです。

　BeginPlayイベントで色々とセットアップするので、Enable Interactable Detectionというカスタムイベントを追加します。

　以下がイベントの中身です。コリジョンの半径を設定したり、オーバーラップイベントなどを作成しています。

　コリジョン内のBP_InteractableはInteractable配列内に格納されます。

　次はSequenceノードの２つ目からの内容です。先ほど、クエリグラフのActors Of Classノードにてサーチ半径にパラメータを使うことに設定していたので、キャラクターのBPから与えてやります。

　UpdateInteractionIconイベントでは、球体内に存在するBP_Interactableに対して、それぞれの可視・不可視に応じてウィジェットの可視性をトグルしています（次項参照）。

インタラクティブなオブジェクトの作成

　Actorクラスを継承したBP_Interactableは、スタティックメッシュコンポーネントと、ウィジェットコンポーネントを追加しただけの単純なものです。

　ウィジェットコンポーネントの詳細設定にて描画をScreenにしておき、ウィジェットの可視性（Visibility）はデフォルト値をFalseにしておきます。ウィジェットクラスには自作のアイコン表示用ウィジェットを設定してください（作成は割愛）。

　キャラクタークラスから実行していたToggle Iconイベントは以下の通り。

⇒実装おしまい

おわりに

　というわけで、今回はEQSを使って遮蔽物の有無によるインタラクションアイコンの表示・非表示をできるようにしてみました。

　実際にはトレースを飛ばし続けてさらに近づいたときに、あとはボタンを押すだけでインタラクトできることを示すようにアイコンの見た目を変えたり、もちろんインタラクション処理も追加実装する必要があります。

　そしてかなりデメリットであるのが、プロジェクトによっては複数の引き出しをコンポーネントとして持つタンスなどのアクターを作成する場合です。この場合、今回の方法を用いると、アクター（タンス自体）の原点の位置情報が使われるため、タンスの原点さえ見えていれば全ての引き出しに対してアイコンが表示されてしまうといったことが生じうるため根本から方法を変えるか大幅な変更を行う必要などが出てきますので、それでも良ければ構わないのですが、できれば今回の方法でも十分なプロジェクトやプロトタイプ程度に使うのが良いかと思います。

　また、タイマーでクエリを実行していますが、For Each Loopによるオブジェクト毎へのウィジェット情報の更新を行いますし、クエリのActors Of Classも決して処理負荷的に優しいものではないという点にご留意ください。

　なので、ちゃんと実装する場合は、素直にC++を使うのがいいです。

対象Actorの速度を監視するAbilityTask

2022-08-20T15:17:16+09:00

概要

GASにてダッシュアビリティ(GA_Run)を実装した際、ダッシュのアクション入力をすると止まっているにも関わらずGA_Runの持つState.RunningのようなGameplayTagが付与されてしまうのが気になっていました。

AbilityTaskですが、どうやらTick動作させることができるみたいなので、それを利用してActorの速度を監視するAbilityTaskを作りました。

AbilityTaskの作り方については、あいす氏の記事でわかりやすく解説されていますのでそちらをご覧ください。また、公式の詳しい作成手順はAbilityTask.h内に示されています。

[UE] AbilityTask のつくりかた - Qiita

使用UEバージョン：5.0.3

作成するAbilityTask

今回作ったものは以下のようなものです。

AbilityTaskを実行するとTargetに接続したActorの速度(高さ方向は無視)を監視し続け、Threshold(閾値)を超えるとOnStartMovingデリゲートが発行され、再度Threshold以下となるとOnStopMovingデリゲートが発行されるといった非常にシンプルな構成になっています。

実装

DECLARE_DYNAMIC_MULTICAST_DELEGATE(FWaitGroundMovingDelegate);

UCLASS()
class YOURPROJECT_API UAbilityTask_WaitGroundMoving : public UAbilityTask
{
    GENERATED_BODY()

    UPROPERTY(BlueprintAssignable)
    FWaitGroundMovingDelegate OnStartMoving;
    UPROPERTY(BlueprintAssignable)
    FWaitGroundMovingDelegate OnStopMoving;

    virtual void TickTask(float DeltaTime) override;

    /** TargetActorのXY速度が閾値Thresholdを上回る、又は、Threshold以下となるのを待つ */
    UFUNCTION(BlueprintCallable, Category = "Ability|Custom|Tasks", meta = (DisplayName= "WaitGroundMoving", HidePin = "OwningAbility", DefaultToSelf = "OwningAbility", BlueprintInternalUseOnly = "TRUE"))
    static  UAbilityTask_WaitGroundMoving* CreateWaitGroundMoving(UGameplayAbility* OwningAbility, AActor* Target, float Threshold);

    virtual void Activate() override;

protected:
    UPROPERTY()
    AActor* TargetActor;
    
    float Threshold;

private:
    bool bIsMoving;
};

#include "Kismet/KismetMathLibrary.h"

void UAbilityTask_WaitGroundMoving::TickTask(float DeltaTime)
{
    if (TargetActor)
    {
        float GroundSpeed = UKismetMathLibrary::VSizeXY(TargetActor->GetVelocity());

        if (GroundSpeed > Threshold)
        {
            if (!bIsMoving)
            {
                if (ShouldBroadcastAbilityTaskDelegates())
                {
                    OnStartMoving.Broadcast();
                }
                bIsMoving = true;
            }
        }
        else
        {
            if (bIsMoving)
            {
                if (ShouldBroadcastAbilityTaskDelegates())
                {
                    OnStopMoving.Broadcast();
                }
                bIsMoving = false;
            }
        }
    }
    else
    {
        ABILITY_LOG(Warning, TEXT("UAbilityTask_WaitGroundMoving ticked without a valid Actor. ending."));
        EndTask();
    }
}

UAbilityTask_WaitGroundMoving* UAbilityTask_WaitGroundMoving::CreateWaitGroundMoving(
    UGameplayAbility* OwningAbility, AActor* InTarget, float InThreshold)
{
    auto* MyObj = NewAbilityTask<ThisClass>(OwningAbility);

    MyObj->bTickingTask = true;  //Tick動作に必要
    MyObj->TargetActor = InTarget;
    MyObj->Threshold = InThreshold;

    return MyObj;
}

void UAbilityTask_WaitGroundMoving::Activate()
{
    SetWaitingOnRemotePlayerData();
}

MetaSoundでお手軽ラジオボイス風表現

2022-07-16T18:03:39+09:00

タイトル通りです。

なんとなく「外部ソフトを使用せずにUE5内でプロシージャルにラジオ風音声に変換したいな」と思ったので紹介します。

※MetaSoundの基本的な使い方は省略します。使用するにはプラグインをONにしてください。

また、音声サンプルはありません。

使用バージョン：UE5.0.3

フィルタを使ってこもったような音声にする
音質を悪くする
仕上げにノイズを追加する

フィルタを使ってこもったような音声にする

まだMetaSoundをほとんど触ったことがなく、機能を把握しきれていないので今回は単純にLPF(Low-pass filter)とHPF(High-pass filter)＋αを使っていきます。もちろんBPF(Band-pass filter)でもできるはずです。

LPFは、所定の周波数以上の成分をカットするフィルターで、HPFはその逆です。

手順は以下の通りです。

①入力ノードのOn PlayピンからWave PlayerノードのPlayピンに接続して音声アセットを再生できるようにします。

②Wave PlayerノードのOut Leftピンから、ワンポールハイパスフィルタノード（HPF）のInピンに接続します。

下図の例では、カットオフ周波数を"3000"に設定しているので、3000Hz以上の周波数成分を通します（数値は割と適当なので調節してください）。

なお、今回はデフォルト設定のモノラル音声のまま進めるので、Wave PlayerノードのOut Rightピンは使用しません。

③ワンポールハイパスフィルタノードのOutピンからワンポールローパスフィルタノード（LPF）のInピンに接続します。

再生してみるとわかりますが、元の音声に比べてこもったような感じになっていると思います。

音質を悪くする

先ほどまでの状態でこもった音声にはなりますが、元の音声の品質が高いとまだまだラジオっぽくなりません。

そこで、Bitcrusherノードなるものを、フィルタを通した先に接続します。

これは、ノードの説明にもあるように「入力オーディオ信号をダウンサンプルし、ビット深度も下げる」ものみたいなので使えそうだなと思いました。

サンプルレートとビット深度をお好みに合わせて調節してください。

これで再生してみると、音質が低下したことで更にラジオっぽくなっていると思います。

仕上げにノイズを追加する

先ほどまでで声のいじくりは終わったので、最後は仕上げにノイズを乗せることでよりラジオっぽくしていきますが、ノイズを追加するかどうかは必要に応じて選択してください。

手順は以下の通りです。

①ノイズノードを出して、出力をPink NoiseかWhite Noiseかを選択する。

②今回はモノラル音声なのでMono Mixer (2)ノードで声とノイズをミックスする。

③声とノイズのゲインを調節する。

いかがでしょうか。

元の音声と比べるとだいぶラジオっぽくなっていると思います。

これで、わざわざ外部ソフトで加工しなくてもUE5内で完結できちゃいますね。また、パラメータを変数化して元の音声ファイルを残したままプロシージャルに調節可能なのもMetaSoundの大きな利点だと思います。

使い方を調べながら検証するつもりが思ったよりも使いやすかったため、一瞬で記事まで書けてしまいました。

つまり、MetaSoundは素晴らしい！

以上

CC3キャラクターの表情シェイプキーとフェイスリグを残し、Blender Auto-Rig Proのボディリグに統合する

2022-02-09T20:23:35+09:00

　今回の記事はタイトル通りです。

　今回ご紹介させていただく方法は、Reallusion公式のチュートリアル動画やAuto-Rig ProとUE4との連携についての先人様のブログをいくつか参考にまとめたものです。

　こちらの方法を使うことによって、下記メリットが得られると考えられます。

・CC3キャラクターをBlenderにインポートしてもリギングされていないためすぐにアニメーション作成に取り掛かれないが、Auto-Rig Proの自動リグ生成によってこれを解消できる。iCloneなどよりBlenderでのアニメーション制作のほうが慣れている場合は特に推奨。

・フェイシャルリグはAuto-Rig Proの生成機能を使わず、CC3の表情シェイプキーとフェイシャルリグを統合させるため、Reallusionの強力なLive Faceアプリなどは引き続き使える（はず）。

・Auto-Rig ProはUE4やUnityなどのゲームエンジン向けのエクスポートに対応しており、これによってUE4やUnity標準スケルトンとほぼ同様の命名に自動変換してくれるので地味に嬉しい。

　ゲームエンジン側で自動でマテリアルなどを設定してくれるプラグイン（Auto-Setupプラグイン）はあるが、これを使っても標準スケルトンに沿った命名はなされない。ただしマテリアル設定に関してはAuto-Setupプラグインを使うのがよいと思われます。今回の手順はあくまでもスケルトンの入れ替えと、アニメーション作成などのためのみです。

・CC3で作成したヒト型キャラクターやそれ以外のソフト（Blenderなど）で作成したヒト型キャラクターを、Auto-Rig Proで作成したアーマチュアに統一することでリターゲティングが不要になったり簡単になる場合が多い。

CC3でのキャラクター作成～Blenderでのインポートと準備
- CC3からエクスポートし、Blenderでインポートする
- Auto-Rig Proのための事前準備
Auto-Rig Proによるアーマチュア・リグ生成とスキニング

CC3でのキャラクター作成～Blenderでのインポートと準備

CC3からエクスポートし、Blenderでインポートする

　ここは特に難しいことはしません。以下の設定でCC3からFBXエクスポートします。

　エクスポートされたFBXをBlenderにインポートします。

インポート時の設定はデフォルトのままでOKです。

Auto-Rig Proのための事前準備

　テンキーの1を押して正面から見ると、おそらく足がZ＝0の面に設置していないことになっているので、アーマチュアを選択した状態で、足がZ＝0にくるようにします

（X軸を示す赤色の線に合わせる）。

　その後、Aキーでアーマチュアとすべてのメッシュを選択した状態でCtrl+A→「適用：全トランスフォーム」をします。

　また、このままだとメッシュ内部に骨があって見えづらいので、以下のように「最前面」にチェックを入れます。

　次に、後で誤って操作しないようにするために各パーツのメッシュ（身体、服、靴、眼球、口、舌、髪の毛などすべて）それぞれに対して、頂点グループをすべてロックします。ちなみに、左クリックした状態でドラッグすると一気にロックできます。あるいは、下向きの「＞」を押すと「すべてロック」というボタンがあります。

Auto-Rig Proによるアーマチュア・リグ生成とスキニング

アーマチュアの自動生成と修正

　キャラクターのメッシュをすべて選択した状態で、Auto-Rig ProのメニューからGet Selected Objectsを押します。

　すると、元のアーマチュアが非表示になりますが、後の作業のためにアーマチュアを再度表示します。

　ここからはAuto-Rig ProのSmart機能を使って、アーマチュアを生成します。Smart機能を使う際、首、アゴ、肩、手首、背骨のルート、足首のアタリをつけていくことになります。

　先ほどAuto-Rig Pro:Smart内のGet Selected Objectsボタンを押した後、メニュー内がAdd Neckなどのボタンに変わっていると思うので、そちらを押すとアタリをつけるためのマーカーが追加されるので、再表示した元のCC3アーマチュアをもとにアタリをつけていきます。

　配置し終えたらGoボタンを押します。Auto-Rig Proのバージョンによってはこのとき、フェイシャルリグを生成するか聞かれますが今回はCC3のフェイシャルリグを統合することが目的なので生成しないようにします。

　すると、アーマチュアが自動生成されますが、元のCC3アーマチュアに対してずれているので各ボーンの位置を修正していきます。なお、手足などは左右対称に位置が移動されるので、片側のみでOKです。

足の3か所（leg_ref.l, foot_ref.l, toes_ref.l）

ひざ（thigh_ref.l）

※重要！！必ずしもCC3アーマチュアの位置に合わせる必要はなく、間違った方向にまがらないようにすること。ひざはCC3アーマチュアよりもすこし前に出すような感じにするとよい。

腕（shoulder_ref.l, arm_ref.l）※正面視でも調整すること。

　ここもひじ関節に注意。画像よりも後ろ（画像上方向）にずらすとよいかもしれません。ボーン位置が適切でないと後で問題が発生しますが、後述するように修正することもできます。

　他のボーンと同様に、指のボーン位置も合わせた方がよいです。

（UE4オプション）UE4標準スケルトンに合わせる

　UE4に持っていく場合は、標準スケルトンの仕様上、背骨の数を4つにしたほうがよいです。これをするにはいずれかの背骨（spine）を選択した状態で、Auto-Rig ProのメニューからLimb Optionsボタンを押して数を4にします。これはGoボタンでアーマチュアを生成する際にも設定できるのでそこで4つに設定していれば変更する必要はありません。

　さらに、ツイストボーンも追加した方がよいそうです。これをするには、腕のボーンを選択した状態で、Limb Optionsボタンを押してTwist Bonesを2~4にします。脚に関してはよっぽど左右のねじれが激しくなければ増やさなくてもよいそう。

（備考）Secondary Controllersについて

　なん氏によるブログ記事（AutoRigProの解説：その2 Smart編 - 当たったらどうすんだよ）より、Limb Optionsのほかにもセカンダリコントローラ設定ができますが、TwistコントローラはBlender独自仕様であり、ゲームエンジンにそのままエクスポートはできないためAdditiveのままでもよいそう。

リグの自動生成

　ここまでできたら、Auto-Rig Proのアーマチュアを選択した状態で、Match to Rigボタンを押します。するとリグがアーマチュアに従って自動で生成されます。

リグが上手く生成されない場合

　生成されたリグを見ると、脚は真っすぐですが、上腕や下腕のリグはねじれているように見えます。このようなときは肘関節のボーン位置などが原因のことが多いので、　Match to Rigボタンの上のほうにあるEdit Reference Bonesボタンを押してボーンを再度位置修正し、Match to Rigボタンを押してリグを再生成、という工程を繰り返します。

上は修正前（リグのねじれが激しい）、下は修正後。

自動スキニングする

　所望のリグが生成されたら、オブジェクトモードで最初にアウトライナーからメッシュをすべて選択し、最後にリグをShiftを押しながら3Dビュー上で選択した状態で、スキンメニューにあるBindボタンを押してしばらく待ちます。すると、Auto-Rig Proのリグに従ってメッシュが自動でスキニングされます。なお、Mesh Binding設定にてスキニングのメソッドをHeat MapかVoxelizedから選択することも可能です。

　※ゲームエンジンに持っていく場合は「体積を維持」のチェックは外す方がよい。

　リグを動かしてみるとAuto-Rig Proのリグに従ってスキニングされていることが確認できますが、CC3のフェイシャルリグは動作しなくなっています。なので、これらを統合する作業に入ります。

Auto-Rig ProのリグとCC3のフェイシャルリグの統合

　まずはCC3のアーマチュアから不要なボーンを削除します。オブジェクトモードでCC3のアーマチュアを選択し、編集モードに切り替えます。

　サークル選択などを使って顔以外のボーンを選択して、Xキー→ボーンを削除します（胸にあるボーンも忘れずに削除）。

　オブジェクトモードに戻り、CC3の残ったアーマチュア（フェイシャルリグ）を選択し、Shiftを押しながらAuto-Rig Proのリグを選択し、Ctrl＋Jでリグを統合します。統合後、フェイシャルリグがメッシュの内部に隠れますが問題ありません。

　次に、Auto-Rig Proの頭部のリグにCC3のフェイシャルリグが追従するようにします。ワイヤーフレーム表示に切り替えてCC_Base_Headボーン（CC_Base_Facialに隠れてます）を選択し、ボーン設定からc_head.xをペアレントに設定します。

ウェイト修正する

　今回は、髪の毛や服などすべて自動スキニングしたため高確率で修正が必要になります。そもそも髪の毛や服を自動スキニングしない方法もありますが、今回はすべて自動スキニングしたものとして修正の仕方の例を挙げておきます。

　前提として知っておくことは、Auto-Rig Proの命名規則として、プレフィックスのないものは基本、できあがりのスケルトンのボーンとなるもの、"c_"のつくものはコントローラです。なので、ウェイトはプレフィックスのないものにつけていくことになります。

・頂点グループhead.xで首以外を選択してウェイト1.0で割り当て

・首の頂点グループにまつげが含まれていたりするので首以外の部分をウェイト削除

・体メッシュ以外は、それぞれのメッシュに対して頂点グループメニューから「未ロックグループを削除」でOK

※基本的には、最初にロックしたCC3ですでにスキニングされたものだけを残すイメージです。なのでhead.xもすべてウェイト削除でよいかもしれません。

（備考）服のスキニングの別の方法

　こちらのツイートの方法を使えば、服は自動スキニングせずに身体メッシュから転送して対応できそうです。

【Auto rig pro・服追随】
①服・体の順番にメッシュを選択。
②スペース押し、メッシュデータの転送→頂点グループを選択。
③左下項目で最接近を選択。補間面をすべてのレイヤー（All Layers）選択。
④これで全ての頂点グループが服に転送される。
参考（https://t.co/NB93E8yIZX）
— ahobaka (@ahobaka) 2019年1月19日

（UE4オプション）UE4-Aポーズにする

　CC3でもエクスポート時にAポーズを指定していますが、ここでいうAポーズとは同じAポーズでもUE4標準に近いAポーズを指します。

　厳密にいえば、Blenderでのリグ＆アーマチュア再生成＆CC3表情シェイプキー統合（要するに今回の方法）を用いないのであれば、CC3でエクスポートする際にUE4-Aposeを指定することができますが、今回の方法はBlenderで、かつ、AutoRig Proを使うことになるためUE4-Aposeでエクスポートは行わず、通常のAポーズでエクスポートしていることになります。そのため、AutoRig Proの機能を使ってUE4のAポーズに近づける必要があります。
　Set PoseでAポーズを選んでApply Pose at Rest Poseボタンを押した後に、Match to Rigボタンを押すことでUE4のAポーズに近いものとなります（Auto-Rig ProのAポーズはUE4のAポーズに非常に近い）。

（オプション）rootの子ボーンの追加

　rootに子ボーンを追加したい場合は、c_trajにペアレントすれば上手くいった。

GASでダッシュアビリティを実装しよう！（アビリティにキー入力を関連付ける）

2022-01-04T18:36:32+09:00

　らくするです。
　今回は、いまアツいGameplayAbilitiesプラグインを使ったダッシュアビリティ（ダッシュ以外にも幅広く使える！）の実装について紹介したいと思います。
　本記事で紹介する方法はダッシュ以外にも色々と使い道があるため、GASの導入時についでに実装しておくといいかも…なんて思ったり。
※本記事の実装方法を用いて生じたいかなる問題に対しても責任を負えませんのでご了承ください。

　今回の記事を書くに至った経緯としては、GameplayAbilitySystemによるダッシュ（スプリント）を実装しようとしたとき、GameplayAbilityクラスを1つだけ使ってShiftキーのPress/Releaseの判定をするように実装するのがブループリンターには少し厄介だったためです。
　例えば、GameplayAbilityクラスを「歩行」と「走行」の2つのアビリティを用意して、インプットアクションによるイベントを使ってShiftキーを押したら「走行」アビリティを発動し、離したら「歩行」アビリティが発動するように仕組めば可能ではあるのですが、あまりスマートじゃないように思えます。

　GameplayAbilityごとにキー入力を関連付けるというのはかなり多用しそうな処理であるにも関わらず、紹介や解説の記事・動画はあまりないようでしたので、自分なりにまとめてみようと思います。

　誤っている部分やよろしくない記述が散見されるかもしれませんので、もしよろしければコメントやDMでご指摘いただけますと幸いです。

　今回の実装にあたって、GASShooterのコードの一部の他に、Twitterでのあいす氏（@koorinonaka）からの下記リプライを参考にいたしました。ご助言ありがとうございました。

https://t.co/AgtR3eV8ST
4.6.2 Binding Input to the ASC にInputPressed/Releasedへの実装が書いてあります。ちょっとこの辺は仕様がややこしいですね。。GiveAbilityで渡すFGameplayAbilitySpecに指定するInputIDが一致してればAbilityTaskのInputPressedでイベントが発行されるって感じです。
— あいす (@koorinonaka) 2021年12月23日

GASの導入
ダッシュの実装
完了

GASの導入

　今回使用したのはUE5EAです。
　GASをプロジェクトに導入するにはC++を使った初期セットアップが必要ですが、これについては、他のブログ様などでもよくご紹介されている
おかわりはくまい氏によるセットアップ方法の紹介記事が非常に参考になります。
　当該記事についてはタイトルだけ下記しておきます。

・GameplayAbilitiesの使い方(セットアップ編) - おかわりのアンリアルなメモ

ダッシュの実装

前置き

　話を振り出しに戻しますが、なぜGameplayAbilityクラスを1つでダッシュを実装しようとすると面倒なのかについて少しだけ…。

　今回、肝要となるのが以下の、WaitInputPress/WaitInputRelease（特に後者）というキー入力のPress/Releaseの監視をしてくれるAbilityTaskになります。

　え、そいつら使えばすぐできるんじゃ…？

と思われるかもしれませんが、これらのAbilityTaskはすぐには使えません。
各GameplayAbilityをキー入力に紐づける必要があり、そのためにはプロジェクト設定のアクションマッピングだけでなく、C++を使って紐づける必要があるためです。

GameplayAbilityにキー入力を紐づける

　本記事では、おかわりはくまい氏によるセットアップ記事の通りにセットアップしたものを改変して実装していきます。

EnumでインプットIDを定義する

　定義する場所はどこが最適なのかわからないのでプロジェクトのヘッダーに定義しました。
　DisplayNameは適当でも大丈夫ですが、各アクション名はプロジェクトのアクションマッピングと同じ名前にしておきましょう。
　開発を進むにつれてインプットアクションを増やす場合はその都度、EAbilityInputIDも増やしていけば良いだけです。

プロジェクト名.h

#pragma once

#include "CoreMinimal.h"

UENUM(BlueprintType)
enum class EAbilityInputID : uint8
{
	// 0 None
	None				UMETA(DisplayName = "None"),
	// 1 Confirm
	Confirm				UMETA(DisplayName = "Confirm"),
	// 2 Cancel
	Cancel				UMETA(DisplayName = "Cancel"),
	// 3 Sprint
	Sprint				UMETA(DisplayName = "Sprint")
};

※今回は参考にしたGASShooterにConfirmやCancelといったInputIDが定義されていたので同様に追加しております。
これはおそらく、WaitForCancelInput / WaitForConfirmInputといったAbilityTaskで用いるものと思われますが、詳しく調べてないためここでは説明無しです。

GameplayAbilityクラスを拡張する

　BPでアビリティ毎のバインド先の変更が簡単にできるよう、MyGameplayAbilityクラスを作成します。

MyGameplayAbility.h

#pragma once

#include "CoreMinimal.h"
#include "プロジェクト名/プロジェクト名.h"
#include "Abilities/GameplayAbility.h"
#include "MyGameplayAbility.generated.h"

UCLASS()
class プロジェクト名_API UMyGameplayAbility : public UGameplayAbility
{
	GENERATED_BODY()
	
public:
	UPROPERTY(BlueprintReadOnly, EditAnywhere, Category = "Ability")
		EAbilityInputID AbilityInputID = EAbilityInputID::None;
};

MyCharacterクラスを改変する

（変更点）
・インクルード対象にMyGameplayAbilityクラスおよびプロジェクトのヘッダーを追加する。
・AbilityListをMyGameplayAbilityクラスの配列にする。
・InputIDに対してキー入力をバインディングするためのBindASCInput()を宣言。

MyCharacter.h

#include "CoreMinimal.h"
#include "GameFramework/Character.h"
#include "プロジェクト名/プロジェクト名.h"
#include "AbilitySystemInterface.h"
#include "MyGameplayAbility.h"
#include "MyCharacter.generated.h"

UCLASS()
class プロジェクト名_API AMyCharacter : public ACharacter
{
	GENERATED_BODY()

・・・

public:
	UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = Abilities, meta = (AllowPrivateAccess = "true"))
		class UAbilitySystemComponent* AbilitySystem;
	UAbilitySystemComponent* GetAbilitySystemComponent() const
	{
		return AbilitySystem;
	};

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Abilities)
		TArray<TSubclassOf<class UMyGameplayAbility>> AbilityList;
};

protected:
	void BindASCInput();

	bool bASCInputBound;

（変更点）
・InputIDを削除。
・MyGameplayAbilityクラスを継承した各アビリティのBPクラスで設定したAbilityInputID != 0であればその値をInputIDに、それ以外はInputIDに-1が割り当てられるように。
・BindASCInput()の処理を記述。

MyCharacter.cpp

・・・

void AMyCharacterBase::BeginPlay()
{
	Super::BeginPlay();
	if (AbilitySystem)
	{
		if (HasAuthority() && AbilityList.Num() > 0)
		{
			for (auto Ability : AbilityList)
			{
				if (Ability)
				{
					if (static_cast<int32>(Ability.GetDefaultObject()->AbilityInputID) != 0)
					{
						AbilitySystem->GiveAbility(FGameplayAbilitySpec(Ability.GetDefaultObject(), 1, static_cast<int32>(Ability.GetDefaultObject()->AbilityInputID), this));
					}
					else
					{
						AbilitySystem->GiveAbility(FGameplayAbilitySpec(Ability.GetDefaultObject(), 1, -1, this));
					}
				}
			}
		}
		AbilitySystem->InitAbilityActorInfo(this, this);
	}
}

void AMyCharacter::SetupPlayerInputComponent(UInputComponent* PlayerInputComponent)
{
    Super::SetupPlayerInputComponent(PlayerInputComponent);

・・・

    BindASCInput();
}

void AMyCharacter::BindASCInput()
{
	if (!bASCInputBound && IsValid(AbilitySystem) && IsValid(InputComponent))
	{
		AbilitySystem->BindAbilityActivationToInputComponent(InputComponent, FGameplayAbilityInputBinds(FString("ConfirmTarget"),
			FString("CancelTarget"), FString("EAbilityInputID"), static_cast<int32>(EAbilityInputID::Confirm), static_cast<int32>(EAbilityInputID::Cancel)));

		bASCInputBound = true;
	}
}

①GiveAbilityで渡すFGameplayAbilitySpecにInputIDを指定することで、各GameplayAbilityとInputIDとを紐づけます。
②BindASCInput()内のAbilitySystem->BindAbilityActivationToInputComponentによって、先ほどEnumで定義したInputIDに対応するキーがPress/Releaseされた際にインプットアクションが発行され、さらに①で紐づけられたInputIDに対応するGameplayAbilityがActivateされるようになっています。

　なお、AbilitySystem->BindAbilityActivationToInputComponentの実行タイミングはSetupPlayerInputComponentの後にしていますが、
　おそらくネットワーク対応ゲームの場合はOnRep_PlayerStateのときも含めて二回とすることが望ましいです（InputComponentが存在しない可能性があるため）。
※bASCInputBoundは二重にBindASCInput()が実行されないようにするための値なので、ネットワーク対応でない場合は不要。

ダッシュのGameplayAbilityクラスを作成する

　MyGameplayAbilityクラスをBP継承したGA_Sprintを作成します。
　作成したら、クラスのデフォルト設定にてAbilityInputIDをSprintにしておきます。
ちなみに、上記②のようにインプットアクションをGameplayAbilityにバインディングしているため、キャラクターのBP内で「インプットアクション○○」→「TryActivateBy~~」などを記述しておく必要はありません。
　つまり、ダッシュ以外のGameplayAbilityを追加した際は、
・EAbilityInputIDと、プロジェクトのアクションマッピングに同名のアクションを追加する。
・追加したアビリティBPの設定から、EAbilityInputIDを選択する。
これだけを行うだけで、キャラクターのBP内でアビリティ発動の処理を記述する必要がなくなるというわけです。

　中身は必要最低限で以下のような感じにしました。
Start/Stop Sprintingの中身はキャラクターのMovement Componentを取得してSetMaxWalkSpeedで移動速度を変更しているだけです。

完了

　うまくいけば、ダッシュのキーを押すとアビリティがActivateされてStart Sprintingによってスピードが上がり、キーを離すとWaitInputReleasedのOnReleaseから続くEndAbilityが実行され、Stop Sprintingによってスピードが下がって歩行に戻る　といった挙動が実現しているはずです。

　無駄な部分やより良い方法があればぜひ教えていただけると幸いです。

「オーストラリアの自然」アセットで使われている道路マテリアルの中身を見てみる（1）

2021-12-13T15:54:20+09:00

※この記事は、シェーダーに精通していない私の勉強のための備忘録みたいなものです。そのため、間違った部分がある場合がございます。

こんにちは、らくするです。

すっかりクリスマスシーズンですね。

今回は、永続無料コンテンツである「オーストラリアの自然」で使われている道路マテリアルの中身がどうなっているのか、ざっくりと見ていきたいと思います。

www.unrealengine.com

なぜ中身を見ようと思ったのかと言いますと、この道路、単純なマテリアルではなく地面と馴染ませるようにされていたり（馴染ませる部分の詳細についてはまた後日ですが…）、その他いろいろと工夫されている点が多い（らしい？）ので一度見てみたかったからです。

道路のメッシュについて
マテリアルについて

道路のメッシュについて

道路メッシュ

道路のメッシュは画像のように、おおよそ長さ3500cm,幅897cmとなっています。

緑色のフレームは単純コリジョンです。

ベースカラーテクスチャ

また、ベースカラーテクスチャは上のように4096*1024となっており、メッシュのUVはV座標0→1までぴっちり配置なので長さ方向に対して若干縮められますね。

マテリアルについて

それでは中身を見ていきます。全体は以下の画像の通りです。

道路マテリアル（全体）

これでは少しわかりづらいので、一旦下側の部分と最後のContactShadows部分を排除します。ちなみに排除した下側部分は、ランドスケープの地面マテリアルとより馴染ませるための部分、ContactShadowsは陰影の調整部分です（内部でワールドポジションオフセットとピクセル深度オフセットを調整している）。

今回見る部分以外を排除したマテリアル

大まかな内容は画像中にコメントで入れておきました。

以下、備考です。

・（ベースカラーについて）

　中央上のオーバーレイについてはみつまめ杏仁さんが以下のツイートで非常にわかりやすく図説されていますが、思った以上に計算コストが高そうです。

ゲーム画面でPhotoshopのオーバーレイと同じ表現がコスト高なことを説明したくて調べてたら、UE4にマテリアル関数が用意されてて、それを調べたらとても解りやすかった件#UI制作 pic.twitter.com/DhHXlMpkGV
— みつまめ杏仁 (@MMAn_nin) 2020年4月21日

・（PDOについて）

　道路メッシュは略半円筒形状になっており、ピクセル深度オフセット（PDO）によって、メッシュのぶっ刺し感を低減しています。PDOが低いほどカメラ奥行方向の深度が深い（奥にある）と見做されるやつで、ディザ抜きと併用した馴染ませ用途なんかでもよく使われてます。

　このマテリアルではベースのPDOと詳細のPDOとを乗算していますが、実際には今回簡易化のために排除してしまった部分が馴染ませの肝となる部分なので、ここまでではたぶん見栄え…というかぶっ刺し感の低減には大きく影響はしません（大事なところが抜けていてごめんなさい）。

・（法線の合成について）

　上の画像中ではだいぶ割愛して書きましたが、法線の合成はおそらく慣用的な手法で計算しているものと思われます。合成計算について気になる方は是非調べてみてください。BlendAngleCorrectedNormalsなんかでもいけるのではないでしょうか。

　また、MF_ReconstructZ中で使われているDeriveNormalZは、二軸の成分から残りの成分を計算するためのものです。わかりやすさのために、FP_GunのノーマルマップからRG成分だけを抜き出して、法線の再構築（B成分の計算）を行いました。

DeriveNormalZによる法線の再構築

　このように、法線情報は2軸成分があれば残り1軸の成分は計算により求められるので、通常のノーマルマップのBチャンネルに別の情報を入れることもできます。これはメモリ節約術として時々見かけることがあります。圧縮形式などなどが変わってくるのでテクスチャの品質に影響したりするかも…。

ストアのコンテンツは本当に教科書ですね。

次回、今回排除した部分について見ていけたらと思います。

第16回UE4ぷちコン振り返り　その③～カーソルを筆に変更する（筆先の動きもつける）～

2021-10-05T18:10:23+09:00

ぷちコンの審査結果発表会も終わりましたが、ありがたいことに賞をいただくことができたのでこのまま逃亡しようとしていた（嘘です）振り返り記事を再開します。

今回紹介するものはこちら↓

概要
要約
実装方法
最後に

概要

前回の記事で紹介させていただいたペイントシステムでは、カーソルがそのままデフォルトのものなのでそれを自前の筆に置き換えよう！っていう内容です。

また、上の動画をご覧の通り、筆の移動に合わせて筆先も動いていますね。

単純にカーソルを画像に置き換えるだけなら

・Set Mouse Cursorを使う方法

・UIに配置したimageをTickでマウス位置に追従させる方法

が一般的だと思いますが、これらの方法では筆先の動きをつけることができません。やっていることはかなり後者の方法に近いですが、少し工夫して実装することにしました。

要約

実装方法を簡単にまとめると

・筆スケルタルメッシュをシーンキャプチャーでテクスチャに描画（常に更新）し、そのテクスチャをUIのimageに設定

・筆スケルタルメッシュのアニメーションBPにマウスの移動量を与える

です。

他にも、筆スケルタルメッシュを直接カメラに映し出すといった方法もあるかもしれませんが個人的には上記の方法のほうが手っ取り早いと感じたのでこちらを採用しました（ほかにも理由はありますが後述します）。

実装方法

スケルタルメッシュを用意する（blender）

今回は、グレイマンを人体改造ロボット改造したものを筆としました。

※意外にも審査員の方たちは初見で気づかなかったようですが…。その①の記事でも述べた通り、当初作成予定だったウケ狙いゲームの名残ですｗ

blenderを使って、インポートしたグレイマンのデフォルトのスケルトンを削除し、引き延ばした頭に新しいスケルトンを作成した至極雑な作りです。

これにSubstance Painterでペペっとテクスチャを作りました。

アニメーションBPを用意する

筆スケルタルメッシュができたら、UE4にインポートします。

筆スケルタルメッシュのスケルトンをベースにアニメーションBPを新規に作成し、AnimGraph内でCCDIKを使用して筆先がいい感じに動くようにしました。

アニメーションBPは以下のように組んでいます。

後述するキャンバスウィジェット（前回記事のWB_TestCanvas）からTarget Effector Location X/Yに値が代入され、実際のCCDIKにはTarget Effector Location X/YにFInterp Toで徐々に値が近づいていくEffector Location X/Yが入力として与えられています。

※BPにいっさい処理を組まず、WB_TestCanvasから直接Effector Location X/Yに値を代入しても大丈夫ですが筆先の動きが固くなってしまいます。

筆アクターとシーンキャプチャーをレベルに配置する

Actorクラスを継承したBP_GrayBrushを新規作成し、Skeletal Mesh Component（筆スケルタルメッシュ）を追加し、上記で作成したアニメーションBPを設定しておきます。

このBP_GrayBrushをレベルに配置し、さらにScene Capture 2Dがうまい具合にBP_GrayBrushをテクスチャ内に収めるように配置します。

※応募作品ではサブレベルに配置しました。

Scene Capture 2Dの設定

ここで、投影方法は平行投影にしました。なぜ今回の実装方法を採用したのかという理由の2つ目（要約のところでほかの理由と述べたやつです）は、筆の投影を平行投影にしたかったためです。

→この記事を書いている途中で透視投影に変更してみたらそっちのほうがいい感じになりましたｗ

上手くできるとこんな感じでキャプチャしてくれます。テクスチャレンダーターゲットTRT2D_Brushのサイズは480*480にしました。

ここまでできたら、新規マテリアルM_TRT2D_Brushを作成します。

TRT2D_Brushのままでは筆の部分だけがアルファの値が0という情報を持っているので、反転させます。

キャンバスウィジェットに追加処理を組む

最後に、前回記事で作成したWB_TestCanvasを若干変更していきます。

まず、ウィジェットに新規のイメージ（BrushのImageにM_TRT2D_Brushを設定）を追加します。

上の画像のようにAlignmentなども調整しておきます。

また、テクスチャサイズが先ほど述べた通り480*480に対して、ウィジェット上では600*600となっていますが、解像度より負荷軽減を優先しました。

で、前回記事にてオーバーライド処理を施した関数On Mouse Moveの途中に以下の処理を追加します。

マウスの移動量を筆スケルタルメッシュのアニメーションBPに与える前にノーマライズして値をベクトルの大きさが1になるように抑えています。2.0を乗算しているのは調整用です。

あ、それとコンストラクトイベントなどで筆アクターのAnim Instanceを取得しておくこともお忘れなく。

他にも細かい処理（例えば、描いてる時より描いてない時のほうが筆の位置が高くしたり、音を鳴らしたり）を色々追加してますが記事の本題から逸れるので説明は省略します。

→完成！

最後に

実装方法は簡単ですが、私は思いつくのにだいぶ時間がかかってしまいました…。

しかしペイント中に筆が現れるようにするだけで、クオリティや描き心地がずいぶん上がったように感じたのでやりがいがありました！

次回の記事その④（ラスト）では「描いた線にそって道を生成する方法」について紹介します。

→力尽きて断念しました。。

第16回UE4ぷちコン振り返り　その②～画面上にペイントする～

2021-09-21T21:27:43+09:00

今回は、第16回UE4ぷちコンで実装した画面上へのペイントシステムをどのように実装したかなどを紹介したいと思います。

★目次★

概要
要約
実装方法
最後に

概要

作るもののイメージはこちら↓

大神インスパイアを突如として受け、お絵描きできるようにしてみました。インクが滲んで広がるような表現をしたくてTextureRenderTargetとかで試行錯誤したけど、最終的にはNiagaraをUIに描画するやり方が一番いい感じに。
ぷちコンに使えるかは…知らない。タスケテ。#UE4 #UE4Study #UE4ぷちコン pic.twitter.com/hWH6dpmnB9
— らくする (@raksul_01) August 23, 2021

マウスの左ボタンを押している間は黒いインクが塗れるようなものになっています。

さて、やり方としてはUE4を触っている方であれば

TextureRenderTarget2D（以下、TRT2D）を用意し、ウィジェットに描画。マウス座標に応じてDraw TextureあるいはDraw Materialを極短い間隔（Tickなど）で使用することによってTRT2Dに対して疑似的にペイント。

といった方法が通常は思いつくかなと思います。

しかし、今回は少し違ったアプローチで実装してみました。というのも、上記の動画をご覧の通り、インクが滲んで広がるような表現をしたかったためです（大神の筆しらべもよく見ると広がっていますね）。

※上述したような通常の方法で、DrawTextureを用いて同じ座標にサイズを徐々に上げたテクスチャを描画するような手法を使ってみたところ、TRT2Dの更新頻度が上がって負荷が半端なくなりました（当然そうなるのはわかっていたことですが）。

また、以下の前回記事で紹介した、大神の筆しらべをUnityで再現したものはUE4で言うTRT2Dのようなものを使用しており、インクが広がるような表現までは再現していませんでした。

要約

使用したUE4のバージョンは4.26となります。

今回のアプローチを簡単にまとめると、

ウィジェット上にNiagaraエミッタをマウス座標にフレーム毎に更新
当該Niagaraエミッタからスプライトパーティクル（TRT2Dを使用するやり方で描画するTextureの代わり）をスポーン

という手法になります。

Niagaraパーティクルをウィジェットに描画するにあたって、下記のプラグインを使用しました。無料です。

使い方はプラグイン制作者様のチュートリアルを見た方が早いので、本記事では割愛します。

実装方法

ナイアガラシステムの準備

それでは実装方法に入りますが、UE4（特にウィジェットブループリント）の基礎知識があるものとして細かいところは省略しつつ進めます。

本記事の真似をするだけではできないかもしれませんのでご容赦ください。また、名付けは適当なので任意でお願いします。

まずは、ナイアガラシステムNS_Brushを作成します。エミッタとしてSimpleSpriteBurstを追加しておくとやりやすいと思います。

今回、最低限下記のエミッタ設定を行いました。

Emitter StateのLife Cycle ModeをSelf, Loop BehaviorをInfinite
→パーティクルのスポーンが止まらないように
Particle StateのKill Particles When Lifetime Has Elapsedのチェックを外す
→パーティクルが消えないように
Spawn Rateを750以上
パーティクル更新にScale Sprite Sizeを追加して、1秒で1.2倍くらいのサイズになるようScale Vector 2DBy Curveを設定

あとはスプライトに適用するマテリアルですが、以下のような適当なものを用意しました。

ナイアガラエディタでのプレビュー用マテリアル(M_BrushParticle)

これは、あくまでもナイアガラエディタ上でプレビューするためのマテリアルです。

使用しているプラグイン Niagara UI Rendererの都合上、マテリアルドメインをUser Interfaceにしたマテリアルも別途用意しておいてください。

結局、応募作品もこの雑なマテリアルのままにしてしまいました。

後述するNiagara System Widgetで使うマテリアル(M_BrushParticleUI)

ウィジェットの準備

キャンバス用に新規ウィジェットWB_TestCanvasを作成し、パレットからNiagara System Widgetを追加します（NS_BrushInkと名付けました）。

また、Borderを最上層に追加します（試したところ、これがないと後のOn Mouse Button Downなどが動作しないみたいです）。

そして、NS_BrushInkを選択した状態で詳細タブから以下のように設定します（マテリアルの名前が誤字ってますが気にしないでください）。

Material Remap Listはナイアガラエディタでスプライトに適用していたM_BrushParticle（左）をウィジェットへの描画用にM_BrushParticleUI（右）に置換する設定です。

また、Auto Activateのチェックを外さないとマウスのボタンを押してなくても常に描かれてしまいますので外しておきます。

次に、On Mouse Button Down関数をオーバーライドして以下のようにノードを組みます。

変数PointsはVector 2Dの配列で、今回は使いませんが後に「描いた線に沿った道の生成」の紹介記事で使うことになります。

ちなみにこの処理は、左ボタンを押したポイントのみにインクを塗るためのものであり、このまま連続して線を描くときには次に説明する処理が必要となります。

この処理のために、次はOn Mouse Move関数をオーバーライドして以下のようにノードを組みます。

始めの部分でエミッタの位置をカーソル位置に更新しています。

マウス位置にエミッタ位置を更新

その後のブランチ処理は、左ボタン押下状態かつマウスが一定距離移動した場合にのみナイアガラシステムをアクティベートするものです。これがないとエミッタの設定上、カーソルを動かさなくても同じ場所に永遠にパーティクルがスポーンされ続けてしまいPCが爆発します。

マウスが一定距離移動したらナイアガラシステムをアクティベート

最後の処理（拡大画像無し）は、先ほどと同様、Pointsにアイテムを追加するものです。

ポーンの用意

適当なポーンを用意して、インプットアクションやキー入力でWB_TestCanvasをビューポートに表示する処理を追加します。

また、必要に応じてSet Show Mouse CursorやSet Input Mode Game And UIなども入れる必要もあります。

※上記のようなFlip Flopの使用はバグの元となりやすいため推奨しません。真面目に作るならbool値を使いましょう。

---セットアップ完了！---

上手くいけば、Hキーを押せばペイントできるようになり、再びHキーを押すことでキャンバスが排除されるようなシステムができているはずです。

最後に

実際の応募作品ではBPC_MagicBrushというコンポーネントにウィジェット作成だとかスペシャルスキルだとかほとんどの機能を入れて、どのポーンに対してもペイント＆道生成＆スキルを簡単に実装できるようにしていました。

絵筆の機能をまとめてコンポーネント化したもの

以上、間違いなどがあればDMやコメント等で教えてください！

第16回UE4ぷちコン振り返り　その①～構想について～

2021-09-20T19:53:51+09:00

らくする (@raksul_01)です。今回がブログ初投稿となります。

今回は、株式会社ヒストリア様主催の

「第16回UE4ぷちコン（https://historia.co.jp/ue4petitcon16）」に参加したので、

開設しっぱなしだった本ブログの重い腰を上げて、その振り返りについて書いていきたいと思います(-。-)y-゜゜゜

ちなみにぷちコン参加は今回で3回目でした。

まず初めに

今回のぷちコンのテーマは「みち」

「みち」に通ずる何らかの要素（道でも未知でも）が入っているゲームであれば基本的には何でもOKというルールになっています。

いやあ、このテーマは苦戦しました。前回の「かわる」というテーマが如何に何でもできてしまうテーマであったかを痛感しました。

着想について

テーマが発表されたときに漠然と考えていたアイデアは

筆で道を自分で描く2～2.5Dのゲーム
MetaSoundとNiagaraを組み合わせて音の道を見立てたオーディオビジュアライザー的なもの
未知の筆を持った伝説の書道家ミッチーがひたすら道を爆走する筆アクションFPS、名付けて「Shodo-ka Simulator」

です。マインドマップの作成などは一切行っていません(^O^)

そして実際にこれらをすべて途中まで作っては、すべてボツとなりました（この時点で約2週間を浪費。MetaSoundの勉強にはなりましたが）。

で、結局何を作ったの？の前に・・・

上述の漠然としたアイデアをご覧の通り、当初から謎に「筆」というものに頭が捉われていた私は、以下のような動画を見つけました。

www.youtube.com

そう、「大神」です。超有名タイトルですね。私は未プレイですが（ん？）

上の動画は、その大神における筆しらべをUnityで再現したものです。

私はこの動画に衝撃を受けました。

・・・いったいぜんたいWhat happens？

これはUnityを使用しているけど、UE4でも何とかして似たようなものを作ってみたい！そして真似するのはお絵描きの見た目部分だけに留めて、それを活かして今回のテーマに沿ったゲームを作りたい！と・・・

こうして、”筆しらべの見た目をUE4で似せてみる”という険しい道のりへ進む決意をしたのでした。

応募作品について

長々とお話しましたが、今回の応募作品はこちら↓

youtu.be

個人的には概ね満足いく結果が得られたと感じます。

※完全な真似ではなく、ゲーム内容に合致する見た目に調整しています。

裏話的なあれですが本当はストーリー構想もあって、ムービーシーンなども作成していました。

ですが、作っているうちに応募要件である動画時間や、提出期限を考えると適切でないと考えて途中で路線変更して、レベル（ページ）選択形式のパズルゲームにしようという流れになりました。

そうすれば、基本システムさえできてしまえばそのあとはギミック追加などでボリュームを補えますし(;'∀')

必要タスクの抽出

一番重要である、筆しらべの見た目再現を実行するにあたり、大神の動画を見ながら細かいタスクを書き出しました。

筆しらべ突入時に画面が停止し、ポストプロセス処理＆紙面が斜めになる
→作品の仕様上、停止＆斜めにならないほうが良かったため除外
描いた部分から徐々に墨汁が幅方向に広がる（滲む）
→実現
描いている途中、墨汁がかすれる
→おそらく私の作ったものにも実装可能と考えるが、時間の都合により断念
描く動きに合わせて筆先が動く、また、柄の部分が傾く
→筆先の動きは実現
→柄が傾くこと完全に忘れていた・・・

他にも色々あるとは思いますが、このようにして、プレイヤーが描くときの感覚が気持ちよくなるための、様々な工夫がなされていると感じました。

そして、これら一つ一つが私の頭を悩ませるものとなったのです。

なんせ調べて出てくるようなものではなかったので（いくら調べても一切のヒントも得られませんでした＿(　_´ω`)_）。

なお、今回の作品の「インクで線を描く方法」「描いた線に沿って道を生成する方法」「筆先に動きをつける方法」の実装の仕方については以降の記事で紹介予定ですので、お楽しみに。

その他・感想

最後に、意識した点、良かった点/反省点などを挙げていきたいと思います。

ある意味、見た目再現（どうやってるのかな？という部分を自分なりに考えて再現してみること）が一番学習したかったことだったので、時間の都合上不足した点もあるがほぼ満足。
リセット機能も用意していた。
非効率なOpen Levelで再読み込みする形式ではなく、GameModeに用意されたReset Level()などを使用するリセット。この場合、アクタごとにリセット時のイベントを用意する必要があり、面倒だった。
面倒だった割に、動画では紹介できていない。
これまた動画では紹介できていないが、特定範囲の外に出ようとすると「絵本の外には出られないよ！」というメッセージ表示も用意してあった。
グレイマンの形をした筆は「Shodo-ka Simulator」という当初作りかけていたバカゲーの名残だったりする。

実は見た目再現と道生成を実装した後、ゲームにどう落とし込むかで相当苦労した。プロシージャル生成マップをひたすら突き進むゲームにするのか、単発ステージを複数用意したパズルゲームにするのか、など。
絵本の世界を題材としており、ドローモード時のアウトライン描画とのギャップが激しく生じるようにしたかったので、背景グラフィックはあえてリアリスティックなものに。
上記に時間をかけたので、UI等に関してはクオリティを損なわない程度のものに。ただし、ちょっと雑すぎたかも。吹き出しは頑張った。
ゲームってユーザビリティがすごい大事だと思ってるので、ぷちコンと言えどもチュートリアルを丁寧にすることを心がけた。
今回もめちゃめちゃに学びが多かった。開催ありがとうございました。