[ODE] New ODE GUI Editor available : ezphysics.org

[William Denniss]

On Thu, 2004-02-26 at 14:04, Billy Zelsnack wrote:
> If you're going to lead a file format attempt, I can picture three
> major
> religous issues. 1. binary or text which is already showing its head.
> 2. if
> text, then xml or not. 3. scope.
> 
> My personal opinion is that it should be xml and have no tags besides
> what
> is in the ODE api. It should be the ODE format, not a general
> physics/simulation format. The naming conventions should reflect this.
> Anything fancy like behaviors or anything else are some other format.
> 
> btw. I don't really like xml, but it does provide a known starting
> point.

I'm certainly not one of those "everything should be xml" people but I
really think that in this case it makes a lot of sense.  The tree
structure, objects, and attributes all play nicely with xml.  There is
also many efficient XML tools already created in many different
languages for us to use.

I am all for a pure ODE format - anything else would just be too broad
and be less useful.

> Some xml issues are how to define the objects. With custom tags or with
> types. (sorry, i don't know the proper xml terminology)
> 
> <hinge id="left_elbow" jointGroupId="blah">
>     <anchor value="0 0 0"/>
>     <axis value="0 1 0"/>
> </hinge>
> 
> vs
> 
> <object type="hinge" id="left_elbow" jointGroupId="blah" >
>     <attribute name="anchor" value="0 0 0"/>
>     <attribute name="axis" value="0 1 0"/>
> </object>
> 
> or maybe a hybrid.

Either works I guess, but considering there are pretty few different
objects in ODE anyway, the former is probably better as it is easier to
read (when one has to load it up in a text file).

> On a side xml note. I like to think of xml elements like a constructor
> with
> a body. In the examples above would be like this in pseudo c++.
> 
> someHinge=new hinge(jointGroupId="blah");
> someHinge.anchor="0 0 0";
> someHinge.axis="0 1 0";
>
> All elements in the constructor exist at the time of creation where all
> elements in the body are only added as they are parsed. This shows its
> usefulness once you start having child objects. The constructor gives a
> parent object enough information to create itself. As each child object
> is
> then parsed and created, it is added to the parent.

and this is one of XML's strengths for this type of problem, the
parent/child relationships are maintained without much effort at all.

It would be very good if all these new editors could at least import and
export to a common format (regardless of their various internal
formats).  The exporting part at least would be fairly straight forward
- just iterate recursively though the object tree printing out tags and
data :)

Cheers,

Will.