XML. (was: Re: [ODE] outputting objects)
Anselm Hook
anselm at hook.org
Wed Feb 5 18:07:02 2003
> On the general subject of storing coordinates you need to agree on the
> packing format, even for euler angles. For example Rus had me
> scratching me head for a few days wondering why my object affected by
> gravity always fell to the left and my back \ forward controls move me
> up \ down.
I guess the quaternion should be saved - not just the rotation. Though
that might make it inaccessible to hand tweaking.
> This affects the xforms as well. Left \ Right handed. Should the
> format be specific enough so that you don't need to refer to the doco
> to understand it or should it be implementation specific with implied
> knowledge in the formatting.
Looking at ODE in more detail - perhaps it is best to just use position
and quaternion instead of matrix.
> On a slight tangent I'd like to recommend using the boost::tokenizer
> (or coding something similar) rather than using hard coded
> decomposition of values with multiple fragments for anything from
> Colour="1 0.5 0.5" through to the matrix cases.
Sure.
> We still havent decided on a half decent XML parser to use. I havent
> used libxml so maybe someone else can comment, I'm sure it's cross
> platform. I still like expat, but I nearly use TinyXML a while back
> which I think was crossplatfom. Probably the bst thing to do is to
> just write a generic XMLparser interface class that does the basic
> work we need then allow a different implementation based on people's
> requirements. I can probably code up a xerces based implementation
> perhaps even an expat based one.
I'm trying a lua based approach; where Lua (well, "tolua") provides
capability to find methods by english name, and a lua xml parser breaks
apart tokens and then tries to find them in the lua structure.
I thought this entire thing (200k) could be embeddable and not actually
expose Lua.
But this might be a bit heavy... and scary for people.
> The only unusual thing I put in all of my file parser\loading classes
> is the ability to accep a memory buffer rather than enforcing use of
> file loading internally. Reason being I support loading from zip\pak
> files that if compressed need to be decomposed in to a memory buffer.
This is preferable - I do that as well for all XML parsing I do in
general... even if I stream the tokens to some other layer of the
application. It is *way* faster.
- a