みつまめ杏仁

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

ゲージ100本ノック 71-73

まだまだゲージ作っていきますよー

なんとかネタが続いててハラハラしてます。

さて今回もUV空間をいじっていきます。UIならではの表現になると思うので、しっかりマスターしてドヤ顔してやりましょう。

 

UV空間とは、とあるポリゴン面にテクスチャを貼り付けるための縦と横 垂直に交わる二次元の四角い領域のことです。数学のグラフや地図のようにXY座標(=UV座標)で場所を示すことができるので、テクスチャ用の画像データのことをテクスチャマップとか呼んだりします。法線情報の画像だったらノーマルマップとか言いますが、わりと「マップ」は省略されがちです。

 

さてさて今回は UIコンポーネントとかで見かけたことがあるかもしれません。

スケール9グリッド とか、9 (8) スライスとか呼ばれているやつ。

最小限のパーツ素材で、いろんなサイズのウィンドウデザインを作れるのがウリです。
角の4隅をサイズ固定して、間の部分を伸縮させるのがポイント。

 

これをシェーダーで実現するのですが、ゲージ版ということで、2つにスライスして作ります。

UVの1方向のみを加工するのであまり複雑にはならないと思います。

今回横向きのゲージなので V方向は何もしません。

 

どう加工するかというと、下図は過去記事からの引用です。

 

数値の変化がこうなればゴールです。

 

この結果にするためにはいくつかの方法があります。

過去記事で ifノードを使ったので今回は使わない方法を2つ紹介します。

 

使用したテクスチャは 64x64px です。

RGBとAlphaは 68. 枠をつける2 と同じ方法でブレンドします。

 

 

 

71. テクスチャの中央だけを引き延ばす Case: 1

 

いきなり全体から

ゲージの長さはパラメータで変更するスタイルです。

 

キモになる部分

まず表示する長さを掛け算します。

例として 表示サイズ 256px を想定して、テクスチャが64px なので 4倍。

ここから AとB 2つのパターンを用意します

 

A は 0 ~ 0.5 の範囲で Clamp

 

Bは Fracノードでギザギザにします

この A と B を Step Lerpノードを使って組み合わせます。

これで実現できましたが、横方向のサイズが 整数倍でしか使えないのが欠点。

例えば 3.2倍の長さにすると ↓このようになります。

Fracノードを使っているので最後がきれいに合わないのが原因です。補正してやると汎用性が上がりますが、せっかくのシンプルなノード構成が複雑になってしまうので、割り切って使うならそれほど問題にはならないと思います。

 

 

72. テクスチャの中央だけを引き延ばす Case: 2

いきなり全体から

これもゲージの長さをパラメータで変更します。

Frac StepLerpノードを使わず 足し算 と 引き算 で何とかするケース。

71. のケースと違って整数倍じゃなくても可変可能。

 

キモになる部分

これも、前半と後半大きく2つにわけて計算しています。

 

前半部分

4倍して 0 ~ 0.5 の範囲で Clamp

後半部分

4倍した長さから 0.5 引いた値を最小値として Clamp

ここから、Clampで使った最小値と同じ値で引くと

これを前半部分と足し算すると出来上がり。

 

この方法だと、3.2倍とか中途半端な長さでも大丈夫です。

使い勝手がよくなりました。

 

 

 

73. 長さを自動で調整するようにする Case: 3

いきなり全体から

パラメータに依存せず、表示サイズを自動的に判断して調整してくれるようにします。

基本部分は 72. と同じです。

長さ(倍率)を計算して求めます。便利なノードが TexCoord です。

 

TexCoordノードの Coordinate Index は 普段の 0 だと UV座標が、 3 にすると表示サイズ WとH のピクセル数が取り出せます。

0、1 は 3Dモデルを作る際、MayaとかBlender など ポリゴンの各頂点に複数のUV情報を付加することができるので、プライマリUVは 0、 セカンダリUVは 1 として選択するときに使います。

3つ目以降のUVに対応しているかどうかはゲームエンジン次第になります。

このあたりの仕様は、公式のドキュメントに従うしかなさそうです。

 

今回使用したテクスチャは 1 : 1 の正方形です。表示サイズの W を H で割ると縦横比として、横幅の倍率がわかります。

リアルタイムにサイズを変えてみるとこんな感じ

 

71.72. は表示サイズを決めてからパラメータを決定するスタイルなので、柔軟とは言えないですが、その分シンプルで計算負荷は控え目にできています。

ぐりぐりすると、両端の形が変形しているのがわかります。

 

ゲームの中でゲージがどのように扱われるのか、また開発中であればどのあたりまで調整したくなるかを考慮してベストな選択をできるようになるといいですね。別の場所で長さを変えて使いまわすとなれば、マテリアルインスタンスを作って対応するとメンテナンスしやすかったり、伸び縮みのアニメーションをするかしないか、など臨機応変な対応を求められるのが UIデザイナーです。

デザインをカッチリ作って、その通りにサクッと実装できることはないので、いろんな手練手管を駆使できるようになりたいものです。

過去記事だと、IF ノード使ったりしてましたね。今なら、IFは極力避けます。当時はまだ手探り状態だったんだけど、今回この記事書いてみて成長を感じてますw

 

今回は以上です

同じ見た目を作るのに、工夫次第で扱い方が変わったりするは面白いですね。

汎用性を重視するかしないか、負荷を気にする必要があるかないか、などなど、一つ作って満足せずにいろんな方法を試してみると、また違った表現やヒントがみつかるかもしれません。

 

ではでは

素敵なゲージライフを!