みつまめ杏仁

アンリアルエンジン(UE4)でGUIを作るためにゴニョゴニョしてます。UIデザイナーの皆様の助けになれば幸いです。

UMGでマテリアルアニメーション制御 2020

蝉の声はまだ数が数えられるくらいしか聞こえてこないけど、確実に夏に向かっていることを感じます。この時期なると現れるジャンボタニシの卵塊を見るたびに、早く駆除されてほしいと願いつつ、アクセントカラーはいくら綺麗な色でも場所を選ばないとダメだなと改めて強く思う今日この頃です。またひとつ自然から学ばせてもらいました。

さてさて

UE4Widgetブループリント は独自のアニメーションタイムラインを持っています。配置したWidgetパーツに対して動きをコントロールする以外に、オーディオの再生、タイミングを見て関数を呼び出すEventTrack、マテリアルパラメータコレクションの値を制御といったものが用意されています。

f:id:hiyokosabrey:20200712104038p:plain

 

最近 この Material Parameter Collection Track の有効利用方法を考えていて思いついた一つが、パターンアニメーションのコントロール

基本構造のイメージが先で、いい見せ方ないかな~と考えていろいろやっているうちに結構日が経ってしまった。

Twitterに貼った動画がこれ。

 

見た目にワールドフリッパーのタッチエフェクトのモロパクリです。再現方法をいろいろ悩みつつ試していたら、なかなか複雑でよくできてるなと感心させられました。ランダム要素を入れつつもきちんと制御するところはされていて、アーティストとプログラマの仕事の境界が大変気になります。アーティスト比重が高ければ素晴らしいツールを使えていることになるので、それはそれで羨ましいし、逆にプログラマ比重が高ければ、アーティストとプログラマの協業レベルがとても高くないとできない仕事で、そんなプログラマとタッグを組めるアーティストが羨ましい。

 

てなわけで

今回の内容はマテリアルパラメータコレクションを使ったアニメーション制御ということで、複数のWidgetパーツを、ひとつのアニメーショントラックを共有して動かすという方法になります。

とりあえず基本的な構成をメモとして残しておくことにします。

 

必要なアセットはだいたい4つ

  • アニメーションパターンをアトラス化したテクスチャ
  • マテリアルパラメーターコレクション
  • Widget用のマテリアル
  • Widgetブループリント


今回テクスチャを節約したかったのでグレースケールテクスチャを採用。色付けにカーブアトラスを使ってます。

 

 

アニメーションを作る

パターンはPhotoshopで作りました。

f:id:hiyokosabrey:20200712150109p:plain

タイムラインパネルから、フレームアニメーションモードに切り替えたら、レイヤーをアニメのセルに見立ててモリモリ描いていきます。

f:id:hiyokosabrey:20200712150707p:plain

各レイヤーを順番に表示する、しないを切り替えるだけの単純なアニメーション。

f:id:hiyokosabrey:20200712150642g:plain

サイズは 64x64px。
512pxのテクスチャに収めたかったのと、キリよく8パターンにしたかったので、

f:id:hiyokosabrey:20200712150939g:plain

これだけだと、MaterialParameterCollectionを使う楽しみが少ないな・・・と考えてたところに ワーフリ と出会ったのでした。

同じ要領でもう2種類、パターン数の違うのを作りました。

f:id:hiyokosabrey:20200712151921g:plain ←4パターン (128x128px)

f:id:hiyokosabrey:20200712151930g:plain←5パターン (102x48px)

 

このパターンズを1枚のテクスチャにアトラスとして並べます。

f:id:hiyokosabrey:20200712152121p:plain

これをUE4にインポートします。

重要な設定が3つあります。

ひとつは タイリング設定。

f:id:hiyokosabrey:20200713230844p:plain

テクスチャを繰り返さない Clamp にしておかないと、パターンが終わらなくなります。

2つめは MipMap、3つめはTextureGroupです。

f:id:hiyokosabrey:20200713231326p:plain

基本 UI にミップマップは不要です。テクスチャグループもUIに設定するので、ミップマップが作られることはないと思いますが、明示的に NoMipMapsを選択しておきます。

 

マテリアルパラメーターコレクションを作る

f:id:hiyokosabrey:20200712175328p:plain

f:id:hiyokosabrey:20200712175539p:plain

マテリアルパラメータコレクションはプロジェクト全体で利用できるので、管理しやすいように名付けます。

 

f:id:hiyokosabrey:20200712194859p:plain

ここではScalar値を一つだけ登録しました。パラメーター名は time としています。

 

 

Widget用のマテリアルを作る

ベースとなるマテリアルの全体図

f:id:hiyokosabrey:20200712195706p:plain

マテリアルドメイン(右端のノード)は User Interface にします。

普通にカラーテクスチャを使う場合は下のようにつなぎます

f:id:hiyokosabrey:20200712200138p:plain

 

マテリアルパラメータコレクションを利用するには専用のノード

検索で coll と入力すると出てきます

f:id:hiyokosabrey:20200712201356p:plain

f:id:hiyokosabrey:20200712201509p:plain

このノードの設定値として、に用意しておいたマテリアルパラメータコレクションをセットします。

f:id:hiyokosabrey:20200712201811p:plain

プロジェクトが認識しているマテリアルパラメータコレクションがプルダウンから選択できるので、名前を憶えていれば簡単に選択できます。

マテリアルパラメータコレクションを選んだら、ParameterNameも簡単に選べます。

 

 

今回はインスタンス化して汎用的に使いたいのでパラメータはそれなりに用意。

f:id:hiyokosabrey:20200712201119p:plain

 キラキラパターンについては、4色の固定カラーにしたかったのもあって、若干ノードを組み替えてスリムにしたベースマテリアルを用意しています。画像は省きますが、マテリアルパラメータコレクションの使い方は同じ要領です。

 

TilingU と TilingV でテクスチャの切り出す大きさを指定、OffsetV で切り出す位置を指定します。

 

f:id:hiyokosabrey:20200712230042p:plain

値は UVなので、 対象のピクセル数をテクスチャ解像度で割り算します。上図の場合、左上が(0, 0)で、上から64ピクセル下あるパターンだから

 

64÷256 = 0.25  OffsetV は 0.25

 

今回全て左端から並んでいるので、OffsetUは考慮しません。

 

切り出すサイズは 128x128px なのですが、 今回のテクスチャサイズが長方形なので TilingU と TilingV の値は異なります。

 

128÷512 = 0.25  TilingU は 0.25

128÷256 = 0.5 TilingV は 0.5

 

上のベースマテリアルから、マテリアルインスタンスを作って、計算した値をセットするだけで、一枚のテクスチャからいろんなパーツを切り出して、Widgetで利用できます。

マテリアルインスタンスはコンテンツブラウザの対象のベースマテリアルのアイコンで右クリックして作ります。

f:id:hiyokosabrey:20200713223523p:plain

ダブルクリックするとパラメータだけが編集できます。

 

 

Widgetブループリントを作る

あとは表示のための用意としてUMGのキャンバスにImageパーツを配置して、マテリアルインスタンスをセット。

f:id:hiyokosabrey:20200713230138p:plain


新しくアニメーションを追加して、さらにトラックを追加します。

