CommonMistakes

From Ogre Wiki

Contents 1 FAQ 2 Initialisation 3 Lighting 4 Transparency 5 Animation 6 Resources And Materials 7 Orienting An Object 8 Performance 9 Exceptions and Asserts 10 Debug To Release 11 Deployment

Initialisation

Why is my render window black?

• Way too many possibilities...start first with:
  • Have you created a camera and a viewport? (See Ogre demo code in createScene() methods for more)
  • Have you set camera clip distances to some sane values?
  • Are you trying to render a black cat on a black background?
  • If you are using multiple scene managers, did you populate the currently active scene graph (SceneManager) or another?
  • If you are using the demo ExampleApplication framework, did you call startRendering()? Did you implement createScene()?
  • If you are using a custom main loop, are you calling the host windowing system's message loop to allow its PAINT messages to fall through and be processed?
  • Is your camera INSIDE a model you've placed in your scene? Try moving your camera backwards on the z plane.

Lighting

Why does my dynamic lighting look all wrong?

• Check you have normals on your mesh
• Check they are pointing in the right direction (ie out of the model)
• If you have scaled any of the nodes the objects are attached to, note that this scaling distorts the size of the normals too. You should either avoid scaling dynamically lit objects (e.g. rescale them in the modeller instead), or use Entity::setNormaliseNormals to compensate

Transparency

Why don't areas behind transparent objects get rendered properly?

• Just blending through scene_blend isn't enough - you have to think about what happens with depth information. By default the rasteriser uses depth information to decide whether to render a pixel, so if your transparent object is updating the depth even in transparent areas, it will occlude objects rendered afterwards. If your material has partially transparent areas (not just fully solid or fully transparent), then you need to turn depth writing off for your transparent material ('depth_write off' in the pass section). If your material only has 'hard' alpha ie either 100% transparent or fully solid, then a more optimal setting is 'alpha_rejection', which rejects depth updates in transparent areas too.

Animation

Why does my animation not run?

• You have to call AnimationState::addTime() each frame to advance the animation. See the AnimationState::addTime() API reference for more
• You might have forgotten to turn it on using AnimationState::SetEnabled(true)
• Maybe it did run once at the start, you just didn't see it. Check if you are looping or not, if not: use AnimationState::SetLoop(true)

Resources And Materials

Why does my object display as white (or black) in Ogre?

• Check the Ogre.log that resides by default in your program's directory . It will contain information about the materials that were not found or could not be parsed for some reason.
• Make sure you place your materials either in the locations mentioned in resources.cfg, or, if assigning resource locations manually, make sure you add the location of the .material script using ResourceGroupManager::addResourceLocation()
• Make sure that you are calling ResourceGroupManager::initialiseAllResourceGroups() or ResourceGroupManager::initialiseResourceGroup(); until you do, your materials, even if they are found, will neither be parsed or available, and you will get lines in Ogre.log asking you if you forgot to define a material.

Why does my resource creation or load fail in strange ways?

• Check you have created at least one render window before loading a resource. Both D3D and GL need a primary window context and many aspects of resources cannot be loaded until there is a window.

Orienting An Object

What are the differences between lookAt(), setAutoTracking(), setDirection(), setOrientation()...

• setDirection() makes your node face parallel to a provided vector. You provide the vector, transform space (local, relative to parent or absolute), and the local axis with which to point (usually the negative Z axis).
• lookAt() uses setDirection(). It makes your node face a certain point. The difference is subtle. Picture object A at 100,100 and B at 90,10. B.lookAt(100,100) will point B at A. B.setDirection(100,100) will point it parallel to the line (0,0)-(100,100).
• setAutoTracking() means lookAt another node and keep looking at it, even if it moves.
• setOrientation() and rotate() are the most useful methods for orienting objects. They are discussed at length along with Quaternions in the Quaternion and Rotation Primer.
• See the API documentation on SceneNode for further details on the above functions.

Performance

My program is running too slow! (or takes a long time to shutdown)

• Debug vs Release
  • You could be building it in 'Debug' mode. Debug mode enables a lot of checks and functions to help debug the code, but at the cost of processor overhead; when you are finished debugging the program, make sure you select 'Release' mode (on Windows systems, on Linux you should add -O3 to your compiler flags) so you can see it run at the proper speed. The difference is usually quite significant. One user reported a 400% difference.
