OpenGL OOP

I am just learning OpenGL under Linux.
Basically getting ready for my object recognition application - following a moving objects thru several cameras views .
I think to got the concept down working on single object.
Now I need to extend that to multiple objects and while researching that it become obvious that using OpenGL is basically build for single object.

So I look for OpenGL OOP “sample code”.
.
I did similar when I was learning basic OOP and found several article on OpenGL OOP - most of them rather discouraging and 100% Windows based .

I sort of understand that OOP involves “this” pointer which is unusable in "functions passing " concept, And that gets rather complex without very good understanding how to bypass “this” using static variables.

On the other hand I am not really sure if real OOP would be of any benefits when I am using “glut”.

Any advise would be appreciated before I get into this too deep.

Cheers

I strongly suggest avoiding OOP practices when dealing with OpenGL. It’s a poor fit for the way that video hardware works. So even if you can fit your code into an OO structure, performance will suffer.

example 1: http://ogldev.org/
this site is (in my opinion) very good in teaching the theory, but understanding the code flow is a completely other story (a huge f***fest, imho)

example 2: http://www.opengl-tutorial.org/
no OOP, but the code flow in at least clearly understandable

example 3: https://learnopengl.com/
no OOP, but the code flow in at least clearly understandable

if you look at a simple example of an application, there are 3 basic phases:

  1. Initializing (when app starts)
  2. running the Main Loop
    – 2.a) process input (execute commands etc)
    – 2.b) update stuff (react to input, time passing, etc)
    – 2.c) process output (draw graphics, audio, etc)
  3. CleanUp (when app terminates)

you could create a class “Graphics”

  1. could be done in the constructor (while GL context is available)
  2. could be done in the destructor (while GL context is available)
    2.c) could be done in a member function “Render(everything…)”
struct Scene {
// this describes your "world" [b][u]without[/u][/b] any visual information (like vertices etc)
};

class Graphics
{
public:

Graphics();
virtual ~Graphics();

void Render(const Scene& scene);

protected:

// stuff you need to draw the scene

};

here is another example:
https://www.khronos.org/opengl/wiki/Tutorial:_OpenGL_3.1_The_First_Triangle_(C%2B%2B/Win)#GLRenderer_Class

you can replace any windows-specific stuff with GLFW or SDL2 of SFML or whatever

You might provide a bit more detail on what usage(s) you’re thinking of as particularly bad.

When I first read your comment, it struck me as not true in general but possibly true with specific overly-fine-grained applications of OOP.

As a side-note, it has been proven (have no links right here) that a program written in C++ can even run more fast than a program doing the same thing written in C. Of course, this is not true for everything and it will depend a lot on the compiler, the library, the coding and so on.
But this is particularly true since C++ 11/14 where move-semantics and other templates now rule within the standard library. So this can avoid a lot of memory reallocations, copies and condition testings, thus offering a substantial gain in efficiency.

Just like for simple inheritance and polymorphism. At first glance there’s an overhead due to the vtable, but on the other hand, it can avoid a lot of condition testings (if this is this kind then do that, else do other thing…) in the code.

If the user feels comfortable with C++, java, C# or so, then why not. Having things clearly stated in encapsulated components help a lot to have a good visualization of the system, mostly when starting, compared to everything stuck in functions and defines from which no one could understand where and where not it should be used.

Just my 2 cents again…

Thanks for all the links.
I did find example 2 and was posting here , but could not post the link reference.
No biggie, but it also wiped out my post text so I given up on the post.
( I had to delete the quoted text to post this !)

I was basically interested in OOP because the samples from my OpenGL book always follow same flow, as you mentioned , and that would be IMHO good application of OOP.
My eventual goal is to use OpenCV , or other tool, to sort of copy from visual object to OpenGL for processing.

I guess my main reason of posting here is to find out what other tools are there.
Google does not always work when one really have no clue what to search for.

As far as tutorials go, I am aware it is a matter of personal preference, however, since there are so many - for example CodeProject site has handful, any advise is greatly appreciated.
Cheers

I’m not sure if this is helpful, but I have an OGL 4.5 OOP framework example on my website. It uses GLFW instead of GLUT and it’s a Visual Studio project for Windows. But there is little in it that is Windows specific. I came from DirectX and tried to divorce the code from Windows since my DX code was the opposite where it was tightly integrated with Windows. My plan was to eventually rewrite it and compile it on Linux, but I haven’t gotten around to that yet.

It’s written for game programming and it sounds like you might be doing more scientific or industrial application. So, I don’t know if it’s useful to you, but it is pretty heavily object oriented. I don’t claim to be any sort of expert, but it might at least give you some ideas. The entire Visual Studio project and all files are available for download and there’s a video clip of the code running to see what it does without having to take the time to compile it and such.

[QUOTE=Dark Photon;1285531]You might provide a bit more detail on what usage(s) you’re thinking of as particularly bad.

When I first read your comment, it struck me as not true in general but possibly true with specific overly-fine-grained applications of OOP.[/QUOTE]
I’m thinking foremost of modelling every world entity as a C++ object encapsulating its own data, then as an afterthought thinking about how to map that to attribute arrays and draw calls.

A secondary consideration is mapping OpenGL “objects” (buffers, textures, etc) to C++ objects which use the destructor for deletion … without any consideration as to whether the correct context is bound at destruction (or any other use, but it’s destruction that usually bites people).

Good words: So even if you can fit your code into an OO structure, performance will suffer.

s/will/may/. It’s about being smart about using it, and knowing how it’s going to map to the underlying machine code and memory. If you don’t know, you’re playing with fire.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.