Object-Oriented OpenGL

Question

I have been using OpenGL for a while and have read a large number of tutorials. Aside from the fact that a lot of them still use the fixed pipeline, they usually throw all the initialisation, state changes and drawing in one source file. This is fine for the limited scope of a tutorial, but I’m having a hard time working out how to scale it up to a full game.

How do you split your usage of OpenGL across files? Conceptually, I can see the benefits of having, say, a rendering class that purely renders stuff to screen, but how would stuff like shaders and lights work? Should I have separate classes for things like lights and shaders?

Answer 1

I think OO OpenGL is not that necessary. It is different when you talk about shader, model, etc class.

Basically you would do game/engine initialization first (and other things). Then you would load textures, models and shaders to RAM (if needed) and Buffer Objects, and upload/compile shaders. After that, you, in your data structure or class of shader, model, have int IDs of shaders, model and texture buffer objects.

I think most engines have engine components and everyone of them has certain interfaces. All engines I have looked into have some component such as Renderer or SceneManager or both (depends on complexity of game/engine). Than you can have OpenGLRenderer class and/or DXRenderer which implement Renderer interface. Then if you have SceneManager and Renderer you can do some of the following things:

• Traverse SceneManager and send each object to Renderer for rendering
• Encapsulate upper case in some SceneManager method
• Send SceneManager to Renderer so it handles it

Renderer would probably call object's draw function which would call draw function of each mesh that is composed of and mesh would bind texture object, bind shader, call OpenGL draw function and then unuse shaders, texture and object data buffer objects.

NOTE: this is just example, you should study SceneManager in more detail and analyze your use case to see what is best implementation option

You would of course, have other components of engine, such as MemoryManager, ResourceLoader etc, which would take care of both video and RAM memory usage, so they could load/unload certain models/shaders/textures as needed. Concepts for this include memory caching, memory mapping etc etc. There are lot of details and concepts about each components.

Take a look at more detailed description of other game engines, there are a lot of them and their documentation is pretty much available.

But yes, classes make life easier; you should totally use them and remember about encapsulation, inheritance, interfaces, and more cool stuff.

Answer 2

OpenGL has some 'Object' concepts in it already.

For example anything with an id can be through of as an object (There are also things specifically named 'Objects'). Buffers, Textures, Vertex Buffer Objects, Vertex Array Objects, Frame Buffer Objects and so on. With a little work you can wrap classes around them. It also give you a easy way to fall back to old deprecated OpenGL functions if your context doesn't support the extensions. For example a VertexBufferObject could fall back to using glBegin(), glVertex3f(), and so on.

There are a few ways you might need to move away from the traditional OpenGL concepts, for example you probably want to store metadata about the buffers in the buffer objects. For example if the buffer stores vertices. What is the format of the vertices (ie position, normals, texcoords and so on). What primitives it uses (GL_TRIANGLES, GL_TRIANGLESTRIP, etc...), size information (how many floats are stored, how many triangles they represent, etc...). Just to make it easy to plug them into the draw arrays commands.

I recommend you look at OGLplus. It's C++ bindings for OpenGL.

Also glxx, that's only for extension loading though.

In addition to wrapping the OpenGL API, you should look at making a slightly higher level one build on top of it.

For example a material manager class that is responsible for all your shaders, loading and using them. Also it would be responsible for transferring properties to them. That way you can just call: materials.usePhong(); material.setTexture(sometexture); material.setColor(). This allows fore more flexibility since you can use newer things like shared uniform buffer objects to just have 1 big buffer containing all the properties your shaders use in 1 block but if its not supported you an fall back to uploading to each shader program. You can have 1 big monolithic shader and swap between different shader models using uniform routines if it's supported or you can fall back to using a bunch of different small shaders.

You can also look at expending on from the GLSL specs for writing your shader code. For example the #include would be incredibly useful and very easy to implement in your shader loading code (there is also an ARB extension for it). You can also generate your code on the fly based on what extensions are supported, for example use a shared uniform object or fall back to using normal uniforms.

Finally you will want a higher level rendering pipeline API that does things like scene graphs, special effects (blur, glow), things that require multiple rendering passes like shadows, lighting and such. And then on top of that a game API that has nothing to do with the graphics API but just deals with objects in a world.

Answer 3

In modern OpenGL you can almost totally seperate rendered object from each other, using different vaos and shader programs. And even the implementation of one object can be separated into many abstraction layers.

For example, if you want to implement a terrain, you could define a TerrainMesh whose constructor creates the vertices and indices for the terrain, and sets them into arraybuffers, and - if you give it an attribute position - it shaderplumbs your data. It should also know how to render it, and it should take care to revert all the context changes it has done to setup the rendering. This class itself should know nothing about the shader program that is going to render it, and nor should it know anything about any other objects in the scene. Above this class you could define a Terrain, which is aware of the shader code, and its job is to create the connection between the shader and TerrainMesh. This should mean getting attribute and uniform positions and loading in textures, and things like that. This class should not know anything about how the terrain is implemented, what LoD algorithm it uses, it is just responsible for shading the terrain. Above this, you could define the non-OpenGL functionality like behivour and collision-detection and such.

Coming to the point, even though OpenGL is designed to be used low-level, you can still build independent layers of abstraction, that let you scale up to apllications with a size of an Unreal game. But the number of layers you want / need really depends on the size of the application you want.

But don't lie to yourself about this size, don't try to mimic Unity's object model in a 10k line application, the result will be a complete disaster. Build the layers gradually, only increase the number of abstraction layers, when it's needed.

Answer 4

ioDoom3 is probably a great starting point, as you can kind of rely on Carmack to follow great coding practice. Also I believe he doesn't use megatexturing in Doom3, so it's relatively straight forward as a render pipe.