I am a OpenGL newbie but an experienced C++ software developer. I am building a C++ object-oriented program and want to incorporate OpenGL/GLUT but as part of the object-oriented paradigm - i.e., I would like to wrap some basic OpenGL rendering within a C++ class object. Then call this class as an object (same as with other C++ classes).
Is this possible, and if so how? Nothing fancy at this point, I am just trying to learn - maybe a function in the OpenGL C++ class wrapper that will render a single triangle.
hi newbi,
We had hoped that you could tell us.
I’m a 100% hobby programmer, so don’t take this for more than it is.
I cannot give you more overview than what you probably would think of yourself: put all the variables in one base.class and inherit from it.
What’s up and down in this? Does the geometry have gl in it’s scoop, or was it the other way round? Dunno, I look at them as sort of a pair.
You may get away with a geometry-base-class containing
virtual void initiate()
virtual void update()
virtual void draw()
and substitute a lot of the gl-types (enum, buffer-identifiers etc) with uint32_t and thus work on this outside the realm of opengl and rely on conversions later on. Havn’t been there.
The problem is not the triangle, but the requested opaque square below that has got the focus of all your pc’s process-ressources.
I have made a fairly good baseclass for such a program. And, I’ve even used it a couple of times. But, over the years I’ve got to realize how far one can get with one fairly simple single object of this class making me question why I would really bother making it in the first place.
With your external work I suggest above, you’ll still have to erect classes that inherits within the scoop of gl.
I do use my class for one good reason. It seems lightweight to us a pointer to an instance as an argument of say void initiate( *glProg){…} or even, in larger conglomerates, give it as a member of the class itself.
Here is one bomb-shell from the class: I only use 2 type of uniforms (vec4 & mat4) and probably has typeId() as member of a small struct (to omit templatation) that also contains the location and a relevant variable. I can write to the variable without the need of a gl-program in scoop and then when calling draw() check if it needs to be updated now that the gl-program is active. Thus, you can hide the nitty-gritty that you keep forgetting the syntax of, pøjfækt.
I have all the glew/glfw-initiation done in main(), and the main-loop too. One of my first steps out of my comfort-zone was to add a .h/.cpp-set that #includes glfw a second time. This is where I erect the program-class. Other .h/.cpp sets can now #include the program.h
…
same goes for the other hardware-types like key(), click(), but, you’ve been there already.
Once you’ve been in opengl for a while, you’ll have a better sense of what you want to sweep under a class-carpet and happily never have to see again.