f:id:hiyokosabrey:20200713224027p:plain

プルダウンリストから Material Parameter Collection Track を選択。

f:id:hiyokosabrey:20200713224045p:plain

用意しておいたマテリアルパラメータコレクションを選んだら、今度は変化させるパラメータを追加して、キーを打ちます。

f:id:hiyokosabrey:20200713225523g:plain

パーツごとのアニメーションがあれば合わせて追加しておきます。

 

あとは、このアニメーションを、カスタムイベントで呼び出して再生するようにすれば勝手にアニメーションします。

 

 

f:id:hiyokosabrey:20200713232331g:plain

 

今回のサンプルは目コピーなので、記事にするのはここまでにしておきます。

 

 

マテリアルパラメータコレクションをUMGで制御できるということ

かつて、まだこの方法に気づいていなかった頃、トリッキーな方法でやってました。

 

limesode.hatenablog.com

 無駄にアニメーション用のパーツやプロパティを消費してさらに、EventTick で値を移すという処理を行っていました。

タイムラインを使えば、アナログみのある味わい深いアニメーションを作ることができます。

 

追記: 7/14

この記事を公開したところ、マテリアルパラメータコレクションを使わずとも、直接Imageパーツなどにセットしたマテリアルのパラメータもアニメーショントラックでキーを打つことができるのを教えていただきました。

 

ヒストリアさんとこのブログでも扱っておられました。

イテばし さん情報ありがとうございます。

 

historia.co.jp

実はものすごく欲しかった仕様で、「なんで無いんだろう・・・」で時間が止まってました。いやもう恥ずかしい限りです。ありましたね。

Unity触っててアニメーションキーを打てると分かった時にすごく悔しかった思い出がよみがえりました。でももう大丈夫です。もうUE4さえあれば何もいらないw

 

というわけで、以下の記事を手直します。

<<<

Material Parameter Collection Trackを使えば、EventTickを使わずに済みます。

ひとつ問題があるとすれば、それは Material Parameter Collection の持つ値は『共有』しているということ。シングルトン的なユニークUIであれば、全く気にしなくてもよいのですが、インスタンス化したり、汎用的に扱う場合は注意が必要です。同じパラメータを参照していれば、タイミングが同期してしまうからです。かといってコレクション内にパラメータを増やすのも、メモリの消費が増えるし、だれがいつどの値を書き換えるか管理が必要になってきて、却って面倒な状況になりそうです。

なので、UI表示での使いどころとして提案したいのが

  • ダイアログウィンドウ(モーダルなやつ)
  • 画面フェード
  • ロゴやチャプター名表示、画面見出し
  • 字幕
  • NowLoding

あたりでしょうか。

 

アニメーションでキーを打てるので、もうEventTickを使わずに済みます。

当時は何を思って使えないとなっていたのか今となっては謎ですが、これでもっと凝ったことが気軽にできそうな予感。多分気づけていなかっただけだと思う。悔しい。

 

今回は、マテリアルパラメータコレクションで値を共有しているのを踏まえたアニメーション制御の方法ということで、一例をご紹介させていただきました。

 

ちなみに

今回作ったマテリアルでは、引き算を加えてるので、試しにパーツごとに時間差を作ってみたのが以下

f:id:hiyokosabrey:20200714001923g:plain

 

 

アニメーションパターンを作るのはそれなりに大変だけど、フェードやスケールアニメーションに飽きてきたなーと思い始めたら試してみてはいかがでしょうか。

 

ぜひぜひ

パターンアニメーションでユニークなUI演出ライフを!

 

UMGでのアニメーション終了検出について

 今回の記事はEditorUtilityWidgetを触ってみようとアレコレしているうちに、気が付くとアニメーションの終了検出について調べる流れになったのでそのメモです。

 UIはユーザがゲームと対話するために存在しているので、何かとリアクションするのが重要です。そのリアクションには何かしらの変化(動き)が起きるので、リアクションとして認識させるには、それなりの「間」が必要になります。

 この見た目の挙動を「ふるまい」とか「マイクロインタラクション」などと呼ばれることもあります。

 UIデザイナーが設計して作るリアクションは、細かいパーツの構成を熟知しているUIデザイナーがコントロールできる環境が理想。

 見た目の部分なんで、UIデザイナーに苦情が来やすいのもありますし、アニメーションに関しては表層部分なのでUIデザイナー自身が修正&調整したほうが、プログラマへの負担は減るはずです。

 UIのアニメーションがプログラマ制御だった時代は、いちいち細かい値(12フレームでアルファ0.12ゆうてましけど、やっぱり0.125に変えてもらっていいすか、みたいな)を伝えて修正をお願いしていました。いい時代になったものです。個人的にそんな時代を経験しているので、UE4のUMGがとても素晴らしく映っています。

 

 さてさて、前置きが長くなりました。

 私はUIのアニメーションは大きく2種類に分けられると考えています。

 

  • 終了を待つ必要のない演出やエフェクト的なアニメーション
  • 終了しないと次のフェーズに進まないアニメーション

 

 これはアニメーションの再生と終了のタイミングをどう扱うか、という視点で分類しています。

 前者は、選択中のアイテムがハイライトされている状態や、バックグラウンドで「賑やかし」として動いているようなもの、ローディングなどの待機アニメーション。途中でインタラプトされても問題ないようなシンプルで繰り返す動きのものが多いです。

 後者は、画面のフェードや遷移、決定演出、モーダルウィンドウの開閉演出、など起承転結があり、ゲームの呼吸とかテンポ感に関わる大事な要素です。さらにこの時間はゲームの進行を統括するプログラマにとっては待ち時間となります。

 UIデザイナーがパーツを動かしている間、待ってくれているわけです。こまめに再生中かどうかチェックして終わったら通知、または事前に掛かる時間をタイマー予約するか。という仕組みになると思うのですが、UE4ではアニメーションが終了したことを通知する仕組みをブループリントで用意することになります。その方法をこのブログで何度か書いてきましたが、最近のバージョンでは、その辺りが少し進化しているようなので、自身のアップデートのためにちょっと調べてみました。

 

 その結果、アニメーションの終了を検出する方法を4パターン見つけました。

  追記)Twitterに更新報告をした後に教えてもらった方法も加えて計 6パターンになりました。

 

 

 Get End Time ノードを使う

f:id:hiyokosabrey:20200517173803p:plain

 結構以前から利用させてもらっています。私にとっては馴染み深い方法。

 上の緑色やつが Get End Time ノード。事前にアニメーションの尺を調べておいて、タイマーをセットする方法。アニメーションごとに専用のカスタムイベントが必要になります。ちょっと複雑でノードが多いのが面倒だなと思ってました。

 残念ながら、ポーズ中(4.25で、set Game Paused 使用で試してみました)だと、Set Timer by Eventノードが動かないようなので、ポーズ中ではこのしくみは使えません。Tickは動いているので、自前で時間計測すれば可能ではありますが、この後の方で紹介するイベントを使ったほうが良さそうです。

 

 

Play Animation with Finished Event ノードを使う

