Hypothetically speaking....

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.

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.

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

quote:

---

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.

---

XML is about what I was thinking of, if I decide to bother with a native file format... I am still wrestling with the best way to approach this.
On one hand, I could only support the limited amount of properties that I know to be more or less universal, or at least that an importer dll would be able to convert format specific stuff to, such as vertex/face based geometry, specular/diffuse/ambient and texture map properties, possibly bump maps as well, and keyframe data for either skeletal animation or vertex animation.

OR... I could try like all hell to make an internally extensible data format.. Or perhaps... no data format.. just pass a pointer to data from importer to model view/exporter (model view has a good chance of not making it in, tho) and just use a naming/typing convention for all plugin writers to follow.

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.