Archived

This topic is now archived and is closed to further replies.

Rykard

Hypothetically speaking....

Recommended Posts

If I was to design an new 3d format for use in a 3d formant conversion program, what do you all think it would need for properties? I mean beyond the basic Vertices, faces, normals, ect. I would like it to be able to hold all the pertinent information from at least the major 3d formats, including game specific formats. It doesn''t need to be terribly efficient, as there will only be one instance of the class loaded at any one time, but I would really hate for someone start a new plugin, and find out that the architecture doesn''t support an important property. I could probably just do the reasearch myself, and will... but I just wanted to get some outside opinions/ideas on this.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I don''t even dare to imagine the filesize of a say 1 million face scene in TerranFury''s fileformat

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites