Welcome to the new Ogre Wiki!
If you haven't done so already, be sure to visit the Wiki Portal to read about how the wiki works. Especially the Ogre Wiki Overview page.

Ogre Wiki Tutorial Framework

Development » Setting Up An Application » Ogre Wiki Tutorial Framework

Ogre Wiki Tutorial Framework

This small 'framework' is meant to be a common framework for the tutorials, the various 'Setting Up An Application' instructions, etc.
The idea is that if the same framework is used across platforms/compilers, the differences and similarities will become much easier to spot.

Quick Download

Tutorial Framework - (Windows Line-endings)

Tutorial Framework - (Linux Line-endings)

If you're only interested in grabbing and using the Ogre Wiki Framework, you can safely skip reading the rest of this page.
Visit the Setting Up An Application page for how to make use of the framework.
Read on to know the details of the framework, or come back later.

Introduction

This page will walk you through the Ogre Wiki Tutorial Framework and try to explain the logic behind it, as well as point out the alternatives.

After reading this page you should have a fairly good understanding of how it works and why it works.

Motivation

Using a common framework for the official tutorials and the instructions for setting up your Ogre applications on various platforms / toolsets means that you can set up your environment and immediately start doing the tutorials without changing your setup.
The Ogre AppWizard for Visual Studio and Code::Blocks and the build your own projects using CMake is using the framework as well, providing you with a quick way to get started learning Ogre.

Overview

The 'framework' consists of two classes: 'BaseApplication' and 'TutorialApplication'.
'BaseApplication' is a pure virtual class because it has a pure virtual function 'createScene'.
It cannot be instantiated on its own and is meant to be used as a base class.
'TutorialApplication' is derived from 'BaseApplication', and thus needs to implement the 'createScene' function.

How It Works

'BaseApplication' is five listeners in one:

class BaseApplication : public Ogre::FrameListener, public Ogre::WindowEventListener, public OIS::KeyListener, public OIS::MouseListener, OgreBites::SdkTrayListener

The app is a FrameListener which means that it is able to execute some code each frame by means of the FrameListener callback functions: frameStarted, frameRenderingQueued and frameEnded.
See Basic Tutorial 4 for more on FrameListeners.

It is a WindowEventListener, because it wants to be notified when the window is moved/resized and hook into the window closed event.

OIS is used for input handling.
It listens to Key events and Mouse events through the two OIS listeners.

The Ogre Wiki Tutorial Framework uses OgreBites for GUI widgets and camera handling.
It uses it because OgreBites - the Ogre sample framework - is included in every Ogre SDK, and because it simplifies things a lot.

Don't worry, though:
How to replace OgreBites with your own GUI code or camera handling will be covered in the Ogre tutorials.

OgreBites was chosen for simplicity: less clutter.
And because it's so easy to replace.

The SdkTrayListener is called each frame to kick off OgreBites GUI events.

We will not walk you through the various listener callback functions in this guide.
It will be covered in the tutorials.
Look at them, or use the API docs, the documentation for OIS or the OgreBites pages.

Chain Of Command

A new Ogre::Root is created.
Resource locations are read from a config file.
The configure dialogue is shown allowing you to choose render system, screen resolution, etc.
Scene manager is created.
Camera is created and set up.
The OgreBites camera manager is hooked up with the camera.
A viewport is created and set up.
All resource groups are initialised.
Scene is created.
OIS is constructed, initialised and set up.
Application asks to be registered as a Mouse and Keyboard listener.
The application registers itself as a listener to window events (closed/resized).
OgreBites SDKTrays widgets are set up, including the debug overlays.
The application registers itself as a listener to frame events.
The render loop starts, and continues to run until the application is quit.

Walkthrough

As a means of walking you through the Ogre Wiki Tutorial Framework, let's see if we can create three alternative frameworks.
These serve to illustrate how the framework works, because the functionality is the same, only organised differently.

MinimalOgre