f:id:hiyokosabrey:20200517192608p:plain

  4.23で追加された比較的新しめのノード。終了したときの処理をシンプルにつなぐことができるのでノードが少なくてスッキリ。これはいいですね。

 ちなみにこのノードは右上に時計のバッジがついてるので、Delayノード同様に関数では使えません。

 ポーズ中(4.25で、set Game Paused 使用で試してみました)だと、アニメーションは再生されますが、Finishedのピンはポーズ解除後に実行されるので、ポーズ中のUIではこのノードは使えないのが痛い。未来のVerに期待したいところ。

 ブログのコメントでご指摘いただきました。upota さんありがとうございます。

 

 

on Animation Finished イベントを使う

f:id:hiyokosabrey:20200517174050p:plain

 結構古いバージョンから存在は知っていたけど、再生するアニメーションの内容に関係なく終了したらとにかく呼び出されるので、アニメーションを複数抱えたWidgetの場合、対象のアニメーションかどうかの判別や仕分けが必要になったり、Play Animation ノードから離れた場所にこのノードを置くことになるので、若干イベントグラフが読みにくくなる印象があって、なんとなく避けていました。

 

 

Eventキーを利用

f:id:hiyokosabrey:20200517195627p:plain

 タイムラインにイベントトラックを追加して、トリガーとしてキーを打ちます。そこで関数やイベントを呼び出すようにする方法。個人的にUMGのタイムラインの操作方法がやや癖があって難しく感じるのと、操作的なうっかりが起こりやすかったり、呼び出す関数名やイベント名を探してセットするのがちょっと面倒な気がするので普段使わないのですが、好みの分かれるところかもしれません。

 

 

事前にバインドしておく方法

f:id:hiyokosabrey:20200518143826p:plain

K.Y.さんに教えてもらった方法その1

事前に対象のアニメーションオブジェクトに対してバインドしておいて、あとは好きなタイミングで再生するだけ、というタイプ。これなら個別に終了を検出できる。

常駐するWidgetの場合 Unbindのしくみも合わせてコントロールする必要がありそう。

 

 

 

対象のアニメーション専用のイベントを使う

f:id:hiyokosabrey:20200518144333p:plain

K.Y.さんに教えてもらった方法その2

アニメーション名でノード検索すると見つかるやつ。

f:id:hiyokosabrey:20200518144603p:plain

グラフ上でノード検索しないと出てこない代物です。

on Animation Finished イベントはザックリしてますが、これなら確実に対象のアニメーション終了を検出できて、さらにグラフ上でもわかりやすく配置できそうなのはよさそうですね。

 

K.Y.さんありがとうございます!

 

 

 まだこのパターン以外の方法があるかもしれません。Play Animation with Finished Eventノードか、個別の AnimationFinished(xxx) はフロー的にわかりやすくなる感じなので、終了を待ちたい時には積極的に使っていこうと思います。

 ただポーズ中はうまく動かないのがあるので注意。

 こうして挙げてみると選択の幅が広がったので、なるべく可読性とかメンテナンスのしやすさを基準に選んでいきたいなと思うのですが、パフォーマンス的にはどうなのかが気になるところ。引き続き情報のアップデートはしていこうと思います。

 

 アニメーションが終わったことを通知できる仕組みさえ作っておけば、あとからアニメーションのクオリティアップや尺調整は、ずっとUIデザイナーのターンです。自分で責任を持つ範囲が明確になれば、いい仕事ができるはずです。

 確認ダイアログなどで登場演出が終わってないのにキー入力を受け付けてしまったり、フェードアウトしてる途中でバックで絵が変化していたりというカッコ悪いUIにしないためにも、イベントドリブンなUI表示を作れるようにしておきたいものです。

 

ではでは 今回はこの辺で

ステキなイベントドリブンライフを!

 

 

 

 

 

Photoshopで墨流しテクスチャを作る

 連続でネタ投稿というのも自分にとっては面白いチャレンジになっていたので楽しかったでのすが、仕事の準備したり気になってたゲームを始めたりで、結局小ネタツイートは2週間で終了してしまった。ネタ切れなんてとんでもない・・・と思ってはいるのだけど、事前にいくつもネタを思いつくことはないので、常にネタ切れ状態であることもまた事実(汗)・・・お題箱作ろうかな。

 

 さてさて、

 いろいろUIデザインを考えていくとき、ただカタチを置いていくだけだと面白くないので、素材感を乗せてみたりするわけです。最初はネットのフリー素材で試してみて、いい感じになりそうだったら自作します。Photoshopであーだこーだと試行錯誤するわけですが、そこで今回たまたま面白いパターンができたのでメモ程度に記事にしておきます。

 

 元のモチーフは『墨流し』です。マーブリングとも言われたりするやつです。

 美術の時間とかで技法として見かけたことがあるかもしれません。

 技法については以下のエントリーで詳しく知ることができます。

http://nihonga-hobbytimes.com/2018/04/18/%E3%80%8C%E5%A2%A8%E6%B5%81%E3%81%97%E3%80%8D/

 漫画でも混乱中の思考を表現するときなんかに見かけることがあります。

 

 今回は、そんな墨流しをシームレスなパターンとして作成します。

 シームレスだとゲーム画面で容量の節約が出来て便利そうです。

 

 歪みツールはドキュメントの端の処理ができなさそうだったので、仕上げに使うとより効果的だと思います。

 

 まずPhotoshopで新規ドキュメントを作ったら、モノクロで進めるので D キーを押して描画色と背景色を白黒にリセットします。解像度は 1024x1024で作成してしますがタイリングの回数と相談で、いろいろなサイズを作りながら調整することにはなります。

 

フィルタ > 描画 > 雲模様1

 雲模様1は描画色と背景色の2色でランダムな模様を生成します。

f:id:hiyokosabrey:20200513133938j:plain

 

 

フィルター > ノイズ >ノイズを加える

 グレースケールでノイズを掛けます

f:id:hiyokosabrey:20200513134654j:plain

 

 

フィルタ > ピクセレート > 水晶

 うまく黒と白の粒が散らばってくれるといい感じになります。

f:id:hiyokosabrey:20200513134839j:plain

 

 これで基本ができました。かんたん。

 ここからは 渦巻とスクロールを交互に数回繰り返します。

 

フィルタ > 変形 > 渦巻

f:id:hiyokosabrey:20200513135508j:plain

 

 

フィルタ > その他 > スクロール

 シームレスにしたいので、ラップアラウンドを有効にします。

f:id:hiyokosabrey:20200513135725j:plain

f:id:hiyokosabrey:20200513135735j:plain

 適当な距離を見計らってずらします。

 

再び渦巻

f:id:hiyokosabrey:20200513135934j:plain

 

渦巻スクロール渦巻スクロール ・・・・ を何度か繰り返します。

 

 渦巻は毎回向きと量をいじるのをオススメ。

 

 で、できたのがこれ。

f:id:hiyokosabrey:20200513140138j:plain

 

 これをPhotoshopのパターンとして登録してタイリングを確認してみるとこんな感じ。

f:id:hiyokosabrey:20200513140335j:plain

 グラデーションマップで色を変えると・・・

f:id:hiyokosabrey:20200513140956j:plain

 

さっそくこのテクスチャをUE4にインポートして遊んでみました。

ポストプロセスマテリアルを作ってこれをセット。

