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.
HwUF: General Ogre Principles
- paul424
- Gnome
- Posts: 314
- Joined: Thu May 24, 2012 7:16 pm
- x 13
HwUF: General Ogre Principles
Last edited by paul424 on Fri Oct 17, 2014 12:00 pm, edited 2 times in total.
- paul424
- Gnome
- Posts: 314
- Joined: Thu May 24, 2012 7:16 pm
- x 13
Re: HwUF: General Ogre Principles
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. "
- dark_sylinc
- 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
Errr... I don't know how to answer that. I don't think the classification is useful.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 .
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.
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.2. Extensive use of objects' retrival mechanism by their name set on the application code side ( programmer ? ) .
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.3. Use of smart pointers (achieved by it's own cooked templates)
Often it's better to have a good design of the lifetime of an object.
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.5. Extensive use of Singleton patterns for main objects ( managers ).
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).7. All rendering operations which require API's calls of 3d libs ( DirectX, OpenGL) are realized in external plugins.