[Ctk-developers] CTK Scene
Quadrani Paolo
p.quadrani at scsolutions.it
Mon Aug 24 08:09:57 UTC 2009
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
More information about the Ctk-developers
mailing list