The biggest complaint about the Ogre Wiki Tutorial Framework could be that it's too hidden away...
TutorialApplication inherits BaseApplication; it's too oblique.
Why not just put everything into one class?

Alright, here's 'MinimalOgre':
MinimalOgre-h
MinimalOgre-cpp
It's identical to the Ogre Wiki Tutorial Framework, but it's only one class, and it has only one function: 'go'.

Take a good look at that function, because it does exactly the same as what the Ogre Wiki Tutorial Framework - and that's it.
Comments indicate what function of OWTF the code relates to:

bool MinimalOgre::go(void)
{
#ifdef _DEBUG
    mResourcesCfg = "resources_d.cfg";
    mPluginsCfg = "plugins_d.cfg";
#else
    mResourcesCfg = "resources.cfg";
    mPluginsCfg = "plugins.cfg";
#endif
 
    // construct Ogre::Root
    mRoot = new Ogre::Root(mPluginsCfg);
 
//-------------------------------------------------------------------------------------
    // set up resources
    // Load resource paths from config file
    Ogre::ConfigFile cf;
    cf.load(mResourcesCfg);
 
    // Go through all sections & settings in the file
    Ogre::ConfigFile::SectionIterator seci = cf.getSectionIterator();
 
    Ogre::String secName, typeName, archName;
    while (seci.hasMoreElements())
    {
        secName = seci.peekNextKey();
        Ogre::ConfigFile::SettingsMultiMap *settings = seci.getNext();
        Ogre::ConfigFile::SettingsMultiMap::iterator i;
        for (i = settings->begin(); i != settings->end(); ++i)
        {
            typeName = i->first;
            archName = i->second;
            Ogre::ResourceGroupManager::getSingleton().addResourceLocation(
                archName, typeName, secName);
        }
    }
//-------------------------------------------------------------------------------------
    // configure
    // Show the configuration dialog and initialise the system
    // You can skip this and use root.restoreConfig() to load configuration
    // settings if you were sure there are valid ones saved in ogre.cfg
    if(mRoot->restoreConfig() || mRoot->showConfigDialog())
    {
        // If returned true, user clicked OK so initialise
        // Here we choose to let the system create a default rendering window by passing 'true'
        mWindow = mRoot->initialise(true, "MinimalOgre Render Window");
    }
    else
    {
        return false;
    }
//-------------------------------------------------------------------------------------
    // choose scenemanager
    // Get the SceneManager, in this case a generic one
    mSceneMgr = mRoot->createSceneManager(Ogre::ST_GENERIC);
//-------------------------------------------------------------------------------------
    // create camera
    // Create the camera
    mCamera = mSceneMgr->createCamera("PlayerCam");
 
    // Position it at 500 in Z direction
    mCamera->setPosition(Ogre::Vector3(0,0,80));
    // Look back along -Z
    mCamera->lookAt(Ogre::Vector3(0,0,-300));
    mCamera->setNearClipDistance(5);
 
    mCameraMan = new OgreBites::SdkCameraMan(mCamera);   // create a default camera controller
//-------------------------------------------------------------------------------------
    // create viewports
    // Create one viewport, entire window
    Ogre::Viewport* vp = mWindow->addViewport(mCamera);
    vp->setBackgroundColour(Ogre::ColourValue(0,0,0));
 
    // Alter the camera aspect ratio to match the viewport
    mCamera->setAspectRatio(
        Ogre::Real(vp->getActualWidth()) / Ogre::Real(vp->getActualHeight()));
//-------------------------------------------------------------------------------------
    // Set default mipmap level (NB some APIs ignore this)
    Ogre::TextureManager::getSingleton().setDefaultNumMipmaps(5);
//-------------------------------------------------------------------------------------
    // Create any resource listeners (for loading screens)
    //createResourceListener();
//-------------------------------------------------------------------------------------
    // load resources
    Ogre::ResourceGroupManager::getSingleton().initialiseAllResourceGroups();
//-------------------------------------------------------------------------------------
    // Create the scene
    Ogre::Entity* ogreHead = mSceneMgr->createEntity("Head", "ogrehead.mesh");
 
    Ogre::SceneNode* headNode = mSceneMgr->getRootSceneNode()->createChildSceneNode();
    headNode->attachObject(ogreHead);
 
    // Set ambient light
    mSceneMgr->setAmbientLight(Ogre::ColourValue(0.5, 0.5, 0.5));
 
    // Create a light
    Ogre::Light* l = mSceneMgr->createLight("MainLight");
    l->setPosition(20,80,50);
//-------------------------------------------------------------------------------------
    //create FrameListener
    Ogre::LogManager::getSingletonPtr()->logMessage("*** Initializing OIS ***");
    OIS::ParamList pl;
    size_t windowHnd = 0;
    std::ostringstream windowHndStr;
 
    mWindow->getCustomAttribute("WINDOW", &windowHnd);
    windowHndStr << windowHnd;
    pl.insert(std::make_pair(std::string("WINDOW"), windowHndStr.str()));
 
    mInputManager = OIS::InputManager::createInputSystem( pl );
 
    mKeyboard = static_cast<OIS::Keyboard*>(mInputManager->createInputObject( OIS::OISKeyboard, true ));
    mMouse = static_cast<OIS::Mouse*>(mInputManager->createInputObject( OIS::OISMouse, true ));
 
    mMouse->setEventCallback(this);
    mKeyboard->setEventCallback(this);
 
    //Set initial mouse clipping size
    windowResized(mWindow);
 
    //Register as a Window listener
    Ogre::WindowEventUtilities::addWindowEventListener(mWindow, this);
 
    mTrayMgr = new OgreBites::SdkTrayManager("InterfaceName", mWindow, mMouse, this);
    mTrayMgr->showFrameStats(OgreBites::TL_BOTTOMLEFT);
    mTrayMgr->showLogo(OgreBites::TL_BOTTOMRIGHT);
    mTrayMgr->hideCursor();
 
    // create a params panel for displaying sample details
    Ogre::StringVector items;
    items.push_back("cam.pX");
    items.push_back("cam.pY");
    items.push_back("cam.pZ");
    items.push_back("");
    items.push_back("cam.oW");
    items.push_back("cam.oX");
    items.push_back("cam.oY");
    items.push_back("cam.oZ");
    items.push_back("");
    items.push_back("Filtering");
    items.push_back("Poly Mode");
 
    mDetailsPanel = mTrayMgr->createParamsPanel(OgreBites::TL_NONE, "DetailsPanel", 200, items);
    mDetailsPanel->setParamValue(9, "Bilinear");
    mDetailsPanel->setParamValue(10, "Solid");
    mDetailsPanel->hide();
 
    mRoot->addFrameListener(this);
//-------------------------------------------------------------------------------------
    mRoot->startRendering();
 
    return true;
}

