Design question: Dynamic Actors

3DVIA.com Forums » 3DVIA Studio » General Discussion

(4 posts) (2 voices)

Started 3 months ago by kglass
Latest reply from flamenco

Tags:

kglass

member
Joined: Feb '10
Posts: 34

Hello

I am designing a system in Studio where it is very useful to use an Object Oriented design. Someone on this forum mentioned that we could think about a Behaviour as a class, containing data and functions.

My question is this: what is the overhead of this approach (performance & memory)? Assuming that I could have potentially hundreds, maybe even thousands of dynamic actors (of type Behaviour) instantiated.

If there is no Task defined in these behaviours, is it safe to assume the behaviour will not get "executed" automatically in some manner at every cycle (thus slowing down the execution dramatically)?

Thanks!

Posted 3 months ago #
flamenco

3DVIA Studio Guru
Joined: Sep '09
Posts: 50

Hi,

There is no direct runtime performance overhead using high number of actors. And an actor olding inactive tasks or only members won't have any runtime performance impact.

From a more play-reset oriented perspective, please note that new actor representations are created at PLAY, and destroyed at RESET. This may have an impact for play / reset performances while dealing with high number of actors.

And of course, independantly from behavior engine, please also note that an actor olding a visual component (3D, 2D) may have performance impact, even with no behavior, because of rendering processing (culling, sorting rendering, etc..).

Having said that, from a hardcore C++ developer point of view, Studio behaviors don't come with all standard OO services (heritage, ..). This is probably not a good idea (nor even possible) to striclty apply standard OO design patterns using Studio Behaviors. For low level hardcore OO approach, you may want to switch to Studio C++ SDK.

A behavior inside Studio is really to be seen as .. well, an atomic behavioral part of an actor. An actor can aggregate several complementary reusable behaviors of course, but I believe you would go the wrong way if you need to aggregate 20 Studio behaviors on an actor to perform a fairly simple "atomic behavior", because of your architecture.

This is my feedback, but some people may have different points of view on this topic .. always hard to give relevant hints without going into the details of what you want to do.

Cheers,
A/

Posted 3 months ago #
kglass

member
Joined: Feb '10
Posts: 34

Hi flamenco

Thanks for the detailed answer.

In fact, my immediate need is to be able to parse and store hierarchical data from an XML file. At some point I would like some actions to be performed on certain subsets of the data (for example, activate certain functionalities in Studio depending on the parameters read in from the file). It makes sense to follow the typical "class" structure, and define the functions that can act on the data within the same structure as where it is stored.

I understand that I could easily store the data using the existing "class" types in Studio, but then the functions would need to be separated from the data itself and defined in a behaviour somewhere.

The alternative is to use a behaviour to store the data, as well as contain the set of functions that can act on it. The downside here is that I would need to create a dynamic actor for each instance. Thus the reason for my question, which you answered perfectly.

Now, I just need to figure out whether it is overboard to create so many dynamic actors, or get over my need to keep functions & data so close together

-Kevin

Posted 3 months ago #
flamenco

3DVIA Studio Guru
Joined: Sep '09
Posts: 50
Hi,

Please find attached a sample project that I used for a quick benchmark.

I manually created a simple behavior (meBeh01) that I duplicate n times at runtime. This behavior has one init VSL task starting an infinite loop, either using schematic task or VSL function call.

BehaviorGenerator dynamically duplicates this behavior n times.

Please find attached a graph of the results I have on my laptop inside authoring environment.

To roughly sum it up: hundreds of behavior instances is definitely fine, thousands of behavior instances should be OK, tens of thousands of behavior instances might becomes critical at some point :o). All that of course highly depends on targeted platform, tasks content (here I perform an infinite loop on each instance, which is probably not so common).

You may want to modify the sample so that it gets closer to you use case (add members to check memory footprint, add specific processing inside tasks for perf benchmarking, use event handlers instead of infinite loops, ..).

By the way, here are a partial list of some "little details that matters" for an efficient benchmarking:

- Compile your scripts in release mode (default mode is debug !)
- Disable Live Update so that property view is not updated (File / Preferences / Engines / GUIApp / Property View Live Update ).
- Disable display of Dynamic actors inside Project Editor, this may drop frame rate when dealing with huge number of actors. The is done by pressing the (very, yes) little button under Project Editor orange tab.
- Disable "Sync to screen" mode to have a free refresh rate independant from screen refresh rate (Project options / Engine / Render / CreateOptions / Syncronize To Screen). This is the only way to have a usable FPS feedback for high frame rates.
- If you really want to bench runtime perf, do the test inside a player, not inside Authoring. Studio console and profiling tools are all available at runtime !

Hope it helps making your mind,
A/
Attachments
Results.jpg (47.3 KB, 9 downloads) 3 months old
DynamicActorBenchmarkProject.zip (10.1 KB, 2 downloads) 3 months old
WARNING: Files uploaded in the forums are not monitored by 3DVIA and therefore might contain content that is malicious or offensive. Download at your own risk
Posted 3 months ago #