Is there any way to read back from server space vertices and fragments generated from vertex and fragment shaders back to client space?
Is there specific functions to do this or some method by which this is done?
And if so what is the function call or method to do this?
Yes.
You can read the vertex shader output with transform feedback.
You can read the fragment shader output with glReadPixels().
Related
I need to pass some variables directly from vertex shader to fragment shader but my pipeline also contains a TCS a TES and A GS that simply do passthrough stuff.
I already know that fragment shader expects to recieve values for its "in" variables from the last linked shader of the program, in my case the Geometry Shader, but I don't want to do MVP and normal calculations there.
How can I output a variable directly to the fragment shader from vertex shader? (skipping the rest of the shaders in the middle)
Is that even possible?
How can i output a variable directly to the fragment shader from vertex shader? (skipping the rest of the shaders in the middle)
You don't.
Each stage can only access values provided by the previous active stage in the pipeline. If you want to communicate from the VS to the FS, then every stage between them must shepherd those values through themselves. After all:
my pipeline also contains a TCS a TES
If you're doing tessellation, then how exactly could a VS directly communicate with an FS? The fragment shaders inputs are per-fragment values generated by doing rasterization on the primitive being rendered. But since tessellation is active, the primitives the VS is operating on don't exist anymore; only the post-tessellation primitives exist.
So if the VS's primitives are all gone, how do the tessellated primitives get values? For a vertex that didn't exist until the tessellator activated, from where would it get a vertex value to be rasterized and interpolated across the generated primitive?
The job of figuring that out is given to the TES. It will use the values output from the VS (sent through the TCS if present) and interpolate/generate them in accord with the tessellation interpolation scheme it is coded with. That is what the TES is for.
The GS is very much the same way. Geometry shaders can take one primitive and turn it into twenty. It can discard entire primitives. How could the VS possibly communicate vertex information to a fragment shader through a GS which may just drop that primitive on the floor or create 30 separate ones? Or convert triangles into lines?
So there's not even a conceptual way for the VS to provide values to the FS through other shader pipelines.
As far as I understand, the color of a pixel is determined by the fragment shader. Why do we need a vertex shader then? Is there anything a fragment shader cannot do (or cannot easily do) but a vertex shader can do (easily)?
But I still can't quite understand why it is named a "shader".
Because that's what programs executed as part of the rendering process are called. The Renderman interface specification was one of the first programmable rendering processes, and they called all of their programmable elements "shaders", even though they didn't all compute colors.
And therefore, "shader" has become the term used for describing any such program.
Vertex shaders convert vertex data, creating a 1:1 mapping from input vertices to output vertices. Fragment shaders operate on fragments. An FS invocation has no control over where it will be executed. They are generated in the location that the rasterizer says they go, and the FS has no way to affect this.
By contrast, a vertex shader has complete control over where the vertices will go.
is there any way I can query which primitive the current vertex belong inside a vertex shader? I'm using a TBO to output some data that I need to access inside a vertex shader, I can access this data inside the fragment shader using gl_PrimitiveID and it works fine but I can't find a way to do the same inside a vertex shader, gl_VertexID/3 won't work for me because I'm using glDrawElements.
thank you!
luiz
This is impossible if you understand how vertex shader invocations work.
While it is true that the vertex shader has to be evaluated for every vertex in a primitive, the transformed clip-space value will be stored in a post-transform cache. As a result, a vertex shared by 10 different triangles may only be computed once (subsequent primitives that use said vertex will hit the post-T&L cache first). There is no clear relationship between the primitive that caused the vertex to be computed and the vertex shader invocation.
The Geometry Shader stage, on the other hand, has gl_PrimitiveIDIn, which may help you - it is not clear what you are trying to accomplish.
I have got a texture which is updated from a fragment shader that calculates points positions.
What is the good way to read it back so it could be drawn as primitives ?
If you want to draw using the data from the texture, reading back to host memory is a waste and slow (But for reference you could use glGetTexImage or glReadPixels).
Instead, you can draw primitives without providing vertex positions and read them from your texture in the vertex shader (bound as a sampler and using texelFetch for example).
The coordinates for texel fetch can come from a per-vertex attribute (just like regular texture coordinates), or you can use gl_VertexID to calculate them implicitly.
As #ColonelThirtyTwo said, you can also use transform feedback. Not using your texture and doing the computation in the fragment shader, but replacing it with computation in a vertex shader. Here the varying variables normally interpolated to the fragment shader get packed and saved in a buffer, still on the GPU.
It is available as output variable in all shaders except fragment shader. So which shader stage must write it? Is its value taken from the last shader stage that wrote it?
Also please explan what is the purpose of having the value gl_ClipDistance in fragment shader?
As long as you only work with vertex and fragment shaders, you write it in the vertex shader. According to the GLSL spec, geometry and tessellation shaders can write it as well.
The fragment shader can read the value. Based on the way I read the documentation, it would give you the interpolated value of the clip distance for your fragment.
Considering it is really only useful for clipping... you need to write it in the last stage of vertex processing in your GLSL program. Currently there is only one stage that does not fall under the category of vertex processing, so whatever comes immediately before the fragment shader needs to output this.
If you are using a geometry shader, that would be where you write it. Now, generally in a situation like this you might also write it in the vertex shader that runs before the geometry shader, passing it through. You don't have to do anything like that, but that is typical. Since it is part of gl_PerVertex, it is designed to be passed through multiple vertex processing stages that way.
Name
gl_ClipDistance — provides a forward-compatible mechanism for vertex clipping
Description
[...]
The value of gl_ClipDistance (or the gl_ClipDistance member of the gl_out[] array, in the case of the tessellation control shader) is undefined after the vertex, tessellation control, and tessellation evaluation shading stages if the corresponding shader executable does not write to gl_ClipDistance.
If you do not write to it in the final vertex processing stage, then it becomes undefined immediately before clipping occurs.