古いバージョンから Maya を更新した際の Maya couldn’t convert mb file to an fbx file の解決

さて、自分はしばらく Maya 2014 の永年ライセンス版を大切に使っていたのだが、とうとうサポート切れで「新規インストールはできません」となってから早Nヵ月。PC新調と共に試しに 2014 をインストールしてみたら案内通り新規のライセンス認証ができなくなっていた。

仕方なく Maya Creative の最新版に移行したのだが(いつのまに LT が消えた!?)、今度は Unity 側から .ma ファイルを開こうとすると三分間固まった上にエラーが出るようになってしまった。

 

エラー内容は Console だと

「Maya couldn’t convert mb file to an fbx file」

Editor.log を開くともう少し細かい内容が出てくる。

Start importing Assets/_Artifacts/Models/Env/MainBG.ma using Guid(6e2ee6458b552764496bb74bd2e3ef89) (FBXImporter)C:\Program Files\Autodesk\MayaCreative2026\bin\maya.exe\bin\Foundation.dll: 指定されたパスが見つかりません。

明らかに maya のアドレスがおかしい(maya.exeの後ろにフォルダが連なっている)のだが、Unity 最新版を DL しても maya 2014 を再インストールしても解決せず。

 

で、試行錯誤した結果の解決手段は

「マイドキュメントの Maya フォルダを一度消す」

だった。一緒にアンインストールしてくれ……

 

恐らく同じエラーを踏む人は残り75億人中3人くらいかもしれないが、AI の Deep Research はブログ記事を読んでくれるので未来の 3 人のために遺しておく。

What's This?

このブログは不定期に更新されるゲーム製作アラカルトのメモ帳です。
記事は以下のカテゴリーに分類されてます。(クリックで記事一覧表示)

全てのソースコードのライセンスについてはこちら

書いてる人→@eiki_okuma

 

Rxdiag message pump が異常に出現する

のに英語の情報しかなかったので一応書いておく。

注:自己責任でお願いします。

原因

NVIDIA の rxdiag.dll が悪さしてるっぽい(ストリーミングサービス?)

症状

  • Windows が重くなる
  • タスクマネージャが激重になる

対処

タスクマネージャからすべての rxdiag.dll に起因する rundll32.exe を強制終了し、すかさず rxdiag.dll をリネームする。

rxdiag.dll は大体<C:\Program Files\NVIDIA Corporation\NvStreamSrv>あたりにある模様。

 

 

SpriteRenderer の裏をぼかすシェーダ

意外と無かったので作りました

 

Shader "Custom/Sprite - BlurBack"
{
    Properties
    {
        [PerRendererData] _MainTex("Sprite Texture", 2D) = "white" {}
        _BlurAmount("Blur Amount", Float) = 0.1
    }

    SubShader
    {
        Tags { "Queue" = "Transparent" }
        GrabPass { "_BGTexture" }    // GrabPass を使用。シンプル!

        Pass
        {
            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            #include "UnityCG.cginc"

            struct appdata
            {
                float4 vertex : POSITION;
                float2 uv : TEXCOORD0;
            };

            struct v2f
            {
                float4 vertex : SV_POSITION;
                float2 uv : TEXCOORD0;
            };

            sampler2D _BGTexture;
            float _BlurAmount;

            v2f vert( appdata v )
            {
                v2f o;
                o.vertex = UnityObjectToClipPos( v.vertex );
                o.uv = v.uv;
                return o;
            }

            half4 frag( v2f i ) : SV_Target
            {
                // ガウシアンぼかし
                float4 col = tex2D(_BGTexture, i.uv);
                float2 blurSize = float2(_BlurAmount / _ScreenParams.x, _BlurAmount / _ScreenParams.y);
                for (int x = -1; x <= 1; x++)
                {
                    for (int y = -1; y <= 1; y++) col += tex2D( _BGTexture, i.uv + float2(x, y) * blurSize );
                }
                return col / 9.0f;
            }
            ENDCG
        }

    }
}

GrabPass 便利ですね。(コンソールとかでも問題なく使えるんかな……?)

秒で使えるタイピングゲームのエンジンを作りました

タイピングゲーム制作キット

 日本語のタイピングゲーム作りたいな~と思った時に、ネット上にチラホラ資料は見つかるものの決定版がなかったので自分で作りました。

 アセットストアのコンプリートプロジェクトやスクリプト系アセットって、たしかにデモの画面は再現できるんだけどいざ開いてみると複雑怪奇な構造をしていて、無駄にスクリプトファイルが分断してたりデモに必須機能が埋め込まれていたりして自分のプロジェクトへの導入に手間取ることが結構あるんですよね。

 その点このアセットはシンプルに作りましたので、秒であなたのプロジェクトにタイピングゲーム機能をぶち込めます。(いるか?)

 ファイル構造はこんな感じ。必要なものは Core に入っている二つの .cs だけです。
 問題データは表示する文字+読み仮名の (string,string) を TypingEngine に渡せばOKで、 Demo では Questions.cs に入ってますが、適当に整備すればOKです。(後述する自作ゲームでは Google Spread Sheet からデータを下ろしてきています)

演出面

 タイピングゲームチュートリアルとかだと「とりあえず入力受け取れればOK」みたいな感じで、現在入力中の文字がどこなのか表示されなかったり、柔軟な入力に対応してなかったり、柔軟な入力をした時に例文のローマ字が変化しなかったりと割と不親切な仕上がりになることも多いですが、デモ動画を見ると分かるようにこのアセットではそういったあたりまである程度対応しています。

 文字入力とかもちゃんとフックできるようになっているので、改造次第で割とリッチな演出もいけます。こういうのって大事ですよね。

 

完成ゲーム例

 で、何を隠そうこのエンジンは去年 unity1week で出したタイピングゲームのエンジンをそのまま分離したものなので、そのままこのゲームが応用例になります。

ためてまわす鳥さんタイピング | フリーゲーム投稿サイト unityroom

 

 他にもあらゆるタイピングゲームが作れると思いますが、例えばタイピングオブザデッドのように複数の目標が出てきてどこからでも倒すことができるようなゲームの場合、TypingEngine を複数作るのがコツです。取り回しも大変楽。

*OnGUI をエンジンに入れ込みたかったので MonoBehaviour になっていますが、OnGUI さえ別の場所から呼んでしまえば MonoBehaviour を外すことも可能です。

 

 

 というわけで、雑にタイピングゲーム作りたくなった人はぜひ焼肉定食をぼくにおごってください。よろしくネ!

【Unity】New Input System をバッチリ使う

 Unity の New Input System、使ってますか。

 長らく Unity 製ゲームでまともにゲームパッドキーコンフィグに対応しようとすると Rewired というアセットを使わざるを得なかったんですが、Unity が公式にこれら機能に対応してくれました。ありがとう Unity。ちょっと遅いぞ Unity。

 早速飛びついて一本ゲームを作るまで一応使い込んだので、解説します。

 

二つの使い方

 さて、New Input System のコア部分には二つの使い方があります。

  • ラッパーである PlayerInput を使う方法
  • C# クラスを Generate して、それを new して使う方法

アセット設定

 で、ネットを検索するとどうも前者の情報しか出てこないんですよね。しかし、自分的には PlayerInput を Component でいちいち追加しないといけないのは GameObject の取り回しが面倒なので避けたい。ので、自分は後者の方法でやってます。後者の方法で New Input System を使うには、新規作成した inputactions アセットで Generate C# Class にチェックを入れるだけ。あ、この前段階のパッケージインポート云々は適当なチュートリアルサイト漁ってください。

 この記事ではクラス名は GeneralInput とします。

 

セットアップ例

 アリスではこんな感じ。Gamepad と Keyboard 両対応です。

 

入力を取る

public enum EInputName {/*略*/}
GeneralInput mInput = null;
InputAction[] mActions = new InputAction[(int)EInputName.Max];
private void Start()
{
    mInput = new GeneralInput();
	mActions[(int)EInputName.Decide] = mInput.Game.Decide;
	mActions[(int)EInputName.Cancel] = mInput.Game.Cancel;

	mActions[(int)EInputName.Jump] = mInput.Game.Jump;
	mActions[(int)EInputName.Dash] = mInput.Game.Dash;
	mActions[(int)EInputName.Menu] = mInput.Game.Menu;
	mActions[(int)EInputName.Attack] = mInput.Game.Attack;
	mActions[(int)EInputName.Change] = mInput.Game.Change;
	mActions[(int)EInputName.Map] = mInput.Game.Map;

	mInput.Enable();
}

