Basic Tutorial 1

From Ogre Wiki

Beginner Tutorial 1: The SceneNode, Entity, and SceneManager constructs

Any problems you encounter while working with this tutorial should be posted to the Help Forum.

Prerequisites

This tutorial assumes you have knowledge of C++ programming and are able to setup and compile an Ogre application (if you have trouble setting up your application, see this guide for specific compiler setups). NO knowledge of Ogre is assumed for this tutorial outside of what is contained in the setup guide.

Introduction

In this tutorial I will be introducing you to the most basic Ogre constructs: SceneManager, SceneNode, and Entity objects. We will not cover a large amount of code; instead I will be focusing on the general concepts for you to begin learning Ogre.

As you go through the tutorial you should be slowly adding code to your own project and watching the results as we build it. There is no substitute for actual programming to get familiar with these concepts! Resist the urge to simply read along.

Getting Started

Initial Code

We will be using a pre-constructed code base for this tutorial. You should ignore all of the code except for what we will be adding to the createScene method. In a later tutorial we will go in depth explaining how Ogre applications work, but for now we will be starting at the most basic level. Create a project in the compiler of your choice for this project, and add a source file which contains this code:

#include "ExampleApplication.h"

class TutorialApplication : public ExampleApplication
{
protected:
public:
    TutorialApplication()
    {
    }

    ~TutorialApplication() 
    {
    }
protected:
    void createScene(void)
    {
    }
};

#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
#define WIN32_LEAN_AND_MEAN
#include "windows.h"

INT WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT )
#else
int main(int argc, char **argv)
#endif
{
    // Create application object
    TutorialApplication app;

    try {
        app.go();
    } catch( Exception& e ) {
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32 
        MessageBox( NULL, e.what(), "An exception has occurred!", MB_OK | MB_ICONERROR | MB_TASKMODAL);
#else
        fprintf(stderr, "An exception has occurred: %s\n",
                e.what());
#endif
    }

    return 0;
}

If you are using the OgreSDK under Windows, be sure to add the "[OgreSDK_DIRECTORY]\samples\include" directory to this project (the ExampleApplication.h file is located there) in addition to the standard include. If using the Ogre source distribution, this should be located in the "[OgreSource_DIRECTORY]\Samples\Common\include" directory. Be sure you can compile and run this code before continuing to the next section, though nothing other than a blank screen with a framerate box will show up until we add things later in the tutorial.

Once the program is working, use the WASD keys to move, and the mouse to look around. The Escape key exits the program.

Troubleshooting

If you have problems, check Setting Up An Application to setup your compiler properly, or look in the Ogre.log file for more detailed information. If you need further help, search the forums. It is likely your problem has happened to others many times. If this is a new issue, read the forum rules then ask away. Make sure to provide relevant details from your Ogre.log, exceptions, error messages, and/or debugger back traces.

Note that later tutorials will not contain this troubleshooting information, so please pay special attention to the following sections if you are having problems.

Message Box Trouble

If you are using Visual Studios with Unicode support turned on for the project you may encounter this error:

 error C2664: 'MessageBoxW' : cannot convert parameter 2 from 'const char *' to 'LPCWSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or  function-style cast

The problem is that the MessageBox function is (in this case) expecting Unicode, and we are giving it an ANSI string. To fix this, change the following line:

 MessageBox( NULL, e.what(), "An exception has occured!", MB_OK |   MB_ICONERROR  | MB_TASKMODAL);

to this:

 MessageBoxA( NULL, e.what(), "An exception has occured!", MB_OK |   MB_ICONERROR  | MB_TASKMODAL);

Or you can change your text format in the compiler from Unicode to ANSI. However, you will lose support for international languages.

The reason for this is that "MessageBox" is automatically resolved to either MessageBoxA (ANSI) or MessageBoxW (Wide/Unicode), depending on the project configuration. We fix the error by being explicit about it using ANSI.

Missing a Configuration File or DLLs

If you try to launch your freshly built application but the program complains of missing DLLs or configuration files (*.cfg), then you probably did not copy them over from the OgreSDK folder. In Visual Studios, when you build your application in release mode, it puts the release executable in the [ProjectFolder]\bin\release folder, and the debug executable in the [ProjectFolder]\bin\debug folder. You must copy all the ".dll" and ".cfg" files over from the OgreSDK into the appropriate folders. That is, copy the files from [OgreSDK]\bin\release to [ProjectFolder]\bin\release and [OgreSDK]\bin\debug to [ProjectFolder]\bin\debug. You will also need to edit the resources.cfg file to point at the correct paths. See the next section for more information on this.

