I'd highly advise against xml for a model format.
Models can have thousands of vertices and thousands of polygons, and each poly needs several pieces of information.
If you start using an xml format, you will waste a ton of space and memory in loading and parsing the model files.
I recommend using a tightly packed binary format for your model files, and use a simple scene descriptor file (maybe xml based) to set up the game environments. you could then reference the model files either by an index into a master model list, or by file name.
An example from a project I was working on ages ago:
<scene id="castle-gate" lighting="castle-gate.lights">
<models>
<model id="base-terrain-0" x="0.0" y="0.0" z="0.0" />
<model id="castle-gate" x="0.0" y="0.0" z="0.0" />
<model id="guard-tower" x="0.0" y="0.0" z="0.0" />
<model id="player" x="0.0" y="0.0" z="0.0" />
<model id="guard" x="0.0" y="0.0" z="0.0" />
</models>
<entities>
<entity id="player" model="3" x="1.0" y="1.0" z="10.0" sx="1.0" sy="1.0" sz="1.0" controller="user" />
<entity id="guard" model="4" x="20.0" y="1.0" z="30.0" sx="1.0" sy="1.0" sz="1.0" controller="guard-control" />
</entities>
<triggers>
<trigger id="start-cam" run="startCameraPan()" x="-5.0" y="3.0" z="5.0" sx="4.0" sy="4.0" sz="4.0" oneshot="true" />
<trigger id="guard" run="interact(guard)" x="guard.x" y="guard.y" z="guard.z" sx="1.5" sy="1.5" sz="1.5" oneshot="false" />
</triggers>
</scene>
Its doubtful you can understand what it all means at first glance...
There are a few lists of objects that the scene describes.
The model list is a list of model file names without the extension, because my engine supported 3 model formats (all based on plg)
The entity list is a list of game world objects that each have a model, a position, a scale, and a controller function.
The trigger list is a list of non-visible objects that are used to trigger events.
Each trigger specifies the script code to execute when the object is triggered in the run argument.
The position of a trigger may be linked with an entity (as I did with the guard) so that when the user controlled entity collides with the trigger-enabled entity, an event can fire.
Each trigger can be set up as a "oneshot" which means once it fires, it cannot be fired again.
This is useful for events that will only happen once per game session, such as the starting camera pan "cut scene" event that I have in the scene above.
I wish like hell that I still had this project's source. Fucking Windows 98 ate this one years ago.
Anyway, good luck, and have fun.
