[ODE] File formats

[Anders Backman]

At VRlab I have been working with specifying and implementing a
authoring environment
for real-time simulations. Right now its called osgVortex because of the
Connection between OpenSceneGraph and Vortex.

I started off with Vortex (Critical Mass Labs) XML format, looking a lot
like the one Nate
described.

I soon realized that their format contained a lot of duality. You had to
specify things twice, one size for the visual object and one size for
the collision geometry.
Also it was hard to extend with new specifications.

As everybody else, I had my own old parser which I brushed up and used.

It turned out to work just fine. By supporting the basic datatypes,
integer float strings, vectors of floats, recursive Structs I got it all
together.

So for example 

Object {
  ID "box"
  Size [1 2 3]
  VisualAttributes {
    Geometry {
      Primitive "box"
    }  }
  PhysicalAttributes {
    Geometry {
      Primitive "box"
    }
    Mass 2
    LinearVelocity [1 0 0]
    AngularDamping 0.03
    Material 2
  }
}

Would describe a box, both visual as well as physical.
We are using OpenSceneGraph for rendering so I can use any object that
OSG supports
Reading for both the visual part, as well as for the collisiongeometry
(TriangleMesh, ConvexMesh, GroundMesh).

We had a lot of discussions about on what level this "language" or "file
format" should have.
Should it be implemented in Python? As wrappers, giving the user full
control of the API.
Or should it just describe a state?

By adding small features like expressions I could at least have things
like

Box {
  size_x 3*tan(pi/2)
  size_y randInterval(0,10)
} 

Sphere_size Box.size_x*4

Size_array [Box.size_x*2 randInterval(0,10) log(1.3)]

Also, the script is lazy, so you can write whatever you like as long as
it has
the right syntax, which makes it easier to use for "other"
specifications.
I our case setting up trackersystems, window-sizes, etc...


Then we used this in a course at Computing Science, and the students
just blew me away by using python and Perl to generate "my" scripts.
I had a limitation of 10.000 lines of code, after a couple of hours of
labbing one of the students asked me to remove that!
That's when I realized he was using perl to generate spirals of Domino
bricks...

So now we are using Perl, Python and Multigen Creator to create
Physical/Visual scenes.
Of course using "your" own language/script/fileformat is always a
hazzle, but using the XML parser is not trivial either...

And in the end, I rather read/edit Something I can read, before XML...
But if your not supposed to hand-edit the files, then the readability
can be safely ignored.

________________________________________________________________
 Anders Backman               Email:    andersb@cs.umu.se
 HPC2N/VRlab                  Phone:    +46 (0)90-786 9936
 Umea university              Cellular: +46 (0)70-392 64 67
 S-901 87 UMEA SWEDEN         Fax:      +46 90-786 6126
                              http://www.cs.umu.se/~andersb 

