OGRE 3D 1.7 Beginner's Guide

4 (1 reviews total)
By Felix Kerger
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Installing Ogre 3D

About this book

Want to make your own 3D applications, simulations, and games?

OGRE 3D, an open source Object-Oriented 3D Graphics Rendering Engine written in C++, which can be utilized to create a variety of 3D applications and is commonly used in game creation, can help you to do so!

OGRE 3D 1.7 Beginner's Guide, based on the latest version 1.7, makes it super easy for you to make your own monsters, spaceship shooters, weapons, enemies, and more!

OGRE 3D 1.7 Beginner's Guide will teach you to develop 3D applications that are exciting and interesting and if used correctly can result in stunning games and simulations. You will start from the very beginning and then work your way up to complex scenes and stunning effects.

In this book you will start with how to download and configure OGRE 3D, then create your first example scene. With the help of this sample scene, you will be introduced to several related topics each of which will be explained through several other examples and by do-it-yourself tasks.

After each example there is a section that explains the theory behind the technique used for deeper understanding. You will also use what you learned in one example in another example and repeat each technique several times while learning new ones at the same time to strengthen the topics learned. Within no time you will master the art of game creation. Imagine how great you will feel when all your friends are playing the great-looking games you've created with OGRE 3D and this book.

Publication date:
November 2010


Chapter 1. Installing Ogre 3D

Downloading and installing a new library are the first steps of learning about and using it.

In this chapter, we shall do the following:

  • Download and install Ogre 3D

  • Have our development environment working with Ogre 3D

  • Create our first scene rendered by Ogre 3D

So let's get on with it.


Downloading and installing Ogre 3D

The first step we need to take is to install and configure Ogre 3D.


Time for action — downloading and installing Ogre 3D

We are going to download the Ogre 3D SDK and install it so that we can work with it later.

  1. Go to http://www.ogre3d.org/download/sdk.

  2. Download the appropriate package. If you need help picking the right package, take a look at the next What just happened section.

  3. Copy the installer to a directory you would like your OgreSDK to be placed in.

  4. Double-click on the Installer; this will start a self extractor.

  5. You should now have a new folder in your directory with a name similar to OgreSDK_vc9_v1-7-1.

  6. Open this folder. It should look similar to the following screenshot:

What just happened?

We just downloaded the appropriate Ogre 3D SDK for our system. Ogre 3D is a cross-platform render engine, so there are a lot of different packages for these different platforms. After downloading we extracted the Ogre 3D SDK.

Different versions of the Ogre 3D SDK

Ogre supports many different platforms, and because of this, there are a lot of different packages we can download. Ogre 3D has several builds for Windows, one for MacOSX, and one Ubuntu package. There is also a package for MinGW and for the iPhone. If you like, you can download the source code and build Ogre 3D by yourself. This chapter will focus on the Windows pre-build SDK and how to configure your development environment. If you want to use another operating system, you can look at the Ogre 3D Wiki, which can be found at http://www.ogre3d.org/wiki. The wiki contains detailed tutorials on how to set up your development environment for many different platforms. The rest of the book is completely platform independent, so if you want to use another development system, feel free to do so. It won't affect the content of this book besides the configuration and conventions of your build environment.

Exploring the SDK

Before we begin building the samples which come with the SDK, let's take a look at the SDK. We will look at the structure the SDK has on a Windows platform. On Linux or MacOS the structure might look different. First, we open the bin folder. There we will see two folders, namely, debug and release. The same is true for the lib directory. The reason is that the Ogre 3D SDK comes with debug and release builds of its libraries and dynamic-linked/shared libraries. This makes it possible to use the debug build during development, so that we can debug our project. When we finish the project, we link our project against the release build to get the full performance of Ogre 3D.

When we open either the debug or release folder, we will see many dll files, some cfg files, and two executables (exe). The executables are for content creators to update their content files to the new Ogre version, and therefore are not relevant for us.

The OgreMain.dll is the most important DLL. It is the compiled Ogre 3D source code we will load later. All DLLs with Plugin_ at the start of their name are Ogre 3D plugins we can use with Ogre 3D. Ogre 3D plugins are dynamic libraries, which add new functionality to Ogre 3D using the interfaces Ogre 3D offers. This can be practically anything, but often it is used to add features like better particle systems or new scene managers. What these things are will be discussed later. The Ogre 3D community has created many more plugins, most of which can be found in the wiki. The SDK simply includes the most generally used plugins. Later in this book, we will learn how to use some of them. The DLLs with RenderSystem_ at the start of their name are, surely not surprisingly, wrappers for different render systems that Ogre 3D supports. In this case, these are Direct3D9 and OpenGL. Additional to these two systems, Ogre 3D also has a Direct3D10, Direct3D11, and OpenGL ES(OpenGL for Embedded System) render system.

Besides the executables and the DLLs, we have the cfg files. cfg files are config files that Ogre 3D can load at startup. Plugins.cfg simply lists all plugins Ogre 3D should load at startup. These are typically the Direct3D and OpenGL render systems and some additional SceneManagers. quakemap.cfg is a config file needed when loading a level in the Quake3 map format. We don't need this file, but a sample does.

