MeshMagick now supports optimisations via AMD Tootle

[sinbad]

Just a heads-up for those of you not watching the commit notifications on ogreaddons or my twitter feed, I just added an extra tool to MeshMagick (Win32 only for now) to allow you to run your meshes through AMD's Tootle optimistion system. This can optimise your mesh for both vertex cache efficiency and to minimise overdraw. Here's a dump of the parameters:

Code: Select all

C:\>meshmagick -help=tootle

Use AMD Tootle to optimise mesh.

Optimisation parameters:
 -vcachesize=N    - specify the vertex cache size (omit to use default)
 -clockwise       - treat clockwise faces as front-facing (default is CCW)
 -clusters=N      - manually specify the number of clusters (default auto)
 -viewpoint=x/y/z - specify one or more viewpoints to judge overdraw
                    Default is to generate viewpoints automatically

I adapted the code from OgreTootle (thanks to ahmedismaiel) and updated it so that it worked with MeshMagick, as well as fixing a couple of things and allowing you to specify a list of viewpoints to calculate overdraw from. For example if your mesh is mostly seen from above (say, an object smaller than the player character) then the optimiser can order the faces so that the top faces are rendered earlier to increase the chance of early depth rejection.

MeshMagick is available from the addons svn repository. You will need to use the CMake build (not the manual projects included in svn) in order to pick up the Tootle support, which is only supported on Windows at this time. You will also need to download Tootle.

To configure in CMake:

• Set a CMake variable TOOTLE_HOME to the location you installed Tootle
• If you're using an OGRE SDK, add a CMake variable OGRE_SDK pointing at the root
• If you're using an OGRE source build, set OGRE_SOURCE to the root of your OGRE source dir, and OGRE_BUILD to the root of your build directory. If you're building against OGRE 1.6 these will be the same folder, if you're building against OGRE 1.7+ then set OGRE_BUILD separately to the OGRE build dir you want to reference.

My early tests indicate that on my fairly powerful card I can get about a 3% efficiency on the BumpMapping sample by using a Tootle'd Athene rather than the standard one. Lower end cards are likely to benefit more significantly, as are more complex meshes. I'm still reviewing the practical benefits.

I welcome community review of this new feature, I can't promise to give any direct support to users (I'm doing this for a project and am just trying to address some of my own issues) but collaboration on enhancements / fixes is welcome.

[masterfalcon]

Very cool. I can't wait to see if this has any impact on iPhone performance. Thanks SInbad!

[Praetor]

Yeah, I'd like to see a comparison on very high-poly meshes.

[reptor]

It's a good idea, thumbs up.

Maybe someone with a finished 3D game could test it? Or perhaps someone did it already and can tell us the effect... it would be nice to know if there is a really noticeable difference for a full game with lots of 3D models displayed at the same time. I don't think the measurements are very good if we only test with a few models, it should be a bigger scene from a real game Some people have a million polygons rendered in a scene with lots of different objects... test it with that sort of a thing, that's where it should really be able to show its worth.

[Praetor]

Anyone got a copy of the famous power plant model in a friendly format? PLY is such a pain to work with. That thing is 13mil polygons. I bet that would be a good test... and I need it for occlusion culling testing anyways.

[sinbad]

Maybe someone with a finished 3D game could test it?

I'll be doing some tests on a real, full-size game later this week (I'm not going to say what it is, this is under contract), that's actually why I made the tool in the first place. I may need to make a few more changes to allow MeshMagick to operate entirely on meshes in memory rather than only being able to read/write files, since I suspect that some geometry built in code may benefit the most from it in this project. It's not a super-high poly game but I've identified a subset of the rendering that has room for improvement and I'm curious whether this will help. I'd encourage others to test it with big models and higher poly scenes too.

[sinbad]

You might want to try the Sponza model Crytek released in .obj format: http://www.crytek.com/downloads/technology/

When they released it I imported it into 3DS and exported it via OgreMax, but haven't played with it much yet. Might be interesting to experiment with.

[haffax]

I may need to make a few more changes to allow MeshMagick to operate entirely on meshes in memory rather than only being able to read/write files, since I suspect that some geometry built in code may benefit the most from it in this project.

Do you mean MeshMagick itself or the tootle tool with this? MeshMagick can be used as a library already and it can work with meshes in memory. You can look at how meshmerge and transform do this. Current implementation may not be the most generic way, but all the tools are rather specialized and I didn't want to force tool users to use a key/value-pair style interface.

Also, if LGPL is a problem in your scenario: I already pondered to go along with MIT license, but will also need to talk with Blakharaz about it.

[sinbad]

Oh, I see you can call the tools direct to do this. I didn't think this was standard since it's not in the base Tool class. I will need to change the Tootle tool to allow this.

It would be nice if you did switch to MIT, otherwise if the runtime generation helps I'd have to pull my runtime bit out of MeshMagick and do it separately for linking direct (not too hard but would be nicer not to have to). I mostly used MeshMagick because the framework was already there and it made sense to reuse it, especially since it's a separate tool, but then it occurred to me that linking it in could be useful.