Hey guys,
It's better to stick to 2.49b for now. I'm following on the release of 2.5. However looking at the current state of things, they are not quite ready for actual stable work yet. I'm planning to only start working on a whole new exporter when they stabilize the script side of 2.5 build. That means their beta 0 build hopefully. However, I believe a proper port with full features will only be available when they release their final stable build which basically means their 2.6. See:
http://www.blender.org/development/rele ... ender-250/
Personally, looking at what they have changed and the core stuffs they have modified, they should call it 3.0
At any rate, I will call for testers when the WIP exporter is ready for testing.

So until then, all production work should still stick to 2.49b.
cyrfer wrote:I have recently been wondering about is how to control the Submesh feature of the Ogre mesh. I think each Ogre SubMesh is more equivalent to a Blender mesh than the Ogre Mesh. For example, I believe that in Ogre, part of a Mesh can have have mulitiple UV coordinates, while other SubMeshes can have one or zero UV coordinates. The Blender mesh does not directly map to the Ogre Mesh, but may map directly to the Ogre Submesh. I wonder how this is handled in the OgreMax exporters for Max/Maya? Can the Ogre exporter be extended to use a hierarchy of Blender mesh Objects? Has this already been discussed? Ogre's mesh seems much more flexible than the Blender mesh definition. Maybe the Ogre community should suggest improvements. Unfortunately, I don't have any 'pull'. Perhaps I'll try anyway.

I've looked much into blender's mesh and yes, like you said, they are less descriptive than ogre meshes. Hence it's impossible to do stuffs like naming submeshes or having more optimal UV allocation on different submeshes. What can be done is to have a special mode where the exporter assumes that all selected meshes in blender must be exported as a single mesh. With this, it is possible to better describe Ogre's submesh using multiple blender meshes. However, this complicates things and only makes it difficult for the artist. In the end, the only proper way to do this is to have the feature build in as part of blender's mesh. It would undoubtedly make things more complicated for the artist though. Note that ogre supports both shared vertices and non shared vertices for their submesh. Trying to introduce that idea to an artist would be nightmarish.