I'm just wondering which of these two styles is preferable:

a) Have a Scene object which is responsible for all rendering. The Scene object asks the model objects (E.G. Player or Ball) for information about their current state, then renders each as it sees fit.

b) Let each model object have a display() method which tells to object to render itself. The Scene object would prepare the OpenGL context. Then, for each of the model objects it wants rendered, it calls display(). Finally, it flushes to screen.

Is there a 3rd style which totally pwns both a and b?

Definitely b.

No, b is bad. a is closer to correct, though I'd have the objects be responsible for their own geometry, shading and positioning, the rendering should be centralized.

OneSadCookie Wrote:I'd have the objects be responsible for their own geometry, shading and positioning

should model objects ever call glVertex3f(), or is that what you meant by rendering?

no, model objects should never call glVertex3f.

I personally vote for b, but I'd like to hear OSC's reasoning for not liking it... As long as you make sure that the modelview matrix doesn't change between objects etc., I see no problems with it. I'm using more or less that method (where every object is put in a double linked list to be sorted each frame for accurate alpha) in the game I'm making and it works fine.

It works fine for simple stuff, but it quickly breaks down if you want to do optimizations like sorting by texture, depth-sorting (for transparency) per polygon, etc.

See this is something I've always been confused over. Why is a so much better? It seems a is harder file-management wise, but it makes inheritance a lot easier for graphical elements, etc?

it also puts all your state management in one place, which means you can't get those nasty state-smasher bugs (y'know, the one where /someone/ is leaving texturing enabled on unit 1, but you can't figure out who)

Once again keith has completely turned my world upside down....... rightly so. I see your points.

Wouldn't it also make it more likely to get processor cache hits since you're increasing temporal locality by keeping the same drawing code mostly happening at once?

I use method a mostly because it makes state management and transparency ordering much simpler, but I also found that doing selection mode drawing is simplified, drawing collision bounds is simplified, and so on. You want to change the style of bounds drawn for editing? Just change it in one place and life is much easier. But another bonus is that it would make it easier to use a different graphics API since virtually all of my OpenGL calls are localized to there and the context setup code (not that I'd *want* to use a different API, but hey).

given Microsoft's apparent attitude to GL in Vista, you may not have a choice but to write Direct3D code if you want Windows support come 2007, so the ability to switch API is not as irrelevant as it might seem today.

I agree with Seth here... Curse you Keith, for making me rewrite so much.
(Jokes aside, there's an awful lot of hat-tipping here)

I'm with OSC on this - I find it's often useful to be able to run a game *without* a renderer (well more accurately, a renderer that doesn't actually draw anything). I always start with a "null" renderer that implements everything a real renderer would, then base drawable renderers on that class (OpenGL or otherwise). This lets you swap renderers at runtime with little work, and that's not just useful for things like OpenGL vs. D3D - E.g. you can implement multiple OpenGL renderers for different hardware targets, like fixed function vs. shaders, or for different effects like cell shading, hidden line, etc.

Doesn't A make for an extremely long render method in Scene if you have hundreds of different models objects to render?