Any way to convert recent Ogre mesh versions to Ogre 1.0.x ?

[nosignal]

Hi,

We have developed some educational software using augmented reality and Axiom (a .NET port of Ogre 1.0). Even though it is an old version of the engine, we are happy with what it is capable of, and it would be quite a large task to upgrade the engine.
We are focused now on creating content. However, we are having problems as 1.0.x Ogre Export plugins are only available for very old versions of Max and Maya, and our content creators do not have these.

Therefore, I would be very interested to know if there are any ways of converting from more recent Ogre versions (Ogre 1.2.x, 1.4.x, 1.6.x) back to Ogre 1.0.x. For meshes and skeletons.

I found a forum topic describing a conversion from 1.6.x to 1.2.x by using the 1.6.x OgreXMLConverter to get a 1.6.x xml file, then use the 1.2.x OgreXMLConverter to get a 1.2.x binary file (https://www.ogre3d.org/forums/viewtopic.php?f=8&t=50221).
I have tried this technique, with a static mesh (no animation), going from 1.6.x to 1.0.x and it worked.
I have tried this technique, with an animated mesh (and skeleton), going from only 1.2.x to 1.0.x but unfortunately it failed. I get the following error:

Code: Select all

System.Exception: Inner Exception ---> System.NullReferenceException: Object reference not set to an instance of an object.
  at Axiom.Core.Entity.CloneVertexDataRemoveBlendInfo(VertexData source)
  ...

I have not been able to find much documentation on older versions and how they changed.
As best as I can tell, Ogre 1.0.x (Azathoth?) uses the 1.30 serializer. And I think that it is not until Ogre 1.4.x that the serializer changes to the 1.40 serializer?
It would be fantastic to see a table showing the relationship of Ogre version to serializer version. Or which Ogre versions share compatibility (presumably the same thing?).
Having said that, I don't think the problem is really in the serialiser. If I try to load a 1.4.x model, it complains about not having the 1.40 serializer, however, if I try to load a 1.2.x model, it does not complain about this, but it does complain about the NullReferenceException in CloneVertexDataRemoveBlendInfo as mentioned above.
Comparing a 1.0.x and 1.2.x mesh (with skeleton) side by side, they seem very similar - the 1.2.x has the addittion of <sharedgeometry> and the <boneassignments> are in a different place in the xml heirachy - they are the only differences. I can load a static 1.2.x mesh with <sharedgeometry> fine, so maybe the only difference that is stopping me is the <boneassignments> are in a different place? I tried manually moving the <boneassignments> into the same place, but then none of the OgreXMLConverters work work on it.

So in summary, I would be very interested to know if there are any ways of converting from more recent Ogre versions (Ogre 1.2.x, 1.4.x, 1.6.x) back to Ogre 1.0.x. For meshes and skeletons. I would be willing to manually edit the files at this stage.
However, I would also be willing to look at paying someone to create a tool that could do this conversion reliably.

Many thanks.

[xavier]

Funny you should ask...

http://www.ogre3d.org/forums/viewtopic.php?f=4&t=58593

In short, not yet (directly, anyway), but perhaps coming soon?

And there's always hacking on the source (in this case, the xml converter)...or have you tried simply recompiling the exporters for the versions of the tools you have?

[nosignal]

Thanks xavier - a very valuable link.

With a lot more research, I am gaining a few more insights:

• A number of sources (including Sinbad) have suggested that it is possible to convert from e.g. 1.6 to 1.0 by using the 1.6 OgreXMLConverter, then using the 1.0 OgreXMLConverter on the 1.6 xml to get a 1.0 binary mesh.
• I have tried this and tested it in CEGUI Mesh Viewer 1.0.6 and it works.
• However, when I take the same mesh that works in the mesh viewer and view it in our software, it has the NullReferenceException in CloneVertexDataRemoveBlendInfo as mentioned above.
• Therefore, I guess it is not an Ogre issue, but rather an Axiom issue. So I looked further into Axiom.
• Apparently I was wring - we are using ~Axiom 0.7.0, which is apparently based on Ogre R13 (I presume this means Ogre 0.13?).
• In the Axiom Changelog, it says "Finished support for 1.30 meshes (minus submesh names at the moment)". I could not find any mention of submesh names having been added later.

• I can load the standard ninga.mesh and robot.mesh, which have complex skeleton and animation.
• I can load a 1.0.6 mesh with skeleton and animation exported from 3DSMax.
• I can load a static 1.2.6 mesh exported from Maya.
• I cannot load a 1.2.6 mesh with skeleton exported from Maya.
• I cannot load a 1.2.6 mesh with skeleton and animation exported from Maya.

So I guess it is a problem with the Axiom 1.30 mesh serializer - presumably due to it not supporting submesh names (or some other feature or quirk). And that these are only used in some skeletons, and are only used in some exporters.

So what are "submesh names"? I cannot find any mention of them with the Ogre Wiki general search.
As mentioned above, comparing a working and a failing mesh (with skeleton), there is very little difference, and there is no difference I can find related to submesh names.

Any help would be greatly appreciated.

[sinbad]

Submesh names are an optional dictionary in the mesh file which maps a name to a submesh index, for convenience if you want to name submeshes in your modeller and refer to them in code. If you think this is the problem, you can remove the submesh names from the XML, they are in their own element called <submeshnames>. You could manually remove them or use a simple XSL stylesheet to do it.

Remember that Axiom was always a rewrite of Ogre and therefore we make absolutely zero guarantees of compatibility, nor do we support it.

[nosignal]

So I guess it is a problem with the Axiom 1.30 mesh serializer - presumably due to it not supporting submesh names (or some other feature or quirk). And that these are only used in some skeletons, and are only used in some exporters.

After about 30 tests, I have a solution. The really critical things are that in the Maya Exporter Plugin, Mesh settings, it needs "Include vertex bone assignments" and "Include vertex normals" (for bone animations anyway), but it must NOT have "Use shared geometry".
I suspect where the Axiom developer who the changelog said that it does not support 'submesh names', I think he actually meant it does not support 'shared geometry'. Well, I'm very glad that is sorted, because as long as the model was exported without shared geometry, it should now be successfully convertible back to Ogre 1.0.4 format.

Is 'shared geometry' optional in most/all exporters, or is it becoming standard (I hope not)?
Its a long shot, but I'll ask - do any scripts exist that convert to go from 'shared-geometry' to 'non-shared-geometry'?

Many thanks.

[nosignal]

Submesh names are an optional dictionary in the mesh file which maps a name to a submesh index, for convenience if you want to name submeshes in your modeller and refer to them in code.

It that kind of description appropriate for the Ogre Wiki Lexicon? http://www.ogre3d.org/tikiwiki/Ogre%20Lexicon#S. If so, I could add it.
I could also add 'shared geometry' if I knew a little more about it.

If you think this is the problem, you can remove the submesh names from the XML, they are in their own element called <submeshnames>. You could manually remove them or use a simple XSL stylesheet to do it.

Thanks for the tip - it pointed me in the right direction, and thought it was not the problem, that process of experimentation led me to the solution. Though converting an xml with 'shared geometry' to one without it was not as easy as removing a tag. Sadly, I guess that means an XSL would not do the job.

Remember that Axiom was always a rewrite of Ogre and therefore we make absolutely zero guarantees of compatibility, nor do we support it.

I totally understand, and I am very grateful for the contributions of both the Ogre and Axiom teams. At the time we made the decision, it was the best option available. I appreciate your help above and beyond the call of duty as it were.

[xavier]

I could also add 'shared geometry' if I knew a little more about it.

Shared geometry simply means a vertex buffer that can be used by multiple submeshes. This way you can have different, say, primitive types without duplicating the vertex data.

It is not that common in practice, and in fact, the problems you had with the Maya exporter and the "shared geometry" switch are not unique to your experience -- hitting that switch and then trying to use the resulting mesh with, say, an Intel GMA950 chipset will guarantee a crash, as that hardware does not support 32-bit indices (which is one of the unmentioned side-effects of using that option in the Maya exporter -- you get 32-bit indices whether you need them or not...and most meshes do not).

[nosignal]

Wow - valuable information. 'Shared Geometry' Now added to the Ogre Wiki Lexicon http://www.ogre3d.org/tikiwiki/tiki-ind ... 20Geometry along with 'Submesh Names' http://www.ogre3d.org/tikiwiki/tiki-ind ... sh%20Names.