resources.cfg contains a list of all resources, like a 3D mesh, a texture, or an animation, which Ogre 3D should load during startup. Ogre 3D can load resources from the file system or from a ZIP file. When we look at resources.cfg, we will see the following lines:



Zip= means that the resource is in a ZIP file and FileSystem= means that we want to load the contents of a folder. resources.cfg makes it easy to load new resources or change the path to resources, so it is often used to load resources, especially by the Ogre samples. Speaking of samples, the last cfg file in the folder is samples.cfg. We don't need to use this cfg file. Again, it's a simple list with all the Ogre samples to load for the SampleBrowser. But we don't have a SampleBrowser yet, so let's build one.


The Ogre 3D samples

Ogre 3D comes with a lot of samples, which show all the kinds of different render effects and techniques Ogre 3D can do. Before we start working on our application, we will take a look at the samples to get a first impression of Ogre's capabilities.


Time for action — building the Ogre 3D samples

To get a first impression of what Ogre 3D can do, we will build the samples and take a look at them.

  1. Go to the Ogre3D folder.

  2. Open the Ogre3d.sln solution file.

  3. Right-click on the solution and select Build Solution.

  4. Visual Studio should now start building the samples. This might take some time, so get yourself a cup of tea until the compile process is finished.

  5. If everything went well, go into the Ogre3D/bin folder.

  6. Execute the SampleBrowser.exe.

  7. You should see the following on your screen:

  8. Try the different samples to see all the nice features Ogre 3D offers.

What just happened?

We built the Ogre 3D samples using our own Ogre 3D SDK. After this, we are sure to have a working copy of Ogre 3D.

Pop quiz — which post effects are shown in the samples

  1. Name at least five different post effects that are shown in the samples.

    a. Bloom, Glass, Old TV, Black and White, and Invert

    b. Bloom, Glass, Old Monitor, Black and White, and Invert

    c. Boom, Glass, Old TV, Color, and Invert


The first application with Ogre 3D

In this part, we will create our first Ogre 3D application, which will simply render one 3D model.


Time for action — starting the project and configuring the IDE

As with any other library, we need to configure our IDE before we can use it with Ogre 3D.

  1. Create a new empty project.

  2. Create a new file for the code and name it main.cpp.

  3. Add the main function:

    int main (void)
    return 0;
  4. Include ExampleApplication.h at the top of the following source file:

    #include "Ogre\ExampleApplication.h":
  5. Add PathToYourOgreSDK\include\ to the include path of your project.

  6. Add PathToYourOgreSDK\boost_1_42 to the include path of your project.

  7. Add PathToYourOgreSDK\boost_1_42\lib to your library path.

  8. Add a new class to the main.cpp.

    class Example1 : public ExampleApplication
    void createScene()
  9. Add the following code at the top of your main function:

    Example1 app;
  10. Add PathToYourOgreSDK\lib\debug to your library path.

  11. Add OgreMain_d.lib to your linked libraries.

  12. Add OIS_d.lib to your linked libraries.

  13. Compile the project.

  14. Set your application working directory to PathToYourOgreSDK\bin\debug.

  15. Start the application. You should see the Ogre 3D Setup dialog.

  16. Press OK and start the application. You will see a black window. Press Escape to exit the application.

What just happened?

We created our first Ogre 3D application. To compile, we needed to set different include and library paths so the compiler could find Ogre 3D.

In steps 5 and 6, we added two include paths to our build environment. The first path was to the Ogre 3D SDK include folder, which holds all the header files of Ogre 3D and OIS. OIS stands for Object Oriented Input System and is the input library that ExampleApplication uses to process user input. OIS isn't part of Ogre 3D; it's a standalone project and has a different development team behind it. It just comes with Ogre 3D because the ExampleApplication uses it and so the user doesn't need to download the dependency on its own. ExampleApplication.h is also in this include folder. Because Ogre 3D offers threading support, we needed to add the boost folder to our include paths. Otherwise, we can't build any application using Ogre 3D. If needed, Ogre 3D can be built from the source, disabling threading support and thus removing the need for boost. And while using boost, the compiler also needs to be able to link the boost libraries. Thus we have added the boost library folder into our library paths (see step 7).

In step 10, we added PathToYourOgreSDK\lib\debug to our library path. As said before, Ogre 3D comes with debug and release libraries. With this line we decided to use the debug libraries because they offer better debug support if something happens to go wrong. When we want to use the release versions, we have to change the lib\debug to \lib\release. The same is true for steps 11 und 12. There we added OgreMain_d.lib and OIS_d.lib to our linked libraries. When we want to use the release version, we need to add OgreMain.lib and OIS.lib. OgreMain.lib, and OgreMain_d.lib contains both the interface information about Ogre 3D and tells our application to load OgreMain.dll or OgreMain_d.dll. Note that OIS.lib or OIS_d.lib is the same for the input system they load OIS_d.dll or OIS.dll. So we link Ogre 3D and OIS dynamically, enabling us to switch the DLL without recompiling our application, as long as the interface of the libraries doesn't change and the application and the DLL are using the same runtime library versions. This also implies that our application always needs to load the DLLs, so we have to make sure it can find it. This is one of the reasons we set the working directory in step 14. Another reason will be made clear in the next section.


