Table of contents
- 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