KhronosGroup / OpenGL-API

OpenGL and OpenGL ES API Issue Tracker
34 stars 5 forks source link

Clarification wanted: wide lines + gl_FragCoord #82

Closed kusma closed 2 years ago

kusma commented 3 years ago

The OpenGL 4.6 Core Profile specification, section 14.5.2.2 "Wide Lines" has the following wording (emphasis is mine):

The preferred method of attribute interpolation for a wide line is to generate the same attribute values for all fragments in the row or column described above, as if the adjusted line were used for interpolation and those values replicated to the other fragments, except for gl_FragCoord which is interpolated as usual.

It's a bit unclear what that last bit means exactly. What is "as usual" in this case?

I think it's pretty obvious what is meant with the X and Y components, which are well-defined. But the Z and W components aren't really well-defined for wide lines. The only two interpretations that kinda makes sense to me would be these two:

  1. "as usual" means "according to the formula in Basic Line Segment Rasterization"
  2. The sentence is only referring to the X and Y components.

Given that the sentence that immediately follows refers to the Basic Line Segment Rasterization explicitly, I somehow doubt that 1 is the right answer. It also seems unfortunate if implementations are expected to set up two different set of interpolation functions for the same primitive, and it seems beneficial to applications to be able to expect a single way of expanding line attributes over a single primitive.

So could we get a clarification here?

pdaniell-nv commented 3 years ago

Yeah that "as usual" is referring only to the XY components. ZW are treated like other attributes. We definitely need to clarify the spec, so thanks for pointing this out.

Do you know if the existing CTS is testing this? I know you've made other comments and changes on line related CTS so perhaps you know if this is covered.

kusma commented 3 years ago

My understanding is that the CTS only tests the preferred interpolation, and AFAICT it tests it consistent with the wording only applying to the X and Y components.

So, "covered" in this regard, yes. But also broken ;)