Table of contents
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?
- Do you have any lights set up (e.g. SceneManager::setAmbientLight)?
- If you are using multiple SceneManagers, 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.
- If you previously broke up startRendering() into a custom main loop, do you still call renderOneFrame() on Ogre::Root?
Why does my dynamic lighting look all wrong?
- Check you have normals on your mesh
- Check they are pointing in the right direction (i.e. 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
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 i.e. either 100% transparent or fully solid, then a more optimal setting is alpha_rejection, which rejects depth updates in transparent areas too.
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)
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 Direct3D and OpenGL need a primary window context and many aspects of resources cannot be loaded until there is a window.
- OgreCore.zip belongs to Ogre 1.6.0 and was removed in 2009 (It seems the mac and iphone versions of ogre still include it in the xcode templates).
- Add SdkTrays.zip to your resources config file (it's in media/packs).
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.
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.
- You may be using too many individual objects/submeshes. Graphics cards (GPU) 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 60 FPS 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.
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 VisualStudio) 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 VisualStudio are here: Visual Studio Debugging Settings
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 SVN 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 SVN 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.
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
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.
D3D11 device can't create shader resource view
- Check the version of your used shader model:Direct3D 9 shaders can be designed using shader model 1, shader model 2 and shader model 3; Direct3D 10 shaders can only be designed on shader model 4. Direct3D 11 shaders can be designed on shader model 5.
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
Can I statically link OGRE?
How to deploy to Windows without an installation?
- You'll just need to transfer your game executable and any Ogre .dlls you're using (eg RenderSystem_GL.dll), your media and config files (by default, resources.cfg and plugins.cfg) and a copy of the Ogre license although this could be done in the form of an in-game message rather than a separate text file.
- If you use Visual Studio you will need to install the Visual C++ 2010 Redistributable package (x86, amd64) on the target machine before you start you application.
- If you use DirectX you will need to install the latest DirectX End-User Runtime on the target machine before you start you application. Normally you don't have to install DirectX because Windows install and update DirectX with the Windows Update Service.