That''s gonna be a hell of a work ! I don''t think that you''ll be able to incorporate everything into a single format, simply because there are always new rendering methods coming out needing new / different data in the file. I would design it as a chunk-based format. It should just contain basic geometric information (mesh, object, hierarchy...). Everything else can be added by user defined chunks. So your format is fully expandable but stays backward compatible. New chunks could even get ''standarized'', if they are used by many people, kind of ARB like
Also interesting, but rather unportable, are constructive geometry based formats, like the .max format: Normally, it doesn''t contain raw geometry (except for editable mesh objects), but a list of instructions on how to create primitives, apply modifiers on them, apply materials etc...

Will your format be ''game type only'' or is it intended for professional use ? if the later is the case, it''s going to be really hard, since you have to include data like NURBS/NURMS, metageometry, CSG, data for raytracers, shaders, perhaps even whole radiosity lighting solutions, and so on...

Good luck

I''d make it an ASCII format (easier to debug), something like this (modeled a little off of C++):

VERTEX(1){  x = 10.000;  y = 28.000;  z = -83.000;  diffuse = 82, 255, 0;}FACE(1){  vertex_list = [1, 2, 3];  texture = "./sheet_metal.tga";  }

And simply ignore attributes that you don''t know about. That way plug-in writers can simply write and read any attribute from a file of your format, regardless of whether or not you anticipated it when you wrote it.

I don''t even dare to imagine the filesize of a say 1 million face scene in TerranFury''s fileformat

But if this is an "abstract" format for use in a conversion program, I don''t think you need to worry about the size as much. You could optimize it so that it only calculates the parts of the file it needs at any one time.

I think a better way would be that the "importing" part of the software "publishes" all the properties it wants, and the "exporting" part "subscribes" to all the properties it wants. So what you do is make a standard set of property names, eg "NumVertices", "Vertex[0].x", "Vertex[20].normal", etc, and the importer just publishes whatever it supports, and when the exporter wants to subscribe to a particular property, if the importer doesn''t support it, you just give it the default. That way, if some new format comes along, you can just make up a new property for it to publish/subscribe to.

If you want to write the abstract data to a file, you could do it lots of ways, in some binary form, maybe using TerranFury''s format, or even XML.

War Worlds - A 3D Real-Time Strategy game in development.

I recommend you avoid reinventing the wheel and instead go check out an amazing little language named Lua (see http://www.lua.org ). it''s embeddable with a nice C API and has excellent data description capabilities by design. thus, your data files are actually Lua code. an example along the lines of your suggestion would be something like:

vertex = {x=10,y=28,z=-83}
faces = {}
faces[1] = {vertexlist={1,2,3}, texture="./sheet_metal.tga" }

Lua also has some OOP syntax if you want it, a metafeature called Tag methods for implimenting any kind of language feature you like (eg, OO systems), and is tiny and fast.

I read about XML and such and just think "why? Lua is a simple convienient solution." many games use Lua now. check it out.

quote:Original post by Rykard
Thanks for all the answers, but I''m not so much working on a "file" format as the internal data format for my program. I don''t think the world REALLY needs yet another 3d format... This app is about converting them from one to another, to make them usuable in your app/game

That''s what my suggestion is about. You an abstract class, like this:

  class Importer{public:    string GetProperty( string name );    bool HasProperty( string name );};  

Then, in your Exporter::DoExport() (or whatever) method, you do this:

      // export vertices, vertices would be a "required" property    int numVerts = importer.GetProperty( "NumVertices" ).toInt();    for( int i = 0; i < numVerts; i++ )        WriteVertex( importer.GetProperty( "Vertex[" + i + "]" ) );.    // now, maybe bones aren''t required, but this exporter supports them, so we ask the    // importer if it supports them, and export them if it does    if( importer.HasProperty( "NumBones" ) )    {        int numBones = importer.GetProperty( "NumBones" ).toInt();        for( int i = 0; i < numBones; i++ )            WriteBone( importer.GetProperty( "Bone[" + i + "]" );    }.    // and so on.  

Of course, you might think of a better way to represent properties than with strings, but you get the idea. An importer can have whatever properties it wants, and the exporter only looks for those properties it supports.

War Worlds - A 3D Real-Time Strategy game in development.