I am just wandering if this is the same for any GL objects.
… How could it be? OpenGL object names are integers; how could OpenGL possibly know that a GLuint
variable holding an object fell off the bottom of the stack?
Not only that, they have explicit creation and destruction functions. Clearly, their lifetimes are not inherently associated with any sort of “scope”.
OpenGL object lifetimes are like the lifetimes of dynamic memory allocations in C++. Every new
needs a delete
. You can even wrap OpenGL objects in smart pointer-like constructs.
I have 2 C++ objects, one renders the sky, the other renders the water. The object that renders the water would like to use some texture from the sky class for rendering the reflections. Do I need to load those sky textures from the hard drive again or should the shader in the water class use use the one used by sky class?
This is the problem with over-object-oriented thinking. You limit yourself and how you think of problems.
There is no such thing as a “sky texture”. There is merely a texture, which contains some data. The objects that have to use it are the objects who should have some control over the lifetime of it. If you want your “sky” object and “water” object to use the same texture, then they need to access the same texture.
Indeed, you probably shouldn’t have a “sky object” or a “water object”. It sounds more like you have two renderable constructs, both of which use one or more programs, some buffers for vertex data and uniforms, and some textures. These objects sound almost identical in terms of their storage and behavior; the only thing that’s different is what programs, mesh data, and texture data they happen to use.
In traditional C/C++ sense, I would expect that I have to load it again
What you describe is not “traditional C/C++” in any sense. If for no other reason than that C doesn’t have classes or automatic lifetime of any kind. It has stack variables, but they don’t have constructors and destructors.
Furthermore, rendering happens in a loop. You wouldn’t be creating these sky and water objects within that loop. So if you created them on the stack, their scopes would have to extend across the whole of the loop.
Most applications of any real size have to do more than just rely on stack variables. You will need to use dynamic memory management techniques.
For example, for a Uniform block can be bind in one shader program
No, uniform buffers cannot be bound to shader programs at all. You associate a particular uniform block in a shader to a location in the context where a buffer is bound. The buffer object with the data is not directly associated with the shader.