answers :

1. ROOT - THE OBLIGATORY CLASS/ OBJECT.

1a. Why do I have to allocate root on heap, and not on stack ?

That is why I do have to write

Root *root = new Root();

and not just :

Root root = Root();

?

A:

Well, devel sindbad often holds root inside a manager class so Root gets constructed as soon as the manager is. So it actually becomes:

class SomeManager
        {
        protected:
            Ogre::Root mOgreRoot;
        ...
        }

You might construct Root like that in your entry point Before the frame loop

is kicked off. When using the RAII technique ( that is what this snippet does )

you must just watch out that mOgreRoot won't be popped off from stack while the

app is running. This is hard to do with the RAII, as with that the function

call frames are deleted in the order opposite to how they were put onto the stack — that

is the 'newest ' call frame first, but when using say threading the things

get more complicated... ( note : This is actually the same consideration as making sure you

don't call 'delete mOgreeRootPointer' during the program's main loop.)

Thus there really isn't a concrete need to manage Root using new/delete, although you can if you want.

1b. How to create similar class with getSingleton() method ?

This pattern is called Singleton :

http://en.wikipedia.org/wiki/Singleton_pattern

Deriving from Ogre::Singleton is merely a matter of doing this:

MyAwesomeClass :: public Ogre::Singleton<MyAwesomeClass>
        {
        //code omitted - obviously
        };
     
    And in the implementation file:
     
        template<> MyAwesomeClass* Ogre::Singleton<MyAwesomeClass>::ms_Singleton = 0;

The Ogre3d's Singleton has been written by Scott Bilas, here's his blog entry

discussing similar Singleton variant :

http://scottbilas.com/publications/gem-singleton/ .

1b2. I need more than one window for my app, can I create more than one root object for that purpose ?

Two instances of root is not possible/recommend/supported.

(M)Ogre uses Singletons, that is one instance of the object in the same

application context) e.g. TextureManager, MeshManager and of course

Ogre::Root, creating -> the second created root will "override" the first one.

1b3. Can I run Ogre3d without actually initializing root ? What functions I do have at hand then ?

1b4. But I have read the tutorial and source SDK , the root is created nowhere !!

Most of the tutorials use the ExampleApplication framework, which does a lot of behind-the-scenes stuff, including the creation of the root.

1c. Ogre::Root::initialise fails — the most common causes.

1d. Explicit 'delete root' causes application crash.

The most possible cause is : your application must have had deleted root

explictly or implicitly before your 'delete root' .

1d2. Explicit 'root->shutdown()' causes application crash.

1d3.Ways of properly shouting down the Ogre3d without leaking the resources.

1e. Ogre::Root extra parametes

1e2. Example Window without borders.

First assign a value of "none" to misc%22Border%22

Next, make sure that when you initialise Ogre, you tell it NOT to create a default window. (pass false as the first param)

Then, create a render window, and assign it to the "window" member variable of your application.

// create some custom attributes for our manually created window
     
        Ogre::NameValuePairList misc;
        misc["border"] = "none";
        misc["monitorIndex"] = "0";  //I use two monitors, so I tell Ogre to draw on my main (#1) monitor
     
        // Here we tell the system not to create a default rendering window by passing 'false'
     
        mWindow = mRoot->initialise(false, "BasicTutorial7 Render Window");
     
        //now we need to create a render window manually
        //for now, the dimensions are hardcoded to MY desktop size so the window LOOKS full screen
     
        mWindow = mRoot->createRenderWindow("BasicTutorial7 Render Window",1680,1050,false, &misc ); //pass our custom attributes in "misc"

1f. root->showConfigDialog displays an empty window.

First you might not have the plugins.cfg file present in your exec's directory . The error message might be quite cryptic though — the last message being some problems with GUI library , and the one about missing plugins.cfg is mysteriously hidden ...

If you have none plugins.cfg create one ; at least should be there :

and if you have there a file say RenderSystem_GL.so ( or with longer multiply extensions as on Unixes* ) just paste the filename there:

When everythings fine you should see in the Ogre.log ( or any other file you log into ) as well in terminal ( iff called from terminal ) :

1g. What are Root's important containers I would have to modify through it's methods ? (

Diagram and Schemes.

1g. How the life cycle of handling FrameListeners look like ? ( Diagram or Scheme )

2. RESOURCES, MATERIALS, AND RESOURCES' MANAGMENT

2a. Do I need to use the Resource, ResouceManagers schemes ?

2a2. Can I make my game without this mechanism ?

2b. Why does my object display as white (or black) in Ogre?

2b2. Why does my resource creation or load fail in strange ways?

2b3. What is the Ogre::Resource's typical lifecycle ( diagram or scheme ) ?

2b4. What are usual methods of managing this lifecycle ?

See the Legend in the picture above ...

2b5. Why is OgreCore.zip missing?

2c. Why it only service small part of assets' types needed to create game (e.g. no music , sound files , no third party data ).

2c2. How do I extend that mechanism for all assets in my game ?

2c3. How do I write my own Resource type ?

2c4. How do I write my own Resource manager ?

3. SCENEMANAGERS AND SCENENODES

3a. Is it necessary to use them in my game ?

3b. How it generally work ?

3b2. There seems to be very little transformations types, why so ?

3b3. What is the order of visiting the SceneNodes tree graph ? Where does it happen in code ?

3c. Can I have more than one Entiety to a SceneNode attached ?

3d. Can I create cycles in the Ogre3d graph ?

3e. Can I prevent from inheriting any property from parent to child ?

3e2. I have two nodes which ain't parent/child related yet I would like two of them to share one of the properties ...

3f. When I attach / detach a node then the Ogre3d seems to have delays. Why is it so ? Can I improve that ?