デザイナーからUIの素材を頂き、UGUIのImageを使って配置したところ、想定と透明度が異なることに気づきました。
設定を見直したところ、どうやらColor SpaceがGammaかLinearで見た目が変わることがわかりました。
以下の画像のように違うのですが、Gammaのときの見た目が正しく、Linearの場合が正しくありません。
Unity 2021.3の環境でプロジェクトを立ち上げるとデフォルトがLinearなので、Linearを選択していたのですが、ここで大きく躓いてしまいました。
(今までデフォルトはGammaだったと思いますが、Linearがデフォルトなのは私の環境だけ?)
最初、何か設定などを見落としているのでは?と思い調べましたがそうではなく、Linearにおける半透明UIの描画処理に関しては仕様や制約といったことのようでした。
以下のForumで話がされており、シェーダーが作成され公開もされており、近づけることは可能ですが見た目を完全に一致することはできませんでした。
Linear space for scene, gamma for UI?
URP限定ですが、RendererFeatureを用いて、解決することができます。
実際、以下の動画とGithubのサンプルを試したところ解決できることを確認できました。
負荷がどの程度かわからないのと採用事例などがないので少し不安でした。
Youtube - CEDEC2022】ちょっと踏み込んだURP: エンジニアに向けた実践的なナレッジ紹介
Github - CEDEC2022-URP
PhotoshopでUIパーツを作る場合、編集→カラー設定
からRGBカラーブレンド部分をガンマ補正
をチェックし、
作成すると見た目を合わせたまま作成できると聞きましたが、今回、PhotoshopでUIを作成していないので私は試せていません。
半透明なUIパーツが比較的多いわけではないので、デザイナーが作った素材とUnity上での表示を並べて表示し、できるだけ一致するように調整することとしました。
Unity 2021.3.31
]]>pixi-spine.jsというPixi.jsコミュニティが作っているspine用のライブラリを使う。
PictureSpine.jsはそれをツクール用に使えるようにしたもの。
ツクールのピクチャのようにSpineを使える。
MVはPixi.js4系なのでSpineは3.8限定
MZはPixi.js5系なのでSpineは3.8~4.1まで使用可能
PictureSpine.jsはSpine3.8基準。多分みんな3.8で作っているので安定を取るなら3.8。
Spine4以上を使いたい場合、pixi-spine.jsは最新のビルドをする必要ある。普通にDLできずNode.js入れてnpm install しないといけない。
こちらで試した限りでは細かいところは未検証だが、4系もとりあえず動いた。
Spineの3.8と4以上の差は、グラフエディタや細かな便利機能が追加されている差がある。
基本的な機能は3.8時点で完成されているが、最新使えるなら使いたい。
json形式でエクスポートすれば良い。
4系使っているとオプションで3.8系式のjsonで出力できるが、原因の切り分けが難しくなるので推奨しない。
テクスチャパックのオプションは基本いじる項目はないが、scaleだけいじることはある。
イラストを大きいサイズで作って出力するときscaleを0.5とかにすれば出力するテクスチャの解像度を減らせる。
トラック(アニメーション)を重ねることができる。
私は待機アニメーションの上にまばたきアニメーションを重ねるなどする。
例:
トラック0 : 待機アニメーション
トラック1 : まばたき
まばたきと待機の周期が違うし、まばたきを共通で使いまわしたいからこのような重ねる。
PictureSpine.jsはトラックの削除がないので、削除する場合は何もないアニメーションで上書きすればトラックを無効化できるのでそれで対応する。
あるいは自分でpixi-spine.jsにあるsetEmptyAnimation
の実装すれば良い。
トラックごとのアルファ値を設定する機能があるが、ここでいうアルファは透明度ではない。
どのくらいの影響度で重ねるか。ダメージ食らって足を引きずるのを徐々に強くするみたいなときに使うらしいが、私は使ったこと無い。
ミックスはアニメーション間の補完の話。
何も設定しないと瞬時にアニメーション切り替わって、シームレスじゃないので適当に設定しておく。
Spine側のエディタではデフォで0.2。
私はデフォで適当に設定して、個別に必要なところは設定している。
setColor(1, 1, 1, 0.1)などとすれば、全体を透明にできる。
Spineで出力時にscaleを変えてもテクスチャの解像度が変わるだけで、モデルのサイズが変わるわけではない。
ツクール側でscaleを変えないといけない。
元ファイルもモザイク処理をする必要ありますが、モザイクしているパーツをメッシュ変形すると違和感がすごい。
だから元ファイルをモザイク処理した上で用意されているモザイク機能を上からかけるのが良いのではないか。
アニメーション状態を保存しているので、メニューを開いたり、場所移動しても前のアニメーションを継続できる
Spine側で設定したオーディオをツクール側で再生したり、スイッチ操作する機能がある。
Spine側で設定したオーディオは別にエクスポートしたファイルに含まれるわけではない。ファイル名を参照したいだけ。
スイッチ操作はイベントに直で設定するのではなく、タイムライン上で設定しないといけない。微妙にハマった。
以下のような感じでプラグインコマンドから指定します。
最初に初期化コマンドから表示位置とサイズを指定し実行します。
その後はメッセージ追加コマンドからテキストを追加します。
ダウンロードはこちら
演出で使用することを想定しているので、マップを移動したり、メニューを表示したら消えます。
Released under the MIT license
]]>公式ブログのspine-unity 2Dおよび3D物理演算に沿って物理演算をSpineのモデルに適用したのですが、ハマったことがあったので書いておきます。
サンプルとして以下の図のように縦にボーンを連結したものを用意し、物理演算を仕込んでいきます。
公式ブログによるとUnityのHinge Jointを使用して物理演算を適用するようです。
ブログの手順に沿って生成する際、Hinge Joint 2Dか Hinge Joint 3Dか選択するフェーズがあります。
Spine自体が2Dですし、2Dを選択したくなるのですが、2Dを選択した場合、うまく行かないケースが2つありました。
公式フォーラムで質問されている「Cape physics issue when flipped」と同じケースです。
詳しい現象はフォーラムに動画があるのでそちらを参照してください。
上記フォーラムの回答でHinge Joint 3Dを使用することが勧められています。
実際、サンプルシーンとして同梱されている「SkeletonUtility Platformer HingeChain Physics」シーンでは、モーニングスターとマントがHinge Joint 3Dで実装されています。
その上、2Dだと向きによってHinge Joint 2Dが2セット生成されて設定しづらいという点もあり、3Dだと1セットで済むので楽です。
Hinge Joint 3Dで実装すると無事、モデルの位置を左右に振ると、物理的にぶらぶら揺れるようになりました。
今回実装した範囲では、Hinge Joint 2Dを使用することができず、またメリットも見出すことができませんでした。
現状、私はHinge Joint 3Dで実装する方法を採用していきます。
Unity 2020.3.11
Spine 4.0.24
Unityで読み込んだSpineで作ったモデルの特定のスロットだけマテリアルを変えたいケースがあります。
例えば、帽子の色の色相を変えたいとか、髪の毛のコントラストを変えたいなどです。
その方法について調べたので今回まとめました。
まず、今回使用するサンプルのSpineのツリーとモデルを以下に示します。
単純に赤色の四角を2つ用意し、今回はマテリアルを変更する例として片方の色相を変えることを目指します。
まず、Unityにインポートしたモデル全体の色相を変える方法を示します。
インポートした際に生成されるマテリアルのShaderをSpine/Sprite/
のShaderに変えます。
ライティングの有無により違いますが今回はUnlit
を使用しました。
このShaderにはColorAdjustmentの項目があり、これをチェックするとHueの値を変更できます。
上図のようにHueを0.14にすると下記のように色が変更されます。
Slotの色相を変える方法は2つあり、その1つがSkeletonRendererCustomMaterialsを使用する方法です。
このコンポーネントをアタッチし、変更したいSlotに別途用意した色相を変更済みのマテリアルを設定するだけで変更可能です。
上図のようにRed_Lに別途用意したマテリアルを設定すると下図のように片方だけ変わります。
上記方法ではなく、プログラムから色相を変えたいケースがあります。
上記のSkeletonRendererCustomMaterialsはドキュメントにあるようにプログラムから使用するものではないようです。
プログラムから変更したい場合はSkeletonRenderer.CustomSlotMaterials
を使用するようです。
以下に、CustomSlotMaterialsを用いて色相を変更するプログラムを載せます。
1 | using Spine.Unity; |
Shaderのパラメータの_Hueというパラメータ名はShaderのファイルを選択すると、インスペクタに表示されます。
今回はスロットのMaterialを変える例として色相を変更しましたが、他の要素を変えるのも要領は同じです。
2通りの方法、どちらもコンポーネントをアタッチしたモデルのみマテリアルの変更が反映されます。
Unity 2020.3.11
Spine 4.0.24
Spine 4.0.19
]]>Unityでアセットの量が膨大なプロジェクトを扱っていると、必要なアセットを探すのに苦労します。
そういったときに手助けになるアセットが今回紹介する「History Inspector」です。
このアセットは選択したファイルの履歴を保存し、その履歴にアクセスする手段を提供するアセットです。
直近で触ったファイルをもう一度いじる必要があるケースはよくあり、そういったときにこのアセットがあると便利です。
History Inspectorをインストールした後、Window -> History Inspector -> Open History Inspector window
をクリックすると、以下のビューが表示されます。
以下動画のように左右の矢印ボタンでファイルの選択履歴を移動できます。
また、上記図の現在選択しているファイル「SampleScene」となっているところをクリックすると以下のような履歴一覧が表示されます。
この履歴一覧で鍵マークのアイコンがありますが、これはある種のお気に入り機能のようなものです。
選択履歴に関係なく、常に一番上に表示しておくことができます。
その次の(1)
の数字はファイル選択数を指します。複数選択した場合もそれが履歴に残るため、このような数字が表示されています。
ソースコードが付属しているので、改造が可能です。
履歴にオブジェクト名しか出ないので、パスも表示したい思いが個人的に少しあります。
このアセットは履歴を/Assets/HistoryInspector/Database/selectionlist.asset
に保存します。
バージョン管理する場合は、以下のファイルとフォルダを除外すると良いと思います。
1 | /Assets/HistoryInspector/Database/ |
今回紹介したHistory Inspectorは選択したファイルの履歴を保存し、アクセスしやすくするアセットでした。
History Inspectorに履歴をロックするお気に入りのような機能がありますが、個人的にお気に入り機能ではオススメしたいアセットが別にあります。
それは「Kris’ Favorite Assets」です。
こちらは頻繁にアクセスするファイルをお気に入り登録できるので、併せて利用すると捗ります。
具体的に「Kris’ Favorite Assets が便利」で紹介しています。
Unity 2019.4.29
History Inspector 1.2
Unityでアセットの量が膨大なプロジェクトを扱っていると、必要なアセットを探すのに苦労します。
そういったときに手助けになるアセットが今回紹介する「History Inspector」です。
このアセットは選択したファイルの履歴を保存し、その履歴にアクセスする手段を提供するアセットです。
直近で触ったファイルをもう一度いじる必要があるケースはよくあり、そういったときにこのアセットがあると便利です。
History Inspectorをインストールした後、Window -> History Inspector -> Open History Inspector window
をクリックすると、以下のビューが表示されます。
以下動画のように左右の矢印ボタンでファイルの選択履歴を移動できます。
また、上記図の現在選択しているファイル「SampleScene」となっているところをクリックすると以下のような履歴一覧が表示されます。
この履歴一覧で鍵マークのアイコンがありますが、これはある種のお気に入り機能のようなものです。
選択履歴に関係なく、常に一番上に表示しておくことができます。
その次の(1)
の数字はファイル選択数を指します。複数選択した場合もそれが履歴に残るため、このような数字が表示されています。
ソースコードが付属しているので、改造が可能です。
履歴にオブジェクト名しか出ないので、パスも表示したい思いが個人的に少しあります。
このアセットは履歴を/Assets/HistoryInspector/Database/selectionlist.asset
に保存します。
バージョン管理する場合は、以下のファイルとフォルダを除外すると良いと思います。
1 | /Assets/HistoryInspector/Database/ |
今回紹介したHistory Inspectorは選択したファイルの履歴を保存し、アクセスしやすくするアセットでした。
History Inspectorに履歴をロックするお気に入りのような機能がありますが、個人的にお気に入り機能ではオススメしたいアセットが別にあります。
それは「Kris’ Favorite Assets」です。
こちらは頻繁にアクセスするファイルをお気に入り登録できるので、併せて利用すると捗ります。
具体的に「Kris’ Favorite Assets が便利」で紹介しています。
Unity 2019.4.29
History Inspector 1.2
不適切なファイルが含まれていないか
デプロイ後のwwwフォルダを開き、この中に意図していないファイルがないか確認します。
ライセンス的に問題があるもの、コピーした仮ファイル、制作メモ、不要なファイル(psdファイルなど)がないかチェックします。
未使用ファイルの削除
デプロイ時に「未使用ファイルを含まない」をチェックすると、ツクールのエディタ上で使われていない画像やサウンドファイルを削除してくれます。
しかし、プラグインで使用している画像も削除されてしまうので、このオプションの使用は少々難しいです。
なので、このオプションを使用せずデプロイすることをオススメします。
一度、このオプションを使用してデプロイし、削除されたファイルとの差分を見つつ、未使用ファイルをプロジェクトから手動で消すのが無難なのではと思います。
(プラグインで使用している画像が削除されるのは、ツクールのエディタ側からはどんなプラグインがどう画像を扱うか把握のしようがないため)
容量のチェック
可能ならばツールなどを使用し、容量が大きいファイルをリストアップすると良いです。
明らかに容量が大きい異常なファイルはしばしば見受けられます(未圧縮、不要なほど解像度が大きいなど)。
Canvasモードでデプロイしていないか
デプロイ後のexeを起動し、F2キーを押します。画面左上に表示が出ますが、これがWebGL modeであることを確認します。
もし、Canvas modeだった場合、描画処理が重く、また一部のプラグインは機能しない可能性があります。
ツクールMV側のバグらしく、MVを再インストールしてデプロイし直すと直ることがあるようです。
Steam版使っている人は大丈夫っぽい?
デプロイ時の暗号化キーをメモしておく
この暗号化キーは画像やサウンドファイルの暗号化に使われます。
暗号化キーをメモしておくと公開後にバグ修正などでデータの一部だけ修正ファイルを公開したいときに役立ちます。
デプロイ時の暗号化キーが同じならば、dataフォルダだけの差し替えでバージョンアップが可能のため、柔軟な対応ができます。
(販売サイトによっては差し替えに1日かかる場合があるので、自身のサイトで修正ファイルを公開するなど)
テスト用のイベントが残っていないか
よく拠点などにデバッグ用の便利イベントなどを設置したまま忘れてリリースしてしまうことがあります。
ニューゲームの初期位置が正しいか
テストで初期位置を別の場所へしたままにしていないか。
Readmeを同梱したか
Readmeや説明ファイルなどがある場合、同梱するのを忘れないようにします。
バージョンアップ時に入れ忘れることもあるので注意。
起動に時間がかからないか
通常のデプロイなら問題ありません。Enigma Virtual boxなどでexeをまとめた場合、起動に時間がかかります。
許容範囲か確認します。
ちなみにEnigma Virtual boxを使用した場合、起動するとWindows Defenderにブロックされることがあります。
ブロックされても無視して起動はできますが、ユーザに知らせることも必要かもしれません。
テスト用のプラグインパラメータにしていないか
プラグインパラメータをテストのときのままにしている場合があります。
また、テスト用のプラグインがある場合、OFFにします。
体験版の範囲で止まらないか
体験版と製品版がある場合、製品版なのに体験版の範囲しかプレイできないことがないか確認します。
セーブファイルを同梱していないか
普通にデプロイしたらセーブファイルは含まれません。
デプロイ後に自分でテストしてセーブして、それをそのままアップロードしない限り。
データを閲覧されても大丈夫か
ツクールの性質上、データを閲覧されるのを防ぐことはできません。
コンプライアンスに関わるテキストなどデータベースに残さないようにします。
(昔、ユーザに見えないエディタ上にしか出ないテキストで販売サイトの審査落ちるみたいなこともありました。)
UnityでSpineで作成したアニメーションを再生するためのコンポーネントとして以下の3つが用意されています。
SkeletonGraphic (UI)に関しては名前のとおりUGUIのcanvasに使用するものなので用途は限られているのですが、問題はSkeletonAnimationとSkeletonMecanimです。
Spineのアニメーションを再生するにはどちらかを使う必要がありますが、調べたり実装したりして考えたことを書いておきます。
公式で推奨されているのはSkeletonAnimationですが、それぞれ比べていきます。
Mecanimを使用した場合、Spineのエディタのプレビューで再生したものと同じになることを保証しない記載があります。
また、アニメーション間のトランジションを最初のフレームに追加のキーを設定する必要があります。
それらのキーはExport時にオプションの Animation clean up をONにすると消されるので、そのオプションはMecanimの場合使用できません。
詳しくはこちら
トランジションはただでさえ、見た目を整える難しさがあるので、さらに考慮すべき項目が増えるのはちょっとしんどい印象です。
トラック
SkeletonAnimation : アニメーション再生のAPI使用時に指定する
SkeletonMecanim : Animatorウィンドウのレイヤーで指定する
ミックス
SkeletonAnimation : Skeleton Data Assetで設定しておくか、アニメーション再生時TrackEntryを介して指定する
SkeletonMecanim : AnimatorウィンドウのTransitionの各値で設定する
アルファ
SkeletonAnimation : アニメーション再生時TrackEntryを介して指定する
SkeletonMecanim : レイヤーのweightで指定する
Spineで設定したイベント
SkeletonAnimation : AnimationStateのEventのdelegateに追加して受け取る
SkeletonMecanim : Animation Clipのイベントとして設定される
どちらも基本的な機能は備えています。
SkeletonAnimationはstarted, interrupted, completed, ended, disposedといった5つのイベントを受け取ることができ、アニメーション再生時のイベントの扱いが便利そうだと思いました。
また、SkeletonAnimationはTrackEntryを介したアニメーションの細かい設定ができる点も気になります。
attachmentのON/OFFやdrawOrderの順番の変更、eventの発火といった徐々に変化せずミックスができない項目に対してしきい値を設定できます。
SkeletonMecanimはSkeletonAnimatonに比べるとパフォーマンスで劣るそうです。
ゲームプレイに影響ある程ではないと思いますが、以下のフォーラムで書かれているように大量に生成したときにパフォーマンスに差が出たという話があります。
Performance Analysis of Mecanim vs Animation
両者の差がパフォーマンスにとってクリティカルになるケースは稀な気がします。
正直多少のパフォーマンスを犠牲にしてでもMecanimのようにGUIでアニメーションの遷移を設定出来たほうが良いという気持ちはあります。
Mecanimを使う最大のメリットはやはりGUIでアニメーションの遷移を定義できることです。
スパゲッティな遷移になりがちとはいえ、アニメーションの遷移をステートマシンで表現できるのは強みです。
逆にSkeletonAnimationを使う際の一番の問題点はこれで、アニメーションを変化させるのにプログラムからAPIを呼ぶしかないのです。
SkeletonAnimationを使いつつ、Mecanimnのようなステートマシンを使いたいというニーズはあり、以下のフォーラムのようにNodeCanvasというアセットを使う方法が提案されています。
NodeCanvasは少し高価ですが、触った感じ、確かにステートマシンでアニメーションを管理できますし、使いやすいアセットです。
上記フォーラムで紹介されているようなSpine用のアクションを自分で作る必要があるものの、一つの解であると言えそうです。
同様にステートマシンを扱うPlaymakerのSpine実装も存在しているのですが、PlaymakerでMecanimのようなアニメーション遷移を作るのは難しいです。
どちらもメリット・デメリットあるのでどちらを採用するかは一概に言えない感じでした。
個人的にはSkeletonAimatonを使っていこうかと思っています。やはり公式で推奨されているなら・・・。
Unity 2019.4.24
Spine 3.8.99