QueueProcessor (class)

The QueueProcessor can be thought of as the air traffic controller for the SALSA LipSync suite. It will keep track of the activating and deactivating animations and resolve any conflicts to prevent jittery fighting over what an animation should be doing.

Allocating QueueProcessors

Each of the suite modules registers animations into the queue and the queue takes it from there. There can be any number of QueueProcessors in a scene; however, we recommend one per character. A QueueProcessor can only handle conflict resolution within itself so creating one queue per character is generally a great way to divide up responsibility and ensure the best performance for your implementation.

We do not recommend creating separate QueueProcessors for each module on a character. Doing so will separate the module animations and they will be unaware of each other, potentially creating conflicts.

Conflict Resolution and Queue Hierarchy

There are different types of expressions available in the SALSA suite. NEW in version 2.3.0+ The QueueProcessor now has separate queues for each controller type that are hierarchically applied to the animation values. This eliminates conflict between controllers and can intelligently merge animations backwards towards lower priority (if enabled).

Conflict resolution within the Queue hierarchy operates under the following rules (new and changed since v2.3.0) and it is expected that each new controller type registration will override itself:

  • Blink is the highest priority -- it is expected that involuntary blink options would override all other controller types.
  • LipSync is next in the list and technically it should be expected lipsync will not be interfered with by any other controller type, including Blink -- however, technically, Blink overrides Lipsync.
  • Emotes are next. In previous versions prior to 2.3.0, blinks were registered as Emotes -- this has changed and they now utilize the top-priority type above.
  • Lid movement is next, followed by...
  • Eye movement, followed by...
  • Head movement.

ExpressionController implementations have been re-written to leverage intelligent influence detection. This works for all controllers and generally speaking, it can be enabled globally and should work very well. Each controller determines if it was overridden by an external value or a higher-priority controller type. If it determines it has been overridden, it will revert to min/max settings until the higher-level component releases it. Once released, it will resume functionality as the high-priority controller. This eliminates an amplification effect that can occur when multiple controllers are assuming the influence is below them and not above them. This will not always have the desired effect; however, will work perfectly most of the time.

Generally speaking, this is all handled behind the scenes for you. However, depending on your situation, you may have to plan your setup to ensure it operates as you intended. Ensure you have a single QueueProcessor for any expression types that need to be aware of other expression types for smoothly transitioning from one type to the next. See the above section on allocating QueueProcessors for more information.

There is now an option to enable intelligent MergeBack on a global basis. This option is located at the top of the QueueProcessor Inspector.
queueprocessor-mergeback-option

Also shown in this image, is a slider which controls the overall length of the component display window for the queue items. And a filter section for turning off the detail of the different controller type sections. This is useful for increasing performance of the component's Editor display as well as limiting the data available to the specific set you are looking at.

NOTE: section headers will still be visible for the specific controller types whether the detail is filtered out or not. Also note: the filter options are in hierarchical order from lowest to highest (Head is lower than Blink), meaning an Emo (emote) will be overwritten by a Blink.

Editor Performance

Unless you are trying to troubleshoot your configuration, we recommend keeping the QueueProcessor component collapsed in your inspector. While the QueueProcessor inspector is open/expanded, there is a visible impact on scene performance. It is only intended for troubleshooting purposes.

QueueProcessor API

The QueueProcessor is designed to be a black-box of operation where the designer and developer need not contribute to or change control. However, with version 2.3.0, the option to enable automatic handling of MergeBack is configurable in the QueueProcessor.

bool useMergeWithInfluencer

Enable global MergeBack for all component registrations. The QueueProcessor and ExpressionController will attempt to smoothly merge animations back to externally influenced values (i.e. Mecanim, custom script, etc.) changed during the Update cycle. If this option is not enabled, it may be enabled in individual component configurations.