Well, it does actually have more than one function, but those are overridden listener functions, because Minimal Ogre is still 5 listeners rolled into one.
To keep things simple.

Pros

For use in your own projects, this is probably the way to go as you don't have to worry about whether you should override the functions of the base class in your derived class, or if you should change the functions directly in the base class.
There's generally no need to be subclassing as the framework is copied from project to project.
So let's skip one additional layer of abstraction.

Cons

As a Tutorial Framework, this is not the way to go.
To illustrate different aspects of Ogre, it works better if the common boiler plate code - which is going to be pretty much the same from tutorial to tutorial - is tucked away in a base class.
It's much easier to deal with changes by overriding functions, instead of telling you to modify that piece of code and then some code here and some lines there.
What's good for your own projects is bad for a tutorial framework.
Having everything in one class doesn't help illustrate certain aspects of Ogre programming. The other code 'gets in the way'.

TinyOgre

'It's still too much code! I want less!'
TinyOgre-h
TinyOgre-cpp

Tiny Ogre doesn't inherit anything.
It's not using OIS for input, it doesn't listen to frame events or window events - it's about as scraped as an Ogre application can be:

bool TinyOgre::go(void)
{
#ifdef _DEBUG
    mResourcesCfg = "resources_d.cfg";
    mPluginsCfg = "plugins_d.cfg";
#else
    mResourcesCfg = "resources.cfg";
    mPluginsCfg = "plugins.cfg";
#endif
 
    // construct Ogre::Root
    mRoot = new Ogre::Root(mPluginsCfg);
 
//-------------------------------------------------------------------------------------
    // set up resources
    // Load resource paths from config file
    Ogre::ConfigFile cf;
    cf.load(mResourcesCfg);
 
    // Go through all sections & settings in the file
    Ogre::ConfigFile::SectionIterator seci = cf.getSectionIterator();
 
    Ogre::String secName, typeName, archName;
    while (seci.hasMoreElements())
    {
        secName = seci.peekNextKey();
        Ogre::ConfigFile::SettingsMultiMap *settings = seci.getNext();
        Ogre::ConfigFile::SettingsMultiMap::iterator i;
        for (i = settings->begin(); i != settings->end(); ++i)
        {
            typeName = i->first;
            archName = i->second;
            Ogre::ResourceGroupManager::getSingleton().addResourceLocation(
                archName, typeName, secName);
        }
    }
//-------------------------------------------------------------------------------------
    // configure
    // Show the configuration dialog and initialise the system
    // You can skip this and use root.restoreConfig() to load configuration
    // settings if you were sure there are valid ones saved in ogre.cfg
    if(mRoot->restoreConfig() || mRoot->showConfigDialog())
    {
        // If returned true, user clicked OK so initialise
        // Here we choose to let the system create a default rendering window by passing 'true'
        mWindow = mRoot->initialise(true, "TinyOgre Render Window");
    }
    else
    {
        return false;
    }
//-------------------------------------------------------------------------------------
    // choose scenemanager
    // Get the SceneManager, in this case a generic one
    mSceneMgr = mRoot->createSceneManager(Ogre::ST_GENERIC);
//-------------------------------------------------------------------------------------
    // create camera
    // Create the camera
    mCamera = mSceneMgr->createCamera("PlayerCam");
 
    // Position it at 500 in Z direction
    mCamera->setPosition(Ogre::Vector3(0,0,80));
    // Look back along -Z
    mCamera->lookAt(Ogre::Vector3(0,0,-300));
    mCamera->setNearClipDistance(5);
 
//-------------------------------------------------------------------------------------
    // create viewports
    // Create one viewport, entire window
    Ogre::Viewport* vp = mWindow->addViewport(mCamera);
    vp->setBackgroundColour(Ogre::ColourValue(0,0,0));
 
    // Alter the camera aspect ratio to match the viewport
    mCamera->setAspectRatio(
        Ogre::Real(vp->getActualWidth()) / Ogre::Real(vp->getActualHeight()));
//-------------------------------------------------------------------------------------
    // Set default mipmap level (NB some APIs ignore this)
    Ogre::TextureManager::getSingleton().setDefaultNumMipmaps(5);
//-------------------------------------------------------------------------------------
    // Create any resource listeners (for loading screens)
    //createResourceListener();
//-------------------------------------------------------------------------------------
    // load resources
    Ogre::ResourceGroupManager::getSingleton().initialiseAllResourceGroups();
//-------------------------------------------------------------------------------------
    // Create the scene
    Ogre::Entity* ogreHead = mSceneMgr->createEntity("Head", "ogrehead.mesh");
 
    Ogre::SceneNode* headNode = mSceneMgr->getRootSceneNode()->createChildSceneNode();
    headNode->attachObject(ogreHead);
 
    // Set ambient light
    mSceneMgr->setAmbientLight(Ogre::ColourValue(0.5, 0.5, 0.5));
 
    // Create a light
    Ogre::Light* l = mSceneMgr->createLight("MainLight");
    l->setPosition(20,80,50);
//-------------------------------------------------------------------------------------
 
    while(true)
    {
        // Pump window messages for nice behaviour
        Ogre::WindowEventUtilities::messagePump();
 
        if(mWindow->isClosed())
        {
            return false;
        }
 
        // Render a frame
        if(!mRoot->renderOneFrame()) return false;
    }
 
    // We should never be able to reach this corner
    // but return true to calm down our compiler
    return true;
}

Please notice that you have to exit the application by closing the window 'manually' - there's no input.

Pros

This code is not going to get in your way. :-)
There's simply too little of it.
As few assumptions as possible.
But: it does illustrate the minimum amount of code required to get Ogre up and rendering.

Cons

It does almost nothing, so you need to hook it up with input, listeners, etc.
This is not suited for a tutorial framework as there would be too much repetition.

LowLevelOgre

'I think you're hiding too much by relying on configuration files!'

You're right: 'resources.cfg', 'plugins.cfg' and 'ogre.cfg' are not really a part of Ogre.
It's an Ogre Samples convenience thing.
We can do this in code:
LowLevelOgre-h
LowLevelOgre-cpp

Setup

This piece of code constructs a new Ogre::Root, telling it to not use any plugins or config files, because we'll be setting it up in code.

// construct Ogre::Root : no plugins filename, no config filename, using a custom log filename
mRoot = new Ogre::Root("", "", "LowLevelOgre.log");
 
// A list of required plugins
Ogre::StringVector required_plugins;
required_plugins.push_back("GL RenderSystem");
required_plugins.push_back("Octree & Terrain Scene Manager");
 
// List of plugins to load
Ogre::StringVector plugins_toLoad;
plugins_toLoad.push_back("RenderSystem_GL");
plugins_toLoad.push_back("Plugin_OctreeSceneManager");
 
