Hi all,
I realised that the selection stack isnt accessible from shaders and im wondering why that is? The only solution I can think of is that the name stack is implemented on the software/driver side and not in HW; But the specification say that glPushName/glPopName are valid operations while creating a display list, and display lists (most of the time) get shoved into vram. So unless the driver filters the operations out and does some trickery with the selection matrix, why can’t I access them from shaders?
Yes, i could use uniforms; but grouping entire objects under 1 name would have been ideal…
Software processing or not, it should be accessible in shaders as its a property of an object. Whether its in SW or HW is an implementation detail IMHO.
Originally posted by DarkProphet:
Yes, i could use uniforms; but grouping entire objects under 1 name would have been ideal…
What keeps you from doing that? It’s just a matter of when you set the uniform. It’s at the same place where you would have loaded your name. If you need a stack for that, build your own.
Software processing or not, it should be accessible in shaders as its a property of an object. Whether its in SW or HW is an implementation detail IMHO.
Shaders work on vertices and fragments, not objects.
You expressed that you want more OpenGL state accessible inside the shader. So far for all state which is not, the answer was to put it into uniforms or attributes.
It’s not available in GLSL because you can archieve the same effect with uniforms and/or attributes.
It’s not entirely true that vertices and fragments belong to an object. Strictly speaking, there are no objects. You only have a “current” name on the name stack, and when something is rendered this name is recorded along with minimum and maximum z.
The current name stack content is just another GL state, nothing more, nothing less. There is no particular reason why this state should be made available in GLSL. Especially there is nothing that can be done with this functionality that can’t be done equally simple with uniforms.
It’s not available in GLSL because you can archieve the same effect with uniforms and/or attributes.
To be fair, you can achieve a lot of things with uniforms/attributes without any state mirroring in glslang. There’s no specific need to have light state, material state, or matrix state be mirrored in glslang; the user can do the mirroring on their own.
So I can’t say that this is a compelling argument against mirroring this name stack in glslang.
Mroe than likely, they just forgot about it. It’s not like you see extensions that deal with selection much. And since nobody would dare use shaders and selection at the same time, it became irrelevant.
I agree with Korval, just because it can be done through uniforms and/or attributes, doesn’t mean that it doesn’t need an official reserved keyword for it to indicate its a valid state available in GLSL.
Do you honestly think that “we forgot” is a valid excuse for not integrating this feature? From what I have understood, GLSL is meant to be able to access most things that are available to the fixed functionality pipe, but that doesnt’ seem to be the case.
Why wouldn’t anybody dare to use selection and shaders at the same time? I dont see a correlation…
Because OpenGL implementations normally don’t offer hardware accelerated selection and emulating vertex shader transformations to calculate the selection result doesn’t make it faster. Give it a try.
Even worse if the input geometry data is stored inside the video memory.
For most uses there are faster ways to do selection higher up in the scene representation.
Why wouldn’t anybody dare to use selection and shaders at the same time? I dont see a correlation…
The question is, what is the fastest solution for your app?
Nobody “forgot.” This isn’t even a close or arguable call.
The fixed-function state available to the GLSL is the state that GLSL subsumes. See section 7.5 of the language spec.
The GLSL vertex shader and fragment shader do not subsume selection. So you don’t get access to the bottom of the selection name stack. Just like you don’t get access to the display LIST_BASE. (Just an example of fixed-function state pulled out of a hat at random.)
Note - OpenGL ES 2.0 has a very elegant solution to what fixed-function state to provide to GLSL. It doesn’t provide any fixed-function state.
If you want a “selection name” accessable to your shader, you should send it as an attribute or uniform yourself.
Why wouldn’t anybody dare to use selection and shaders at the same time?
Because OpenGL selection, as a feature, is a bad idea. Using it at all is dubious, but doing so with shaders (and VBOs) is just not wise.
The fixed-function state available to the GLSL is the state that GLSL subsumes. See section 7.5 of the language spec.
We don’t need you and your wicked spec reading here. We’ll do just fine with wild speculation.
Originally posted by Korval: We don’t need you and your wicked spec reading here. We’ll do just fine with wild speculation.
That would be me and my wicked spec writing.
(7.3 & 7.4 of the spec, and a few other sections.)