• Batching
  • You may be using too many individual objects/submeshes. Graphics cards (GPUs) like to have rendering queued into a relatively small number of large batches to operate at peak efficiency. If you use lots of small movable objects, especially if they are composed of multiple submeshes (each of which is its own render operation), the GPU underperforms because too much time is being spent in the overhead of setting up the individual rendering operations. This enqueueing process is done in the driver, which is constrained by the speed of the CPU, not the GPU. This presentation explains that 25000 batches per second will saturate (completely, on its own) a 1Ghz CPU. That means to maintain 60fps on a 1Ghz CPU you cannot issue more than about 416 batches per frame, where a batch is one instance of a submesh (for example). Of course, other factors may limit your performance earlier. You can improve batching by grouping static objects together in a StaticGeometry object, or by reducing the number of submeshes you use per mesh (do you really need that many different materials per mesh?).

Why does the camera 'lurch' regularly as I move?

• This appears to be an internal window timing issue which only happens at relatively low frame rates (<200) on D3D9 when you use windowed mode and don't use VSync. Turning on VSync, or switching to full screen (or indeed, using GL in any mode) resolves the problem, and you also won't see it at higher frame rates. If you suffer from this in windowed mode, just enable vsync to resolve the problem. In full screen you can continue to leave VSync disabled if you want.

Exceptions and Asserts

My Ogre application builds fine, but when I run it I get an error saying it can't find OgreMain_d.dll. Help!

• Chances are you are running this in the debugger. How do I know? It's looking for the Debug build of the main Ogre DLL. If you are running your app in the Debugger (for instance, inside Visual Studio) then you need to set the "Working Directory" in your project's settings (under the "Debugging" tab in the project property sheet) to the location where your app resides. Visual C++ defaults to the location of the .vcproj project file for its working directory when running instances in the IDE. If you are running your app outside the IDE, you need either to have the path to OgreMain_d.dll (as well as the other Ogre DLLs and plugins) in your system PATH, or move the DLLs to where your application EXE resides.
  

Tips for setting up Visual Studio is here: Visual Studio Debugging Settings

My Ogre application builds fine, but when I run it I get an assert about ms_singleton. Help!

• More often than not, the singleton assert is because you are trying to run Debug DLLs with code linked against Release libs, or vice versa. You could also be running DLLs built with one compiler against DLLs built with another (for example, using SDK files for VC7.1 when you are using VC8). It may not be your actual linkage either; in plugins.cfg (or the equivalent programmatic method) if you specify Debug plugins and you are running Release code (or vice versa) this will happen when the opposite DLL build type is loaded. For example, your program links against OgreMain.lib (release) but you are referencing, say, ParticleFX_d.dll (debug). When ParticleFX_d is loaded, it will load in turn OgreMain_d.dll (which is what IT was linked against), and then you have a problem. This is one of the reasons it always happens in the Singleton code: two of something exist for a class that should only have one instance. Instant assert. The "Dependency Walker" tool (Win32 only -- Linux users can use the "ldd" command) is an invaluable aid in determining which modules your libraries and executables are using, and can sometimes turn up unexpected dependencies. Note that running this with your program will not scan the plugins, since they are not compile-time linked to the program; you'll need to run it for each plugin as well. Make sure you are referencing the correct plugins, either in plugins.cfg (when using that method) or in your code when loading plugins via code. In your project files in VS, make sure you are linking against the intended import libraries (.lib files); Ogre marks its Debug builds with a "_D" suffix on its DLL filenames.

Ogre Application throws Exception: Cannot find Camera with name PlayerCam

• This is almost a sure sign that you need to build/rebuild Ogre, probably after a cvs update.

Ogre is debugging with Microsoft MFC, and Ogre Memory Manager keeps reporting Leakage assert...

• When Ogre's memory debug macro works with MFC's counterparts,they always got each other redefined. This makes OgreMemoryManager to report "deallocate RAM that wasn't allocated by this memory manager" -- they are allocated by MFC debug routines. One Possible solution is to remove all MFC "*define new DEBUG_NEW" macros from your source code. The removal does no harm to your code because the Ogre Memory Manager works just as well as the MFC Memory Manager.

Each and every Ogre Application throws Run-Time Check Failure *0 - The value of ESP was not properly saved across a function call.

• This usually happens when rebuilding the Ogre source after a CVS update. Do a complete clean and build again. If this doesn't fix it, check that you are not loading any uncleaned addon plugins, like the DotSceneOctreeManager. Just comment it out in plugins.cfg.

My Ogre application, built with Visual C++ 2005, runs fine on my machine, but when I copy it to a friend's machine, it complains that it can't find MSVCR80.DLL (and/or MSVCP80.DLL) -- I copied these files too, but it still doesn't work. Help!