Resources or Plugin Problems

Make sure you have a plugins.cfg and a resources.cfg in the same directory as the executable. Plugins.cfg tells OGRE which rendering libraries are available (Direct3D9, OpenGL, etc). Resources.cfg is used by the ExampleApplication and specifies paths to textures, meshes and scripts. Both are text files, so edit them and make sure the paths are correct. Otherwise your OGRE setup dialog box may not have any rendering libraries in it, or you may receive an error on your screen or in Ogre.log that looks something like this:

Description: ../../Media/packs/OgreCore.zip - error whilst opening archive: Unable to read zip file

If this is the case, open up the resources.cfg file and change the paths it contains to point to locations in the Media folder that came with Ogre. Note you cannot use environment variables such as $(SomeVariable) in these paths.

Cannot Launch the Application in Visual Studio

If you are using Visual Studio or Visual C++ to create the application and are having trouble launching it from the environment, the problem is most likely due to the debugger settings. If you press the play button (or go to the Start Debugging menu item) and you get an exception saying that a configuration file (*.cfg) cannot be found, then the Working Directory has probably not been set.

The exact instructions for fixing this will vary based on which version of Visual C++ you are using, so I cannot give you a direct walk through, but the basic steps should be the same. Right click on your project in the solution explorer (not the solution itself) and go to properties. Somewhere in the configuration properties should be options for "Debugging". In the debugging options there should be a field for "Working Directory". This should be set to the location that the executable file for your project is being placed.

If you are having trouble figuring out what to put there, try to mimic the "Command" field which should also be in the debugging options. For example, in Visual C++ 2003, the "Command" field should be something similar to "..\..\bin\$(ConfigurationName)\$(TargetFileName)". For the Working Directory, we need to remove the portion of the command which is the target file name (the executable). In this case, the working directory would be "..\..\bin\$(ConfigurationName)". The exact string you have to put there may vary based on your version of Visual C++ and on your build environment, so be sure to check what the Command field is before doing this. Be sure to change the Working Directory for both the Release and Debug configuration.

In Visual C++ 2005 it will probably be something different entirely. I've found the "..\..\bin\$(ConfigurationName)" directory a good thing to try first, if it still does not work you may have to play with it some, or consult some help from the Ogre forums.

The reason we have to do this is that Ogre expects certain files to be in the same directory as the executable, and without setting the working directory to be a directory with these files in it.

How Ogre Works

A broad topic. We will start with SceneManagers and work our way to Entities and SceneNodes. These three classes are the fundamental building blocks of Ogre applications.

SceneManager Basics

Everything that appears on the screen is managed by the SceneManager (fancy that). When you place objects in the scene, the SceneManager is the class which keeps track of their locations. When you create Cameras to view the scene (which we will cover in a later tutorial) the SceneManager keeps track of them. When you create planes, billboards, lights...and so on, the SceneManager keeps track of them.

There are multiple types of SceneManagers. There are SceneManagers that render terrain, there is a SceneManager for rendering BSP maps, and so on. You can see the various types of SceneManagers listed here. We will cover more about other SceneManagers as we progress through the tutorials.

Entity Basics

An Entity is one of the types of object that you can render on a scene. You can think of an Entity as being anything that's represented by a 3D mesh. A robot would be an entity, a fish would be an entity, the terrain your characters walk on would be a very large entity. Things such as Lights, Billboards, Particles, Cameras, etc would not be entities.

One thing to note about Ogre is that it separates renderable objects from their location and orientation. This means that you cannot directly place an Entity in a scene. Instead you must attach the Entity to a SceneNode object, and this SceneNode contains the information about location and orientation.

SceneNode Basics

As already mentioned, SceneNodes keep track of location and orientation for all of the objects attached to it. When you create an Entity, it is not rendered in the scene until you attach it to a SceneNode. In addition a SceneNode is not an object that is displayed on the screen. Only when you create a SceneNode and attach an Entity (or other object) to it is something actually displayed on the screen.