ab > -----Original Message-----
ab > From: ode-admin@q12.org [mailto:ode-admin@q12.org] On 
ab > Behalf Of Anselm Hook
ab > Sent: den 28 januari 2003 12:26
ab > To: Nate W
ab > Cc: ode@q12.org
ab > Subject: Re: [ODE] File formats
ab > 
ab > 
ab > 
ab > > Should the 'one true physics file format' include 
ab > rendering-related
ab > > information like mesh data?
ab > 
ab > The failure of VRML was the slight ambiguities that led to 
ab > different
ab > implementations and fractured the user base.  Minimizing 
ab > the functionality
ab > is a good way to avoid fractures.  While it is appealing 
ab > to subsume extra
ab > features (especially this one) it is one more 
ab > responsibility.  Then there
ab > are issues like texturing, UV coordinates, stripping of 
ab > polys etc.  This
ab > is as bulky as the rest of the format.
ab > 
ab > Also if one person can be sufficiently autocratic and own 
ab > the spec then
ab > that would help prevent feature bloat.  (A joke my father 
ab > once told me
ab > about decision making by committee:  intelligence of 
ab > groups is not the sum
ab > of member intelligence but the multiplier of - the 
ab > intelligence of each
ab > person multiplied by the other - ie if joe is .90 percent perfectly
ab > intelligent, and tom is .80 percent perfectly intelligent 
ab > then together
ab > they are .72 ...).
ab > 
ab > > Or should each object include a reference to rendering 
ab > data stored in
ab > > another file?  Elsewhere in the same file?
ab > 
ab > Some kind of url or named external reference must be 
ab > possible in valid
ab > XML.  I'd vote for that.
ab > 
ab > > Or should objects just have unique identifiers so that 
ab > the application can
ab > > apply mesh to bodies using information from multiple files?
ab > 
ab > Is a name unique enough? relatively unique in path?  
ab > effectively an url.
ab > 
ab > > What about collision data?  The above questions apply here too.
ab > 
ab > This is harder - at least texturing and suchlike is not a 
ab > consideration at
ab > all.  Obviously the answer has to be yes; although I can 
ab > imagine things
ab > like BSP (although that could be computationally 
ab > generated) and seamless
ab > terrains and elevation maps versus polygon soups.
ab > 
ab > > Juice used primitives shapes so I just set up an enum 
ab > for each shape type,
ab > > and some float parameters for dimensions.  Should 
ab > support for such
ab > > primitives be part of the file spec, or should it just 
ab > treat all things as
ab > > arbitrary meshes?  I prefer the former, but I'm open to 
ab > argument.  The
ab > > latter approach has a nice uniformity to it, but I'm not 
ab > sure how to take
ab > > advantage of built-in primitive collision detection 
ab > without primitive data
ab > > in the file format.
ab > 
ab > I'd vote for the former since even though different types 
ab > introduce more
ab > complexity - there is fantastic bang for bug.
ab > 
ab > > Which axis is up?  Which is left-right and which is 
ab > front-back?  Should we
ab > > adopt the OpenGL axes?  D3D axes?  Invent our own?  In 
ab > Juice, +Z is up, +Y
ab > > is forward, and +X is right.  That's probably not 
ab > compliant with anything
ab > > else. :-)
ab > 
ab > Imitate VRML?
ab > 
ab > > What about motorization?  Should the file format include 
ab > that sort of
ab > > information?
ab > 
ab > Routes might help?  Controller nodes might be stubs where 
ab > real behaviour
ab > is elsewhere.  Actual routes between controllers and ODE 
ab > objects could be
ab > implemented by bridge objects - routes in VRML.
ab > 
ab > Routes are needed even for trivial visualization of 
ab > behavior; connecting
ab > an ODE body to a graphical representation.
ab > 
ab > The data-flow and wiring together of stuff is a big 
ab > question actually -
ab > what about perhaps using hierarchy to specify routing 
ab > relationships?
ab > 
ab > > In the ODE paradigm, motors are basically properties of 
ab > joints.  I
ab > > personally hope to eventually see motors have their own axes and
ab > > orientations, independent of any joints.
ab > 
ab > No ideas.
ab > 
ab > > Should the file format treat motor parameters as just 
ab > joint parameteres,
ab > > or should motor paramters (including orientation) be 
ab > decoupled from joint
ab > > parameters?
ab > 
ab > Not a clue.
ab > 
ab > > What about higher-level behaviors, like mapping keyboard 
ab > and joystick I/O
ab > > to motors and gaits?  Should the file format deal with 
ab > such things, or
ab > > should that be treated as a separate matter?
ab > 
ab > Question is where is the cut-off?  Does the doc include 
ab > just ode bodies,
ab > collision hulls, geometries, motors and relationships, or 
ab > also switch
ab > nodes, cloning nodes, user input, camera control, 
ab > controller widgets, arc
ab > ball controllers, sensors, timers, system events, layout 
ab > management -
ab > hmmm... it is a slippery slope!
ab > 
ab > What would be great is if the parser could respectfully 
ab > ignore things it
ab > did not recognize.
ab > 
ab > > What else should be asked and answered?
ab > 
ab > This will be a very far reaching discussion undoubtably.
ab > 
ab > Nate, I think you've definately got the issues down.
ab > 
ab >  - a
ab > 
ab > _______________________________________________
ab > ODE mailing list
ab > ODE@q12.org
ab > http://q12.org/mailman/listinfo/ode
ab >