kRogue

04-01-2013, 07:32 AM

This suggestion is relatively straight forward: expose in a useful way the barycentric coordinates of a fragment. I propose the following details:

a built in vec3 giving those coordinates (s0, s1, s2) defined in the fragment shader

a mechanism to fetch the values of an input of the fragment shader for each vertex of a triangle. One possible method is to defined a function U(x, I) where x is the name of an input into a fragment shader and I is 0, 1 or 2 signifying which vertex of the triangle to grab

Before anyone jumps up and down and says one can get this via a geometry shader, I'd like to point out that such a system would be terribly inefficient since to do (2) above would induce a heck of a lot more in's to the fragment shader and doing (1) also induces an extra in. On a related note, I also have this suggestion in mind for OpenGL ES [the GLES message boards are kind of barren really, the last message being posted in last July].

Naturally this jazz above needs some additional tweaks to handle point and line rasterization (I suggest that s2 is made 0 for line rasterization and that U(x, 2) is an implementation dependend undefined value).

The mentality of this suggestion is that those numbers are likely sitting around anyways (at the very least the values of (2) are around, though the barycentric coordinates of a primitive may or may not be explicitly calculated).

a built in vec3 giving those coordinates (s0, s1, s2) defined in the fragment shader

a mechanism to fetch the values of an input of the fragment shader for each vertex of a triangle. One possible method is to defined a function U(x, I) where x is the name of an input into a fragment shader and I is 0, 1 or 2 signifying which vertex of the triangle to grab

Before anyone jumps up and down and says one can get this via a geometry shader, I'd like to point out that such a system would be terribly inefficient since to do (2) above would induce a heck of a lot more in's to the fragment shader and doing (1) also induces an extra in. On a related note, I also have this suggestion in mind for OpenGL ES [the GLES message boards are kind of barren really, the last message being posted in last July].

Naturally this jazz above needs some additional tweaks to handle point and line rasterization (I suggest that s2 is made 0 for line rasterization and that U(x, 2) is an implementation dependend undefined value).

The mentality of this suggestion is that those numbers are likely sitting around anyways (at the very least the values of (2) are around, though the barycentric coordinates of a primitive may or may not be explicitly calculated).