public bool isHold( EInputName in ) => mActions[(int)in].IsPressed();
public bool isTrig( EInputName in ) => mActions[(int)in].WasPressedThisFrame();
public bool isReleased( EInputName in ) => mActions[(int)in].WasReleasedThisFrame();

 はい。簡単ですね。ここまでは解説なしで大丈夫だとおもいます。

 

ゲームパッドを接続しているか?

static public bool HasPad() => Gamepad.current != null;

 基本的にはこれでOKです。ただし、ゲームパッドを差しているけどキーボードを使いたい人に対処したいなら、今入力しているものがパッドなのかキーボードなのかを検知し、その都度切り替えてあげましょう。

 

キーコンフィグと保存

 RebindingOperation というものを使います。
パラメータを色々とセットして Start() すると、キーを押すかキャンセルするかするまで待機します。onComplete まで来たらすでにキーバインドは変更されているので、わざわざセットする必要はありません。
 ついでに、キーバインドは SaveBindingOverridesAsJson で Json 取得可能なので、そのまま保存してしまいましょう。

InputActionRebindingExtensions.RebindingOperation mRebindingOperation = null;

public void rebindButton( int index = 0 )
{
    mInput.Disable();
	mRebindingOperation = mActions[mCursor].PerformInteractiveRebinding( index )
		.WithBindingGroup( "Gamepad" )
		.WithControlsHavingToMatchPath("<gamepad>")
		.OnMatchWaitForAnother( 0.2f )
		.OnCancel( op => onCancelKeyBinding() )
		.OnComplete( op => onFinishKeyBinding() )
		.Start();
	}
}


void onFinishKeyBinding()
{
	disposeOperation();

	// セーブする
	PlayerPrefs.SetString( "KeyBinding", mInput.Game.Get().SaveBindingOverridesAsJson() );
	PlayerPrefs.Save();
}

void onCancelKeyBinding() => disposeOperation();

void disposeOperation()
{
	mRebindingOperation?.Dispose();
	mRebindingOperation = null;
	mInput.Enable();
}

 index は何番目のキーコンフィグを変更するか指定します。

 上のコードでは Input を Disable / Enable していますが、別のスキームに差し替える方法もあるようです。Enable() 直後は謎の入力が入っていたりするので、ウェイトをかけるなどして二連続でキーコンフィグに突入しないよう注意してください。

 特定の行動にスティックなどを Bind したくない場合は

.WithControlsExcluding( "leftStick" )

 などをパラメータとして追加してください。
 キーボードを検知したい場合は、Gamepad の部分を二箇所 Keyboard にし、index を

mActions[mCursor].GetBindingIndex( InputBinding.MaskByGroup( "Keyboard" ) )

 のように取得してください。

 

キーコンフィグのロード

 ロードの場合は保存した String を LoadBindingOverridesFromJson で読みます。

public void loadKeyBinding()
{
	if ( PlayerPrefs.HasKey( "KeyBinding" ) )
	{
		try {
			mInput.LoadBindingOverridesFromJson( PlayerPrefs.GetString( "KeyBinding" ) );
		}
		catch
		{
			Debug.Log( $"[Keybinding] error" );
		}
	}
}

 ここで一点注意。General Input は new するだけでどのクラスでも使えますが、LoadBinding したキー設定は、そのインスタンスにしか適用されません*1。LoadBinding したインスタンスを使いまわしたい場合は、どこかに static な GeneralInput を持っておいて、それを Get() して使いましょう。

 

手動でボタンを書き換える

mInput.FindAction( "Decide" ).ApplyBindingOverride( 0, "<Gamepad>/buttonEast" );
mInput.FindAction( "Cancel" ).ApplyBindingOverride( 0, "<Gamepad>/buttonSouth" );

 これだけ。例えば Switch 環境だけ決定ボタンとキャンセルボタンを逆にしたい、みたいな設定は簡単。

コントローラを震わせる

public IEnumerator seq_vibrate( float power = 1f, float duration = 0.15f )
{
	Gamepad.current.SetMotorSpeeds( power, power );
	yield return new WaitForSeconds( duration );
	Gamepad.current.SetMotorSpeeds( power, power );
}

 これも簡単ですね。SetMotorSpeeds は二つの周波数の振動をコントロールできるようで、具体的にどういうモノかはお手持ちのコントローラで試してみてください。

