[Ctk-developers] more on CTK Scene

[Stephen Aylward]

Hi Paolo,

You (the MAF gang) summarized the issues and options very well!   Thank you.

I agree that if option 1 is feasible, it would be more elegant, and I
think it is feasible.

Really looking forward to the meeting in Oxford to discuss this
face-to-face.   I think a few more drawings, similar to what Marco
started, will be very helpful and set a clear path for us.

Thanks!
Stephen



On Thu, Sep 10, 2009 at 7:11 AM, Quadrani
Paolo<p.quadrani at scsolutions.it> wrote:
> 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
>
>
>
>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>



-- 
Stephen R. Aylward, Ph.D.
Director of Medical Imaging
Kitware, Inc. - North Carolina Office
http://www.kitware.com
stephen.aylward (Skype)
(919) 969-6990 x300