Configuring an Animation Model Object

An IDLgrModel object that supports animation acts as a container for any number of objects. However, instead of displaying all objects when the model is drawn, a model object that supports animation lets you instruct the object to draw only one of the objects in its container. For example, this allows you to display a succession of single images from a series of images that has been added to the animation model.

To create a model object that supports animation, set the RENDER_METHOD property value to 1 to display single objects from the model collection. Use the ACTIVE_POSITION property of the model, a zero-based index into the model collection, to define what object to display. The default RENDER_METHOD value (0), draws all objects in a model. If your animation model contains a single object (e.g., when you are rotating a surface), you do not need to set the RENDER_METHOD property.

The index of the item to draw does not automatically increment when the model is drawn, so redrawing the scene graph always draws the same content. This maintains the window contents when the window is refreshed or resized. Therefore, the model object must be explicitly told which item to draw. The logic that determines which item to draw is left to the application and is typically encapsulated in a user-defined behavior class. See Designing a Behavior Object for more information.

Using Multiple Models

It is suggested that you create a main-level display model (that renders in the traditional all-object fashion) in addition to the animation model (that sets the RENDER_METHOD property). This compartmentalization provides more flexibility in terms of display content. For example, suppose you have a Cine display. The main-level display model could contain a text object that is displayed on all image frames. If you did not have the main-level model, the text would only appear as part of the Cine, according to its position in the animation model.

If you are adding more than just images to an animation model (e.g., you want a contour or ROI overlaying an image), then you can create additional sub-models. These are useful when each frame of an animation is a composite of several individual, data-specific objects. The following figure provides a simple illustration of a possible model hierarchy in animation.

Figure 10-2: Possible Model Object Hierarchy in an Animation Display

animation_models.gif

Typically, images can be added directly to a model object. However, if your application provides a way to interactively change the properties of the images (e.g., by filtering or modifying the color table), you should add the images to an object collection. You can then pass a pointer to this object array, and access the images when needed. This is significantly easier than accessing the image data from the animation model. The following short segment of code shows such an image collection, oImageColl, and the animation model, oAnimationModel: 

; Access the image data. 
head = READ_BINARY( FILEPATH('head.dat', $ 
        SUBDIRECTORY=['examples','data']), $ 
        DATA_DIMS=[80,100, 57]) 
 
; Initialize an object array with dimensions equal to the  
; number of images in the series. 
oImageColl = OBJARR(57) 
 
; Create the image objects, add each to the image collection and 
; the animation model. 
FOR i=0, 56 DO BEGIN 
   oImageColl[i] = OBJ_NEW('IDLgrImage', head[*,*,i], 
      PALETTE=oPalette, /INTERP) 
   oAnimationModel->Add, oImageColl[i] 
ENDFOR