What's the Philosophy behind multiple glStencilFunc() parameters???

Already Posted on the beginners board but seems rather advanced …

Does anyone know the philosophy behind the parameters GLint ref and GLuint mask in the call glStencilFunc.

I was wondering why the extra parameter: mask, and why is it bitwise “anded” to ref and stencil … ?

I have sought the answer to this question in so many places, but every one just quotes the redbook or the bluebook - neither of which appear to be in a hurry to justify the extra “baggage”

Already Posted on the beginners board but seems rather advanced …

if you have a bitwise value, what ever it is… take


and a bitwise mask like that:


and you bitwise and it ( &-operator in c )

then you get this result:

1001010110101 &
0000000111111 =

means you can mask a specific part of your stencil as value… this way you can threat different parts of the stencil buffer (say you have an 8bit stencilbuffer) you can use the first 4bits for some stencil-effect and the last 4bits for some other… for example the first 4 for shadow-volumes, the second four for mirrors…

something like that…

its just for choosing on wich part of the stencil you want to draw to…

possibly learn a little about bitwise operators, bitflags (GL_FLAG0|GL_FLAG1|GL_FLAG2), CreateWindow(…,WS_OVERLAPPEDWINDOW&~WS_MAXIMIZE,…) and such stuff and you learn whats the use of it…

hope you got the idea…

Thanks <Davepermen>

… there’s one more thing I’m not sure of.

Is the comparison (GLenum) func performed on a bitwise basis or on the integer result of the masked values of GLint ref and Stencil?

For example, if the Stencil buffer content is say 1100 1100, and the Ref is 1010 1010, the intoduction of a Mask 0000 1111 will result as follows:

(Stencil & Mask ) = 0000 1100 = 12
(Ref & Mask) = 0000 1010 = 10

In which case, glStencilFunc() will fail if GLenum func is GL_GREATER since (Ref & Mask) < (Stencil & Mask ) (i.e. 10 < 12)

My thinking is that, since 3rd and 4th bits of the stencil buffer are “enabled”/eligible for writing even after the mask is applied (0000 1100), if comparisons are made on the integer values and not on a bitwise basis the “enabled”/eligible bitplanes end up not being written to!!! …

Is this how it’s supposed to work or am I missing something?

[This message has been edited by Olumide (edited 01-07-2002).]