SceneNodes can have any number of objects attached to them. Let's say you have a character walking around on the screen and you want to have him generate a light around him. The way you do this would be to first create a SceneNode, then create an Entity for the character and attach it to the SceneNode. Then you would create a Light object and attach it to the SceneNode. SceneNodes may also be attached to other SceneNodes which allows you to create entire hierarchies of nodes. We will cover more advanced uses of SceneNode attachment in a later tutorial.

One major concept to note about SceneNodes is that a SceneNode's position is always relative to its parent SceneNode, and each SceneManager contains a root node to which all other SceneNodes are attached.

Your first Ogre application

Now go back to the code we created earlier. Find the TutorialApplication::createScene member function. We will only be manipulating the contents of this function in this tutorial. The first thing we want to do is set the ambient light for the scene so that we can see what we are doing. We do this by calling the setAmbientLight function and specifying what color we want. Note that the ColourValue constructor expects values for red, green, and blue in the range between 0 and 1. Add this line to createScene:

        mSceneMgr->setAmbientLight( ColourValue( 1, 1, 1 ) );

The next thing we need to do is create an Entity. We do this by calling the SceneManager's createEntity member function:

        Entity *ent1 = mSceneMgr->createEntity( "Robot", "robot.mesh" );

Okay, several questions should pop up. First of all, where did mSceneMgr come from, and what are the parameters we are calling the function with? The mSceneMgr variable contains the current SceneManager object (this is done for us by the ExampleApplication class). The first parameter to createEntity is the name of the Entity we are creating. All entities must have a unique name. You will get an error if you try to create two entities with the same name. The "robot.mesh" parameter specifies the mesh we want to use for the Entity. Again, the mesh that we are using has been preloaded for us by the ExampleApplication class.

Now that we have created the Entity, we need to create a SceneNode to attach it to. Since every SceneManager has a root SceneNode, we will be creating a child of that node:

        SceneNode *node1 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode" );

This long statement first calls the getRootSceneNode of the current SceneManager. Then it calls the createChildSceneNode method of the root SceneNode. The parameter to createChildSceneNode is the name of the SceneNode we are creating. Like the Entity class, no two SceneNodes can have the same name.

Finally, we need to attach the Entity to the SceneNode to give the Robot a render location:

        node1->attachObject( ent1 );

And that's it! Compile and run your application. You should see a robot standing on the screen.

NOTE: Robot.mesh is not in OgreCore.zip. Following the tutorials to this point your app may run but come up empty. I found adding the following to the resources.cfg and adding the appropriate directories got the application to work.

FileSystem=../../media/materials/programs
FileSystem=../../media/materials/scripts
FileSystem=../../media/materials/textures
FileSystem=../../media/models

Coordinates and Vectors

Before we go any further, we need to talk about screen coordinates and Ogre Vector objects. Ogre (like many graphics engines) uses the x and z axis as the horizontal plane, and the y axis as your vertical axis. As you are looking at your monitor now, the x axis would run from the left side to the right side of your monitor, with the right side being the positive x direction. The y axis would run from the bottom of your monitor to the top of your monitor, with the top being the positive y direction. The z axis would run into and out of your screen, with out of the screen being the positive z direction.

Notice how our Robot is facing along the positive x direction? This is a property of the mesh itself, and how it was designed. Ogre makes no assumptions about how you orient your models. Each mesh that you load may have a different "starting direction" which it is facing.

Ogre uses the Vector class to represent both position and direction (there is no Point class). There are vectors defined for 2 (Vector2), 3 (Vector3), and 4 (Vector4) dimensions, with Vector3 being the most commonly used. If you are not familiar with Vectors, I suggest you brush up on it before doing anything serious with Ogre. The math behind Vectors will become very useful when you start working on complex programs.

Adding another Object

Now that you understand how the coordinate systems work, we can go back to our code. In the three lines we wrote, nowhere did we specify the exact location where we wanted our Robot to appear. A large majority of the functions in Ogre have default parameters for them. For example, the SceneNode::createChildSceneNode member function in Ogre has three parameters: the name of the SceneNode, the position of the SceneNode, and the initial rotation (orientation) the SceneNode is facing. The position, as you can see, has been set for us to the coordinates (0, 0, 0). Let's create another SceneNode, but this time we'll specify the starting location to be something other than the origin:

        Entity *ent2 = mSceneMgr->createEntity( "Robot2", "robot.mesh" );
        SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );
        node2->attachObject( ent2 );

