I have created my own C# binding for OpenGL and in doing so learned a lot about VAOs and VBOs, shaders and everything between them. Now I would like to create a game engine rendering with shader-based OpenGL. Now, I am a little bit confused on what would be the best way to abstract all those buffers and shaders to make them more easily usable. Some questions I have are:

What are the game development implications of treating the OpenGL concepts "VBO", "VAO" and "Shaders" as classes in my engine and how should they interact with each other?


closed as too broad by DMGregory, doppelgreener, Engineer, Philipp, wondra May 10 '17 at 21:35

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ This question looks too broad to me. It doesn't lay out a specific problem to solve so much as ask for collaborators in designing a whole API. In its current state, this question might not be a good fit for the StackExchange format. Consider editing the question to narrow it down to a single specific architectural decision you're considering (eg. "What are the game development implications of treating OpenGL concepts A B C as a single construct X in my engine?" — you can always ask other Qs later) or going to a discussion/chat forum if you want to debate approaches in a more open-ended fashion \$\endgroup\$ – DMGregory May 10 '17 at 15:28
  • \$\begingroup\$ @DMGregory I hope you dont mind that I used your comment to re-word my question a bit. Maybe this is more specific now :) \$\endgroup\$ – j8a2b0e7 May 10 '17 at 15:48
  • \$\begingroup\$ Well…define "best" or "should" ;) How a program should behave depends on the goals it sets out to achieve. There's likely no one right answer to how an engine "should" abstract OpenGL. It sounds like you haven't really sorted out what you want to know here, and you're hoping someone else with more experience will fill that in for you. That tends to lead to either no answers at all, or scattershot/meandering responses that don't really come together into a "solution" per se. Try to make this more concrete — what one problem do you need to solve, or what specific alternatives are you evaluating? \$\endgroup\$ – DMGregory May 10 '17 at 15:56
  • \$\begingroup\$ I would suggest don't - the OpenGL API is inherently procedural in nature (note that even D3D - despite using COM objects - is also a procedural API) and contains sufficient corner cases that you risk breaking things badly; putting OO on top of low-level GL objects is essentially trying to shoe-horn a paradigm they were never designed to be used with onto them. Instead you should create objects for mesh, material and other higher-level constructs which will then call the low-level API in a procedural manner. \$\endgroup\$ – Maximus Minimus May 10 '17 at 18:39

Browse other questions tagged or ask your own question.