PDA

View Full Version : OpenGL and OOD



Hannibal
10-14-2013, 02:29 AM
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.

Thanks in advance

GClements
10-14-2013, 06:13 AM
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.

Hannibal
10-14-2013, 08:15 AM
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 ?

Aleksandar
10-14-2013, 01:15 PM
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.


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.


The texture and the model objects are passed in as parameters of render.
It depends on the applied architecture. Not necessarily. See above.


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.


Do you just bind them every time render is called even if they are already bound.
Quite possible scenario. See above. Drawing ordering should minimize unnecessary calls. Also, drivers optimizations probably eliminate unnecessary calls (I have proved some of them on NV implementations).


Do you query what texture and VAO is currently bound and bind them only if needed.
Not likely. It will probably result in a lower performance, but it should be tested.


Do you store the status of all bound OpenGL object on application side so you can query them without bothering the driver? That is a very reasonable and frequently used approach. But drivers optimizations sometimes make it unnecessary. In any case there is no drawbacks of this approach except code complexity.

Hannibal
10-15-2013, 01:50 AM
You may use direct state access (DSA) if you find it more suitable for your purpose.
I am aware of that extension but rather stick to core.



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.
It was just an example to demonstrate my problem.
But I will think about implementing a Render-Class.



Also, drivers optimizations probably eliminate unnecessary calls (I have proved some of them on NV implementations).
That was my guess too.
Thanks for confirming it.
I guess I go back to this approach.