Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 5 of 5

Thread: OpenGL and OOD

  1. #1
    Junior Member Newbie Hannibal's Avatar
    Join Date
    Sep 2012
    Posts
    9

    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.

    Thanks in advance

  2. #2
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    498
    Quote Originally Posted by Hannibal View Post
    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.

  3. #3
    Junior Member Newbie Hannibal's Avatar
    Join Date
    Sep 2012
    Posts
    9
    Quote Originally Posted by GClements View Post
    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 ?

  4. #4
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,161
    Quote Originally Posted by Hannibal View Post
    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.

    Quote Originally Posted by Hannibal View Post
    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.

    Quote Originally Posted by Hannibal View Post
    The texture and the model objects are passed in as parameters of render.
    It depends on the applied architecture. Not necessarily. See above.

    Quote Originally Posted by Hannibal View Post
    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.

    Quote Originally Posted by Hannibal View Post
    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).

    Quote Originally Posted by Hannibal View Post
    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.

    Quote Originally Posted by Hannibal View Post
    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.

  5. #5
    Junior Member Newbie Hannibal's Avatar
    Join Date
    Sep 2012
    Posts
    9
    Quote Originally Posted by Aleksandar View Post
    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.


    Quote Originally Posted by Aleksandar View Post
    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.


    Quote Originally Posted by Aleksandar View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •