Ogre Optimisation Checklist

http://www.ogre3d.org/tikiwiki/Optimisation+checklist&structure=Cookbook

 

Table of contents

• Optimisation checklist
  • Speeding up startup
  • C++ Optimization Strategies and Techniques
  • Debug / Release Mode
  • Memory Handling
  • Objects/Nodes
  • Shadows
  • Materials
  • LOD
  • Particles
  • Profile
  • Releasing an Ogre app

 

Optimisation checklist

• Some things to check if your application is running slow
• Also before you release an Ogre app to the public

 

Speeding up startup

• If you have many resources that are stored as separate files they can be loaded faster by putting them into a ZIP archive.

C++ Optimization Strategies and Techniques

• No document can beat this one by its simplicity, clarity and proven basis : here (be sure to read at least C++ Optimizations You Can Do "As You Go" )

Debug / Release Mode

• Make sure you test speed using Release mode. Debug mode introduce many, many slowdowns for debugging efficiently and therefore do not reflect final speed (expect from 2x to 10x difference). If you're compiling your app for first time in release mode since a long time, then, you might have interest in this document Surviving the Release Version.

Memory Handling

• Minimize Memory creation/deletion during frames.
• Use Memory pools for frequently deleted/created objects. (as ogre does with billboards..) It helps speeding application and reduce memory fragmentation that leads to big slowdown on long running applications.

Objects/Nodes

• setVisible(false) doesn't remove object from all calculations. Detach node instead. see forum topic
• lots of objects - use 'staticGeometry'. Can't be individually controlled. Good for trees etc. Uses memory.
• draw distance - use 'setRenderingDistance' to cull far away objects. Set far clipping plane and fog also.

Shadows

• Texture - fast, blocky, no self shadowing
• Stencil (Modulative) - medium speed
• Stencil (Additive) - slow speed, but "correct" for multiple/coloured lights

 

Materials

QA with Sinbad (taken from this post http://www.ogre3d.org/phpBB2/viewtopic.php?t=19702&highlight=)
1. Does it differ in rendering speed whether 50 objects all have the same material, or all have a different material but with exactly the same settings and textures.

• Yes, because you save the rendering state changes. It's even more efficient though if you batch those 50 objects into a single render call, which you can only do if they are not moving relative to one another (ie can use the same world matrix)

2. If materials and/or texture-names are swapped dynamically quite often during gameplay, does this give worse performance than when all materials stay the same? I am assuming here that I have already loaded all necessary textures and materials on start-up.

• Yes, texture swaps are relativelly expensive as a state change. Note however that OGRE will order your passes by common texture usage in the same texture units to minimise texture state changes so if there is a case whre unit 0 uses the same texture across 3 material passes but texture 1 is different, it will place those together in the ordering so unit 0 stays constant. Only for solids though (transparency needs depth sorting)

3. I have 9 textures in different colours. I know that if I make a texture-atlas with all of them in it and use that for all objects, this will be faster than 9 seperate textures. However, is this still true if each texture has a different scale and scroll in the texture-unit? Or will much of the performance be lost because these settings have to be re-set? How much will I win anyway if I use texture-atlasses that bring me from 9 tot 1 texture? Should I think around 1% or even 10%, or will it hardly be noticeable?

• Mostly. It will require state changes to alter the scroll etc but these are cheaper than switching textures.

 

LOD

• (on by default?)

Particles

• Allocate particles at the beginning. Avoid creating particle system at runtime.
• Try achieving the desired effect minimizing the particle count. That can easily leads to huge slowdown.

Profile

• Use profilers to find where the application does hang the CPU. Here's a Development Tools.
• Use profilers to find where the application does hang the GPU. Here's a Development Tools

Releasing an Ogre app

• Test material fallback for older cards (material script supports this)
• delete all unused DLL's
• compile as release build!
• A few more pointers