How do I retrieve the 3D position of a fragment? I am just looking for the interpolated position between the three vertices of the triangle the fragment lies on. I am trying to darken a rendering pass along a plane, and thought it would be easier to just do the math instead of using a texture.
Originally posted by halo:
How do I retrieve the 3D position of a fragment? I am just looking for the interpolated position between the three vertices of the triangle the fragment lies on.
Inside the vertex shader write position of vertex into varying variable. The fragment shader will get its interpolated position from that varying.
I would have thought it already had a built-in varying vertex position.
Why would you think that?
Because it’s such a common thing to use.
What if you don’t use it? Then it’s just a wasted varying :-/
Just so you know, all the built-ins are listed in the spec.
as komat saiz
in vs use
varying vec3 pos;
pos = gl_Vertex.xyz;
Originally posted by Leghorn:
What if you don’t use it? Then it’s just a wasted varying :-/
This is the same as the gl_FragCoord or gl_FrontFacing varyings. When such varying is not used, it does not wast any hw resources. The only thing that might be “wasted” by don’t using it, is development time that would be necessary to implement such varying.
Because it’s such a common thing to use
Haven’t used it once. But I’ve seen some people using it for things that could be implemented cleaner ans faster without it.
gl_FragCoord is usefull for reflections, deferred shading and other fullscreen effects. As for gl_FrontFacing I’ve decided not to use it at all for now, since many people still have GPU’s that don’t support that in HW.
This is the same as the gl_FragCoord or gl_FrontFacing varyings.
Well, yes and no. Those are both post TnL quantities and are independent of the VS during compilation, I imagine. To recognize that a position varying is not used would require a link-time check, as opposed to a compile-time check, which could have performance implications.
And if you toss in a varying position, then you’ll have folks clamoring for normals and colors, then texcoords, then God knows what else.
I simply meant to reaffirm that there’s no need for the language to deal in application-specific use cases, even the “common” ones.
Is gl_FragCoord the fragment 3D position, or is it relative to the camera or something?
Why don’t you look for an answer in the specs and get it immediately instead of posting and waiting? 
Because the spec is 93 pages.
lol
Originally posted by halo:
Because the spec is 93 pages.
The specification has the never before seen next-gen features such as text searching (unless you have it in printed form, try search for FragCoord ) or table of content.
Woohaa! Do i need a next-gen console for those great features?!
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.