OpenGL Style In OO Land

Member
Posts: 208
Joined: 2005.04
Post: #1
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?
Quote this message in a reply
⌘-R in Chief
Posts: 1,254
Joined: 2002.05
Post: #2
Definitely b.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
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.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #4
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?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
no, model objects should never call glVertex3f.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #6
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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
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.
Quote this message in a reply
Member
Posts: 196
Joined: 2003.10
Post: #8
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?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #9
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)
Quote this message in a reply
⌘-R in Chief
Posts: 1,254
Joined: 2002.05
Post: #10
Once again keith has completely turned my world upside down....... rightly so. I see your points.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #11
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).
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #12
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.
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #13
I agree with Seth here... Curse you Keith, for making me rewrite so much. Wink
(Jokes aside, there's an awful lot of hat-tipping here)
Quote this message in a reply
Member
Posts: 446
Joined: 2002.09
Post: #14
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.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #15
Doesn't A make for an extremely long render method in Scene if you have hundreds of different models objects to render?
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  old style engine and other stuff stuepfnick 3 2,570 Feb 15, 2003 09:08 PM
Last Post: henryj