We created a new class, Example1, which inherits from ExampleApplication. ExampleApplication is a class that comes with the Ogre 3D SDK and is intended to make learning Ogre 3D easier by offering an additional abstraction layer above Ogre 3D. ExampleApplication starts Ogre for us, loads different models we can use, and implements a simple camera so we can navigate through our scene. To use ExampleApplication, we just needed to inherit from it and override the virtual function createScene(). We will use the ExampleApplication class for now to save us from a lot of work, until we have a good understanding of Ogre 3D. Later, we will replace ExamplesApplication piece-by-piece with our own code.

In the main function, we created a new instance of our application class and called the go() function to start the application and load Ogre 3D. At startup, Ogre 3D loads three config files Ogre.cfg, plugins.cfg, and resources.cfg. If we are using the debug versions, each file needs an "_d" appended to its name. This is useful because with this we can have different configuration files for debug and release. Ogre.cfg contains the configuration we selected in the setup dialog, so it can load the same settings to save us from entering the same information every time we start our application. plugins.cfg contains a list of plugins Ogre should load. The most important plugins are the rendersystem plugins. They are the interface for Ogre to communicate with OpenGL or DirectX to render our scene. resources.cfg contains a list of resources that Ogre should load during startup. The Ogre 3D SDK comes with a lot of models and textures we will use in this book and resources.cfg points to their location. If you look inside resources.cfg, you will see that the paths in this file are relative. That's the reason we need to set the working directory.

Pop quiz — which libraries to link

  1. Which libraries do you need to link when using Ogre 3D in release configuration?

    a. OgreD3DRenderSystem.lib

    b. OgreMain.lib

    c. OIS.lib

  2. What would we have to change when we want to use the debug build versions of Ogre 3D?

    a. Add an _debug after the library name

    b. Add an _d at the file extension

    c. Add an _d after the library name


Loading the first model

We have a basic application with nothing in it, which is rather boring. Now we will load a model to get a more interesting scene.


Time for action — loading a model

Loading a model is easy. We just need to add two lines of code.

  1. Add the following two lines into the empty createScene() method:

    Ogre::Entity* ent =
  2. Compile your application again.

  3. Start your application. You will see a small green figure after starting the application.

  4. Navigate the camera with the mouse and WASD until you see the green figure better.

  5. Close the application.

What just happened?

With mSceneMgr->createEntity("MyEntity","Sinbad.mesh");,we told Ogre that we wanted a new instance of the Sinbad.mesh model. mSceneMgr is a pointer to the SceneManager of Ogre 3D, created for us by the ExampleApplication. To create a new entity, Ogre needs to know which model file to use, and we can give a name to the new instance. It is important that the name is unique; it can't be used twice. If this happens, Ogre 3D will throw an exception. If we don't specify a name, Ogre 3D will automatically generate one for us. We will examine this behavior in more detail later.

We now have an instance of a model, and to make it visible, we need to attach it to our scene. Attaching an entity is rather easy – just write the following line: mSceneMgr->getRootSceneNode()->attachObject(ent);

This attaches the entity to our scene so we can see it. And what we see is Sinbad, the mascot model of Ogre 3D. We will see this model a lot during the course of this book.

Pop quiz — ExampleApplication and how to display a model

Describe in your own words how to load a model and how to make it visible.



We learned how the Ogre 3D SDK is organized, which libraries we needed to link, and which folder we needed in our include path. Also, we got a first glance at the class ExampleApplication and how to use it. We loaded a model and displayed it.

Specifically, we covered:

  • Which files are important for the development with Ogre 3D, how they interact with each other, and what their purpose is

  • What ExampleApplication is for: How this class helps to save us work and what happens during the startup of Ogre 3D

  • Model loading: We learned how we can create a new instance of a model with createEntity and one way to attach the new instance to our scene

After this introduction to Ogre 3D, we will learn more about how Ogre 3D organizes scenes and how we can manipulate the scene in the next chapter.

About the Author

  • Felix Kerger

    Felix Kerger is a Computer Science Student at the Technical University of Darmstadt and has been developing 3D real-time applications using OGRE 3D for more than 5 years. He has given several talks on software development and 3D real-time applications at different conferences and has been working for three years as an assistant researcher at the Fraunhofer Institute for Computer Graphics Research. He also works as a freelance journalist and reports yearly from the Game Developer Conference Europe.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Bestellabwicklung wieder optimal. Leider ist das Buch etwas veraltet, aber trotzdem brauchbar.

Recommended For You

OGRE 3D 1.7 Application Development Cookbook

Over 50 recipes to provide world-class 3D graphics solutions with OGRE 3D

By Ilya Grinblat and 1 more