[ODE] GUI Editor, to XML or not?

[Mike Wuetherick]

i don't see needing something like this for an engine for run-time, just 
for a tool for the developers to create the physical models of the game 
objects, which would get written to a game-specific binary (or 
compressed) format of some kind.

while we may want to change parameters, etc for testing, having a 
seperate tool for this will be somewhat necessary - which in turn is all 
that i was thinking of for this specific tool (and is all that the 
current offerings provide i believe).

if you want a complete 'simulation' tool to mock up your game world, you 
are better off with a full 3d modeling package (or prototyping package) 
likely.

just my 2 bits
mike w
www.gekidodesigns.com

Frederic Marmond wrote:
> I do agree that XML is very open and so on...
> But:
> - to introduce a big overhead in file size
> - load/save time may be long (parser)
> 
> So, It would be nice to have a XML<->binary converter.
> I mean:
> In a simulation, you may have lot of objects that all contains their own 
> physics data -> a lot of XML code.
> When you have designed it (using XML), you may convert xml files into 
> binary ones.
> Then, you use it (runtime performances will be greater...)
> And if you want to re-change some parameters, you can come back to XML 
> by converting bin->xml files.
> 
> That was just my comment... ;)
> 
> Fred
> 
> 
> Jani Laakso wrote:
> 
>> My opinion for an export goes still for XML, if you know basics of XML 
>> (and XSL), you get things done very quickly. And in bonus, structures 
>> tend to be well defined even when things later grow more complex.
>>
>> For developers this would mean that everyone can then use XSL (like 
>> xpath expressions) in any imaginable way to extract simulation parts 
>> or modify simulation data before inserting it to my application.
>>
>> Here's couple important points more imho:
>>
>> 1. Integration to custom applications
>> -I would not like to construct totally custom parsers from ground up 
>> to read editor data into my application, I'd exploit existing XML 
>> tools here (XSL, DOM or even SAX).
>>
>> 2. Transforming
>> -I would not like to programmatically convert one simulation format to 
>> another, I'd use XSL here.
>> -Example, transform simulation X to simulation Y: increase all jeep 
>> cars geoms mass by %12 and extract only basic simulation parameters + 
>> jeep cars. I'd use XSL here than to create custom converters. Add 
>> lot's of custom examples here.
>>
>> 3. Debugging
>> -problems are easier to solve, xml is easier to comphrehend
>>
>> This format is meant for developers on development stage, so it should 
>> be extensible and easy to use in all kind of situations. On production 
>> platforms one can convert XML files into developer's own custom format 
>> if needed.
>>
>> A physics editor that is meant for constructing complex simulation 
>> setups for ODE, Novodex.., I'd go for XML when exporting / importing 
>> e.g. bodies definitions to / from a file. I do not know how similar 
>> these two are but there could be possibility to do one XML 
>> implementation for an physics editor and then use plain XSL to export 
>> simulation data to ODE, Novodex.. users. It might be that this is not 
>> suitable but author's of physics editors know this better than me.
>>
>> The first impression for XML world can be quite disturbing, but once 
>> you get into it and know where it's suited best, you'll love it. 
>> Learning basic XML and XSL (+XSLT) is simple.
>>
>> Summary, there exists this XML/XSL and bunch of other tools for 
>> various platforms, let's exploit them :)
>>
>>
>> Comments are welcomed, Jani.
>>
> 
> 
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
> 
>