As a java programmer, I’d like to give you my $.2 
Instead of having a common xml format, I think what you need is a common API, much like the SAX API that can read any xml document easily. I’ll try to give an example and give you the similarities with SAX:
SAX knows events like “tags”, “attributes”, and “characters”. That’s basically all there is in an XML file. In a 3D model file, we’d have events like “vertices”, “coordinates”, “groups”, “animation”, …
for every file format, you’ll need a parser. SAX readers are basically different implementations that read the same kind of documents. However, when reading 3D files, we would need one parser for every format. (For example, an “OBJParser”, a “3DSParser”, a “COLLADAParser”, etc) Every time this parser encounters a vertex in the 3D file, it will fire a “vertex” event. The parser logic does not need to know who is interested in this vertex, and it does not need how to store this vertex. It just says “hey, I’ve found a vertex!”
on the receiving end of this pipeline, are the sax handlers. In sax, if you want to parse xml documents, you simply write a small handler that looks only for the xml-tags you’re interested in. For our 3D models, you’ll need to write a handler for every scene-graph notation you wish to store the files. A game engine like Xith would have a “XithHandler”, for example, and JME would have a single “JMEHandler”. And when one of the parsers shouts “I’ve found a vertex!”, then the XithHandler will reply: “So you’ve found a vertex? Here, let me handle it and store it into my proprietary format…”
So when somebody invents a new 3D file format, they would only have to write the “parser” part. This parser would fire a bunch of events, just like all the other parsers. By writing one parser class, the file can now be parsed by all game engines that have a Handler!
If Java3D wants to have a model loader, they’ll have to write a handler, and for every kind of event fired, they would have to decide how to store that internally. By writing one Java3DHandler, they can read all 3D formats someone bothered to write a parser for!
The Java3D team need not know about the newly invented 3D format, just like the parser for the new format does not need to know about Java3D. Any programmer who wishes to read the new format inside a Java3D scene, simply downloads the parser for the new format, and the handler for Java3D. Their code would look like this:
import new.format.parser.*;
import java3D.handler.*;
//...
Java3DHandler h = new Java3DHandler(new NewFormatParser("NewFormat.txt"));
javax.media.j3d.Node theImportedObject = h.parse();
EDIT: if you wanted to load 3D files in your own custom game engine, you’d need to implement a certain interface, like this:
public interface Handler {
public void startTriangle(String ID);
public void startVertex(String ID);
public void startCoordinate(String ID);
public void endVertex(String ID);
public void endTriangle(String ID);
}
I’ve listed the methods in the order they would typically be executed. If your program is interested in triangles, you can allocate memory each time you get a startTriangle() method call, store the vertices as they fly by, and save the triangle() into your own format every time you get a endTriangle() method.
On the other hand, if your program is not interested in triangles, but only in vertices (far-fetched example, but the same would hold for smoothing groups, animation frames, etc), the startTriangle() and endTriangle() methods would do nothing, and you would only code the start/endVertex() methods.
EDIT2: You could also easily have Handlers that write to a file, like an “OBJHandler”, a “3DSHandler” and a “COLLADAHandler”… This way, you could read ANY format 3D file, and write it to ANY format. Theoretically, you could read an 3DS file and store it as an OBJ file, if you constructed a 3DSReader, and coupled it with an OBJHandler.
Unfortunately, I don’t have NEARLY enough experience with 3D data formats to distill a good, common API. One thing is for certain: the API would require a great deal more methods than the SAX API
