so where's all this going? (OpenGL)
just would like to hear some of the views on where OpenGL is heading. no sooner than we had celebrated the release of the 2.0 standard, the "Great Vista Freakout of 05" hit and all our thunder was stolen in the face of "50% slower" quotes from slashdot twerps.
now that things have settled down, and the cooler heads are pointing towards MS's history of offering lackluster support, i feel a deeper rumbling.
while C++ will be around for quite some time, i feel C is moving towards the lowel levels that were once reserved for assembly (look at shaders).
the thing is that OpenGL is low level, and C style. it is not object oriented. the new languages (Java, C#, VB.NET) don't work comfortably with it.
unlike python, and even VB 6.0, there is no direct support for these. secondary wrapper libraries are the best that Java and C# can offer. whereas the .NET languages get a shiny new wrapper for Direct3D.
this may seem like a small issue, but in the professional world where support for libraries used in a product come into play when picking technologies, it may mean everything. in fact, it has been OpenGL's bread and butter for many years.
i am biased to liking OpenGL, and could care less about moving to .NET. i do however wonder if its on the sturdy ground it has been on. can it survive while OO langauges lack support? if so, will c++ be enough to keep it going? is a GDI+ or STL type standard unthinkable?
You realize it isn't all that difficult to make a OO wrapper around OpenGL, right? Anyway, OpenGL also has literally no competition for hardware-accelerated 3D cross-platform development, so it'll probably stay around for a while there.
Quote:Original post by Roboguy
You realize it isn't all that difficult to make a OO wrapper around OpenGL, right? Anyway, OpenGL also has literally no competition for hardware-accelerated 3D cross-platform development, so it'll probably stay around for a while there.
no, that one blew past me. but seriously, i mean a standard wrapper. are we ever going beyond a C style standard and if not will it cost OpenGL?
personally, i think the rigid use of OO in Java (and others) is plain silly. there are things were OO makes sense, but others don't really fit the paradigm and things only become more complicated by forcing it's use. i think opengl should stick with the C-style api, even if only for compatibility reasons. maybe an aditional standardized wrapper, but that might be hard to define due to differences between languages. besides, as Roboguy said, writing a wrapper isn't that difficult, and there already are wrappers for the languages you mentioned. (albeit not standardized)
In any serious project there will be at least one level of abstraction between the graphics API calls and scene management, so there's no real need for a natively OO design. Frankly, in my experience it's a little easier to wrap OpenGL into an OO framework than it is to wrap D3D into an OO framework since you don't have to worry about keeping COM's reference counts happy. But that's a minor difference; this whole thing is pretty much a non-issue.
It doesn't really make much sense to abstract something as low level as a 3D API into some object structure or hierarchy. Sure, an object oriented resource manager (for texture, shaders, etc) is useful, but many will argue that this is the job of the engine, and not of the API. Yeah, OpenGL is low level, but so is D3D. That's the very nature of the thin layer between GPU and application that current 3D APIs are.
If we're talking about graphics engines, then things look very different. A heavily object oriented approach is a good choice on that level, and perfectly well suited for such an application. But it really doesn't matter whether the underlaying API is OOP or not, since its calls are going to be deeply buried into the engine internals anyway.
OOP is great for high level abstraction. But on a 3D API, it's just semantics without any real advantage or drawback. It really doesn't matter.
Edit: well, Sneftel was faster :)
If we're talking about graphics engines, then things look very different. A heavily object oriented approach is a good choice on that level, and perfectly well suited for such an application. But it really doesn't matter whether the underlaying API is OOP or not, since its calls are going to be deeply buried into the engine internals anyway.
OOP is great for high level abstraction. But on a 3D API, it's just semantics without any real advantage or drawback. It really doesn't matter.
Edit: well, Sneftel was faster :)
I agree with the mods, but on the other hand it would be nice to have some standardized OO management stuff in an add-on library rather than everyone having to roll their own and worrying about bugs / supporting anyone else who may end up using it.
That said, I doubt the OpenGL ARB will take it upon themselves to begin such an undertaking. In the world of OSS, things like that are generally accomplished by an individual or group beginning a project, this project reaches maturity and gains popularity, and then finally (if its deemed worthy) is addopted by the 'parent' project or otherwise officially/unnofficially recognized.
If you want to see this, find some like-minded and intelegent people to get together and start it yourself.
That said, I doubt the OpenGL ARB will take it upon themselves to begin such an undertaking. In the world of OSS, things like that are generally accomplished by an individual or group beginning a project, this project reaches maturity and gains popularity, and then finally (if its deemed worthy) is addopted by the 'parent' project or otherwise officially/unnofficially recognized.
If you want to see this, find some like-minded and intelegent people to get together and start it yourself.
Quote:Original post by Ravyne
I agree with the mods, but on the other hand it would be nice to have some standardized OO management stuff in an add-on library rather than everyone having to roll their own and worrying about bugs / supporting anyone else who may end up using it.
I would not like to see that I really like having a "thin" layer to interface with the graphics card. This allows the fastest results and leaves the OO design in the hands of programmer. After years of designing my own management, I would feel really restricted moving to a force OO design of some one else’s planning.
OpenGL is fine, and going to stay.
Quote:Original post by skowQuote:Original post by Ravyne
I agree with the mods, but on the other hand it would be nice to have some standardized OO management stuff in an add-on library rather than everyone having to roll their own and worrying about bugs / supporting anyone else who may end up using it.
I would not like to see that I really like having a "thin" layer to interface with the graphics card. This allows the fastest results and leaves the OO design in the hands of programmer. After years of designing my own management, I would feel really restricted moving to a force OO design of some one else’s planning.
OpenGL is fine, and going to stay.
Thats why I said an "add on" library, similar to GLUT or GLX, "official", standardized, but not strictly necessary. Something that people can learn and use if they don't want to be bothered writting their own to get things up more quickly.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement