OpenGL and OOD

Hello forum

I am a friend of OpenGL as well as object oriented programming.
Because of OpenGL's bind/use philosophy I find it complicated to find an OO-Approach.
Take for instance a shader class, a texture class and a model class.
The shader class has a method render. The texture and the model objects are passed in as parameters of render.
What do you do in the render method to bind the OpenGL texture (inside the texture object) and the VAO (inside the model object) ?
Do you just bind them every time render is called even if they are already bound.
Do you query what texture and VAO is currently bound and bind them only if needed.
If you practice one of the two approaches how much performance do you loose with unnecessary binds and query's ?
Do you store the status of all bound OpenGL object on application side so you can query them without bothering the driver?

I am sure that a lot of you have thought about that problem as well and I just want to here what approaches you have found / chosen.

I am sure that a lot of you have thought about that problem as well and I just want to here what approaches you have found / chosen.

I've found the "don't try to put a square peg in a round hole" philosophy works well.

Basically, OO and video hardware don't mix, so don't try to use OOP in the renderer. Or at least accept that when the two are in conflict, the OO philosophy has to give way, because the hardware won't.

I've found the "don't try to put a square peg in a round hole" philosophy works well.

Basically, OO and video hardware don't mix, so don't try to use OOP in the renderer. Or at least accept that when the two are in conflict, the OO philosophy has to give way, because the hardware won't.

How come that DirectX is fully object orientated if the hardware is to blame ?

Because of OpenGL's bind/use philosophy I find it complicated to find an OO-Approach.

You may use direct state access (DSA) if you find it more suitable for your purpose.

Originally Posted by Hannibal

Take for instance a shader class, a texture class and a model class.
The shader class has a method render.

That is very unusual architecture. Usually there is a class called Renderer (or so) that is responsible for the rendering. Shader should not and cannot be a renderer.

Originally Posted by Hannibal

The texture and the model objects are passed in as parameters of render.

It depends on the applied architecture. Not necessarily. See above.

Originally Posted by Hannibal

What do you do in the render method to bind the OpenGL texture (inside the texture object) and the VAO (inside the model object) ?

A renderer should have structures for storing textures and models. If textures are not shared between models, then models should "contain" textures.
In any case, these structures should provide optimal order of (binding and) drawing. Sorting by textures, shaders etc. is frequently used to minimize state changes.

Originally Posted by Hannibal

Do you just bind them every time render is called even if they are already bound.