ボタンアイコンの表示

 これは少しめんどいです。でも、最近のゲームは大体やってるので根性で頑張りましょう。

 まず、TextMeshPro にスプライトアイコンを表示する……あたりのくだりは省略します。いい感じに全ボタン分のアイコンを設定してください。

//--------------------------------------------------------------------------
static public string GetSpriteName( string device_layout_name, string controlPath )
{
	return GetSpriteName( GetPadType( device_layout_name ), controlPath );
}

static public string GetSpriteName( EPadType pad_type, string controlPath )
{
	var prefix = pad_type == EPadType.XBox ? "XB" : pad_type == EPadType.DualShock ? "PS" : "GP";
	switch( controlPath )
	{
		case "buttonSouth":		return prefix + "_S";
		case "buttonNorth":		return prefix + "_N";
		case "buttonEast":		return prefix + "_E";
		case "buttonWest":		return prefix + "_W";
		case "start":			return prefix + "_ST";
		case "select":			return prefix + "_SE";
		case "leftTrigger":		return prefix + "_L";
		case "rightTrigger":	return prefix + "_R";
		case "leftShoulder":	return prefix + "_L2";
		case "rightShoulder":	return prefix + "_R2";
		case "leftStickPress":	return prefix + "_L3";
		case "rightStickPress": return prefix + "_R3";
		case "dpad":			return "LStick";
		case "dpad/up":			return "Up";
		case "dpad/down":		return "Down";
		case "dpad/left":		return "Left";
		case "dpad/right":		return "Right";
		case "leftStick":		return "LStick";
		case "rightStick":		return "RStick";
	}

	return "INVALID";
}

//--------------------------------------------------------------------------
static EPadType GetPadType( string device_layout_name )
{
	if ( InputSystem.IsFirstLayoutBasedOnSecond( device_layout_name, "DualShockGamepad" ) )
	{
		return EPadType.DualShock;
	}
	else if ( InputSystem.IsFirstLayoutBasedOnSecond( device_layout_name, "XInputController" ) )
	{
		return EPadType.XBox;
	}
	else return EPadType.Gamepad;
}

static public string GetSpriteNameOfKeyboard() => "KB_KEY";

 なんとなく分かったでしょうか。pad_type と controlPath によって適切なボタンの Sprite アイコンを呼んでいます。ただ、キーコンフィグを想定するとどのアクションにどの controlPath が設定されているのかわからないので、 GetSpriteName の呼び方にコツがあります。

public string getSpriteName( string action_name )
{
	var act = mInput.FindAction( action_name );
	if ( act == null ) return "";
	if ( !HasPad() )
	{
		var b = act.GetBindingIndex( InputBinding.MaskByGroup( "Keyboard" ) );
		act.GetBindingDisplayString( b, out var deviceLayoutName2, out var controlPath2 );
		return $"<sprite name=\"{GetSpriteNameOfKeyboard()}\">{controlPath2.ToUpper()}";
	}
	else
	{
		act.GetBindingDisplayString( 0, out var deviceLayoutName, out var controlPath );

		return $"<sprite name=\"{GetSpriteName( deviceLayoutName, controlPath )}\">";
	}
}

 特定のアクションに割り振られているキーは GetBindingDisplayString で取得します。キーボードの場合はキーが返ってくるのでよしなにしてください。一番目の引数は例によって index なので、メインキー、サブキーを併記したい場合はそんな感じに改変してみてください。

 

まとめ

 大体ゲームに必要な機能は網羅できたとおもいます。よき new input system ライフを*2

 え?よく分からなかった? そうかもしれません……でも大丈夫! そんな人のためにサンプルプロジェクト&UnityPackage も作りました。コインいっこでね。

 こちらからどうぞ↓

note.com

 

*1:これに気付かなかったため、アリスではマスター直前まで「キーコンできてるように見えてできてなかった」致命的な不具合が存在した。

*2:Rewired への恨み節は割愛します……

Unity バージョンの選び方のヒント

 いつものように前口上書いているうちにテンション下がるので本題から。

