My WIP

[sinbad]

I'm currently bootstrapping a Cocoa project so I'm not hacking on Ogre so much, but this week I'm back on it thanks to a bit of customer work. I'll be implementing:

• Normals animation in vertex morph / vertex pose animation. Software, SSE and hardware paths will be supported but the technique will be incompatible with stencil shadows; this is because of conflicting buffer layout requirements (animation wants the pos & normal buffers to be unified to keep the temp buffer binding the same, but stencil shadows needs the pos buffer to always be separate because of the vertex duplication for backface extrusion). I can't square that without making one or the other not work, or implement 2 paths which will be hideous in code and which I don't have time for. So the lesser of 2 evils is to not support stencil shadows and animated morph/pose normals at once.
• Versioned mesh writing. Currently the mesh serialisers already handle loading previous versions of a mesh format through a class hierarchy, but when you save meshes you always save in the latest version. So that developers of tools can support all versions of Ogre in one tool, I want to support saving as previous binary file versions more easily (you could do it by writing XML then pushing that through an old XMLConverter, but it's nasty). I'll also clean up the class naming - the mesh format version names have had a different naming convention to the main versions of Ogre which is confusing, I'll sort that out so that we use the mesh version internally but there's an Ogre version translation which makes things easier to map to Ogre versions.

FYI when I do work on Ogre, I'll typically talk about it first here: http://twitter.com/sinbad_ogre (and no doubt rant about things here: http://twitter.com/stevestreeting )

[Praetor]

Normals animation in vertex morph / vertex pose animation: sounds like it could be useful to certain people...

[nedelman]

These will be great additions. (Insert thumbs up smilie here)

[ekt]

you already answered in the past but animating the vertex color buffer in morph would also be nice.
imagine an objects which blows up. pieces fly around and start to fade when near the ground.
having a precanned morph animation with alpha vertex color for the fade effect makes this possible on low end hw

[sparkprime]

At some point you hvae to switch it to a material that has alpha blending set, though.

[nosignal]

Versioned mesh writing - that has made my day. Funny that I had just asked for help on this matter at http://www.ogre3d.org/forums/viewtopic.php?f=2&t=58635. Thanks xavier for connecting the dots.

But I have a couple of questions:

(you could do it by writing XML then pushing that through an old XMLConverter, but it's nasty).

as I mentioned in my forum post, I tried this, and it did not work when a skeleton was involved.

And does this mean that new versions of all plugins will have to be released? Not to be impatient, but how long does this process usually take? We have a July 14th deadline - is that too soon?

Many thanks.

[sinbad]

And does this mean that new versions of all plugins will have to be released? Not to be impatient, but how long does this process usually take? We have a July 14th deadline - is that too soon?

I'm not quite sure what you mean - if you mean Ogre plugins like the scene managers et al, this won't impact on them particularly, just the serialisers.

Everything here will be a 1.8 feature, and 1.8 is the unstable version and will be for quite a while yet (1.7 was only released early this year). However, what this will allow is that tool developers can use the 1.8 unstable version to build their tools if they want, but still export data that will work with 1.7 and before by choosing the appropriate compatibility version. Obviously you lose some features in the process such as the animated normals if you go to 1.7 or earlier, and the new mesh LOD options if you go to 1.6 or earlier, etc.

[sinbad]

Bullet point 1 (vertex animation on normals) is in the repository now.

When doing the SSE implementation I deleted all the manual intrinsics for gcc that genva added some years ago, because I think they're all obsolete now and relate to some ancient version of gcc on cygwin. I've been testing heavily on the Mac with gcc 4.2 and all the standard intrinsics in xmmintrin.h work fine.

[xavier]

On a side note -- when was the last time anyone did a pass through all of that "OptimizedUtil" code to see if it's all still current? Or was that what you were talking about?

[nosignal]

And does this mean that new versions of all plugins will have to be released? Not to be impatient, but how long does this process usually take? We have a July 14th deadline - is that too soon?

I'm not quite sure what you mean - if you mean Ogre plugins like the scene managers et al, this won't impact on them particularly, just the serialisers.

Everything here will be a 1.8 feature, and 1.8 is the unstable version and will be for quite a while yet (1.7 was only released early this year). However, what this will allow is that tool developers can use the 1.8 unstable version to build their tools if they want, but still export data that will work with 1.7 and before by choosing the appropriate compatibility version. Obviously you lose some features in the process such as the animated normals if you go to 1.7 or earlier, and the new mesh LOD options if you go to 1.6 or earlier, etc.

Sorry for being vague - I was referring to, for example, Maya Exporter Plugins. So it sounds like Ogre 1.8 Maya Exporter Plugins will have the ability to export older mesh formats. And these won't be available and stable for a few months. Ok, that is what I need to know.

I understand now that the

you could do it by writing XML then pushing that through an old XMLConverter, but it's nasty

does work, so as I've mentioned in http://www.ogre3d.org/forums/viewtopic. ... 64#p394564 I think am having a problem with an older port of Ogre, not with Ogre mesh formats themselves. I can import Ogre 1.0.x meshes with skeletons from 3DSMax, but not Ogre 1.0.x meshes with skeletons from Maya.

Thanks again, and if you could shed some light on 'submesh names' in my other post, I'd love to hear it. I would be willing to pay for a custom OgreXMLConverter that does not use 'submesh names' (assuming that is even possible, and assuming that is the problem).

[sinbad]

On a side note -- when was the last time anyone did a pass through all of that "OptimizedUtil" code to see if it's all still current? Or was that what you were talking about?

Well, I hacked out the manual intrinsics and just used xmmintrin.h now for gcc. I needed to do that because I needed to use SSE instructions that weren't in the manual definitions, but were in xmmintrin.h. I haven't done any more auditing than I needed to, but the rest seemed to be just helper stuff & still relevant.

[sinbad]

The second bullet (Versioned Mesh Writing) is now complete too.

The MeshSerializer interface has been expanded so there are now variants of the exportMesh() method that take a MeshVersion parameter, which is defined thus:

Code: Select all

	/// Mesh compatibility versions
	enum MeshVersion 
	{
		/// Latest version available
		MESH_VERSION_LATEST,
		
		/// OGRE version v1.8+
		MESH_VERSION_1_8,
		/// OGRE version v1.7+
		MESH_VERSION_1_7,
		/// OGRE version v1.4+
		MESH_VERSION_1_4,
		/// OGRE version v1.0+
		MESH_VERSION_1_0,
		
		/// Legacy versions, DO NOT USE for writing
		MESH_VERSION_LEGACY
	};

As you can see, you identify the version you want by the OGRE version rather than the Mesh version you see in the mesh files, that due to historical issues and external contributions has not been in sync with the actual OGRE version all the time so is more confusing. Internally the mesh strings are the same, although I've made the effort to bring them back in sync in 1.8 at least.

OgreMeshUpgrader now has an additional '-V' parameter which lets you specify the version of mesh you want to write, and also lets you downgrade meshes as well as upgrade them, which is what I've tested with.

I've only tested back to 1.6, I don't have any apps built for 1.4 or earlier anymore and don't have the time to build any (not least because I have to go outside of Mercurial to do that). However the code to write the parts of the data that changed was lifted directly from the old versions of OGRE so all should be well.

[nosignal]

I think am having a problem with an older port of Ogre, not with Ogre mesh formats themselves. I can import Ogre 1.0.x meshes with skeletons from 3DSMax, but not Ogre 1.0.x meshes with skeletons from Maya.
Thanks again, and if you could shed some light on 'submesh names' in my other post, I'd love to hear it.

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.

[nosignal]

I've only tested back to 1.6, I don't have any apps built for 1.4 or earlier anymore and don't have the time to build any (not least because I have to go outside of Mercurial to do that). However the code to write the parts of the data that changed was lifted directly from the old versions of OGRE so all should be well.

The Ogre CEGUI MeshViewer binary is available at http://sourceforge.net/projects/ogre/files/ogre-tools/ for many different versions, including 1.0.6.

It is great to have that feature done - thankyou so much.

[nosignal]

Hi again sinbad,

It would be nice to see a completed table like this on the wiki (I've filled in as much as I know):

Ogre Version ? to ? (including 0.13) uses MeshSerializer v1.2
Ogre Version <=1.0.x to 1.2.x uses MeshSerializer v1.3 < This is most relevant to us.
Ogre Version 1.4.x to 1.6.x uses MeshSerializer v1.4
Ogre Version 1.7.x uses MeshSerializer v1.?
Ogre Version 1.8.x uses MeshSerializer v1.?

[sinbad]

I've made it so that you don't need to know the internal serializer version numbers, that's why the exportMesh parameter is in Ogre versions. If you need to know the mapping, it's in the constructor of OgreMeshSerializer.cpp.