// Load the OpenGL RenderSystem and the Octree SceneManager plugins
for (Ogre::StringVector::iterator j = plugins_toLoad.begin(); j != plugins_toLoad.end(); j++)
{
#ifdef _DEBUG
    mRoot->loadPlugin(*j + Ogre::String("_d"));
#else
    mRoot->loadPlugin(*j);
#endif;
}
 
// Check if the required plugins are installed and ready for use
// If not: exit the application
Ogre::Root::PluginInstanceList ip = mRoot->getInstalledPlugins();
for (Ogre::StringVector::iterator j = required_plugins.begin(); j != required_plugins.end(); j++)
{
    bool found = false;
    // try to find the required plugin in the current installed plugins
    for (Ogre::Root::PluginInstanceList::iterator k = ip.begin(); k != ip.end(); k++)
    {
        if ((*k)->getName() == *j)
        {
            found = true;
            break;
        }
    }
    if (!found)  // return false because a required plugin is not available
    {
        return false;
    }
}

One additional bonus feature of this code is that it checks the loaded plugins against the required list of plugins and exits if a required plugin is missing.

Here's a list of the plugin names and the render system names:

BSPSceneManager PluginName = "BSP Scene Manager"
OgreCgPlugin PluginName = "Cg Program Manager"
OgreOctreePlugin PluginName = "Octree & Terrain Scene Manager"
OctreeZone PluginName = "Octree Zone Factory"
OgreParticleFXPlugin PluginName = "ParticleFX"
PCZSceneManager PluginName = "Portal Connected Zone Scene Manager"
Direct3D10 PluginName = "D3D10 RenderSystem"
OgreD3D11Plugin PluginName = "D3D11 RenderSystem"
OgreD3D9Plugin PluginName = "D3D9 RenderSystem"
OgreGLPlugin PluginName = "GL RenderSystem"
OgreGLESPlugin PluginName = "OpenGL ES 1.x RenderSystem"

OgreD3D10RenderSystem Name = "Direct3D10 Rendering Subsystem"
Direct3D11 Name = "Direct3D11 Rendering Subsystem"
Direct3D9 Name = "Direct3D9 Rendering Subsystem"
GL Name = "OpenGL Rendering Subsystem"
GLES Name = "OpenGL ES 1.x Rendering Subsystem"

Resources

