<p>Clipping could be done in normalised device coordinates as all primitives with z-coordinates outside -1 to 1 are outside the clipping planes. However, there is no reason not to do it in clip coordinates by considering z-coordinates from -w to w.</p>

<p>Theoretically it possible. However it seems there is performance increase when doing the clipping in clip coordinates. By first comparing z-coordinates before perspective division it saves time by not computing perspective division for the clipped primitives. This means less division operations. This favourable as floating point division can take a few processing cycles.</p>

<p>Refer also to the answer in <a href="https://gamedev.stackexchange.com/questions/65789/why-is-clip-space-always-referred-to-as-homogeneous-clip-space">this</a> related question</p>

CC BY-SA 3.0
2017-11-25T18:09:36.357Z
2017-11-26T11:33:36.287Z
2017-11-26T11:33:36.287Z
Reynolds
<p>The space after clip space is normalized device coordinate space, which is obtained by dividing <code>clip.xyz</code> by <code>clip.w</code>. If W is zero... oops.</p>

<p>Oh sure, you could put a conditional test to see if W is zero or very close to zero. Or you can just do the clipping math in clip space and never have to worry about it. No post-clipping vertex can have a W of zero, because the clip box for each vertex is based on being in the <em>closed</em> range (-W, W). And if W is 0, then the closed range is an empty set, and thus the vertex is not on that range.</p>

<p>Also, negative values of W are outside of the clipping space. The closed range (-W, W) is inverted where W is negative, but the meaning of the range itself is not. Consider a W of -1; the range becomes (1, -1). There are no numbers that are simultaneously greater than 1 and less than -1. Therefore that space is <em>empty</em>.</p>

<p>And yet, division by a negative W can still land NDC points in the [-1, 1] NDC-space range, where they will not be clipped if you didn't clip them beforehand.</p>

CC BY-SA 3.0
2017-11-26T03:05:57.547Z
Also, W < 0 for points behind the camera. So if you divide by W first, you then cannot tell whether a point/primitive was behind the camera or in front of it.
Nathan Reed
CC BY-SA 3.0
2017-11-28T12:46:25.150Z
Last fact seems most important to me
Nolan
CC BY-SA 3.0
2017-11-28T14:44:29.060Z
But I doubt it's true. Could you prove it or provide an example?
Nolan
CC BY-SA 3.0
2017-11-28T15:10:57.973Z
@Nolan: The point (0, 0, 0, -1). Divide by -1, and it's in the [-1, 1] range. But it can't be in the range of [1, -1], since that is an empty set.
Nicol Bolas
CC BY-SA 3.0
2017-11-28T16:50:23.430Z
You can't get point (0, 0, 0, -1) after multiplying by the projection matrix. It requires initial point have w coordinate equal 0 or have weird projection planes like negative near or far behind near.
Nolan
CC BY-SA 3.0
2017-11-28T16:53:26.857Z
@Nolan: Nowhere in OpenGL is there an assumption that `gl_Position` can only arise by "multiplying by a projection matrix". The specification must deal with *all* possible values, not just the ones that come about through the usual means.
Nicol Bolas
CC BY-SA 3.0
2017-11-28T17:04:57.883Z
Also I would argue this point must be clipped. You can multiply (0,0,0,-1) by (-1) and get (0,0,0,1) which denotes same point in 3D but shouldn't be clipped according to its w coordinate.
Nolan
CC BY-SA 3.0
2017-11-28T17:06:22.437Z
@Nolan: But it cannot be clipped in NDC space, because in NDC space, the point is just (0, 0, 0). Remember: NDC is 3D space, not 4D. So it cannot tell the difference between a clip-space (0, 0, 0, 1) and (0, 0, 0, -1). The former should not be clipped; the latter should. NDC space can't tell the difference. This is why clipping is done in clip-space; because it has sufficient information to do it correctly.
Nicol Bolas
CC BY-SA 3.0
2017-11-28T17:08:10.540Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/69391/discussion-between-nolan-and-nicol-bolas).
Nolan
CC BY-SA 3.0
2017-11-25T20:17:32.463Z
2017-11-26T16:30:41.583Z
2017-11-26T16:30:41.583Z
Nicol Bolas
<p>Is there any reason why OpenGL performs primitives' clipping in clip coordinates? Can it be at least theoretically done in normalized device coordinates?</p>

