**1**

# what is the range of clipping space in OpenGL?

###
#1
Members - Reputation: **435**

Posted 30 November 2012 - 02:52 PM

I calculated perspective matrix myself and passed it to vertex shader, but why triangle was visible only when the z value of vertices multiplied by my perspective matrix is positive? Since the z value range of perspective frustum [n, f] is mapped to [-1. 1] in clipping space, any -1 < z < 1 should not be clipped which is just not the case in my situation. In case that my perspective matrix is miscalculated, I directly passed vertices with -1 < z < 0 to vertex shader, still I got nothing. but it works just fine with 0 < z < 1.

###
#2
Members - Reputation: **1104**

Posted 02 December 2012 - 02:14 PM

If you use something like 0 and 100 for n and f respectively, you should be able to see geometry where incoming vertex z is negative.

Can you post the function that calculates the projection matrix, and your vertex shader?

+---------------------------------------------------------------------+

###
#3
Crossbones+ - Reputation: **8945**

Posted 02 December 2012 - 04:15 PM

The near-plane value should never be zero, or you will lose an immense amount of precision (remember the depth buffer uses a logarithmic scale). The best values depend on the scale of the scene, but if you're working in meters, 0.1 to 1000 is a good start IMHO.From what I understand, near and far represent values that relate to camera space, not clip space.

If you use something like 0 and 100 for n and f respectively, you should be able to see geometry where incoming vertex z is negative.

**Edited by Bacterius, 02 December 2012 - 04:15 PM.**

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- *Pessimal Algorithms and Simplexity Analysis*

###
#4
Members - Reputation: **1104**

Posted 02 December 2012 - 11:44 PM

The near-plane value should never be zero, or you will lose an immense amount of precision (remember the depth buffer uses a logarithmic scale). The best values depend on the scale of the scene, but if you're working in meters, 0.1 to 1000 is a good start IMHO.

Ah, yes, as written here: http://www.opengl.org/archives/resources/faq/technical/depthbuffer.htm

Thanks for pointing that out.

+---------------------------------------------------------------------+