Lerpでカラーを乗せて、グレーマンのCustomDepthをTrueにして、歪み用のノイズテクスチャでうにょうにょと動かせば出来上がり。

f:id:hiyokosabrey:20200513145718j:plain

このブログは動画をアップできないので、Twitterに貼ります。

動いてるのはそちらをみていただければ。

 

 

 

UMGだと、体力ゲージのデバフ表現だったり、フォントマテリアルとして乗せてみたりしても面白そう。

 

ではでは今回はこのへんで

素敵な墨流しライフを!

 

最近のツイートまとめ

f:id:hiyokosabrey:20200503093516p:plain

UE4でUI制作の何かに役に立てれば~と思って始めてみましたが、どうなんだろう。少しはキッカケになってUE4を触り始めた方がいればいいなぁとそんな妄想をしながら先週もネタをツイートしていました。この記事はそのまとめです。

 

先週のフチドリを改造

f:id:hiyokosabrey:20200503094320g:plain

 

 

前に紹介したフチドリを、一つのマテリアルで表示、非表示を切り替えられるように改造しました。

 

f:id:hiyokosabrey:20200503094609p:plain

テクスチャのカラー(RGBの方)にフチドリの色が入っているせいで、表示した際に若干フリンジが出てしまっていたのを、軽減する対策を入れてみました。

f:id:hiyokosabrey:20200503100448p:plain



 

可変できる引き出し線

f:id:hiyokosabrey:20200503101534j:plain

一見無駄に折れてるように見えて、でもなんとなくいい感じの引き出し線をメニューのフォーカスに追随するようにしてみました。

 

 

 動きはTwitter に動画を上げているので上のリンクから確認できます。

 昔スプライトでUIを作るしかなかったときに、すごく面倒な指定書をプログラマに渡して作ってもらった記憶がある。別のハードではポリゴンで作ったりして、当時頂点を触ることができなかったので長さの違うのを数タイプつくって切り替えてもらってた。

 

 今はUMGで、一人でさくっと作れてしまう時代。

f:id:hiyokosabrey:20200503102233p:plain

f:id:hiyokosabrey:20200503102302g:plain

 

f:id:hiyokosabrey:20200503111253p:plain

ただこの方法には欠点があって、サイズがマイナスになると見た目がおかしくなる。

f:id:hiyokosabrey:20200503102848g:plain

 

一応アレンジしたやつも作ってました。

f:id:hiyokosabrey:20200503114246j:plain

ワールドに置いたオブジェクトの座標をスクリーン座標に変換して、あとはラインにマテリアルでアニメーションを付けました。動きは以下のツイートから確認できます。

 

 

 

 

2Dだけどテキストの影で3Dっぽく見せる

f:id:hiyokosabrey:20200503114705j:plain

 

 

 動きはTwitter に動画を上げているので上のリンクから確認できます。

 普通に3Dでつくればいいんですけどね。

 最初、マウスカーソルのホバー演出でダイナミックに開閉するメニューを作ろうとしたんですが、VerticalBox内での表示順を制御する方法が見つけられなくて、いろいろキャンバスをいじっているうちにこうなりました。

 せっかくなので、テクスチャとかUMGのアニメーションを使わないでやってやろうという謎の使命感で仕上げました。

 

 影がぴょんぴょんするのはこんなマテリアル。

f:id:hiyokosabrey:20200503115435p:plain

移動量を加算する直前で、0.0 か 1.0 をかけると動きをOn、Offできる仕様。

 

 

 

ディゾルブを作ってみた

f:id:hiyokosabrey:20200503120006j:plain

 

 

 動きはTwitter に動画を上げているので上のリンクから確認できます。

 Epicのおかずさんがツイートされてるのを見て、気になって公式のPVを見てたらふと作りたくなった表現です。

 

 

  0:20 付近から漫画のコマ割りを活かした2Dのデモが入るのですが、絵パーツごとに動いてるので、汎用的に使えるマテリアルを作れないかと試してみたものです。

 

f:id:hiyokosabrey:20200503121407p:plain

 ふるふる震える動きは、下のようなノイズテクスチャを用意して頂点に加算しています。

f:id:hiyokosabrey:20200503121540p:plain

 TexCoodinate の Tiling の値を小さく( UVの範囲を小さく)して、各頂点がバラバラに動かないようにしています。

 あとはWidgetブループリントで出現アニメーションとディゾルブの量を制御してます。

f:id:hiyokosabrey:20200503121926p:plain

 きっちり1画面に収まったのが気持ちよかったです。

 私が少年期に出会った雑誌に1画面プログラムというコーナーがあったのを思い出しました。1画面に収まるようにテキストベースでぎっちぎちにプログラムのコードを書くチャレンジングな企画で、ブループリントでもやってみたら面白いかもしれません。

 変数名やら関数名、ピン名を極限まで少なくして可読性なんて気にしない、とにかく動けばいいんだ的なやつ。ノードの重なりはNGということで。こういうミニマムでも面白いことができるというハックみたいなのに憧れます。

 

 

あつ森のUIが気になるシリーズ スマホ

『あつ森』とは Nintendo Switchのソフト、『あつまれ どうぶつの森』 のことです。

f:id:hiyokosabrey:20200503123339j:plain

 

 

 動きはTwitter に動画を上げているので上のリンクから確認できます。

 実際に遊んでて動きが気になってよく見てると、波打った表現が入ってたので真似してみました。完全再現が目的ではないので、それっぽくしてるにとどめています。

 ただできそうというだけが動機で、やってみたらそれっぽくなったというやつです。

 

 ちょっとテクスチャを節約したかったので、1/4だけ作って並べてます。

f:id:hiyokosabrey:20200503123741p:plain

 これを4枚並べると、Imageパーツそれぞれに Get Dynamic Material するか、別にCreate Dynamic Materialしたものを、あとから4つのImageパーツにセットすることになるので、なんかなーと思っていたら、マテリアルパラメーターコレクションがあるじゃないかと、閃いたわけです。

f:id:hiyokosabrey:20200503124223p:plain

f:id:hiyokosabrey:20200503131234p:plain

 サイン波をタテ方向のUVに足してやることで、ピクセルを波型に引き伸ばしています。

 今回UMGのアニメーションと同期させたかったので、見えないパーツを一つ追加してそのアニメーションさせた値をTickで拾って流しこんでます。

f:id:hiyokosabrey:20200503132309p:plain

 

いやほんと、細かい動きが実装されてますね。

 

 

 

あつ森のUIが気になるシリーズ カーソル編

f:id:hiyokosabrey:20200503132646j:plain

 

週末ネタ切れ感ハンパないですね。またしてもアツ森からいただきです。

 

 

 文字列の長さに合わせて、カーソルの長さも可変してて、さらに決定ボタンを押したときはカーソルの端にパターンアニメーションのような演出が入ります。

 これもUMG使いとしてはやってやれるとこを見せないわけないはいけません。(謎の使命感)

 まずカーソルのパターンアニメーションを用意。

 

f:id:hiyokosabrey:20200503133659g:plain

 

これをテクスチャにする。128x512 ちょっと贅沢かも。
 f:id:hiyokosabrey:20200503133642p:plain

