[Ctk-developers] Scenes

Wed Sep 16 21:05:13 EDT 2009

Here is a condensed list based on emails I wrote before (included below)
- I think Stephen summarized a lot of it already in the Wiki page, but I
would like this to be included at the end of the Wiki page as my
suggestions:
1) We need a common, generalized scene graph file format that we can use
to exchange information across toolkits
2) It is not useful to implement a new scene graph library - there are
so many off-the-shelf scene graph-based toolkits already, some very good
3) XML is a good choice for an easy to parse scene graph file. Ideally
this XML file could be parsed and translated to object instances from
any scene graph library. The XML format should be organized in different
sections to facilitate parsing in a fault-tolerant way. This is because
a C++ scene graph object that has been modified by a software developer
may get out of sync from the corresponding description found in the
scene graph file.
4) The structure of such XML scene graph file format must not change
drastically if a user loads a scene graph file, makes a simple change to
the scene graph and saves it again. It should be possible to use a
diff-and-merge tool like the ones used for source code in order to see
where specific changes occurred. This is a must-have in order to be able
to work on large projects with multiple developers.
5) The file must allow for the inclusion of information stored in
separate files, in the form of nodes that load "sub-graphs". This is the
equivalent of #include files in C++ code, and it is another must-have in
large projects with multiple developers.
6) The format should include, at least optionally, additional
presentation information about each scene graph object so that a Visual
Programming environment can save and restore the way a developer has
arranged scene graph objects within the workspace (position, grouping,
etc.)

Needless to say, this is what we have implemented for the new XML-based
XIP scene graph file format - except for (1): so far we looked primarily
into Open Inventor, and there are still open questions about whether
this format is general-purpose enough. We'll give it a try for a while
;-)

Cordially,
    Gianluca

-----Original Message-----
From: Paladini, Gianluca (SCR US) 
Sent: Friday, August 21, 2009 12:22 PM
To: Marco Viceconti
Cc: Stephen Aylward; ctk-developers at commontk.org
Subject: RE: [Ctk-developers] CTK Scene

Hi Marco,
I can see this concept of Actors corresponding to Open Inventor
Manipulators, and the concept of RenderWindows corresponding to Open
Inventor Examiners.

Just playing devil's advocate - are we trying to reinvent the wheel?

The goal of CTK is to provide a common set of functionality that we can
all use in our respective frameworks. The idea of having a common,
generalized scene graph file format that we can use to exchange
information across toolkits can be very useful, but is it useful to
implement a new scene graph library, knowing that there are so many
off-the-shelf libraries developers can already use?

For example in the case of XIP there is one free, open source version of
Open Inventor from Sgi which we use in OpenXIP and two commercial
versions from Mercury (http://www.vsg3d.com) and SystemsInMotion
(http://www.coin3d.org) which we use to implement XIP-based products.
Alternatively there are free open source libraries like OpenSG
(http://opensg.vrsource.org/trac), OpenSceneGraph
(http://www.openscenegraph.org/projects/osg), OpenRM
(http://www.openrm.org), NVSG
(http://developer.nvidia.com/object/nvsg_home.html).

Since existing open source scene graph initiatives have put several
years of development into their libraries, an effective way to design
CTK's scene graph interchangeable file format may be to look at what
exists already - a 'competitive analysis' if you will. Do you think this
could be a useful exercise? I admit we only look at Open Inventor for
our XML file format, therefore we may be missing support for
functionality existing in other scene graph libraries.

  - Gianluca

-----Original Message-----
From: Paladini, Gianluca (SCR US) 
Sent: Thursday, August 20, 2009 10:32 PM
To: Stephen Aylward
Cc: ctk-developers at commontk.org
Subject: RE: [Ctk-developers] CTK Scene

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: Paladini, Gianluca (SCR US) 
Sent: Thursday, August 20, 2009 9:38 PM
To: Stephen Aylward; ctk-developers at commontk.org
Subject: RE: [Ctk-developers] CTK Scene

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: Wednesday, September 16, 2009 8:19 PM
To: ctk-developers at commontk.org
Subject: [Ctk-developers] Scenes

Hi,

ctkScene:  Love it?  Hate it?  Know you can make it better?

Regardless of your current attitude, please send me your ideas and
presentations!!!

I'd like to help organize the discussion on ctkScene that is scheduled
for next Friday.

1) If you are interested in making a brief presentation (less than 10
minutes), then please send me an email with the title.   I will add it
into our agenda.

2) If you have revisions to the Wiki page on ctkScene - please make
those revisions by 5pm EST (22:00 GMT) on Friday.   I am going to
summarize those wiki pages as a set of slides at the start of the
meeting.
      http://my-trac.assembla.com/protoctk/wiki/ctkScene

3) If you have questions, concerns, needs, wants, or rants regarding the
ctkScene, please send them to me and I will create a set of slides
that list "open-issues" to help focus our discussions.   We only have
one-hour, so I'd like to focus on high-level issues that remain, prior
to getting into implementation details.   For example, should a
ctkScene be only a file format or should it also be implemented as a
set of C++ classes?   Should a ctkScene be specific to or independent
of the visualization library?   Should a ctkScene be our primary data
structure, or should our primary data structure simply be an image?
...please add to this list of questions...

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