Higher C++ interface for OpenGL

[thAAAnos]

I'm thinking on creating a basic but higher interface for OpenGl in C++. The main idea is
to handle the OpenGL context and calls as
a stream, so one could write something like
gl::rc << gl::begin(gl::POINTS)
<< p << q << gl::end;
where say p,q points that overload the
<< operator

My question is if any of you knows there is something like that already (and is open source) ?

[3k0j]

foo(bar, x, y, z);

hmmm..., we need something higher...

bar->foo(x, y, z);

Good! But we can get higher than that..

fubar << foo(bar, x, y, z);

Great!! But why stop now? Let's go even HIGHER!!

fubar << foo << bar << x << y << z;

AWESOME!!!!!
Now that's a higher C++ interface for OpenGL \o/ !!



[This message has been edited by 3k0j (edited 12-19-2003).]

[thAAAnos]

Ok my example is lame, but if I had worked
all the details out, I wouldn't need to post
right?
Something like...

template< typename T, class Stream >
somedrawfunc(Stream out)
{
  ...
  Container< Point<T> > &amp;points;
  out << "Here are the points" << points;
  ...
}
and then something like
gl::RCstream<DC> rc(dc);
gl: [img]http://www.opengl.org/discussion_boards/ubb/biggrin.gif[/img]Lstream< RCstream<DC> > list(rc);
gl::CSstream< RCstream<DC> > clien(rc);
...
somedrawfunc< float >(rc);
somedrawfunc< double >(list);
somedrawfunc< mpz_class >(clien);
somedrawfunc< int >( std::cout );
somedrawfunc< int >( std::fstream("point.bmp"));

and yes << could be syntactic sugar but it
makes more sense to me at least like that...

[Won]

I'm working on something similar. I'm calling it "Ozone".

Object-Oriented OpenGL -> O^3 -> Ozone.
If I get permission from the employer, I'd like to open source it.

You might want to check out XEngine, too.

-Won

[Tom Nuydens]

But... why?!?

Isn't your energy better spent writing useful and cool applications with the existing C interface, rather than trying to write ugly and contrived C++ wrappers that no sane person will want to use?

-- Tom

[Won]

This is a good point. It is very difficult to write a C++ wrapper that doesn't somehow sacrifice performance or readability.

So what's the point?

First of all, I DO plan on using my own wrapper, otherwise why would I bother?

Second, to say that it is merely a "contrivance" tacitly denies the possibility that a wrapper can improve productivity/code legibility etc. Quite the presumption. There are many benefits to having that extra layer of indirection.

Third, immediate mode is something of an abomination, anyway. I wouldn't really bother too much wrapping that in C++; it would be more for the object-oriented aspects of OpenGL that are crippled with a C-like interface.

Obviously, the wrapper won't be as familiar as straight-up OpenGL code, but I'm hoping the advantages will outweigh this disadvantage enough that someone besides the authors will use it.

-Won

[cass]

In general, the only place I've found an OO wrapper useful in OpenGL is for managing the lifespan of "objects". Specifically texture objects, display lists, and program objects.

And with those, I would probably do it differently today than I did then.

The class of code that I have found very useful to keep is for doing things that OpenGL doesn't do for you, like linear algebra and object interaction. It would be really great if OpenGL included more support in this arena (via a major GLU update or another *standard* companion library). OpenGL does not compete well with D3D in this regard, and it is a barrier to entry for OpenGL developers.

Thanks -
Cass

[Korval]

Something like...

Well, that has to be the worst interface for drawing triangles imaginable. Not only does it put horrific overhead in a performance-critical section of code, it reduces the readability of that section of code by an order-of-magnitude. Additionally, it continues the poor C++ paradigm of overloading the bitshift operator for non-bitshift tasks.

Second, to say that it is merely a "contrivance" tacitly denies the possibility that a wrapper can improve productivity/code legibility etc. Quite the presumption. There are many benefits to having that extra layer of indirection.

Such as? Besides slowing down performance-critical sections of code?

Third, immediate mode is something of an abomination, anyway. I wouldn't really bother too much wrapping that in C++; it would be more for the object-oriented aspects of OpenGL that are crippled with a C-like interface.

You don't have the ability to "un-cripple" them. The way to uncripple them would be to have functions that, effectively, took an object as a parameter. However, the OpenGL interface doesn't take the object as a parameter, so you have to keep re-binding the object each time you want to call a function. I don't know what kind of penalty object binding costs, but I can't imagine that it is cheap in all cases. At which point, once again, you're dropping performance in performance-critical sections of code.

[This message has been edited by Korval (edited 12-19-2003).]

[Tom Nuydens]

Just to make myself clear: I think that putting a thin C++ wrapper around the GL is a complete waste of time. Especially if it looks as ugly as what you're proposing.

But I'm not at all opposed to the idea of having, say, a reusable texture class. You could add in some functionality to load images from disk, or you could have separate classes for disk-based textures and dynamically rendered textures, and share some code between them through inheritance. Similarly, encapsulating shaders or vertex arrays in classes might facilitate writing multiple code paths for different HW. Nobody will argue with you if you do any of this. I wouldn't call this a "C++ interface for OpenGL" or a "wrapper" anymore though.

-- Tom

[JanHH]

I think that the fact that OpenGL is an absolutely not object oriented state machine thing is a pain a lot of times, when you are trying to write a rather large application with a neat class structure that uses OpenGL. Keeping track of "which objects need which OpenGL states in which condition and where are all these states at the moment one certain object is called to render itself" is a chaos, again and again. So a clear object oriented solution to this would be a good thing (and again, it would not have to wrap time critical code pars like the stuff that happens between glBegin() and glEnd() ), but also probably impossible when not using something like a scene graph.