表示した際に左側は位置が固定なので、反転したパーツを置いてもよかったかも。

そうするとテクスチャ半分で済むな。と、今この瞬間この記事を書きながら思いました。

 

色とUVはマテリアルでコントロール

f:id:hiyokosabrey:20200503134956p:plain

これを Box にすることで可変する長さに対応。

f:id:hiyokosabrey:20200503133850p:plain

 

選択肢用の子Widgetを用意しています。

f:id:hiyokosabrey:20200503134537g:plain

ヒエラルキーは、CanvasPanel を親にして、カーソルとテキストブロックをひとつづつ配置。

カーソルは親キャンバスにフィットするようにアンカーを設定。

親キャンバスは、子に配置したテキストブロックに対して、Size to Content を設定しておくだけ。

 

あとは、フォーカスの切り替えと決定時のアニメーション再生をWidgetブループリントで制御。

f:id:hiyokosabrey:20200503135848p:plain

UMGのアニメーションでスプライトシートとかUVシーケンスみたいなのが使えたらこういうパターンアニメーションを仕込むのラクになると思うんだけど、もっといい方法があるのかな。

一定のパターン数を表示したら、イベントディスパッチャーで通知して、ウィンドウそのものを消す流れにしています。

 

 

 

今回はここまで

 やることとデザインが決まっていればサクッと作って表示するとこまでは簡単なのですが、やっぱりUI制作の一番の難しさは、未来との折り合いの付け方です。

 ゲーム制作に慣れてくればある程度の 読み ができるのですが、船を作ってる途中で、陸上も走れるようにしようとか言いだすと、設計の見直しは必須。

 なので、いろんな作り方で臨機応変に対応できるよう日頃から脳筋の柔軟体操をしておくのが大切だなと改めて思う次第。

 UIを研究するにはいい機会なので、みなさんぜひ目コピしましょう。ゴールがある分作りやすいはず。そこから機能性や有用性を広げるアイデアが生まれることを期待して、まず作ってみる。そしてアレンジ。うまくBADケースやユーザーテスト案件に気づけばそれはそれでお宝GETです。

 

 来週はちょっと状況次第なとこがあるので、引き続き、というわけにはいかない気配ですが、余裕があれば続けていきたいと思います。

 

ではでは

すてきな目コピライフを!

 

 

 

 

 

 

 

 

 

最近のツイートまとめ

f:id:hiyokosabrey:20200426003440p:plain

 普段ほとんど呟かないのですが、自宅待機中なので、それとなく何か役に立ちそうなネタを、思いついたものから試して呟やいていこう。そうすれば仕事してる感覚を忘れなくていいかもしれない。と思い立って1日1UIネタ投稿を実践してみたものの、早くもネタ切れ感が・・・

 いくつかツイートできたので、このブログにまとめておこうと思います。

 

 

 

UIでよくやるテクスチャ節約術

f:id:hiyokosabrey:20200425230720p:plain

 

 

f:id:hiyokosabrey:20200425230738p:plain

f:id:hiyokosabrey:20200425230750p:plain

 UIデザイナーで実装を経験した方なら、一度は経験されているのではないでしょうか。

 UE4のマテリアルで復元するので、表示に使うImageオブジェクトは1つで済むというネタです。

 

 

 

あつ森のUIが気になるシリーズ フキダシ編

f:id:hiyokosabrey:20200425231402j:plain

 あつ森は Nintendo Switchのソフト、『あつまれ どうぶつの森』 のことです。

 

 

  動きはTwitter に動画を上げているので上のリンクから確認できます。

 

 結構 たくさんの いいね を頂いてびっくり。

 ルビも振ろうか迷ったけどフキダシを検証したかっただけなので今回はパス。

 一応過去記事を貼っておこう。

limesode.hatenablog.com

 

 

 この後

 ぷちコンの受賞があってブログ記事を書いてたりしたので少し間があきます。

 

 

あつ森のUIが気になるシリーズ DIYカード編

f:id:hiyokosabrey:20200425215409j:plain

 

  描かないと怠けるのでトレーニングも兼ねて、題字と背景のストライプ以外は手描き。

  最初にツイートした時に上げた画像が間違ってたのであとから修正しました。

 

  自分の字がいまいちで、何度も書き直しました。

 以外にぴょんたろうがいい感じに描けたので満足。

 UE4を全く使わなかった。

 

 

 

Photoshopの操作で気になったやつ

f:id:hiyokosabrey:20200425220305g:plain

 

 ちょっと気になってたやつ。

 一度操作した後で Ctrl + Shift + T で重ね掛けしておくと安心、というのを教えていただきました。

 

 

 

レイヤーブレンド『オーバーレイ』を調査

f:id:hiyokosabrey:20200425225752p:plain

 

 

 Photoshopでレイヤーを重ねながら、その計算方法を暴いてやろうとゴニョゴニョやってたんだけど、だんだん面倒くさくなってきて、諦めかけた時にふっと、UE4のマテリアルに関数があったような・・・と思ってUE4起動したらドンピシャでした。

f:id:hiyokosabrey:20200425225808p:plain

f:id:hiyokosabrey:20200425225820p:plain

 

 

古の秘術?

f:id:hiyokosabrey:20200425225910p:plain

 

 シェーダーで縁取らないので事前にPhotoshopでの仕込みが必要です。

 Switchの深世海をちまちまプレイしてたのもあって、メンダコを元ネタにしてキャラを描きました。それとなくアメリカンな雰囲気を醸してみたつもり。

f:id:hiyokosabrey:20200425225840p:plain

f:id:hiyokosabrey:20200425225944p:plain

f:id:hiyokosabrey:20200425230002p:plain

 当時は、今ほどシェーダーをいじることができなかったので、いくつか用意されているテクスチャのブレンド方法を組み合わせるくらいしかできなかった。そのときはフチドリは加算半透明で、2種類のブレンドを1枚にまとめられなかったけど、今回試した方法だとマテリアル1個でできるんじゃ、と後から思ってみたり。よし次のネタにしよう。

 

 

 

 

そろそろメニュー画面でも

f:id:hiyokosabrey:20200425230538j:plain

 

 

 動きはTwitter に動画を上げているので上のリンクから確認できます。

 

 最近UMG触ってないよね、ということで ScrennPosition のネタで何かUIを作ろうとしたらできた感じ。頑張ってオシャレ感を出そうとしてみたけど難しい。無理やりお花を置いた感じが雑な作りで申し訳ない気になる。

 

 テクスチャあまり使ってないよアピール。

f:id:hiyokosabrey:20200425230045j:plain

 

 

あつ森のUIが気になるシリーズ タヌポートのフレーム編

f:id:hiyokosabrey:20200425232334j:plain

 

 

 動きはTwitter に動画を上げているので上のリンクから確認できます。

 

 またまた大人気 あつ森 のUIからネタを頂きました。ゲームの仕様上ものすごい量のテクスチャメモリを使ってそうなので、どんな やりくり をしているのか気になる。

 大きめのUIパーツはメッシュ使ってる気がする。

 

 どうぶつの森のUIは、ほぼ直線の無い柔らかなシェイプで構成されていて、色の選び方と見せ方の工夫がとにかくステキです。隅々まで丁寧な作りに頭が上がりません。見せたいデザインにちゃんと技術が寄り添っている。そんな印象を受けます。

 

 

 

 

 

 

 以上です

 

 最近なるべくいつもの時間に起きるようにしていて、食事の時間をずらさないようにするだけでもリズムが崩れていない感覚はあるので、このまま維持していこうと思ってます。

 買い物に行くときは徒歩で行くようにしていますが、椅子に座らない時間が長くて、さらに歩く時間も激減したので、さすがに足腰が弱まっていきそうな予感がしないでもない。

 出社できるようになるまで まだ時間がありそうなので、この1日1UIネタ投稿をもうしばらく頑張って続けてみたいと思います。

 

 

最後に

 

 UIデザイナー志望、または現役のみなさま。

もし時間があるなら、ぜひぜひこの機会にアンリアルエンジンでオリジナルのUIにチャレンジしてみたり、気になるゲームの目コピーをされてみてはいかがですか?

 きっといい経験が得られます。たくさんUIを作るほどスキルになって積みあがっていきますよ。

 

 

ではでは

ステキなおうちライフを!

 

 

 

ぷちコンで賞をいただきました!

今日ぷちコンの結果発表ライブを見逃してしまったのが痛恨の極み。

改めまして、

開催いただいたhistoriaさま、審査されたみなさま、参加されたみなさまおつかれさまでした。

昨今のコロナ対応で通常業務もままならない中 なんとか無事に発表会も開かれて、調整やら準備やら大変だったと思います。

ぷちコンというステキな場を与えていただき本当に感謝の言葉しかありません。

次回の予告もあったので安心しました。

 

さてさてその審査発表の結果ですが、なんと

 

徳が高いで賞 を頂きました! ありがとうございます!

 

今回の参加作品はこちらです


【第13回UE4ぷちコン作品】蓮華

 

テーマは「さく」  → ぷちコン詳細ページ

 

相変わらずいろんな「読み」が可能なワードを選ばれるので、ネタの被りを回避しやすいからかなと思うんだけど、その分 奇をてらってしまってなかなか作品としてまとまる気配がないまま三週間ほど経ってしまった。

キャラクターを制御するスキルが無いのはなんとかしないと選択肢が広がらないのを痛感。

 

今回の審査発表にてそれとなくコメントがあったので、

受賞にあたって応募作品制作の簡単な流れとアセットとかBPなんかを一部紹介してみようかと思い、取り急ぎ書くことにしました。

 

 

まず最初に考えたこと(着想)
  • 上空から雫を落として地上の花の蕾に当てると花が咲く(テーマ回収)
  • ゲームパッドのトリガーで左右から風を吹かして雫を左右に寄せる
  • トリガーの引き具合で強い風を当てると雫が小さくなる
  • 花は一つで雫を一定量当てないと開花しない
  • 落下中に雲にあたると、加速度はリセットされて雲のどこか(ランダム位置)から再び落下
  • 途中画面の端を出たりトンボなどの障害に当てると失敗
  • 風のエフェクトでリボンを使いたい
  • いい感じの雫感
  • 芥川龍之介の「蜘蛛の糸」の冒頭のようなイメージ
  • 和風でスタイライズした絵作り

 

 

実際に作ってみて(実践)
  • 標的がカメラに入ってくるまでズレが認識しづらく緊張感がない
  • ある程度落下したらカメラを引くようにしてみた
  • 標的のある位置からまっすぐ上に柱的な光の筋を置いてみた
  • 垂直方向の落下を扱うのに横画面は向いてない
  • そもそも狙って当てた感が弱い
  • ナイアガラを使いこなす時間が必要だった
  • やっぱり物理難しい
  • まだまだ知らないことがいっぱいあった

 

 

ということでどうにかしないと

とりあえず雲のモデルを作って雫を乗せてみたら、ふっと 昔ゲーセンに置いてあったゲーム機(ジャンル的にはコリントゲームとかスマートボールというよりもシーソーゲームというジャンルらしい)で拾円やらボールをゴールまで運ぶやつを連想。

 

ゲームパッドのトリガーで傾きをアナログ制御すればできそうな気がしてきたので、動かしてみたら、狙って落とす感覚が出てきた。

 

PlayerController で左右のトリガー量を検出。

f:id:hiyokosabrey:20200419150316p:plain

このイベントはトリガーに指が触れていなくても毎フレーム?0.0~1.0で値を返し続けます。値の大きい方を十倍にして一つの変数に保持。

それを 雲BP の方からPlayerControllerにアクセスして値を取得。角度に適用というフローにしてみました。雲BPの数を管理しなくてもいいので楽でした。

雲をいくらか配置して遊んでみたら、十分遊べそうな手応えを感じたので超上空からの落下をやめることにしました。

 

記事を書きつつ改めて触ってみたら左右のトリガーの優先判定処理がバグっていたので、スティック操作の方が向いてたなと、今になって思う。

 

 

ただ花が咲くだけなのも単調なので

ハスの資料を漁りながら、花托の不気味さにおののきつつ、四種類ほどの花弁を作ればいいや。それでゆっくり開いたらキレイかな~と甘々なことを考えながらモデルを作ってみたら、花弁一枚つくるのに思いのほか時間がかかってしまい、サクッと作り切れる自信がなくなってくる。

このときアーケードゲーム機のイメージに引っ張られていたのもあってサクッと作れるタイプに変更。

さらに画面が横長なので横に五つ並べて賑やかさアップ。

雲のカタチを考えるときに見ていた仏教系の資料で、五色の彩雲というのがあってそれをヒントに、花が開くとなんかエフェクトを出そう、しかも五色の。

全部咲かすことができたら、何か揃う感じ?

五色といえば・・・あれか(ここでひらめく)

youtu.be

花の数え方にちなんで 輪っかを五つ、カラーをセットして出現するようにしてみた。

 

今年に入っていろいろドタバタしてるし、私自身それほどときめいているわけではないので、そんな自分が例のシンボルを出してうぇーい、ってやるのはどうなのか、と我に返ってしまい非表示に決定。 

 

結局 カウント用の囲み文字だけが残った形。

お手本をみながらお習字しました。

f:id:hiyokosabrey:20200419113158p:plain

輪を平仮名にしたかったのと字面的に四と五だけ漢数字です

 

もっとエフェクトで遊びたかったな。

 

 

縦書き

特にこれといって盛り上がる要素もないままだけど、なんとかそれらしくはなったのが締め切り前日。

急いで体裁を整えなきゃということで、毛筆のフォント入手してインポート。

カウント表示を作り始めたのはいいものの、縦書きにこだわって結構時間がかかってしまった。一二三を縦書きにすると読みにくいので、なんとか十を入れ込もうとしたのが原因。

f:id:hiyokosabrey:20200419154537p:plain

賢い方法が降りてこなかったので、ちょっと強引な方法で対応。

f:id:hiyokosabrey:20200419160131p:plain

とりあえず 百 まではカウント可能。

漢数字で 廿 とか もやりたかったけど、フォントに含まれていなかったので断念。

これについてはまた別途検証してみたいな。

 

 ちなみに「の雫」 はフォントにグリフが無かったのでテクスチャで用意。VerticalBox でタテに並べている。

