As with any other library, we need to configure our IDE before we can use it with Ogre 3D.
main.cpp
.int main (void) { return 0; }
ExampleApplication.h
at the top of the following source file:#include "OgreExampleApplication.h":
PathToYourOgreSDKinclude
to the include path of your project. PathToYourOgreSDKoost_1_42
to the include path of your project. PathToYourOgreSDKoost_1_42lib
to your library path. main.cpp
.class Example1 : public ExampleApplication { public: void createScene() { } };
Example1 app; app.go();
PathToYourOgreSDKlibdebug
to your library path. OgreMain_d.lib
to your linked libraries. OIS_d.lib
to your linked libraries. PathToYourOgreSDKindebug
.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 PathToYourOgreSDKlibdebug
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 libdebug
to lib
elease
. 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.
a. OgreD3DRenderSystem.lib
b. OgreMain.lib
c. OIS.lib
a. Add an _debug after the library name
b. Add an _d at the file extension
c. Add an _d after the library name
3.22.130.232