[Ctk-developers] CTK Scene

Stephen Aylward stephen.aylward at kitware.com
Mon Aug 24 10:53:40 EDT 2009 

Following Gianluca's suggestion, I'm compiling a list of scene
libraries on the wiki at:
http://my-trac.assembla.com/protoctk/wiki/ctkScene

I'd like to then evaluate each with respect to the requirements we've
listed on that page.   So, if you have any suggestions for changes /
additions to the requirements, please add them to the page or send
them to the list via email.

Thanks,
Stephen

On Mon, Aug 24, 2009 at 4:09 AM, Quadrani
Paolo<p.quadrani at scsolutions.it> wrote:
> Hi Stephen,
> SpatialObject Viewer technique is something similar to what happen now in
> MAF2.
> A VME (Data object) is rendered with a default Visual Pipeline through a
> mafView, but you can customize this association at vertical application
> level (at compile time), so the mafView will instantiate the custom Visual
> Pipeline through an object factory or you can customize the association
> dynamically at run time.
> What we intend to do in MAF3 is to go a step further; abstract also the
> connection with the graphic engine by using adapters toward the more
> suitable graphic engine for fulfilling the specific task. This is the reason
> of the "finding the cutting point" between data and graphic that Marco was
> rising.
> Cheers.
>
> Paolo
>
> On 21/ago/09, at 14:20, Stephen Aylward wrote:
>
>> Both options have merit.
>>
>> I agree that exporting single objects should be supported.   It allows
>> the system to interact with other (legacy) systems and, as you said,
>> provides IO flexibility.    One question regarding terminology...when
>> you say "Actors" you are not referring to vtkActors, right?   I'm
>> fairly certain you are not, but I mention it because this is a point
>> of contention for me at times...I've found vtkActors to have too
>> limited an API to be used as scene objects (e.g., no standard method
>> exists for querying if a point is inside of them, limited concept of
>> parent-child relationships... - they fulfill almost none of the
>> requirements that I posted on the wiki:
>> http://my-trac.assembla.com/protoctk/wiki/ctkScene).
>>
>> Perhaps RenderWindow-specific information can be broadcast via traits.
>>  Traits can be used to describe a RenderWindow (3D vs 2D, MIP
>> transfer function, Grayscale vs Color, Interactive vs passive) and for
>> these traits each object in the scene may optionally change its
>> default appearance (For ObjectX, if renderWindow is 2D,  grayscale,
>> and interactive; then display ObjectX as a semi-transparent contour,
>> and show its control points so that the contour can be edited).   Any
>> application can override these defaults with application-specific
>> behaviour, but those settings should (perhaps?) not be stored in the
>> scene if those settings are not inherent to the object.  The reason
>> the renderWindow is given traits instead of the object having traits
>> is so that the application developer (who is defining the renderWindow
>> within his/her application) can specify the general nature of how
>> objects will appear within it so as to be most effective for the user
>> / task.
>>
>> Really interesting idea about exposing the renderwindow.   I need to
>> learn/think more about that - not certain how it promotes the exchange
>> of information between multiple views or between views and logic
>> modules within a single application.
>>
>> This discussion reminds me of yet another approach...a scene rendering
>> pipeline developed by Julien Jomier called SpatialObject Viewers.   In
>> it, each renderWindow had an objectFactory associated with it.  This
>> objectFactor would generate a different renderer for each object fed
>> to it, based on the object's type.  The application developer could
>> choose different objectFactories (one that produced MIPs, one that was
>> interactive, one that was 3D) for each renderWindow in the application
>> and in that way achieve a desired behaviour/appearance.   Julien
>> presented this system to the NAMIC group years ago:
>>  http://www.na-mic.org/Wiki/images/f/.../Na-Mic-SLC05-SpatialObjects.ppt
>> Wow, we even have a website for them (this is a surprise to me -
>> google is amazing):
>>  http://public.kitware.com/SOViewer/
>> This design pattern could be extended so that the objects, by
>> specifying how they should be viewed in renderWindows having
>> particular traits, could influence which renderer the renderWindow's
>> objectFactory produced for them.  Furthermore, there is no need to
>> extend a renderWindow or application as each new object type is
>> defined.  Only objectFactories need to be extended, and those are
>> intended to be extended via shared libraries.
>>
>> My thoughts for the morning...
>>
>> Stephen
>>
>>
>>
>> On Fri, Aug 21, 2009 at 2:58 AM, Marco Viceconti<viceconti at tecno.ior.it>
>> wrote:
>>>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
> Paolo Quadrani
> _________________________________
> BioComputing Competence Centre
> SCS s.r.l.
>
> Via Magnanelli 6/3, 40033
> Casalecchio di Reno
> Italy
>
>
>
>
>
>



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

More information about the Ctk-developers mailing list