[WF-Protocols] Proposals on common format

[Cody Russell]

On Mon, 2003-06-30 at 07:41, Miguel Guzmán wrote:
>     I agree to this. AFAIK the Ogre engine also uses a binary format 
> that can also be serialized to XML, so this seems a popular choice. 
> Correct me if I'm wrong, but I also recall fluoro from NeoEngine also 
> preferring an XML format for starters. Seems that, if no one disagrees, 
> we'll be using XML.

Hi, I'm fluoro from NeoEngine.  Yes, I was advocating the use of XML for
this file format also.  But first...

>     Of course if a format is not widely used, or is incomplete, it is a 
> waste of time and effort to adapt a project to it. The trick here would 
> be to first design the format, then make converters or loaders for the 
> engines, but still keeping each engine's own format, at least until the 
> standard reaches a level of development in which using it as the primary 
> format is a no-brainer.

I think before we sit down and design the file format, we should sit
back and first discuss the exact purpose of this proposal and make sure
that everyone is on the same page.  It serves no purpose for everyone to
sit down and define a file format only to discover halfway through the
design process that someone thought this file format was meant to do
something else.

We should define the initial goals of the file format.  It also would
serve no purpose to start designing a file format only to discover later
that .md3 does everything we want to do and is already somewhat
standard.  Jorrit covered a little bit about goals, but I think someone
should make up a nice list covering everything so that people can add or
discuss things.  Off the top of my head, such a list might look
something like this:

1/ Easily extensible
2/ Easy to implement
3/ Independent of platform (e.g., Win32, Linux)
4/ SDK-independent (e.g., OpenGL, Direct3D)
5/ Prefer robustness to speed

These are just some ideas.  Some people may want it to aim for speed to
be more useful for in-game use or whatever.  These sorts of things
should be discussed.

>     I think the proper way here would be to get the best of both worlds: 
> determine the maximum set of features that would be useful to all 
> engines and add them all to the standard, even if some engines currently 
> don't support them, and make the readers / loaders / converters ignore 
> features they currently don't use. IMHO for a model (mesh + bone 
> skeleton + materials) there is a wide common set of features, being the 
> differences between the distincts implementations minimal and thus 
> justifying the use of a standard.

One option would be going with an OpenGL-like approach and having
features that are part of the specification, then having additional
features that could be marked as "extensions" with an extension source
tag (e.g. "CrystalSpace" or "NeoEngine"), then any other tools that read
in the file can either choose to ignore extensions they don't support. 
Then we could choose to promote those extensions to file format features
in future versions, but in the mean time it gives different engine
designers the liberty to add any features they want to the file format
for their own use.

In the mean time, people would decide what features they want to go into
the 1.0 file spec, and those features would be based upon what features
their engine uses.