Features Missing?

Why isn’t there a GetSubTexImage for convenience? To only get a part (eg 1 Pixel) of a Texture, do I really have to create a Framebuffer, attach the texture and use glReadPixels?

Isn’t there a way to copy the state settings from one VAO into another (preferably even the default non-vao)? This would come in handy if only needing to change few settings.

There’s no way to copy state data from any object; why should VAO’s be special in this regard? The only objects you can copy are those that hold bulk data (textures and buffers), and even then, you can only copy the bulk data part, not the state data.

In any case, you set the state in that VAO. You can set it into a different one. Alternatively, you can use the state querying API to write such a copy function. There’s a reason why OpenGL has a query for every piece of state you set.

You can use glGetTexImage and extract the pixel you need.

As a general rule when reading back from the GPU it’s not the amount of data you read back that’s the bottleneck, it’s the required synchronization. This will be true in all but the most extreme cases. My own feeling is that if you need to read back a 1x1 texel from a texture then you’ve a bigger design problem and should be addressing that instead.

Your VAO question sounds like a micro-optimization. Presumably you have the code to create the original VAO you wish to copy from, so why not run it through that for your second VAO?

The thing is I’m not sure it will be a readback from the GPU and I do not see how this would be different from the framebuffer-procedure.

VAO: I would have original code to create a VAO if it would have made sense to create one…

VAO: I would have original code to create a VAO if it would have made sense to create one…

Now you’re not making sense. If you don’t have the code to create a VAO… how do you have one to copy? OpenGL objects do not materialize out of nothing; your code must create it.

And even if a VAO did appear ex nihilo, that doesn’t change the fact that you can still copy one using the query API.

Har, har, har! Why would I write code to put the Pointer-calls into a vao if I knew that I’ll have to Change a small number of pointers otherwards.
Right now, I have an object that sets the unmodified pointers up properly (which is not alltoo complicated but not near a noop either) which gets processed by another object that applies transformations to some of the vertices’ attributes, rebinding the transformed attributes’ buffers/pointers as needed.
So I know that the pointers set up by the first object will always be the same but some of them will get modified afterwards.
It would make sense to create a VAO if I could copy it - as I cannot copy, it makes no sense, as it makes no sense, there is none.
QED

PS: Actually the code to create and use the VAO is already there but does not get called if a transformation is to be applied.

Right now, I have an object that sets the unmodified pointers up properly (which is not alltoo complicated but not near a noop either) which gets processed by another object that applies transformations to some of the vertices’ attributes, rebinding the transformed attributes’ buffers/pointers as needed.
So I know that the pointers set up by the first object will always be the same but some of them will get modified afterwards.
It would make sense to create a VAO if I could copy it - as I cannot copy, it makes no sense, as it makes no sense, there is none.
QED

So, you have some function A, which will set up some state within a VAO (either one you pass in or one it creates). And you have some function B, which you may or may not call on a VAO from A, that modifies some state in the VAO.

But you have a problem when you need multiple of the VAO’s from A, that have different forms of function B applied to them. And the only solution to this problem that you can see… is to copy the VAO? It never occurred to you to just create a new VAO and use A on it, thus giving you an exact duplicate copy of the first VAO from A?

QED is used at the end of a mathematical proof. You may have proven something, but I don’t think it’s what you intended.

Allow me to explain what I think your problem is (because otherwise, I must assume that you don’t realize that calling the same function twice will result in creating two identical objects, therefore having the effect of copying it).

Right now, I have an object that sets up a VAO. However, I will sometimes pass this VAO to another function that will modify the buffer bindings. But glVertexAttribPointer doesn’t just modify the buffer bindings; it also potentially changes the format. Therefore, that other function needs to know what the format data for a particular attribute is to be able to leave it unmodified. Which means I need to have pieces of the original function in the modified function.

If this is an accurate description of your problem, then I see two issues.

First, I don’t see how the ability to copy a VAO would help in any way, shape, or form. Your glVertexAttribPointer call will still need to know the format information either way.

Second, we can already do this. Or at least, “we” meaning NVIDIA; AMD is dragging their feet on 4.3 stuff.

