[Ctk-developers] more on CTK Scene

[Quadrani Paolo]

Dear Stephen:
  sorry for the late reply, but Marco email and your reply started a
discussion inside MAF developers group that took some time to come to
a consensus. Here is our reply as a group.

Traditionally, data objects contain only data, but not space- 
hierarchical information;
this is defined in the scene. However, complex environments like ITK  
or MAF
implement a different approach where all data objects are posed in an
absolute space. ITK SpatialObjects and  MAF VmeTree are surprisingly
similar in this respect, with the parent-child and absolute poses.

There is also consensus on the fact that the data objects should be
separated by the graphic primitives we use to visualise them, in
respect to the MVC pattern.

the point Marco was trying to make is different. We can imagine the
future CTK architecture as organised around components that can be
plugged and replaced as transparently as possible. So we can imagine
to have a module where the data objects are defined, and also their
spatial containers (SpatialObjects / VmeTree).  We should be able to
take one spatial container from this module and give it to another
module that is in charge of its visualisation.  There are two problems
that we are trying to solve:

a) the data object module should be independent from the visualisation
library in use.

b) in general the Data Object Model required by a complex library such
as CTK is much broader than that is typically supported by
some visualisation libraries.  This means that before I can pass my data
object to the visualisation library I have to transform it in order to  
be presented
to the rendering library and to be used.

We see two options possible:

1) Create for each CTK Data Object type a series of adapters that
"present" that data object as expected by a certain visualisation
library without duplicating it in memory.  So our ctkVolume object
would have an adapter for VTK, one for OpenInventor, etc.  an object
like ctkMeshHermite, which has  not reasonable counterpart in any
visualisation library, would require a downcasting adapter, that
convert the Hermitian cells into lower order cells for the shake of
visualisation.  If these adapters can be done, we could have a CTK
data objects module, which can be connected to any visualisation
component done with any of the libraries for which adapters are
available.

2) Create a CTK Scene module that takes in input whatever CTK data
object (or spatial container of data objects), convert it to a
suitable graphic primitive, let you add camera, lights, and any other
scene element, and output a representation of the rendering
scene made of primitives that every visualization library can render.
In this case the downcasting would be done in this ctkScene module,
and the scene format could then be visualised with any library.

To use vtk examples many of us understand, a ctkVolume object in
the first case would have a vtk adapter that "present" it as vtkVolume.
This is passed for example to a standard VTK pipeline for isosurface
visualisation.

In the second case the ctk Volume would be passed to the ctkScene
module where we would define an isosurface visualisation, extract the
isosurface, set suface rendering elements, create the scene, and pass
it to a visualisation library via a neutral scene description.

To us, if the adapter approach (solution 1) is viable, it looks much  
more elegant.

cheers

the MAF gang

_________________________________
BioComputing Competence Centre
SCS s.r.l.

Via Magnanelli 6/3, 40033
Casalecchio di Reno
Italy