f:id:hiyokosabrey:20200419161256p:plain

 

 

結局タイトル画面もないまま

ギリギリまで背景描いたり、操作ナビの表示タイミング調整したり、 急いで動画撮って編集できたのが締め切り当日の午前4時。

時期的に仕事がちょうど詰まってなかったのでよかった。

 

 

 

あっさりシンプルな構成とアセット

エンジンのバージョンは 4.24

使用したテンプレートは  Side Scroller

f:id:hiyokosabrey:20200419013353p:plain

 

花と雲はモデルを作りました。

カメラが動かないのと画角が狭いので厚みはほぼ見えない。

f:id:hiyokosabrey:20200419014014j:plain

f:id:hiyokosabrey:20200419014209j:plain

 

背景は載せるのをためらうくらい雑過ぎるのですが、二Kの正方形一枚。

(受賞取りやめになったらどうしよう・・・)

f:id:hiyokosabrey:20200419180832j:plain

カメラのFOVと引きで、意外に距離感が出せたのが割と気に入ってます。

f:id:hiyokosabrey:20200419182402j:plain

 ボカシ掛けたくなってきたので、背景はこの辺にしておこう。

 

このカメラの動きでちょっと試してみたのが こちら。

f:id:hiyokosabrey:20200419203413p:plain


タイムラインはこのFloat型のカーブが一本。

f:id:hiyokosabrey:20200419203609p:plain

この出力だけ作ってあとは、Lerp ノードに値を入れて調整。

カーブエディタをいじるより調整が楽だったので、開始と最終の状態が決定するまではこの方法は悪くない気がする。

 

花弁が開くところは、Vector型のカーブにして、外側の花弁より内側にかけてXYZのカーブで三つの尺を用意。これもカーブの変化量は 0.0~1.0。

同じように Lerpノードで開く量を調整しています。

0~1のカーブアニメーションは掛け算でも扱いやすいので結構重宝します。

 

 

 

最後に

とまぁ今回あまりテクニックとしては目立ったところが出せない分、ビジュアルを頑張ってみた結果、なんとか雰囲気は出せたかなと思ってます。

プレイしてみると、不思議とイライラせずに繰り返し雫を落とし続ける自分がいました。途中ピンボールの玉のように重い感じにしようとしたのですが、むしろこのふわっとした感じが、ある種の落ち着きというか、幻想的な印象を与えてくれている気がしないでもない。

そんな、自分でもちょっと不思議なとこに着地した感のある作品になったと思います。

 

最近啓蒙の甲斐あって UE4を気に入って触ってくれている後輩に、ぷちコン出そうぜ!って言ったら、「いいですね~頑張ります!」というので、こちらも出さないわけにはいかない空気になって、引くに引けなくなってという次第。

ぶっちゃけ去年秋から二月にかけて、忙しくてあまりUE4を触れていない時間が多かったので、久しぶりにガッツリと楽しめました。

 

ステキな応募作品がたくさんある中で、まさか受賞するとは驚きです。しかも徳が高いっていうコトバが、めったに聞かないせいか頭の中でしばらくつながらなかったのが可笑しかった。

 

確かに誰も狙わなさそうな方向性だなとは思ってました。海外製のゲームエンジンだけれど和の表現どんどんやってこーぜ!というのを見せられたらいいなと思ってたのもちょっぴりあります。

 

選んでいただいて本当にありがとうございました。

ぷちコンの存在はとても貴重だと思います。

個人的にはかつてのベーマガのような有難みと期待を感じています。

これからもぷちコンがますます注目を集めてUE4プレイヤーが一人でも増えることを祈りつつ

小さなブログではありますが陰ながら応援していければと思っています。

 

ではでは

ステキなUE4ライフを!

 

 

 

グレースケールテクスチャに現れる謎のゴミドットについて

最近は絵を描いたり、少し前にリリースされたゲームのエゴサしまくったりで、ぜんぜん記事に手が付けられていない状態。図らずも自宅待機で時間が取れるようになったので、グレースケールテクスチャの作成についてちょっと調べてみました

グレースケールテクスチャが大好きなので、このブログでもちょくちょく取り上げているのですが、今回取り上げるきっかけとなったは、Photoshopで作業していると、意図しない誤差拡散が入ることがたびたびあって、ずっと気になっていました

 

例えば下のような図の場合(500%に拡大)

f:id:hiyokosabrey:20200413114249p:plain
自動選択ツールで1色だけ選択するようにして、(↓超絶推奨)

f:id:hiyokosabrey:20200413114117p:plain

選択範囲を確認するとまだキレイな状態

f:id:hiyokosabrey:20200413105849g:plain

 

そこで、カラーモードをグレースケールに変更

f:id:hiyokosabrey:20200411214435p:plain

カラー情報を破棄するか確認されるのでOKすると、ぱっと見ではわからないけど・・・

f:id:hiyokosabrey:20200413110203p:plain

選択範囲で確認するとしっかり誤差拡散が入っているのが分かります

f:id:hiyokosabrey:20200413110051g:plain

これは、モニタで表現するときに、広範囲の色域を たかだか 256段階程度のグレースケールに落とし込むわけにはいかないとPhotoshopが気を利かせてくれているのではないか、と推測しています

とはいえ、途中に入るピクセルの分布にばらつきがあるのが謎ですが、これも高度な計算や配慮のなせる業なのでしょう。きっと。

f:id:hiyokosabrey:20200413113239p:plain

 

実際グレースケールテクスチャを作る際は、カラーで描いたりせずモノクロで作業をするので、上記のような事態は起こりにくい、というか気づきにくいです

 

とはいえモノクロで作業すればゴミドットが入らないかといえば、少しは発生します

 

しかも、ベタ色の面積が大きくなるほど、謎のゴミドットの数が目立つようになります

そもそも

 

グレースケールテクスチャを作るのに、なぜカラーで作業するのか?

 

ゲームUIで使用するテクスチャは、テクスチャアトラスとも言ったりしますが、描画コストを少しでも抑えるために、できるだけいろんなパーツを詰め込んだ状態にします

 

私の場合は、UVの範囲を判りやすくするためにカラーで区分けしたものをレイヤーで管理しています

f:id:hiyokosabrey:20200413211350g:plain

f:id:hiyokosabrey:20200413211425p:plain
こうすることで、あとからパーツの配置を変えるときに便利だったり、何の部品か判らなくなることを防げます

また周囲がボケたパーツの範囲を明確にするというのも重要な役割です

パーツの表示サイズを調べるときもワンクリックで済みます

グレーのみだと色分けが難しいのも理由のひとつ

 

ゲームのUIは、開発中に何度もリサイズや仕様の変更が入ります

なので、この方法でテクスチャを管理する方がなにかと都合がいいのです

 

書き出すときは一旦グレースケールに変換してから、Targa形式で別名保存というフローなので、時折混入するゴミドットが気になっていたのです

 

 

と、ここまでは前置きです

ここからは、ゴミドット混入を防ぐためにPhotoshopの振る舞いについてもう少し検証を進めていきます

 

 

グレースケール化と誤差拡散

グレースケール化した際の誤差拡散の入り方について、サンプルを作って検証してみました

 