This one is almost too easy to do in code:

// setup resources
// Only add the minimally required resource locations to load up the Ogre head mesh
Ogre::ResourceGroupManager::getSingleton().addResourceLocation("../../media/materials/programs", "FileSystem", "General");
Ogre::ResourceGroupManager::getSingleton().addResourceLocation("../../media/materials/scripts", "FileSystem", "General");
Ogre::ResourceGroupManager::getSingleton().addResourceLocation("../../media/materials/textures", "FileSystem", "General");
Ogre::ResourceGroupManager::getSingleton().addResourceLocation("../../media/models", "FileSystem", "General");

Configure

We have hardcoded ourselves to using the OpenGL Rendering Subsystem, with a windowed mode in 800x600 resolution with vsync turned off:

// configure
// Grab the OpenGL RenderSystem, or exit
Ogre::RenderSystem* rs = mRoot->getRenderSystemByName("OpenGL Rendering Subsystem");
if(!(rs->getName() == "OpenGL Rendering Subsystem"))
{
    return false; //No RenderSystem found
}
// configure our RenderSystem
rs->setConfigOption("Full Screen", "No");
rs->setConfigOption("VSync", "No");
rs->setConfigOption("Video Mode", "800 x 600 @ 32-bit");
 
mRoot->setRenderSystem(rs);
 
mWindow = mRoot->initialise(true, "LowLevelOgre Render Window");

Pros

It's much clearer what's happening as there isn't an additional layer of logic.
Nothing is fetched from the outside.

Cons

Each and every change requires you to change the code and recompile.
It's literally hard-coded.

The Framework

Pros and Cons of the Ogre Wiki Tutorial Framework.

Pros

The modularity of the framework - base class, derived class - makes it obvious what is changed/customised.
It's also easier to walk through as it's neatly organised in touched (overridden) functions and un-touched functions.

Cons

If you're not careful, you won't see the tucked away code (much).
Hopefully, the progression of the Ogre Tutorials will make sure that you get around all corners of the small framework.

Conclusion

You are still thinking to yourself:
'Why are you hiding so much functionality'?

The answer is:
Ogre is abstracting away those nitty gritty details so you don't have to worry about them.

If you really want to learn the low level basics of 3D programming, look into nitty OpenGL and/or gritty DirectX.

Honest. :-)

The tutorial framework is not really hiding anything not already hidden by Ogre itself.

Sure, you can do some tricks using some lower level Ogre API, but that is something for the intermediate tutorials, in-depth articles and the snippets.

Geek Alert

It's a good idea to study Ogre::Root!
It's a façade class, which means that everything Ogre::Root does, you can do yourself.
Ogre::Root is more or less a convenience class which does some housekeeping for you.

The Files

The Downloads

Ogre Wiki Tutorial Framework

Tutorial Framework - (Windows Line-endings)

Tutorial Framework - (Linux Line-endings)

Minimal Ogre

Minimal Ogre - (Windows Line-endings)

Minimal Ogre - (Linux Line-endings)

Tiny Ogre

Tiny Ogre - (Windows Line-endings)

Tiny Ogre - (Linux Line-endings)

Low Level Ogre

Low Level Ogre - (Windows Line-endings)

Low Level Ogre - (Linux Line-endings)

Contributors to this page: spacegaier , jacmoe and harkathmaker .
Page last modified on Sunday 04 of December, 2011 19:27:30 GMT by spacegaier .

The content on this page is licensed under the terms of the Creative Commons Attribution-ShareAlike License.
As an exception, any source code contributed within the content is released into the Public Domain.

SourceHistory8 files attached

List of attached files
	ID	Name	desc	uploaded	Size	Downloads
