[Ctk-developers] more on CTK Scene

[Marco Viceconti]

Let me think aloud.

CTK modules will create data objects that we want visualise.  These  
objects are made into scene actors, a scene around them is defined,  
and (usually through a visualisation library) a render view is returned.

If the the visualisation is interactive, in addition to this I need to  
define an interaction style, and I might need to add inside the scene  
additional service actors such as handlers that exist only to sustain  
a certain interaction.  The I need to connect the interactions with my  
interaction hardware, and with the rest of the GUI.

In many of our applications there is an additional level of  
complexity, when an interaction does not change only a parameter of  
the scene of its rendering, but it actually modify an actor.

For CTK I can see two possible options:

a) The quantum of encapsulation in the View. A CTK View is a module  
that can take as input standards CTK Data Objects ( I here postulate  
CTK will have a unique Data Object Model) and return a render window.   
In addition, the View exposes some interaction styles, that must be  
connected to actual interactions, and a number of View Settings, that  
the application must capture and pass to the View (typically via a  
GUI).  Each view run a separate thread, and connects with the rest of  
the application through a limited set of public APIs.  a Facade class  
prevents any access to internal methods, and makes easier the wrapping  
into scripting languages. So for a programmer writing a CTK-based  
application a View is something he can use as it is or not, but cannot  
be modified (except of course changing the code of the view itself).   
Which visualisation library is used inside each view is immaterial.   
The View programmer has the responsibility to transform the CTK Data  
Objects into Actors compatible with VTK, Open Inventor or whatever he  
plans to use for that view. Similarly, it is his responsibility to  
transform the rendering output of the visualisation library into a CTK  
Render Window.  In the picture below the CTK View would be the blue box.

b) The quantum of encapsulation is the scene. CTK provides classes  
that automatically compose data objects into actors and these into  
scenes, and expose such scene in a way that is neutral to the  
visualisation library.  Each application programmer is responsible to  
decide what to do with this scene, but in principle CTK could also  
provide additional modules for interactive rendering.  The scene  
composer module is the red box, and the interactive rendering module  
is the brown box.

I personally believe that we would have an advantage with option b)  
only if the brown box could be entirely replaced by an existing  
visualisation library; unfortunately I suspect this is not the case:
- Most scengraph libraries treat only vector data + textures;  
extensions are needed for example to render volumes
- Most complex interaction styles cannot be encoded in the scenegraph,  
and need to be programmed with direct calls to the visualisation  
library.
- No visualisation library could provide you out-of-the-box mechanism  
to modify CTK data objects from interaction.

This means in most realistic cases the application programmer should  
anyway cross the brown box and code directly with the visualisation  
library calls.

This is why we consider option a) the most interesting for CTK.  If  
you are an application programmer you use pre-packged View modules,  
and you just have to pass your data object, attache your interaction  
devices to the pre-defined interaction styles, and expose in your GUI  
the View settings, and the render window: done.  If you need a special  
View, then of course you need to dirt your hands with a visualisation  
library, but this would happen anyway.  CTK community could provide  
template of View modules to be programmed with VTK, Open Inventor,  
OpenSG, etc. to make life easier.

Added these notes and the figure to the wiki:
http://my-trac.assembla.com/protoctk/wiki/ctkScene

cheers

Marco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctk_view_encapsualtion.gif
Type: image/gif
Size: 7792 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20090829/389f9439/attachment-0002.gif>
-------------- next part --------------







--------------------------------------------------
MARCO VICECONTI, PhD                              
(viceconti at tecno.ior.it)
Laboratorio di Tecnologia Medica              tel.   39-051-6366865
Istituto Ortopedico Rizzoli                            fax.    
39-051-6366863
via di Barbiano 1/10, 40136 - Bologna, Italy

Tiger! Tiger! Burning bright in the forest of the night,
what immortal hand or eye could frame thy fearful symmetry?
--------------------------------------------------
Opinions expressed here do not necessarily reflect those of my employer