RGB → グレースケール

f:id:hiyokosabrey:20200411212723p:plain

例えばこの 元の画像 512x512 カラーモードは RGB

レイヤーは以下の状態

f:id:hiyokosabrey:20200411214606p:plain

背景は 50%(128,128,128)のグレー

 

これを、

先に画像を統合してから、カラーモードを グレースケールに強制変更

f:id:hiyokosabrey:20200411214435p:plain

f:id:hiyokosabrey:20200411212957p:plain

見た目ではわからないけど、自動選択ツール(W) で調べると

f:id:hiyokosabrey:20200411213712g:plain

誤差拡散がばっちり

 

テキストレイヤーを統合せずにカラーモードをグレースケールにすると、

f:id:hiyokosabrey:20200411214037g:plain

誤差拡散は入らない

 

つまりはレイヤーに直接描画したり、統合したりしてラスタライズされているものは誤差拡散が適用されてしまうということになるようです

 

以下の特殊なレイヤーには誤差拡散が適用されないことが判明

  • テキストレイヤー
  • シェイプレイヤー
  • グラデーションレイヤー
  • ベタ塗りレイヤー
  • etc.

 

RGB → モノクロ → グレースケール

次は事前にモノクロにしてからグレースケールにする手順を試してみます

 

モノクロ化する方法は3通りあります

f:id:hiyokosabrey:20200411220416p:plain

輝度成分を元に割り当てるグラデーションマップが一番素直な印象

『白黒』は、モノクロ写真のロジックを理解せずにうかつに触るのは控えた方がいいと思うけど、初期設定で赤と緑が同じというのは意外な結果だった

色相・彩度はこれも意外な結果

調整レイヤーが用意されているので統合せずにグレースケールな見た目にすることも可能

 

で、

直前に上の3つの方法でグレースケールな見た目にしたあと、

カラーモードを変更すると

f:id:hiyokosabrey:20200411230822p:plain

f:id:hiyokosabrey:20200411230847p:plain

f:id:hiyokosabrey:20200411230858p:plain

事前にグレースケールにしておくと誤差拡散の量が軽減されたので効果はあった

『白黒』だと誤差拡散がかからないのは発見

 

少々のゴミドットはもう目をつぶるしかないかもしれない

 

カラーのレイヤー管理を諦めて、始めからグレースケールで作業するという選択肢もあるけど、最初からグレースケールで作業すると、0~255の輝度ではなく 0~100% のK値で扱うことになるので、微妙な諧調の絵を作りにくくなる懸念があるのが敬遠したいのも理由のひとつ

f:id:hiyokosabrey:20200414220353p:plain

f:id:hiyokosabrey:20200414220420p:plain

 ↑ 整数のみで小数点は使えない

 

 

ここで疑問なのが

 

なぜグレースケールにするのか

 

 Photoshopでカラーモードをグレースケールにすると、カラー情報が破棄されているので、例えばTarga形式(*.tga)にしたときに ファイルフォーマットを 8bit で書きだすことができるし、単純にファイルサイズが 約1/4程度になるし、 エンジンに持って行ったときに、自動判別してくれて設定の手間が減ったりする

 

その程度なら

 

グレースケールにせずにエンジンに持って行ってもいいのでは?

 

確かに・・・

RGBの状態の画像を 24bitのTGA形式で書きだして試してみた

インポート設定で Grayscale を選択できる

f:id:hiyokosabrey:20200412204641p:plain

赤色のレッドチャンネルのみが残されて、緑と青が無くなってしまうけど、誤差拡散が入らないのはいい

 

となると、モノクロ画像でインポートしても

f:id:hiyokosabrey:20200412205352p:plain

 キャプチャしてカラーを拾ってみてもまったく損失なし問題なし

 

なんだかちょっと拍子抜けな感じだけど

Photoshopの グレースケール化問題で悩む必要がなくなった

他のフルカラーのテクスチャとは分けた方がアセット管理的に何かと都合がよいのでファイル名にサフィックスをつけることで解決できそう

 

 

 

マスクにコピペすると誤差拡散が適用される

操作の途中でグレースケール化と同じような誤差拡散が適用される事例をあげておきます

 

レイヤーマスクを作成するときに、モノクロ状態の画像をレイヤーマスクとしてペーストすることもよくやります

f:id:hiyokosabrey:20200414204302p:plain

↓こういった抜きのレイヤーが作れます

f:id:hiyokosabrey:20200414204450p:plain

このペースト時にグレースケール化されて誤差拡散が適用されてしまうのです

 

これはレイヤーのピクセルからではなく、レッドチャンネルからコピペすることで誤差拡散を回避できます

f:id:hiyokosabrey:20200414210124p:plain

モノクロで作業していれば、レッド以外のチャンネルでも問題は無い

 

 

グラデーションツールとグラデーションレイヤー

f:id:hiyokosabrey:20200414155409p:plain

これはグレースケール化の操作とは関係ないところで、誤差拡散処理が入ったり入らなかったりする例です

 

私の認識としては

グラデーションレイヤーは後から色味や傾斜、角度などを調整できたり、さらにマスクで濃淡や範囲まで自由自在な優れもの

一方、グラデーションツールは直接ピクセルとして描いてしまうので、角度を決めるときに、それなりに緊張を伴う完全に不可逆な作画ツール

というところでした

 

ところが今回グレースケールテクスチャの検証で気づくことができました

今まであまり解像度の高いグラデーションは禁忌として使わない習慣があって避けていたのですが、今回思い切って大きいサイズのテクスチャでグラデを作ってみたところ

以下のような結果になりました

 ※400%に拡大しています

f:id:hiyokosabrey:20200414163417p:plain

 

グラデーションレイヤーには誤差拡散が入らないので、解像度の高い大きな面積を塗る際には諧調の段差が見えます

レイヤーをラスタライズしてもそのままの状態でラスタライズされます

 

もう一方のグラデーションツールは滑らかに見えるように誤差拡散を適用した状態で描画します

 

この違いを頭に入れおいて損はないと思うので、いつか使い分けが必要な場面で活用したいと思います

 

 

まとめ

グレースケールテクスチャを作る場合は、

  • カラーモードをRGBで作業して問題ない
  • UE4にインポートする際に Grayscale にする(Rチャンネルのみが使われる)
  • インポートするとレッドチャンネルのみが使われる

 

Photoshop上でカラーモードをグレースケールに変更した際に判明したことは

  • グレースケールに変更すると誤差拡散が適用される
  • 一部の特殊なレイヤーはグレースケール化した際に誤差拡散されない
  • RGBからチャンネルにコピペするとグレースケール化と同様に誤差拡散が適用

 

ということで、謎のゴミドットに悩まされることなく、安全にグレースケールテクスチャを作成できそうです

また一歩Photoshopに近づくことができた気がします

 

4K解像度が当たり前になる日もそう遠くない気もするので、効率のいいテクスチャ制作ができるように準備はしておきたいところです

 

カラフルな描き込みにこだわるあまり、圧縮の餌食になって画質を落とすことになるのはもったいないので、うまくグレースケールも活用しつつステキなUIデザインを実装できるようになりたいですね

 

 

ではでは

ステキなグレースケールテクスチャライフを!