Perhaps I've been going about this the wrong way... I've been searching for quite a while now for a file format to use for importing 3D models into openGL. I've asked here and elsewhere, and I haven't even come close to anything. I've tried many file loading libs, but the vast majority either assume you know their library back and front, that you enjoy being handed a large document full of poorly described functions (and then having to go line by line trying to figure out how they relate), or that you find much comfort in examples that don't really demonstrate anything (had one that showed you only how to load a file, then save it to another file. Nothing else. Never anything to do with displaying it, never touching anything but the surface of the lib. I could do that with a simple fopen fread fprint....) What I want is a very simple and straightforward way to have interchangeable meshes attached to animating bones. In other words, a modular system - like displaying weapons/armor/helmets in an FPS, but with many more points of interchangeability. Originally I thought this was merely a matter of loading all the meshes and a single, separate skeleton (the meshes, for simplicity, all animate the same way). The meshes would be weighted as normal to the entire skeleton, but there would be a requirement that the graphics designers keep meeting points between meshes (the neck and head, for instance) similar enough that they do not generate gaps. Evidently, this seemingly easy task is a monster. First, I need a format - ideally one that blender can deal with, though this is resolvable by a python script. If it doesn't have normals, it's already out - I use per pixel lighting and can't waste more time calculating the normals of every vertex from the faces alone. I already have to calculate the normals every frame, but it's much easier if I already know the vertex normals (just rotate those normals by the current rotation of the vertex, which is just the total rotation of the bone and it's ancestry). I need it to have texture coordinates, and while before I would have assumed that this was a given, turns out it wasn't. I need it to have bones, and to store the weight of bones per vertex (no .obj). Ideally it would sort the vertexes in some sort of optimized order (triangle list with 0 area triangles to compensate for complexity?) but this isn't a prerequisite. Finally, though this can be separate, a simple storage of keyframes (by bone). Second, I need a loader for that format. It's very unrealistic to tell someone "hey, all you need to do is stare at a format specification for about 3 months and you're fine!" That's rather like telling someone they can learn to write an operating system by staring at the definition of one. Likewise, any loader for that format should be clear, explicit, and direct with their documentation and examples. Again, the bare-bones definition of an operating system doesn't help anyone in using it, unless they already know operating systems. Writing my own loader does eliminate the need for a loader, but it exacerbates the first part of this paragraph: if I don't know the format, I can't write a loader. Third, I'd appreciate any pointers towards optimization. This sounds slow - terribly slow - but I can't test it because I can't even get off the ground. Any help in optimization of techniques, any links to related documents or just design theories, I would appreciate. The more clear and in depth, the better. Thanks for wading through this wall of text - I appreciate you taking the time.

I've been thinking about it, and listening to what most have said. Perhaps I should write my own XML file format so that the project I'm working on doesn't grind to a halt. I'll have to "hand craft" models until my next question gets answered, but I wonder if this is the best thing to do.

And this, of course, brings up my next question. How can I possibly write my own format if I don't understand the available formats well enough to write a converter? It seems to be the common suggestion to "write a game specific format," but this seems even more complicated than just reading the file itself.

Anyway, I've looked about and came up with something like this:

<?xml version="1.0" encoding="UTF-8"?><skeleton>	<figure>		<bone name="root" parent="NULL">0.0,0.0,0.0</bone>		<bone name="spine" parent="root">0.0,10.0,0.0</bone>		<bone name="cocyx" parent="root">0.0,-1.0,0.0</bone>		<bone name="shoulder_left" parent="spine">-3.0,0.0,0.0</bone>		<bone name="shoulder_right" parent="spine">3.0,0.0,0.0</bone>	</figure>	<animation name="idle">		<frame duration="1000.0">			<move target="spine">0.0,20.0,2.0</move>			<move target="cocyx">0.2,39.0,1.0</move>		</frame>	</animation></skeleton>

Then, something similar for each vertex.

<?xml version="1.0" encoding="UTF-8"?><mesh>	<points>		<vertex>			<normal>0.0,1.0,0.0</normal>			<texcoord>0.0,0.0</texcoord>			<location>0.0,3.0,0.0</location>			<weight bone="spine">0.9</weight>			<weight bone="shoulder_left">0.05</weight>			<weight bone="shoulder_right">0.05</weight>		</vertex>		<vertex>					</vertex>	</points>	<faces>		0,1,2		1,2,3		3,4,5		6,7,8		9,10,11	</faces></mesh>

The idea being that an entire mesh can be created, weighted to a bone system, then diced up into fragments and exported.

I haven't gotten much clearer advice than this, so I'd really appreciate some pointers.