<opengl><clipping>
Why does opengl perform clipping in clip coordinates?
Nolan
# Why does opengl perform clipping in clip coordinates?

(Asked by: username_0 on 2017-11-25)

Is there any reason why OpenGL performs primitives' clipping in clip coordinates? Can it be at least theoretically done in normalized device coordinates?

**Tags:** opengl, clipping


---

## 2 answers

### Answer by username_2 on 2017-11-25. Score: 10 | Accepted answer

The space after clip space is normalized device coordinate space, which is obtained by dividing `clip.xyz` by `clip.w`. If W is zero... oops.

Oh sure, you could put a conditional test to see if W is zero or very close to zero. Or you can just do the clipping math in clip space and never have to worry about it. No post-clipping vertex can have a W of zero, because the clip box for each vertex is based on being in the *closed* range (-W, W). And if W is 0, then the closed range is an empty set, and thus the vertex is not on that range.

Also, negative values of W are outside of the clipping space. The closed range (-W, W) is inverted where W is negative, but the meaning of the range itself is not. Consider a W of -1; the range becomes (1, -1). There are no numbers that are simultaneously greater than 1 and less than -1. Therefore that space is *empty*.

And yet, division by a negative W can still land NDC points in the [-1, 1] NDC-space range, where they will not be clipped if you didn't clip them beforehand.

> **Comments:**
> **username_3**: Also, W < 0 for points behind the camera. So if you divide by W first, you then cannot tell whether a point/primitive was behind the camera or in front of it.  
> **username_0**: Last fact seems most important to me  
> **username_0**: But I doubt it's true. Could you prove it or provide an example?  
> **username_2**: @username_0: The point (0, 0, 0, -1). Divide by -1, and it's in the [-1, 1] range. But it can't be in the range of [1, -1], since that is an empty set.  
> **username_0**: You can't get point (0, 0, 0, -1) after multiplying by the projection matrix. It requires initial point have w coordinate equal 0 or have weird projection planes like negative near or far behind near.  
> **username_2**: @username_0: Nowhere in OpenGL is there an assumption that `gl_Position` can only arise by "multiplying by a projection matrix". The specification must deal with *all* possible values, not just the ones that come about through the usual means.  
> **username_0**: Also I would argue this point must be clipped. You can multiply (0,0,0,-1) by (-1) and get (0,0,0,1) which denotes same point in 3D but shouldn't be clipped according to its w coordinate.  
> **username_2**: @username_0: But it cannot be clipped in NDC space, because in NDC space, the point is just (0, 0, 0). Remember: NDC is 3D space, not 4D. So it cannot tell the difference between a clip-space (0, 0, 0, 1) and (0, 0, 0, -1). The former should not be clipped; the latter should. NDC space can't tell the difference. This is why clipping is done in clip-space; because it has sufficient information to do it correctly.  
> **username_0**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/69391/discussion-between-username_0-and-username_2).  

---

### Answer by username_1 on 2017-11-25. Score: 1

Clipping could be done in normalised device coordinates as all primitives with z-coordinates outside -1 to 1 are outside the clipping planes. However, there is no reason not to do it in clip coordinates by considering z-coordinates from -w to w.

Theoretically it possible. However it seems there is performance increase when doing the clipping in clip coordinates. By first comparing z-coordinates before perspective division it saves time by not computing perspective division for the clipped primitives. This means less division operations. This favourable as floating point division can take a few processing cycles.

Refer also to the answer in [this](https://gamedev.stackexchange.com/questions/65789/why-is-clip-space-always-referred-to-as-homogeneous-clip-space) related question


---

