Cookbook  »  OgreArticles  »  Coding and Design philosophy

- A quick guide to some design issues. What to use when. Please contribute!

Class inheritence

• http://www.users.on.net/~edan/misc/ogre_classviz_nodeps.gif Here's a diagram showing inheritance. Might make some things clearer.
• Although Ogre is a SceneGraph, it's not a strict one. Light, Camera and few things aren't inherited from node. They don't need to be attached to a scenenode (although they can be). This is for convenience and speed.

Custom objects

- Use Movable Object Factories when creating reusable custom objects. eg Particle systems, water meshes (eg current water demo would be nice to rewrite as a movable)

• this allows easy creation and management in Ogre
• easy to modularise and reuse
• please wiki any nice custom objects!

Scene managers

- Write a custom scene manager when you require unique scene management.

• eg existing BSP, Octree culling managers
• custom SM's are rarely needed. Octree is a good default for alot of cases.
• multiple scenemanagers can't be run in the same scene (eg terrain and bsp)

Scene definition

- Or level/scene design

• common solution is the dotScene xml format (search wiki)
• most modellers can export whole scenes to this format, while also exporting the actual meshes
• example dotScene implementations are in 'ogreAddons' in CVS

Main loop/Initialisation

• You don't need to use FrameListeners for updating every frame. You can call the render loop manually from a 'normal' while loop if you like.
• You don't need to use ExampleApplication like all the demos use. This either helps or hinders new people. See these examples for alternatives and a clear understanding of what ogre needs to initialise.

Nice clean example. Uses Framelisteners for render updates
'Hello World' example
Manual render loop example - windows only
Replacement ExampleApp to inherit new apps from
A complete framework tying alot of libraries together

Alias: Coding&Design philosophy?