• You cannot just copy the runtimes around with VC8 applications like you could with VC7x and prior. This is due to the way that Microsoft decided to deal with the "DLL Hell" issue (namely, to make it a developer's problem instead of the operating system's). The target system will need to have the Visual C++ 2005 SP1 Redistributable Package run on it if you are getting these errors (and you most likely will get these errors on any system that (a) does not already have Visual C++ 2005 installed on it, or (b) is trying to run a VC8 application that was just copied to the machine, instead of installed using the Visual Studio 2005 Deployment Project installer. Whether you are installing your app on the target machine using a Deployment Project installer, or installing the VC8 Redist Package, the target machine will need to have the Microsoft Installer 3.1 or higher installed. This is because that installer is needed to deal with the "merge module" form of runtime library distribution that the MSI works with. Why is this so complicated? Only Microsoft knows, but the only answers to your problems (and there is no other way around this, short of building your app statically linked to the runtimes -- which you do using the Project Settings under C++/Code Generation), if you are getting this error, are (a) have the target install the VC Redist Package, or (b) pack up your app using an installer (you can also use NSIS or WiX instead of the Visual Studio Deployment Project, but the Deployment Project is probably the simplest if you have it available). See also this MSDN Article and this Microsoft Forum thread if you need more convincing.

My Ogre application, built with Visual C++ 2005, runs fine on my machine, but when I copy it to a friend's machine, it complains that it can't find MSVCR80D.DLL (and/or MSVCP80D.DLL) -- I copied these files too, but it still doesn't work. Help!

• Don't pass around your Debug builds unless needed; pass around Release builds instead. If you absolutely need to pass around Debug builds, see the FAQ entry directly above this one.

Why does Ogre 1.4.x with VC8 fail to start? (usually with error code 0xc0150002) - make sure you've installed VC8 SP1. The longer answer has to do with the way MS "solved" the "DLL Hell" problem - see two answers above for more. VC8 SP1 has different runtime libraries than does the original VC8 release, so you cannot run apps built with VC8 against DLLs built with SP1. Usually, however, the converse is not true -- the original VC8 runtime DLLs will already have been installed on your system if you have VC8, and when you install SP1, you get the new runtime DLLs as well, so apps/DLLs built with pre-SP1 VC8 will work with apps/DLLs built with VC8 SP1. Fun, eh?

I get an exception from the Cg plugin about not being able to find the image when launching the SampleBrowser or my own app on Mac OS X! What image is it talking about?

• This is actually NVIDIA's fault and seems to be something that they changed between Cg Toolkit 2.0 and 2.2. It's unclear on whether it is an intentional or accidental change. But anyways, OGRE looks for Cg.framework in the standard place which is MyApp.app/Contents/Frameworks/Cg.framework. The problem is that even if the framework is in the right place, information included in the framework when it was built says that it is somewhere else.

So if you are seeing errors like this: An exception has occurred: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library Plugin_CgProgramManager. System Error: dlopen(//Path/To/Your/App/build/Debug/MyApp.app/Contents/Plugins/Plugin_CgProgramManager.dylib, 9): Library not loaded: @executable_path/../Library/Frameworks/Cg.framework/Cg Referenced from: /Path/To/Ogre/Source/build/bin/Debug/Plugin_CgProgramManager.dylib Reason: image not found in DynLib::load at /Path/To/Ogre/Source/OgreMain/src/OgreDynLib.cpp (line 91)

• You will need to do this:
  • First, open Terminal.app and navigate to where your Cg framework is. Not the copy inside your application. It's possible that it could be in the Dependencies folder or /Library/Frameworks.
  • sudo install_name_tool -id @executable_path/../Frameworks/Cg.framework/Cg Cg.framework/Versions/1.0/Cg
  • sudo install_name_tool -change @executable_path/../Library/Frameworks/Cg.framework/Cg @executable_path/../Frameworks/Cg.framework/Cg Cg.framework/Versions/1.0/Cg
• You will be prompted for your administrator password so that the commands can make changes to the file. Note that unless NVIDIA changes this you may need to do it again if you upgrade to future versions of the Cg Toolkit.

Debug To Release

Running application in debug mode is ok, but in release it crashes...

• 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. Most important thing to remember is that Debug not only adds many checks but also initialize variables, something that release mode won't do for you. The common problems which occur when switching from debug to release mode and their solutions can be found in this article: Heap Corruption

Deployment

Can I statically link OGRE?

• Since Eihort (Ogre 1.4.x) static link targets are provided, see Static Linking OGRE