'''Name''': Transition Model

'''Intent''': Design software so it's primary function is not states but transitions.

'''Context''': In show environments, the music never stops. Intermissions and failures aside, the focus should be on constantly shifting audio - and video displays. With that in mind, visual displays for shows should focus primarily on transitions(dynamic over static displays). Displays for shows are usually of the video sampling or procedurally generated types.

'''Solution''': Design the software from the beginning for transitions.

For a procedurally generated 3d scenegraph this means the following all must be able to transition between at least two states:
* Texture
* Material (base,Diffuse,Ambient,Specular,Shininess,Transparency,etc)
* Animation (translation,rotation,scale,bend,twist,shear,etc)
* Model
* Entire scenes

For full scene transitions, not every part has to shift perfectly. For instance a simple A->B fade might lower the transparency of A as B raises. However inside the scene (imagine a bouncing cube), such transparency bouncing is unacceptable.

Transforms and RGB/RGBA sets are fairly easy to tween the values of. Textures can be done by multitexturing techniques. 3d models remain much more complicated. One solution is to used Sculpted Prims (xyz coordinates represented as an rgb grid). Tweening model 1 to model 2 is then as easy as tween the rgb values of the image.

in progress, up for review, etc...
-- LayneThomas

I'd note that the most stable of transition systems have regular checkpoints (e.g. the I-frames of MPEG) where the state is set, followed by limited-period sequences of changes.  The regularity of checkpoints determines the rate of signal regeneration in event of error.  The TransitionModel is rather primitive to all forms of compression (wherein you compute and communicate changes to be expressed upon a shared model).  In a large scene-graph, a large change can be expressed as a sequence of smaller-changes to the scene-graph model.  It's worth noting that many systems provide ONLY this 'TransitionModel' over their scene-graphs and world-models, and lack the capacity to regenerate in the event of errors, and that this often results in failure over long runtimes.

Agreed, the way I implemented it in software is where each scenegraph element has various states it can tween between, scenegraph transitions are then full scene tweens between tweening elements. Bear in mind this is for real-time at shows where you don't necessarily want an A->B->C style of transitions. You might easily want B to transition to D halfway through B's micro-cycle. Storage of the scenegraph is the states, not transitions. The focus on the transition from the beginning helps keep all the ephemeral states inherent to the system. Implement those tween unit tests early on.. -- LayneThomas
----
CategoryModels