1	127	MinimalOgre.tar.bz2	Minimal Ogre - (Linux Line-endings)	Sat 01 of Jan., 2011 02:31 GMT by jacmoe	4.49 Kb	1159
2	126	LowLevelOgre.tar.bz2	Low Level Ogre - (Linux Line-endings)	Sat 01 of Jan., 2011 02:29 GMT by jacmoe	2.69 Kb	1023
3	125	TinyOgre.tar.bz2	Tiny Ogre - (Linux Line-endings)	Sat 01 of Jan., 2011 02:27 GMT by jacmoe	2.48 Kb	987
4	124	TutorialFramework.tar.bz2	Tutorial Framework - (Linux Line-endings)	Sat 01 of Jan., 2011 01:44 GMT by jacmoe	4.72 Kb	7803
5	69	TinyOgre.zip	Tiny Ogre - (Windows Line-endings)	Thu 24 of June, 2010 19:38 GMT by jacmoe	2.70 Kb	2239
6	67	LowLevelOgre.zip	Low Level Ogre - (Windows Line-endings)	Thu 24 of June, 2010 13:21 GMT by jacmoe	2.89 Kb	2272
7	63	MinimalOgre.zip	Minimal Ogre - (Windows Line-endings)	Thu 24 of June, 2010 13:19 GMT by jacmoe	4.91 Kb	2766
8	61	TutorialFramework.zip	Tutorial Framework - (Windows Line-endings)	Thu 24 of June, 2010 13:18 GMT by jacmoe	5.96 Kb	41159

Click this link to toggle the Report Page Issue Form

Search by Tags

Search Wiki by Freetags

Last changes

...more

Search box

Advanced search:

Non Advanced Search or Natural Search

The documents are returned sorted on relevance depending on order, proximity, frequency of terms.

Advanced Search or Boolean Search

Default search behavior

By default, all search terms are optional. It behaves like an OR logic. Objects that contain the more terms are rated higher in the results and will appear first in their type. For example, wiki forum will find:

objects that include both terms
objects that include the term wiki
objects that include the term forum

Requiring terms

Add a plus sign ( + ) before a term to indicate that the term must appear in results. Example: +wiki forum will find objects containing at least wiki. Objects with both terms and many occurences of the terms will appear first.

Excluding terms

Add a minus sign ( - ) before a term to indicate that the term must not appear in the results. To reduce a term's value without completely excluding it, use a tilde. Example: -wiki forum will find objects that do not contain wiki but contain forum

Grouping terms

Use parenthesis ( ) to group terms into subexpressions. Example: +wiki +(forum blog) will find objects that contain wiki and forum or that contain wiki and blog in any order.

Finding phrases

Use double quotes ( " " ) around a phrase to find terms in the exact order, exactly as typed. Example: "Alex Bell" will not find Bell Alex or Alex G. Bell.

Using wildcards

Add an asterisk ( * ) after a term to find objects that include the root word. For example, run* will find:

objects that include the term run
objects that include the term runner
objects that include the term running

Reducing a term's value

Add a tilde ( ~ ) before a term to reduce its value indicate to the ranking of the results. Objects that contain the term will appear lower than other objects (unlike the minus sign which will completely exclude a term). Example: +wiki ~forum will rate an object with only wiki higher that an object with wiki and forum.

Changing relevance value

Add a less than ( < ) or greater than ( > ) sign before a term to change the term's contribution to the overall relevance value assigned to a object. Example: +wiki +(>forum < blog) will find objects that contain wiki and forum or wiki and blog in any order. wiki forum will be rated higher.

Online users

49 online users

Quick Download

Introduction

Table of contents

Motivation

Overview

How It Works

Chain Of Command

Walkthrough

MinimalOgre

Pros

Cons

TinyOgre

Pros

Cons

LowLevelOgre

Setup

Resources

Configure

Pros

Cons

The Framework

Pros

Cons

Conclusion

The Files

The Downloads

Ogre Wiki Tutorial Framework

Minimal Ogre

Tiny Ogre

Low Level Ogre

Sidebar

Search by Tags

Last changes

Search box

Non Advanced Search or Natural Search

Advanced Search or Boolean Search

Default search behavior

Requiring terms

Excluding terms

Grouping terms

Finding phrases

Using wildcards

Reducing a term's value

Changing relevance value

Online users