Transitions

Concept and Use Cases

Transitions Concept

Generally speaking, the concept of "transition" indicates the edge between two different states. In our case, the very notion of transition indicates the visual dynamics involved in displaying the content of a scene which is replacing another scene. Using a transition provides continuity so that the scene change is not quite so abrupt.

The rules editor panel allows the definition of transitions on a per scene basis and test these transitions directly in SceneComposer's display preview. The designer can use the editor to set the transitions to (="Destination") or from a scene (="Source") just by selecting effects (="Transition Types") on the scene list.

drawing-7-1723016272.png

Types of Transitions

The rules editor features a toolbox where both "built in" transitions and "custom" transitions are available, a configurable default behavior, two scrollable lists ("Source" and "Destination") of all scenes in the solution, a "Variant" scrollable list, and a properties panel. To create a rule it is mandatory, first, to select the source and the destination, a specific type of that transition and, finally, to set the transition properties. After all these steps are done, the transition can be executed in the "Transition Execution" panel.

The available simple transitions are the following:

  • Cut
  • Fade
  • Slide
  • Scale

The available combined transitions are the following:

  • Fade & Slide
  • Fade & Scale
  • Slide & Scale
  • Fade & Slide & Scale

Transition Type Animation

The Transitions framework has a special build-in transition type – Animation. By using this transition type, it is possible to trigger animations or group animations within transitions. The Variant holds three Additional optional parameters:

  • AnimationId – Candera::Id of the animation that will be executed by the Transitions framework.
    • AnimationTimeline - specifies the time when the animation will start. The end time of the animation depends on the selected playback mode.
    • IsAnimationTimeRelative - defines the playback mode for the animation:
      • TransitionTime - default (false) - The animation speed is adapted such that the end time of the transition, specified by the AnimationTimeline parameter, will match the end time of the animation.
      • AnimationTime (true) - The animation duration is given by the animation itself.

The animation specific parameters can be specified in the properties panel once the corresponding transition type has been selected:

drawing-4-1676444250.png

The animations can be triggered through a Request using the corresponding Variant name.

drawing-4-1676444271.png


Sequential Execution of Transitions

The Transitions framework furthermore allows the sequential execution of transition fragments. One or multiple activation or deactivation fragments can be executed before or after fragments of the respective opposite fragment type. Therefore, the rules editor offers the option to set the "Activation" and "Deactivation" strategy.

The strategy types are:

  • Normal
  • Early
  • Late

The combination of "Early" and "Late" will cause a sequential execution of the involved transition fragments. Any other combination results in a default transition behavior. "Early" fragments are executed before "Late" fragments.

For example: Scene_1 has a rule to perform a transition with a Fade to Scene_2. Scene_2 (activation fragment) should fade in completely before Scene_1 (deactivation fragment) begins to fade out. For this rule, the "Activation" strategy would be "Early" and the "Deactivation" strategy would be "Late". The opposite result can be achieved by swapping the fragments' strategy.

However, it is important to note that multiple "Early" or "Late" fragments will be executed in parallel and that "Late" fragments will only be executed once all "Early" fragments have finished first.

drawing-4-1682584490.png


Early and Late Transition Delays

Sequential Transitions furthermore offer the possibility to customize the moment, when "Late" fragments are executed after the "Early" fragments are finished. Next to the strategy type, a delay value (in milliseconds) can be set for "Activation" and "Deactivation" fragments. During a transition, the delay values are applied after the respective fragment.

The following shows the resulting sequence:

Early (Source) -> Delay -> Late (Destination) -> Delay

If the transition is bidirectional, the sequence is reversed (more on bidirectional transitions further below):

Delay -> Late (Destination) -> Delay -> Early (Source)

Reverse Transitions

The Transitions framework offers the possibility of reversing transitions. If a reversible fragment has been identified, the already running TransitionFragment shall go backwards, from its current state to the original one.

This option shall be used, for example, when a second transition request is posted which contains a fragment that goes from Deactivate(B) - Activate(A), while the previous fragment - from Deactivate(A) to Activate(B) - is still running. In this case the already running transition will be reversed from the current state to the beginning.

This feature is optional and can be specified via an optional flag "Is Reversible" in the Properties associated to the selected rule. Default value is true.

drawing-4-1682584509.png