This should look familiar. We have done the exact same thing as before, with two exceptions. First of all, we have named the Entity and SceneNode something slightly different. The second thing we have done is specified that the starting position will be 50 units in the x direction away from the root SceneNode (remember that all SceneNode positions are relative to their parents). Compile and run the demo. Now there are two robots side-by-side.

Entities more in Depth

The Entity class is very extensive, and I will not be covering how to use every portion of the object here...just enough to get you started. There are a few immediately useful member functions in Entity that I'd like to point out.

The first is Entity::setVisible and Entity::isVisible. You can set any Entity to be visible or not by simply calling this function. If you need to hide an Entity, but later display it, then call this function instead of destroying the Entity and later recreating it. Note that you don't need to "pool" Entities up. Only one copy of any object's mesh and texture are ever loaded into memory, so you are not saving yourself much by trying to save them. The only thing you really save is the creation and destruction costs for the Entity object itself, which is relatively low.

The getName function returns the name of Entity, and the getParentSceneNode function returns the SceneNode that the Entity is attached to.

SceneNodes more in Depth

The SceneNode class is very complex. There are a lot of things that can be done with a SceneNode, so we'll only cover some of the most useful.

You can get and set the position of a SceneNode with getPosition and setPosition (always relative to the parent SceneNode). You can move the object relative to its current position by using the translate method.

SceneNodes not only set position, but they also manage the scale and rotation of the object. You can set the scale of an object with the scale function. You can use the pitch, yaw, and roll functions to rotate objects. You can use resetOrientation to reset all rotations done to the object. You can also use the setOrientation, getOrientation, and rotate functions for more advanced rotations. We will not be covering Quaternions until a much later tutorial though.

You have already seen the attachObject function. These related functions are also useful if you are looking to manipulate the objects that are attached to a SceneNode: numAttachedObjects, getAttachedObject (there are multiple versions of this function), detachObject (also multiple versions), detachAllObjects. There are also a whole set of functions for dealing with parent and child SceneNodes as well.

Since all positioning and translating is done relative to the parent SceneNode, we can make two SceneNodes move together very easily. We currently have this code in the application:

        Entity *ent1 = mSceneMgr->createEntity( "Robot", "robot.mesh" );
        SceneNode *node1 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode" );
        node1->attachObject( ent1 );

        Entity *ent2 = mSceneMgr->createEntity( "Robot2", "robot.mesh" );
        SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );
        node2->attachObject( ent2 );

If we change the 5th line from this:

        SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );

To this:

        SceneNode *node2 = node1->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );

Then we have made RobotNode2 a child of RobotNode. Moving node1 will move node2 along with it, but moving node2 will not affect node1. For example this code would move only RobotNode2:

        node2->translate( Vector3( 10, 0, 10 ) );

The following code would move RobotNode, and since RobotNode2 is a child of RobotNode, RobotNode2 would be moved as well:

        node1->translate( Vector3( 25, 0, 0 ) );

If you are having trouble with this, the easiest thing to do is to start at the root SceneNode and go downwards. Let's say (as in this case), we started node1 and (0, 0, 0) and translated it by (25, 0, 0), thus node1's position is (25, 0, 0) relative to its parent. node2 started at (50, 0, 0) and we translated it by (10, 0, 10), so its new position is (60, 0, 10) relative to its parent.

Now let's figure out where these things really are. Start at the root SceneNode. Its position is always (0, 0, 0). Now, node1's position is (root + node1): (0, 0, 0) + (25, 0, 0) = (25, 0, 0). Not surprising. Now, node2 is a child of node1, so its position is (root + node1 + node2): (0, 0, 0) + (25, 0, 0) + (60, 0, 10) = (85, 0, 10). This is just an example to explain how to think about SceneNode position inheritance. You will rarely ever need to calculate the absolute position of your nodes.

Lastly, note that you can get both SceneNodes and Entities by their name by calling getSceneNode and getEntity methods of the SceneManager, so you don't have to keep a pointer to every SceneNode you create. You should hang on to the ones you use often though.

Things to Try

By now you should have a basic grasp of Entities, SceneNodes, and the SceneManager. I suggest starting with the code above and adding and removing Robots from the scene. Once you have done that, clear all the contents out of the createScene method, and play with each of the following code segments:

Scale

