[Ctk-developers] CTK Scene

Fri Aug 21 02:32:29 UTC 2009

XIP is open source, therefore it will serve as a reference implementation on how to parse this XML file. The file refers to nodes by their class name (and optional instance name), the same goes for fields (i.e. public data members) and methods. Therefore in principle the file can refer to objects belonging to any class library. It is up to the application to create instances of such C++ objects while loading and parsing the XML file, connecting objects together and setting their values and properties. If unknown objects are found it means that the application does not have the right scene graph library to match what's described in the file. 

-----Original Message-----
From: Stephen Aylward [mailto:stephen.aylward at kitware.com] 
Sent: Thursday, August 20, 2009 10:22 PM
To: Paladini, Gianluca (SCR US)
Cc: ctk-developers at commontk.org
Subject: Re: [Ctk-developers] CTK Scene

Hi Gianluca,

That sounds like extremely useful work.

I think the medical image analysis field could greatly benefit from
standardizing scene representations as well as standardizing the
recording of data providence (what is the data source, and what
processing has been applied).   These should be base technologies (ITK
/ CTK level) and, like you said, platform independent.

I like the idea of starting from a file format / database structure
for the scene.   Having extensions to define visualization properties
is also an interesting idea.   My only concern is to keep a scene from
become application or visualization specific.   There should be no
storage of gl contexts, gl triangle strips, vtkActors, or properties
specific to those platforms within the scene.

Is there going to be a group / committee that will manage the
extensions to that format?   A reference implementation in C++?

Thanks,
Stephen

On Thu, Aug 20, 2009 at 9:37 PM, Paladini, Gianluca (SCR
US)<gianluca.paladini at siemens.com> wrote:
> Hi Stephen,
> I would like to add another requirement - we should pick a "platform
> neutral" representation of a scene graph that can be parsed into any
> proprietary scene graph technology. In XIP we have already moved in that
> direction - we are about to release a new scene graph file format to
> store/retrieve scene graphs using an XML representation. This is being
> done in the spirit of having XIP Builder becoming a "CTK friendly" scene
> graph editor tool. Ideally this XML file could be parsed and translated
> to object instances from any scene graph library, including Open
> Inventor, OpenSG, OSG, OpenRM, NVSG and so on (yes, there are a lot of
> scene graph libraries out there already...).
>
> This new XML format solves two major drawbacks of Open Inventor scene
> graph files:
> 1) If two developers are working independently on the same scene graph,
> there is no way of using a diff-and-merge tool to synchronize their
> changes (the same way it is done with C++ files). The structure of Open
> Inventor files is rearranged considerably even after the smallest
> change. Our XIP file format is designed in such a way that any changes
> from version to version can be easily identified. This is a must-have in
> order to be able to work on large projects with multiple developers!
> 2) If a scene graph object changes (for example a field name or method
> is renamed or removed) Open Inventor is unable to load a file containing
> an obsolete object being used in the scene graph. Our new XML-based
> format is more fault-tolerant and will simply avoid forming connections
> between objects with mismatched functionality, and will flag those
> objects so that they can be seen and corrected by the user.
>
> I will notify everyone when the file format is posted in the public
> domain. Right now we are testing it with the largest scene graphs ever
> created at SCR (thousands of nodes). It is really not XIP-specific,
> therefore it could be used as a starting point for CTK. In addition, it
> has extra information (in a separate section) that goes beyond just the
> scene graph description: it contains a description about how to
> visualize the scene graph hierarchy itself within a visual programming
> tool (how nodes are positioned on the screen, how they are grouped
> together, their shape and color etc.).
>
> Note that there is an existing consortium for defining a standard XML
> representation of a scene graph, it is called X3D.  They have been at it
> for YEARS and YEARS, it was supposed to be a replacement for VRML but is
> it still lagging behind Open Inventor. And X3D's Medical working group
> is progressing at even a slower pace. In my opinion we are better off
> staying away from X3D - it is my hope that our CTK group will be a
> productive one ;)
> Cheers,
>    Gianluca
>
> -----Original Message-----
> From: ctk-developers-bounces at commontk.org
> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen
> Aylward
> Sent: Thursday, August 20, 2009 6:39 PM
> To: ctk-developers at commontk.org
> Subject: [Ctk-developers] CTK Scene
>
> 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
>

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