performance optimizations and code-structure cleanup

The problem

each object potentially carries one or more triggers.

When evaluating triggers, this means iterating through every object available and test for any triggers. That’s the naïve approach and has a huge drawback: only a tiny subset of the available objects are interactive and actually carry triggers.

Having to check every single object is a big performance hit, since we’re performing 99% of unnecessary checks.

The solution

Triggers

Since the introduction of the action- and trigger-manager classes, continuing to carry trigger-evaluation within the scenegraph-manager has become sub-optimal.

The new approach would add a method to the trigger manager that checks all of its created triggers for any matches and, if applicable, fires them.

Since any triggers are instanciated using the manager, we can store their pointers and evaluate them whenever necessary. This is the minimum effort needed for trigger evaluation: perform a check on every (active) trigger that is potentially able to fire.

Actions

A similar mechanism will be implemented in the action-manager: Blended actions shouldn’t be carried within the scenegraph-manager anymore, but should be managed by the action-manager from now on.

Meaning whenever an action is triggered that is in ‘bleded’ state, it is added to the action-manager’s internal processing list instead, leaving the scenegraph-manager with only having to call the action-manager’s new ‘process’ method.