Object-Oriented OpenGL

[ethorteran]

This would be more of an OpenGL 2 or an opensource project by freelance programmers:

I recently fell in love with Cocoa, a great programming language for MacOS X. It is extremely compact code, excellent workflow, easy to write for, etc. My idea for OpenGL 2 or 1.3 or whatever the next version is, is to have stuff stored in objects (for like Objective C or C++ or Objective C++) so instead of making hard-to-get-the-hang-of calls to texture stuff, you would call something like:

TheTexObject = [OGTexObject readFromFile:"FileName"];

[theModel applyTexture:TheTexObject toArea:...

bla bla bla

Yes, I know this would radically change the way OpenGL is written, but I think it would definately be for the better. This way, only one person would have to write file IO for textures, only one person (or group) would have to write highly optimized code for rendinging models. Thus keeping everybody from doing redundant work on the same basic things.

Erik

BTW, the code above is my favorite language, Objective C. The '[' and ']' are basically telling theModel to execute the function "applyTexture". Just thought you should know...

[This message has been edited by ethorteran (edited 09-04-2001).]

[MikeC]

Sigh. It must be all of five minutes since the last "rewrite OpenGL in $MY_FAVOURITE_LANGUAGE" suggestion...

There's a reason OpenGL is fundamentally a C API. In fact there are several reasons.

1. C imposes a minimal abstraction penalty on performance. GL apps typically want to run as fast as possible. This is important. Abstraction is downright dangerous if it prevents you from understanding what's going on. If you don't care so much about performance and want ease of use, fine, write a wrapper. It's a great exercise. If you don't want, pick one of the zillion OpenGL wrapper libraries floating around on the Web.

2. C is available on just about every computing platform in the known universe. C compilers are ubiquitous, stable, compliant and often free.

3. C is THE language for libraries, because almost every other language can be persuaded to bind to C interfaces, and the ABI is standardized on all platforms that I know of. The reverse is typically not true.

Don't get me wrong, I'm not a wild C zealot. I can't think of any application I'd want to write in C rather than C++. I agree that OpenGL would benefit from more "objectifying" - vertex array objects and state objects in particular. But IMHO there are NO good arguments for abandoning C for the basic interface.

[V--man]

How true. There is one post about making opengl COM based even.

But basically everyone wants something that will suit their particular need or taste. OpenGL came into existance in C, with extension mechanism and so on. If you want something else, then I'm sorry to tell you this but opengl is not for you. OOP solutions already exist and if you want COM, use D3D.

IMO, this place is for suggesting new graphics technics, new extensions for opengl that will advance opengl in terms of generating 3D graphics.

V-man

[ethorteran]

I actually don't care in what language this level of abstraction should be done. However, objectification of certain things would be extremely helpful in programming, namely Textures, as I read (and am reading) the Red Book, it seems you have to re-define the texture, every time you use a different one, and switch back. Maybe you could put them in display lists...

Anyhoo, it was the objectification that I was aiming at, not rewriting it in $MY_FAVORITE_LANGUAGE (I dabbled in TCL a little!).

Erik

[This message has been edited by ethorteran (edited 09-04-2001).]

[MikeC]

Um, textures are already "objectified", that's what texture objects are for. You're not reading an OpenGL1.0 Red Book, are you? Recent ARB meeting notes have mentioned similar "objectification" for vertex arrays; I was disappointed these didn't make it into 1.3.

My point 1 is that it's abstraction itself which is bad, irrespective of the language, for a fundamental API. A huge number of techniques have been implemented in OpenGL which were *never* imagined by the designers of the API. You *cannot* get that level of flexibility with an abstract API. I've seen the OpenGL command set described as a graphical assembly language. I think that's a good description, and I think that's what it should be. (It's certainly what the next-gen paradigms for vertex and pixel programs are looking like.)

Low-level APIs are always more flexible and no less efficient than high-level ones. You can always turn a low-level API into a high-level one by wrapping it. You can't turn a high-level API into a low-level one.

[ethorteran]

This is why Cocoa (High Level Wrapper For Carbon) is such a good example, in Cocoa code, if something is not implemented, you can just have Carbon (or in this case, straight OpenGL) code to fill that gap.

Erik

[Sansus]

Object Oriented OpenGL ?? Do you want another Direct 3D!!???

OpenGL is right now, clean and simple.

[john]

Hello,

do you even know what object oriented means?

OGL is essentially object oriented already. You have an opengl context == the object, and you access it via member functions. do you ever get direct access to the frame buffer? no; its private. (but, then, you can't inherit contexts and so on, but... that isn't a necessary condition for the defn of an obj).

in a very real sense, ogl is already objectified.

cheers,
John