You can scale the mesh by calling the scale method in SceneNode. Try changing the values in scale and see what you get:

        Entity *ent1 = mSceneMgr->createEntity( "Robot", "robot.mesh" );
        SceneNode *node1 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode" );
        node1->attachObject( ent1 );

        node1->scale( .5, 1, 2 ); 

        Entity *ent2 = mSceneMgr->createEntity( "Robot2", "robot.mesh" );
        SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );
        node2->attachObject( ent2 );

        node2->scale( 1, 2, 1 );

Rotations

You can rotate the object by using the yaw, pitch, and roll methods using either Degree or Radian objects. Pitch is rotation around the x axis, yaw is around the y axis, and roll is around the z axis. Using your right hand as a guide: point your thumb to the axis, the other fingers points to the positive angles. For example, pitch(Degree(90)), point your thumb to right, the other fingers show the direction of the rotation. Imagine closing a box lid.

Try changing the Degree amount and combining multiple transforms:

        Entity *ent1 = mSceneMgr->createEntity( "Robot", "robot.mesh" );
        SceneNode *node1 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode", Vector3( -100, 0, 0 )  );
        node1->attachObject( ent1 );

        node1->yaw( Degree( -90 ) );
 
        Entity *ent2 = mSceneMgr->createEntity( "Robot2", "robot.mesh" );
        SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2");
        node2->attachObject( ent2 );

        node2->pitch( Degree( -90 ) );
 
        Entity *ent3 = mSceneMgr->createEntity( "Robot3", "robot.mesh" );
        SceneNode *node3 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode3", Vector3( 100, 0, 0 ) );
        node3->attachObject( ent3 );

        node3->roll( Degree( -90 ) );

The Ogre Environment

Most of the files (.DLL and .CFG) referred to in this section (and throughout the tutorials) can be found in the OgreSDK "bin" folder under either debug or release. Debug programs which you create should use the files in the debug OgreSDK folder, and release programs should use the files in the release folder.

Note that a lot of this section discusses Windows specific monikers. Under a Linux the same information basically applies, but the shared libraries end in .so and reside in another location, and some things may be slightly different. If you have problems, be sure to post your question to the Ogre help forums.

DLLs and Plugins

Now that we have played with the Ogre environment a bit, I'd like to explain how the Ogre library works in general to make your life easier when working with it.

Ogre is divided into 3 large shared library groups: The main library, the plugins, and the third-party libraries.

Main library.

The first group consists of the library itself and the shared libraries it relies on. The Ogre library is contained, in its entirety in OgreMain.dll. This dll requires a few other libraries such as cg.dll. These DLLs must be included with every Ogre application without exception.

Plugins.

The second group of shared libraries are the plugins. Ogre pushes a good portion of functionality out into shared libraries so that they may be turned on or off depending on the needs of your application. The basic plugins included with Ogre have filenames which start with the "Plugin_" prefix. You can create new plugins yourself if your application needs them, but we will not be covering this in any tutorial. Ogre also uses plugins for the render systems (such as OpenGL, DirectX, etc). These plugins start with the "RenderSystem_" prefix. These plugins exist so that you can add or remove render systems from your application. This can be especially useful if you write shaders or something which is specific to (for example) OpenGL and you need turn off the ability to run the program in DirectX, you can simply remove the appropriate RenderSystem plugin and it will be unavailable. Additionally if you are targeting a non-standard platform, you can write your own RenderSystem plugin, though this will not be covered in the tutorial. We will cover how to remove plugins in the next section.

Third party libraries and helper libraries.

The third group of shared libraries are the third party libraries and helper libraries. Ogre itself is just a graphics rendering library. It does not include things such as GUI systems, input control, physics engines, and so on. You will have to use other libraries to do these things. The Ogre demos and SDK includes a few of these third party helper libraries. The CEGUI library is a GUI system that integrates easily into Ogre, and the DLLs that begin with "CEGUI*" and the "OgreGUIRenderer.dll" are part of this. Using CEGUI will be covered in a later tutorial. Keyboard and mouse input is accomplished through OIS (an input system). This is contained in OIS.dll. There are also other libraries (not included with the SDK) which give more functionality (such as sound and physics) which you can find more information about in other places such as on the Wiki and in the forums.