A reversible fragment is identified through a Variant that will match a Rule to its corresponding RequestFragment using the following conditions:

  • the Variant of the already running TransitionFragment shall match the Variant of the current Request.
  • the Source of the already running TransitionFragment shall match the Destination of the matching Rule.
  • the Destination of the already running TransitionFragment shall match the Source of the matching Rule.

There are special cases: a transition with AllowReverse==true might consist of fragments that are not found in the already running transitions. In this case these fragments shall be executed normally.

Bidirectional Transitions

The "bidirectional" feature allows to define only one transition rule that matches as well the forward as the backwards direction from two request fragments.

Bidirectional transitions will not support playing reverse AnimationGroups, only Animations.

The image below shows how two "symmetrical" transition rules can be replaced with only one if the "Is bidirectional" property is enabled:

drawing-7-1723016725.png

Bidirectional rules will be applied in the other direction whenever it would be the first match in the ruleset.

To preserve backwards compatibility, on solution conversion, the "Is Bidirectional" property is set to false if it didn't exist in the old Solution.

Use Transitions

Use Transitions

Every existing scene is automatically added in two scrollable lists, which are available in the rules editor as "Source" and "Destination".

drawing-7-1723015595.png

After the selection of the source scene, the destination can be another scene or just "None". If the later option will be chosen, a selected "Transition Type" will be applied to the selected scene.

drawing-7-1723015691.png

The left combobox of the "Activation" and "Deactivation" columns respectively sets the transition strategy. In order to enable a sequential transition execution, one strategy has to be set to "Early" and the other one to "Late". See the image below for an example.

drawing-7-1723015770.png

Previously to the usage of an existing transition, the camera from every scene which will be used in the transition has to be assigned to a render target. Supposing that the scenes are prepared to be used in a transition, the user has to choose which kind of transition will be assigned to the "Activate" and "Deactivate" state of the scene. The former concept indicates what will happen when the transition will be working from a scene to that scene or when will be working on a scene alone, and the latter indicates what will happen when the transition will be working from that scene to another one or when will be working on a scene alone. This operation can be done in a secondary panel named "Transition Execution".

drawing-7-1723015905.png

This means that when the user will use the button "Execute Transitions" some scene will get "activate" (if that specific option was checked) and other scenes will get "deactivate" (if that option was checked). For instance, if the transition type "Fade" will be executed for a scene which will get deactivate its content will be fading.

If desired, it is possible to create custom transitions. This can be done by using the "+" button that is placed in in the upper side of the "Rules Editor" panel. The properties that belong to that transition type can be set and will remain available for later re-use. Furthermore, transition strategies and delays can also be edited in the Properties tab. (see the image below).

drawing-7-1723016133.png

Transition panel

This page describes the panels you can use when configuring and executing transitions.

Transition Rules Editor

The Transition Rule Editor panel can be displayed by checking [ View > Transitions > Transition Rules Editor ] on the menu bar.

drawing-7-1723005936.png
(1)

Add new transition rule:

Add a new transition rule.

(2)

Delete transition rule:

Deletes the selected transition rule.

(3)

Search:

If many transition rules are set, you can enter a search term to narrow down the number of results displayed.

(4)

Clear Search:

Delete the search term.

(5)

Source:

Set the source of the transition.

(6)

Transition Type:

Set the transition type.

(7)

Destination:

Set the destination of the transition.

(8)

Activation/Deactivation:

Set the activation delay/deactivation delay.

(9)

Variant:

Sets the transition rule variant.

Transition Execution

The Transition Execution panel can be displayed by checking [ View > Transitions > Transition Execution ] on the menu bar.

drawing-7-1723009048.png
(1)

Add an example of a new transition execution:

Add a new transition execution procedure.

(2)

Delete transition execution example:

Delete the selected transition execution procedure.

(3)

Add an example of how to use a scene:

Add a scene use case to the transition execution procedure.

(4)

Delete Scene Example:

Delete the selected scene use case.

(5)

Execute Transitions:

Run transition execution procedure.

(6)

Scene:

Set the scene to be transitioned.

(7)

Action:

Set the action to be taken by the transition.

(Activate: Transition to the set scene, Deactivate: Transition from the set scene to another scene)

(8)

Variant:

Sets the transition rule variant.

For more information on how to configure transitions, please refer to Concepts and Use Cases and Using Transitions.