A renderer does not care about whether it's rendering a player, an enemy, or whatever. It usually contains data for a piece of static world geometry (in your case, this would be the terrain), for a large amount of small static geometry (for instance, rocks and trees) and a large amount of small dynamic geometry (your enemies and player).

The program (and not the scene manager) then matches in-game entities with their scene representation.

Quote:Original post by ManixReaper
Thanks for the reply ToohrVyk.
The reason I was thinking of having several list was basically for height calculations. If we want to get the height on the terrain for the placement of another object and it is mixed in a tree/vector/list structure with other object that do not return height values, you will need to find the type of object that you are looking at when iterating, and if it is the terrain object (Used loosely to describe the whole terrain), then get the height of the terrain at the point you are looking at.
If we put them into a separate list, then when adding other objects, you can call ‘terrain->getheight()’ and not have to worry about the type of the object or casting.

You're mixing 'renderer' with 'game logic'. The renderer doesn't care WHAT it's rendering - all it wants is some vertex/face and texture data. Your game logic should figure out terrain heights and object placement and whatnot.

A brief of how I go about it (and I'm not saying this is definitive, just my way): I have a class called CPlaceable, which contains position/rotation vectors and the matrix and such, and derived from it I have CGeometry, which contains mesh and material data, and derived from THAT I have things like CPlayer, CEnemy etc.

My octree class organises what is currently in view and builds a vector of pointers of CGeometry objects, i.e., if a CPlayer is in view, it is dynamic_cast<CGeometry>'d and placed into the vector. This vector gets sent to the renderer which draws it all.

Any game logic is performed in the CPlayer/CEnemy/CTerrain objects, complately separate from the renderer.

I'm not a great programmer to say the least, so I'm damn sure someone else has a prettier method.

Hello,

right now I am venturing into the same territory as ManixReaper, so I will add to the discussion. [smile]

It is my understanding that a Scene Graph is a type of structure or format that manages animation, and updating of scenes.

Something that might work would be to have a class called "GameWorld." In game you have a vector list of of pointers to "GameObjects" which are pointers to your specific class such as terrain, sky, etc.

In each class you have a render function. The job of the GameWorld is to iterate through the vector list of GameObjects and render them each frame.

I know verily little on the subject of engine management when it comes to objects such as terrain, and sky, etc. and how to manage their interactions, so do not take my ideas and interpret them as _good_. [wink]

A scene graph would be for management for something such as trees, or people since there would many people/trees/whatever in a scene at one time. This list of objects would constantly be changing and need updating since the objects would quite often come in and out of view, and most likely require some form of animation.

Looking forward to more feedback from those with more experience on such subjects. [smile]

--Jonathan Janevski