Arbor

お世話になっております。
バグというわけではありませんが、ArborFsmで、FsmをSubStateMachineReferenceを利用して、AIのメイン処理を分けていましたが、負荷が高く感じます。SubStateMachineReferenceは、ステートを移行するたびに再ロードするのでしょうか？　負荷を検証するために Profilerを確認しましたが、FindFieldBase.FindFieldでかなりの時間を要しているようです。Profilerのスナップを載せておきます。一度ご確認お願いします。

ご報告ありがとうございます。

まず、こちらの不具合報告にはフォーラムルールがありますが、その必須項目がなかったため警告させていただきました。
フォーラムルールを確認の上、必須項目も記入するようにお願いいたします。

負荷に関しましては、SubStateMachineReferenceを追加しているステートを初めて実行する際(OnStateAwake)にプレハブをInstantiateしております。
なので、最初の実行時にはInstantiateの負荷及びデシリアライズなどの処理が行われるため高負荷となっています。

また、既に実行したステートに戻ってきた場合はインスタンスを使いまわすようになっていますので、繰り返し実行した場合は問題ないかと思います。

処理負荷の改善は順次行っていきますが、動作上問題ないと思いまずので不具合対応ではなく今後の改善対応とさせていただきます。

返信有難うございます。Instantiate時の高負荷については了解しました。
ただ、２回目以降のステート切替時も同様に負荷が高い気がします。資料をご確認ください。
できれば、SubStateMachineReferenceを利用したいので、こちらでも負荷軽減策が無いか模索してみます。

以上よろしくおねがいします。

環境
Unityバージョン: 2018.1.16f1
Arborバージョン: 3.2.0
OS: maxOS High Sierra 10.13.6
再現方法: SubStateMachineReferenceを利用したステート管理。SubStateMachineReferenceからSubStateMachineReferenceを呼ぶこともしています。

詳細ありがとうございます。

その画像にある負荷については、SubStateMachineReferenceから抜ける際に遷移回数の初期化のためにStateLinkを全検索している関係ですね。
こちらも改善できないか検討いたします。

見た感じ、ArborFSMInternal.ClearTransitionCountでリセットしているtransitionCountは、Editorでしか使われていない感じなので、とりあえずUNITY_EDITORで囲って対応できそうです。ありがとうございました。