Right - that did not come to my mind as this would move managing the VAO to some piece of source code that does not have anything to do with OpenGL. This would fall into the scope of the first or second object. As the first can be ruled out for doing so as it is the one that contains the not-to-be-modified data the second should do this. But wait - this one cannot contain per-instance-data - this has to be stored elsewhere. So another Abstract object - the per-intance-data needed - will have to be declared that can be stored in the entity calling both. This means one interface and N implementations of it. And this alledgedly is to be compared to a { vao[dest]=vao[src]; }.
I’ve to say I’m not really interested in what one can do already. I’m interested in what can be done under certain restrictions. And then you’re right to say that mentioning this feature missing now won’t help at all - which doesn’t make things better. Given the likely fact that this is not a very common use-case.

PS: Besides the implementation-afford this wouldn’t work either as the function B Needs the untransformed form of A everytime it is called.

You’re right, Alfonse, as everytime: The description is not accurate.
I have a function A whose postconditions are: Everything(attrib-pointers) is set up in a way that a Rendering-call like drawArrays will draw object1’s untransformed vertices.
Function B is an intermediate step that where preconditions=A’s postconditions and postconditions: a draw-call like drawArrays will draw the transformed Vertices.
Function C is a function that does a draw-call.

The flow in the piece of code is A - (maybe B) - C

This is where copying Comes in: Function B Needs to modify the pointers of the attributes it transforms. This could be done by a CopyVao and changing the pointers. The copy would ensure that Setting pointers will not destroy A’s vao with the untransformed vertex-attribute-pointers.

Then you seem to have written yourself into a corner. This happens all the time in programming. And the solution is simple:

Write yourself out of it.

You don’t need derived classes and such; simply change how your code works with these objects. You haven’t explained what it is you’re trying to do very well, or how different pieces of code inter-relate, so it’s pretty much impossible to offer anything specific to help.

Just simplify your handling of mesh code, instead of using this overcomplicated thing that for some reason wants to rely on “copying” VAO data. I see no reason why two meshes with the same vertex format need to communicate with each other to have the same vertex format. Indeed, I see little reason why two meshes should need to talk to each other. If you want meshes to share VAOs, then there should be some third vertex format handler or vertex format data type that they talk to which provides the VAO that they share. Thus both objects reference the same VAO.

In short, if you have created a scenario where this is necessary, then uncreate that scenario. It’s your code; you tied it into a knot, so untie it already. Your code does not have to work this way.

Or, as I’ve said before, just copy the VAO. OpenGL provides you all of the means needed to be able to implement glCopyVertexArray. Which is why OpenGL need not provide such a function. So if that would solve your “problem”, then do that already.

You have two means to write yourself out of this corner without any modifications to OpenGL. Pick one.

Copying the vao likely isn’t much less fiddling than setting everything up without.
Dunno if my code could/should work another way. It’s pretty much straight Forward:
There is a vertex-buffer which contains mesh data (this is a global-const - not per model-instance thing). This is function A.
There is function B which uses shaders to do mesh-animations. B renders from the pointers currently bound into textures, which get copied into buffers, the pointers to animated attributes get bound to those buffers.
C just takes whatever is bound as attributes and renders changing only the surface-settings(meaning program, textures and so on) to the one used by the triangle-range(s) emitted.

The function calling A, B and C checks if programs to be selected for rendering by C do mesh-animations themselves which may or may not cancel out the Need to call B.

Having written that: I do not really see the Need to Change the code at all. It would just have been a lot more elegant from the programmer-perspective with a copyVao as A needs to do a for(i=0;i<16;++i) loop everytime it sets up it’s pointers. Not that this would matter performance-wise when compared to the stuff done when rendering just 1 triangle… :wink:

Can you confirm - when you’re talking about the “transformed” and “untransformed” versions of your data - are you transforming on the CPU? And if so, why?

I’m only transforming on the CPU if necessary - meaning if there is no SL-Support or the max. number of draw-buffers is too small. But that is a whole other story…
Otherwise transforms are done by shaders as scatched above.