[Ctk-developers] CTK Scene

[Paladini, Gianluca (SCR US)]

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