The moral of the story is that when you are testing your application locally, you can leave everything "turned on" (that is, don't remove anything) to test with. When you are ready to distribute your application, you will need to build it in Release mode, and include all of the release DLLs that your application uses, and you should remove the DLLs that you do not use. If your program doesn't use CEGUI but does use OIS, then you shouldn't bother including the CEGUI DLLs, but you must include the OIS dll or your application will not run.

Configuration Files

Ogre runs off of several configuration files. They control which plugins are loaded, where the application's resources are located, and so on. We will briefly look at each of the configuration files and what they do. If you have more specific questions, you should direct them to the Ogre help forums.

plugins.cfg This file contains which plugins your application uses. If you want to add or remove a plugin in application, you will need to modify this file. To remove a plugin, simply remove the appropriate line, or comment it out by putting a # at the beginning of the line. To add a plugin, you will need to add a line like "Plugin=[PluginName]". Note that you do not put .DLL at the end of the plugin name. Your plugin also does not have to start with "RenderSystem_" or "Plugin_". You can also define the location that Ogre looks for plugins by changing the "PluginFolder" variable. You can use both absolute and relative paths, but you cannot use environment variables like $(SomeVariable).

resources.cfg This file contains a list of directories which Ogre should scan to look for resources. Resources include scripts, meshes, textures, and so on. You can use both absolute and relative paths, but you cannot use environment variables like $(SomeVariable). Note that Ogre will not scan subfolders, so you must manually enter them if you have multiple levels. For example, if you have a directory tree like "res\meshes" and "res\meshes\small", you will have to add two entries to the resources file containing both of these paths.

media.cfg This file tells Ogre more detailed information about some of the resources. It is unlikely that you will need to modify this file at this time, so I will skip over the details. More information can be found in the Manual and in the Ogre forums.

ogre.cfg This file is generated by Ogre's configuration screen. This file will be specific to your individual computer and graphics setup. You should not distribute this file to other people when you share your application, as they are likely to have different settings than you do. Note you should not edit this file directly, instead use the configuration screen.

quake3settings.cfg This file is used with the BSPSceneManager. You will not need this file unless you are using this scene manager (which you are not using at this point), so ignore it. You should not distribute this file with your application unless, again, you are using the BSPSceneManager, and even then it will likely be completely different depending on the needs of your program.

These are all of the configuration files that Ogre manipulates directly. Ogre must be able to find "plugins.cfg", "resources.cfg", and "media.cfg" to run properly. In a later tutorial we will cover more about these files and how to change their location and manipulate them to do more advanced things.

A Better Way to Test Your Application

Note this section is Windows and Visual C++ specific.

As mentioned in many places (including the Troubleshooting section above), Ogre must be able to find the configuration files, DLLs, and media resources that your program uses. Most people solve this by manually copying the bin folder from the OgreSDK into their project's directory to put the correct DLLs in the same folder as the executable file. This is probably the best thing to do if you are creating a game or application which will be distributed to many people because you will undoubtedly change the configuration files and add/remove plugins from the norm. In many other situations though, copying all the DLLs over to each Ogre project you create will waste space and a lot of time. Here are a few things you can do instead.

One alternative is to copy the OgreSDK DLL files (minus the plugins) over to the c:\Windows\System folder. This has the advantage that no matter where your executable files are, Windows will always be able to find the appropriate DLL. To make this work, modify the resources.cfg and plugins.cfg to contain absolute paths to the media folder and plugins respectively. Now, whenever you create a project, you simply have to copy the modified configuration files over to your bin\debug and bin\release directories. I personally do not use this approach since it's possible to lose track of which OgreSDK DLLs are in your Windows directory. Ogre releases new versions often, so actually updating your install with this method could become quite a hassle.

A better alternative is to leave all OgreSDK files where they are and set the working directory of every Ogre application you create to be OgreSDK's bin\release or bin\debug directory. To do this, go to your project's properties and change the "Working Directory" field (in the Debugging options) to be "C:\OgreSDK\bin\$(ConfigurationName)". You may need to change "C:\OgreSDK" to wherever you installed Ogre; then, no files will need to be copied to make your Ogre programs work. This is the approach I personally use on my Ogre projects. The only drawback is that if you need to make modifications to the configuration files, you will be modifying them for every Ogre project, which is obviously bad. If you use this approach and need to modify the configuration files for your project, copy all of the files into your project as you normally would instead, then change the Working Directory back to what it originally was.

Conclusion

By this point you should have a very basic grasp of the SceneManager, SceneNode, and Entity classes. You do not have to be familiar with all of the functions that I have introduced. Since these are the most basic objects, we will be using them very often. You will get more familiar with them after working through the next few tutorials.

You should also be familiar with setting up a working Ogre environment for your projects.