Status: Draft William Denniss Version: 1 Tank Software Revision: 03 March 2004 XML ODE Data Interchange Format - XODE Status of This Memo This document specifies a proposed standard for the ODE community. Distribution of this memo is unlimited. Notices Copyright (C) William Denniss (2004). All Rights Reserved. Abstract This document describes an XML format which can be used as a common ODE interchange format. 1 Introduction 1.1 About ODE Open Dynamics Engine (ODE) is a "free, industrial quality library for simulating articulated rigid body dynamics - for example ground vehicles, legged creatures, and moving objects in VR environments. It is fast, flexible, robust and platform independent, with advanced joints, contact with friction, and built-in collision detection". A typical ODE scene hierarchy consists of physics, collision and display objects. Physics and collision is typically handled by ODE with the graphics potentially using any number of display libraries (three dimensional or otherwise). This scene structure is commonly used in both graphical ODE editing applications, and software using ODE. 1.2 Purpose The goal of this standard is to provide a method of storing an ODE scene, representing the physics, collision and graphical objects and to do so in a generic, interoperable and extensible manner. It is domain specific to ODE to avoid compromises and hence is suited to people using the built in ODE physics and collision objects but like ODE, doesn't limit them to one display method or another. 1.3 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant." 1.4 Terminology importer Code which can read the XODE format into some internal representation for manipulation, display or otherwise. exporter Code that can write an XODE formatted file from some internal representation. collision system A mathematical engine which detects when two objects intersect and generates an appropriate response physics engine A mathematical engine that has set of physical rules for example gravity or friction that it applies to objects in it's system graphical engine A programming library used to display objects to the user, for example a 3D OpenGL scenegraph. world A container for physics body objects body A physics object with such properties as mass space A container for collision objects collision geom A geometry describing a shape that is used for collision mesh A list of three dimensional coordinate data used to display an object in a graphical engine trimesh A collision geom consisting of a mesh of triangles. Whilst it shares a similar structure to 3D meshes used in the graphical engine, it must not be confused with them. group A collection of objects organised into a bag for organisational reasons. 2 XML Tags 2.1 The root tag of an XODE file, there must be one and only one. It can contain multiple the tag and nothing else. 2.2 Represents an ODE world - a container for bodies, geoms, meshes and joints. It can contain all ODE tags such as , , and . 2.3 Representation for the ODE body object (used in the physics engine). Belongs to the - or a 2.4 Representation for geometry objects (used in the collision detection engine). It is usually attached to a body (as a child node) but this doesn't have to be the case if it is representing a static - immovable object (such as a wall). All s must have a tag which among other things specifies the shape of the geom (for example, box or sphere). [ TODO: Define geom shape tags ] 2.2 tag Representation for the graphical objects used by the graphical engine to display the ODE scene. As for , it is usually attached to a body but not in the case that it represents a static object. The actual type of the object is not stored to preserve the Independence of this format from any one graphical engine. Instead only basic data such as the mesh's name and scale are stored. It is up to the importer to determine what to do with the name. For example it could use the name of the mesh to load a particular file or extract the relevant node from a Map of names to nodes. 2.3 tag For extensibility reasons - all XODE tags without exception may additionally contain an "" tag. This tag is provided so that extensions can be added to the format by applications. Any time an XODE file is imported with the intention of being altered and exported, the importer SHOULD read this tag and save it's data for exporting even if they are not using any extensions themselves. This is so that an XODE file with such extension data can be edited in an editor which doesn't support it's extensions without losing said data. Applications using the tag of XODE SHOULD attempt to do so in a way that multiple extensions can co-exist in a file. The RECOMMENDED way of doing this is using a tag named with the name of the extension stored in a "name" attribute. Eg: ... ... In the above example, and application not supporting the extension "foo" should still preserve its data when exporting. 2.4 The group tag is a container for all the objects that is but has no actual meaning in ODE. Importers MUST be able to read the group and it's contents but it is OPTIONAL for them to actually do anything with the group meta-data itself. Exporters MAY export groups. The tag can be present in a or another only. It exists for a variety of reasons, mainly so that objects can be organised by editors and applications for other uses. 2.5 Attached to a or tag - this is a container for joints. 2.6 Represents a joint in ODE. Can either belong to a or directly to a (or ). Must contain a tag which among other things defines the type of joint it is. [ TODO - define joint types ] 3 Example File This is an example XODE file. ./data/models/tire-small.3ds ./data/models/tire-small.3ds ./data/models/motorcycle-body.3ds 0 0.05 0.0001 0 0.2 0.00001 0 0.05 0.0001 0 0.2 0.00001 4 References ODE Homepage: http://opende.sourceforge.net/