POINT clipping inconsistent across OpenGL implementations

[MarkCallow]

The OpenGL 4.6 specification says, w.r.t point clipping:

If the primitive under consideration is a point, then clipping passes it unchanged if it lies within the clip volume; otherwise, it is discarded.

This gives non-pop-free clipping. It has been reported that there are many implementations that have pop-free clipping. If it is intended to allow this, the specification should be updated to explicitly allow it. If not, the CTS should be fixed to fail implementations with pop-free clipping.

Note that OpenGL ES has had pop-free clipping since 2.0 and everyone seems agreed this is the preferable way to handle point clipping. So I'm guessing it is being implicitly allowed in OpenGL implementations.

The ARB_ES*_compatibility specifications do not point out this difference in behavior between OpenGL and OpenGL ES. They should. Adding a note to these specs should wait until the main issue is resolved so the notes can reflect the reality.

[pdaniell-nv]

This issue has been discussed on and off for years. For those with access, you can see a discussion here: https://www.khronos.org/members/login/bugzilla/show_bug.cgi?id=10698.

I think updating this language was considered for OpenGL, but it never got done. I agree the spec should allow pop-free clipping, since that would be a more desirable behavior, but not all hardware can do it. Given the history, I don't think we can mandate one way or the other.

Vulkan also discussed this same issue and as part of VK_KHR_maintenance2 added a new VkPhysicalDevicePointClippingProperties property so the implementation could advertise whether it was clipping points to the viewport volume or not.

[MarkCallow]

This issue has been discussed on and off for years.

The linked issue is for OpenGL ES and mostly about rasterizing fragments outside the viewport rather than vertex-level clipping which is consistent across OpenGL ES implementations. It was never resolved.

WRT vertex-level clipping, I think the OpenGL spec. should be changed to reflect that both pop-ful and pop-free are allowed. It is regrettable that not all implementations can do pop-free. The spec. should reflect the reality. Perhaps a future minor API version update could add a query for the clipping behavior.

[pdaniell-nv]

I started looking into the wording required to update the OpenGL spec to allow both pop-free and non-pop-free behavior by comparing what it currently states to OpenGL ES. OpenGL ES currently says:

If the primitive under consideration is a point, then clipping passes it unchanged if it lies within the near and far clip planes; otherwise, it is discarded.

It never states what the "near and far clip planes" are. Does it mean the user clip planes, but OpenGL ES doesn't support that. Does it mean the "clip volume", which it defines earlier, but then it would be the same as OpenGL's non-pop-free definition.

[MarkCallow]

@pdaniell-nv, take a look at Khronos Bugzilla #10698 which, referring to the language you quoted, says:

This very clearly says that points and lines are not clipped against XY planes and thus they will extend beyond viewport boundaries. Desktop GL defines this differently; in GL points and lines are clipped against all clip planes.

Clipping wide lines and points against XY planes causes some artifacts (points suddenly disappearing near edges for example), which I believe is the reason this change has been made in ES spec.

So it seems the intention then was pop-free clipping to the viewport. There was an earlier proposal for pop-free clipping against the clip volume which said:

If the primitive under consideration is a point, then clipping discards it if it lies outside the front or back clip plane; otherwise, it is passed unchanged.

I don't recall and have not done sufficient archaeology to determine why that proposal was not adopted.

[pdaniell-nv]

Yes, I'm not disputing that the intent of OpenGL ES is to require pop-free clipping. My concern was about the language talking about "near and far clip planes", which aren't defined anywhere. I suspect it means "user clip planes", but I don't think OpenGL ES has user clip planes. So perhaps that entire sentence just needs to be discarded for OpenGL ES?

[MarkCallow]

I also don't think OpenGL ES has user clip planes. Section 2.13 of ES 2.0 (going back to when the previously quoted language was introduced) "Primitive Clipping" talks about near and far clip planes. I agree there is no strict definition but it seems logical that they are the front and back of the viewing frustum, i.e -w_c and w_c on the z axis.

[pdaniell-nv]

Discussed in the OpenGL/ES and cleared up my confusion regarding the near/far terminology.

So this line:

If the primitive under consideration is a point, then clipping passes it unchanged if it lies within the clip volume; otherwise, it is discarded.

Should be changed to this for OpenGL:

If the primitive under consideration is a point, then clipping passes it unchanged if it lies within the near and far clip planes, and the client-defined half-spaces; otherwise, it is discarded. In addition, implementations may discard points that lie outside the view volume.

I didn't want to add any commentary about which of the two behaviors is desirable since that would be unfair to implementations that can't do pop-free clipping.

[pdaniell-nv]

During the OpenGL/ES joint working group meeting today we approved the proposed change above to the OpenGL spec. Assigned to @oddhack to make the change.

[oddhack]

Fixed in the 2019-10-22 spec updates.