OO and Opengl

[Gregg Bolinger]

This is not java specific but I thought some of you game developers might have some input here. Opengl seems very procedural to me. I've done a bit of dabbling with opengl and java via several wrappers but haven't built anything large. Same with opengl and C++ although it might as well be C. Which brings me to my discussion topic. How do you make opengl programming fit in with OO ideals and methodologies?

[Ernest Friedman-Hill]

I've seen threads on other boards where people have dicussed this very point. I think to a good approximation, the "scene graph API" concept is the object-oriented version. Remember that SGI invented GL (which begat OpenGL) and then invented Inventor (which begat OpenInventor, which begat (or perhaps adopted...) VRML) as an object-oriented layer on top of GL.

The scene-graph methodology breaks down as your object count goes up. If you're really drawing a million discrete lines, a scene graph implementation needs a million Java objects -- perhaps 20 million bytes -- just to represent them. If you're using a "procedural" API, it needs... 0 bytes. YOu just draw the lines. So I think both have their place. The kinds of apps I write always involve very large numbers of very simple objects, and scene-graphs are awful with that.

Now, another way to look at it is to compare, say, the jogl.GL interface to java.awt.Graphics2D. GL has more methods, but these two things are really very similar: they've both got a large number of essentially procedural drawing methods (drawLine() vs. glVertex()). For some reason nobody complains that Graphics2D isn't O-O. Maybe that's because the Graphics object itself represents a graphics context, while in Jogl the context is managed for you due to threading concerns. In some older APIs (and I'm thinking of GL4Java here) it was up to the programmer to manage the context, and chaos ensued. In a multithreaded environment, given that 99% of GL drivers are single-threaded, this is virtually impossible for the user to do, which is why Jogl does it for you. And remember that GL4Java itself was a second-generation GL mapping: there were many products and projects before that which did an even poorer job of managing context. The current crop of GL mappings has benefitted by learning from a lot of mistakes.

That sounded awful preachy. Just giving you my 2 cents!

[Gregg Bolinger]

I appreciate your 2 cents. And I know some of the horrors of gl4java. It was one of the first wrappers I used. As you know Ernest, I am not a huge fan of the Scenegraph. Well, not yet anyway, however I'd say that I am probably not experienced enough one way or another to deter someone else from using one. I know they have their place. I am just weird about wanting full control and I often question the scenegraph implmenetations performance. I think that jME and Xith are good for what they are. I am just usually not ready to invest in one.

That aside, let's say you are making a ship that flies around. My first thought would be to create my Ship data structure, basically a class that represents the ship and have this class implement some interface like, Renderable that has methods like draw(), and anything to do with opengl and that object. The open GL code in this might be a bunch of glVertex3f functions or it might load a model and display the mode. Obviously the class would have methods to keep poitioning, rotation, etc.

Then this ship object would be added to some sort of collection that is iterated over in the game loop and so each objects draw() method is called which updates everything.

But my gut is telling me this is a very bad approach. So keeping as simple as possible so using JOGL or LWJGL would you consider this bad design? If so, what would you change to make it better?

[Ernest Friedman-Hill]

I'd be interested to hear why this sounds bad to you. That's more or less how I like to do things.

[Gregg Bolinger]

Originally posted by Ernest Friedman-Hill:
I'd be interested to hear why this sounds bad to you. That's more or less how I like to do things.

It's too much in one class? Not enough seperation of logic and rendering? Those are my initial questions about that method.

[Aaron Roberts]

I'd have to agree with Ernest.

What's so bad about a nice clean basic OO design like you described? There are times when pure OO makes the most sense and when pure function based design does. Often, a mix of both makes for a nice approach.

If you're worrying about performance, don't. Performance metrics are best done once you have something to start with- IE rendering my 9 Million things is slow. (Tongue in cheeck example) Then you can baseline where you are and adjust things to improve.

Since you admitted you are not a lover of scenegraphs, but also that you've never used them to their extent, maybe you're trying to be more anti-scenegraph than is practical? In your example, you didn't mention anything about inheritance of the ship class from a drawable class or a moveable class. You also didn't talk about interfaces. It seems like you've take a reasonable approach to the problem you have at hand. It also seems more intuitively maintainable than going a purely lower level way.

My 3.5 cents.

Aaron R>

[Gregg Bolinger]

Originally posted by Aaron Roberts:
I'd have to agree with Ernest.

What's so bad about a nice clean basic OO design like you described? There are times when pure OO makes the most sense and when pure function based design does. Often, a mix of both makes for a nice approach.

If you're worrying about performance, don't. Performance metrics are best done once you have something to start with- IE rendering my 9 Million things is slow. (Tongue in cheeck example) Then you can baseline where you are and adjust things to improve.

Since you admitted you are not a lover of scenegraphs, but also that you've never used them to their extent, maybe you're trying to be more anti-scenegraph than is practical? In your example, you didn't mention anything about inheritance of the ship class from a drawable class or a moveable class. You also didn't talk about interfaces. It seems like you've take a reasonable approach to the problem you have at hand. It also seems more intuitively maintainable than going a purely lower level way.

My 3.5 cents.

Aaron R>

Thanks Aaron. Actually, I did talk about interfaces. Well, I said my ship class would implement an interface called something like Renderable that contained method declarations for draw(), etc. Maybe having a more generic class that ship inherits of which that implements the interface. I'll play around with some of these ideas and see how it goes.

As to the scenegraph, I think that right now me understanding more about opengl and 3D graphics in general is more important than deciding which scenegraph to use if any. So it's not that I'm anti-scenegraph but more like I am pro low level learning.

[Aaron Roberts]

Ooops! You did mention an interface. If thats the only thing super OO'ey (definite made up word-thingy there) thing you do, I still think it makes perfect sense.

I'm sure whichever way you end up implementing things will work well. If not, then you can come back and tell us 'I told you so!'

Cheers,
Aaron R>