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.

Komat

01-04-2007, 12:11 PM

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.

halo

01-04-2007, 03:18 PM

I would have thought it already had a built-in varying vertex position.

Brolingstanz

01-04-2007, 05:19 PM

Why would you think that?

halo

01-04-2007, 06:21 PM

Because it's such a common thing to use.

Brolingstanz

01-04-2007, 06:42 PM

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.

zed

01-04-2007, 11:21 PM

as komat saiz
in vs use
varying vec3 pos;
pos = gl_Vertex.xyz;

Komat

01-04-2007, 11:21 PM

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.

k_szczech

01-04-2007, 11:41 PM

Because it's such a common thing to useHaven'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.

Brolingstanz

01-05-2007, 02:45 AM

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.

halo

01-05-2007, 03:38 PM

Is gl_FragCoord the fragment 3D position, or is it relative to the camera or something?

k_szczech

01-06-2007, 02:39 AM

Why don't you look for an answer in the specs and get it immediately instead of posting and waiting? :)

halo

01-07-2007, 01:14 AM

Because the spec is 93 pages.

jide

01-07-2007, 03:37 AM

lol

Komat

01-07-2007, 05:41 AM

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.