FSMにおける負荷の仕様について

Forum rules
Here is the forum to do the questions about how to use to Arbor developer.
Attention point:
  • We can not answer your questions about your project specific issues.
  • We can not answer your questions on Unity's specification issues.
  • Please check Arbor Documentation and ask a question if you still don't know how to use it. If the desired function is not described in the document, it is highly possible that the function does not exist from the beginning, so go to the request forum.

ここは、Arbor開発者へ使い方に関する質問を行うフォーラムです。
注意点:
  • ユーザー様のプロジェクトの仕様上の問題や設計に対する質問には答えられません。
  • Unityの仕様上の問題に対する質問には答えられません。
  • Arbor Documentationを確認の上、それでも使い方がわからない場合にご質問ください。欲しい機能の記載がドキュメントにない場合は機能が元から存在しない可能性が高いので要望フォーラムへ。

Post a reply

Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: FSMにおける負荷の仕様について

Re: FSMにおける負荷の仕様について

by SilkTofu » 2021/07/20 12:38

迅速なご返信ありがとうございます。

なるほど! 確かにプログラム自体容量が重くはございませんし、最初に読み込んで実行するものですね。納得致しました。
また、FSMにおいても特別独自で処理を行う仕様は無いとの事で安心致しました。

ご見解と細かな情報メモもありがとうございます。
やはり組んだものが一目でわかる視認性の良さでArborを愛用させて頂いているので、可能なら一つにまとめたいところです。
大きな影響を与えるほどではないだろうという心強いお言葉も頂きましたので、ひとまず分割せずにつくり、
ご指摘通りどうしても負荷が増えてしまうようであればprefab化して分割する事も視野に入れておきます。

ありがとうございました!

Re: FSMにおける負荷の仕様について

by caitsithware » 2021/07/20 11:05

ご利用ありがとうございます。

Arborにおけるデータの持ち方についてですね。

結論から申し上げますと、シーンかプレハブに全て保存されている状態ですので、ノードがアクティブになるかによらず全データ(NodeBehaviourなどのコンポーネントデータも含む)が読み込まれます。

FSMを一つにまとめるべきか分割すべきかはノードの総数や対象スペックとの兼ね合いから一概には言えないため、一般的には楽に実装できる方で検証してみてどうしても負荷が高いようなら改めるのが良いかと思います。

また個人的な見解ではありますが、消費メモリの観点からするとテクスチャや音楽データなどの大サイズデータに比べるとグラフ制御用のデータサイズは微々たるものである点、処理負荷の観点からすると実行しているコードの内容次第である点、これらから直接ノード数が負荷に大きな影響を与えるほどではないと考えております。
(もちろんUnityのコンポーネントである以上、処理負荷は0にはなりません)
(追記:ノード数が多いにしても当然限度はありますし、多すぎるとグラフが広くなりすぎて管理しずらいなどの懸念点も別途あります)

以下UnityとArborのデータに関するメモ
  • コンポーネント:
    GameObjectに設定して処理を追加するデータ。GameObjectをシーンに配置(もしくは実行中にInstantiate)すれば設定しているコンポーネントは全てUnityのシリアライズシステムによって自動的に読み込まれる。
  • Serializableクラス:
    コンポーネントが持てるシリアライズ可能な内部データ。こちらもUnityのシリアライズシステムによって自動的に読み込まれる。
  • NodeGraph:
    ArborFSMなど。コンポーネント。各種ノードを複数持ち、再生状態を管理。
  • ノード:
    Stateノードなど。Serializableクラス。種類によってNodeBehaviourを1つ以上持ち、アクティブな時にNodeBehaviourの実行を制御。
  • NodeBehaviour:
    StateBehaviourなど。コンポーネント。ノードの挙動を実行する。
  • このようにArborはUnityのコンポーネントシステム上で動作するように組んでいるため、内部データは全てGameObjectに関連付けられて保存されている。

FSMにおける負荷の仕様について

by Silk » 2021/07/20 10:20

大量のデータベース(Listなど)を条件に分岐してArborによる処理へ繋ぐ仕様を作ろうと考えているのですが、
Arbor内で大量の条件分岐を用意して全ての分岐先を一つのFSMにおさめてしまうか、処理ごとにFSMを用意して外からアクセスさせるかで迷っています。

そこで仕様をお伺いしたいのですが、ひとつのFSM内で大量のノードを配置した場合、そこを通過しなくても(例えばノードの配置情報だけが全て最初に読み込まれるなどして)処理に影響する事はありますか?
それとも、どんなにたくさんのノードを配置しても通過しなかったノードは完全に無かったものとして扱われますか?

よろしくお願い致します。

Top