[Ctk-developers] CTK Scene

Fri Aug 21 06:58:36 UTC 2009

One of the goal of MAF3 is to fully separate VMEs (our data objects)  
from Views and from Operations, so as to maximise reusability, and to  
make possible that each of these MAF resources can be added at run  
time as a plugin.

This of course raise the debate on how to provide a neutral  
representation of the visualisation components. Firstly, Stephen  
implies that the right point where to cut is the scene, as most of the  
visualisation libraries do.  But I would like to bring some  
alternative ideas on the table:

a) Actors.  One could image to export single actors instead of whole  
scene.  this would reduce the granularity, and would make conceptually  
easier to develop distributed applications where single actors are  
being generated/updated by separate processes, and the visualisation  
application has the responsibility to compose the scene with them and  
to render it. Actually this idea is not necessarily in conflict with  
the one Stephen and Gianluca advocate; we could image an extensibility  
mechanism to the scene format, so that I can also export a single  
actor using the same XML syntax.

b)  RenderWindows: to the other extreme, in MAF we are considering to  
expose out of the visualisation module not the scene, but the  
RenderWindow.  The rationale behind this is that the true  
conceptualisation nowadays is in choosing for each type of actor a  
certain rendering style, so that multi-actors Views produce a coherent  
representation. So for example, in our MIP View volumes are rendered  
with a MIP visual pipe, but surfaces are rendered with a flat surface  
rendering, so that it appears consistent with a radiography-like image  
where geometric objects are usually man-made and thus of homogenous  
opacity.  In this perspective the View becomes like a virtual imaging  
machine, which produces a visual representation for each digital  
object according to the type and properties of this object in a  
coherent way.

The problem with approach b) is that I have difficulties to see how  
this could be made compatible with scene approach.  One possibility  
could be to extend the XML syntax to include an optional section where  
one can also specify the rendering elements; does this make any sense?

I do not have a strong opinion on this, but I thought it might be  
useful we try to thing a bit out of the box here.

Cheers

Marco

Il giorno 21/ago/09, alle ore 00:39, Stephen Aylward ha scritto:

> Continuing the discussion of CTK data types...
>
> I propose that we have a ctkScene as a driving datatype.
>
> First, perhaps, we need to agree on the definition of a scene.   I
> propose that a ctkScene should have two main traits:
>
> 1) Generically, a scene is composed of objects that fill a portion of
> space and time
> * Objects have a position in space
> * Objects have an orientation in space
> * Objects have a range in time
> * Given a point in physical space and time, it should be possible to
> determine if an object contains it or not.
> * An object should contain at least one point in space and time
> * The concept of units is paramount in a scene.
> ** Units describe the spatial and chronological scale of an object
>
> 2) A scene represents a hierarchy of object in space and time.
> * Objects have a single parent (except a root object) and may have one
> or more children objects
> ** That is, a scene is a tree
> * Moving a parent object in space or time should (by default) cause
> its children to experience the same movement in space and time
> * The coordinate system for root objects is defined as "real-world"
> space.   It is an absolute space.
> * A scene may have multiple roots
> ** It is not necessary to represent everything in space from a  
> single root.
> ** One or more roots are used to contain the physical/temporal objects
> relevant to a particular task.
> * Objects implicitly include their child objects
> ** When querying the time/space extent of an object (e.g., to
> determine if a point is inside of it or to determine its bounding box)
> that query typically also includes its child objects in its
> computations.
> * Most queries to and responses from objects should be with respect to
> real-world space (i.e., the coordinate system of the root object).
> ** For example, querying an object if it contains a physical point is
> done using real-world coordinates (i.e., a coordinate system common to
> all objects in its tree).
>
> I'm adding this to the wiki at:
> http://my-trac.assembla.com/protoctk/wiki/ctkScene
>
> Stephen
>
> -- 
> 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
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>

--------------------------------------------------
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