HwUF: General Ogre Principles

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

HwUF: General Ogre Principles

Post by paul424 »

Here I try to sum up all general principles of Ogre ( going to put there into Ultra FAQ ) -- sure one can deduce that from somwhere else ... but it could always spare beginner time :

1. Is the Ogre3d error-liberal or error-conservative engine ? The way how it handles wrong materials ( render white surface anyway ) seems it's error-liberal ? Hmm on the other hand if there are some misssing meshes it returns with an error .
2. Extensive use of objects' retrival mechanism by their name set on the application code side ( programmer ? ) .
3. Use of smart pointers ( achieved by it's own cooked templates )
3 + 1. All complex declarations are hidden behind the typdef directive. Internal type system which is independent of what compiler / c++ std library you are using.
4. Extensive use of Managers ( in OO pattern nomenclature : Factories ) when comes to object creation .
5. Extensive use of Singleton patterns for main objects ( managers ) .
6. Plugins mechanism ( facilitated loading of shared libraries -- DLL's / SO's ) .
7. All rendering operations which require API's calls of 3d libs ( DirectX, OpenGL) are realized in external plugins.
Last edited by paul424 on Fri Oct 17, 2014 12:00 pm, edited 2 times in total.
User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: HwUF: General Ogre Principles

Post by paul424 »

Seems the quesrtion in my first paragraph is not well understood , I mean what is general strategy of handling wrong request to the engine ? . For Example , from Irrlicht engine : "Extreme stability. Most libraries for realtime applications crash when the user does something the library programmer did not expect. This is different in the Irrlicht engine. It prints out a warning to (debug-)log and continues, always trying to keep on running. "
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: HwUF: General Ogre Principles

Post by dark_sylinc »

paul424 wrote:1. Is the Ogre3d error-liberal or error-conservative engine ? The way how it handles wrong materials ( render white surface anyway ) seems it's error-liberal ? Hmm on the other hand if there are some misssing meshes it returns with an error .
Errr... I don't know how to answer that. I don't think the classification is useful.

Ogre treats imporant and fatal user/input errors... as fatal. They will raise an exception. Exceptions can be caught and program execution will continue while leaving the error in the log. Minor errors often just leave a warning in the log.
Sometimes it is Ogre itself which raised and caught the exception.
Other times it's the user who may try to catch it or decide to leave it uncaught forcing program termination.
For example in Ogre Meshy I catch most of the errors to prevent crashing, making the mesh viewer tool very stable even with rare meshes.
But in my game, I often don't catch these, just catch them at the top level main(), leave a message box and terminate the program, so that asset problems don't start piling up silently until I check the log.
2. Extensive use of objects' retrival mechanism by their name set on the application code side ( programmer ? ) .
I hate this pattern from 1.x as it is inefficient. In 2.x, names are optional, and we're favouring the pattern of storing the pointer when you create it. Other retrieval mechanism exists, and now every object has a unique ID at least.
3. Use of smart pointers (achieved by it's own cooked templates)
Use with care. Materials, textures and shaders in Ogre are smart pointers. While one Entity refereces they won't be destroyed. But smart pointers have non-negligent overhead.
Often it's better to have a good design of the lifetime of an object.
5. Extensive use of Singleton patterns for main objects ( managers ).
No. God no!. Using singletons was one huge mistake. Taking them out requires a huge undertaking, so they're staying. But we're not adding more and we discourage singletons.
7. All rendering operations which require API's calls of 3d libs ( DirectX, OpenGL) are realized in external plugins.
Yes. Sadly history showed us this wasn't perhaps the best choice (it wasn't a mistake though). A RenderSystem chosen at compile-time has many more optimization opportunities, while a RenderSystem chosen at runtimes through plugins has little advantages (users rarely change render system at all, unless the app is well written, switching may not be painless i.e. crash; and you can provide multiple binaries for each RS if you want diversity).
Post Reply