[Ctk-developers] X3D

Marco Viceconti viceconti at tecno.ior.it
Fri Aug 21 06:06:30 UTC 2009


I have some ideas on neutral scenes, which I shall write on separate  
reply to this thread. Here I would like to notice that while I agree  
with Gianluca, the fact is that ACR-NEMA have a working Item under  
WG06 on n-Dimensional Presentation States which explicitly refers to  
X3D:
http://medical.nema.org/Dicom/minutes/WG-11/2009/2009-02-11/WG-11_2009-02-11_Min.doc

So while I am not advocating we buy into X3D, we should keep an open  
root toward it somehow, in case this action of the Web3D consortium  
suddenly gets legs.

Also notice that X3D is a draft ISO standard, although I do not think  
it has been ratified yet.

cheers

Marco



Il giorno 21/ago/09, alle ore 03:37, Paladini, Gianluca (SCR US) ha  
scritto:

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






More information about the Ctk-developers mailing list