理由がなければ LTS

  • 最新メジャーバージョンは Experimental*1どうしても最新機能を使いたい理由が無い限り、LTS が出ているメジャーバージョンを使う。
  • LTS は2年間のサポートが保証されるだけでなく、以後のバージョンで修正された不具合も遡って修正されることがあるので、名目上は最も安定している。
  • 初期ほどの不安定さはないものの、Unity 自体が様々な機能を持ち、様々なプラットフォームで動作する巨大なプロダクトであるため、最新バージョンには結構な確率でとんでもない不具合が潜んでいる。

できるかぎり最新のメジャーバージョン

  • メジャーバージョンが上がるとエディタの使い勝手が結構変わったりして、ユーザ的にはお気に入りのバージョン、あんまりお気に入らないバージョンがあるとは思うが、そんなことを言っていられるほど開発環境というのは甘くない
  • なぜなら、PC 以外のほぼすべてのプラットフォームで、リリースできる Unity バージョンは極めて狭く制限されているからである。
  • コンシューマではマスター提出可能バージョンなどと言われており、マスターアップ時に必ず指定されたバージョンでなければ QA で弾かれる。
    • 一度出してしまえば、パッチ等で更新する時に古いバージョンの開発環境のままであっても不問申請が可能。
  • モバイルでは時折唐突に更新されるガイドラインに従って、ROMを更新する必要があり、その要件を満たすために新しいバージョンの Unity を求められることがある。
    • 最新である必要はないことが多いが、リリース5年後でも対応が求められる。
    • Android の場合は提出可能 Android バージョンが容赦なく上がっていくので、最新付近の環境を求められる。
  • そもそもゲーム制作が2年以上に及んだ場合、作っているうちにマスター提出できないバージョンになってしまったりするので、更新の必要は出てきたりするのだが……。
  • (幸い、Unity5->Unity2017の時に起きたような壊滅的なプロジェクト破壊は最近はあまり起きないのでバージョンアップくらいなら割となんとかなる)

できる限り古いマイナーバージョン

  • 例えばバージョンが 2021.3.20f1 であったら、この「20」にあたるのがマイナーバージョンだが、ここはできる限り古い値にしておきたい。なぜかというと……
  • 残念なことに、Unity の LTS は LTS であるにもかかわらずに結構な不具合が潜んでいることがあり、バージョンが一つ違うと修正される、あるいは発現する不具合がある。
  • コンシューマにおいては更にその足並みは混沌を極める。例えばゲーム機 A の◯◯という機能を使った場合に起こる不具合が 3.10f1 で修正された一方で、別の□□という機能を使った場合に起こる不具合が 3.16f1 から発現し、それがいまだ修正されていない、みたいなことがままある
  • しかたないから 3.15f1 で開発していると、ゲーム機 B では 3.14f1 から発生したとある不具合が致命的でマスターできなくなる、なんてことが起きる。最近の Unity では比較的安定しているとはいえ、基本的に開発環境のダウングレードは避けたい。
  • なので、マイナーバージョンはできる限り古いものを利用し*2、自分のプロダクトにクリティカルな不具合が出た場合のみ、それが修正されたバージョンへと上げるべきである。英語のリリースノートとにらめっこしながら最適なマイナーバージョンを選ぼう。地獄である

開発中はあんまり更新するな!

  • 「そういえば最近、ここの表示おかしいな……いつからだ……?」と追ってみると、なぜか実装時のリビジョンからおかしくなっており、辿ってみれば結局 Unity のバグだったということが結構ある。Unity もマイナーバージョン一つ上げるのに何千とあるアセットやシェーダとの整合性を確認することは難しく、多少の不具合は仕方ない。
  • が、最新が出たから更新シヨーみたいな気持ちで更新しまくると、自分が世界で初めて見つける不具合にもまあまあ出会う。お前が報告するんだよ!
  • というわけで、開発中にあんまり更新するのはやめよう。マスターを見据えるようになった時期に、最適なマイナーバージョンを選び、あとは祈るのみである。幸あれ。

 

まとめ

  • できるかぎり最新の LTS を使い、マイナーバージョンは古いものにする
  • 開発中はあんまり更新しない
  • アップデートする時は祈れ

以上!

*1:執筆時点で2022がβ、2023がα。6月に2022のLTSが出るらしいが……?少し待ったほうがいいかもしれない。

*2:とはいえ、3.0f1 には高確率で変なバグが仕込まれていたりするので、リリースノートを見ながらちょっと後ろのバージョンにしよう