It seems that it would NOT allow writing depth buffer when just disable depth testing. I use the following sentences:
glDisable(GL_DEPTH_TEST);
glDepthMask(GL_TRUE);
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
Can anybody tell me the truth?
Use glDepthFunc(GL_ALWAYS)
It seems that disabling teh depth test will also disable the depth updating in the z-buffer
What do you mean by using glDepthFunc(GL_ALWAYS)?
It seems cannot make depth buffer writable when disabling depth test and using glDepthFunc(GL_ALWAYS).
You need to keep depth test enabled, because that’s what GL_ALWAYS is; a depth test function.
Disabling depth test completely disables everything related to the depth buffer. That’s not what you want, you want the depth buffer writes to happen so you must have it enabled.
Is it the same for other buffers, such as stencil buffer ?
I mean that, when you call glDisable(GL_STENCIL_TEST), everthing stencil-buffer-related will be disabled?
Correct.
This is all spelled out very clearly in the specification.
Thanks to you all, guys.
I find it 
, thanks again, I think I should refer to it more frequently later on:
{
4.1.6 Depth Buffer Test
The depth buffer test discards the incoming fragment if a depth comparison fails.The comparison is enabled or disabled with the generic Enable and Disable commands using the symbolic constant DEPTH TEST.
When disabled, the depth comparison and subsequent possible updates to the depth buffer value are bypassed and the fragment is passed to the next operation.
}
Ok recap time, there is a lot of confusion in this thread, so here is exactly how it is.
glDepthFunc(…); sets the test to be made against the depthbuffer, normally this should be GL_LEQUAL, GL_ALWAYS is not a good one since it will always pass, even if the fragment is behind previous written depth value.
glDisable(GL_DEPTH_TEST); and glEnable(GL_DEPTH_TEST); controls the discarding the color part of the current fragment, based on the above test.
glDepthMask(…); same as above but for the depth part of the fragment.
(It should really be glEnable(GL_DEPTH_WRITE), but i guess whats done is done.)
So to answer the original question, yes it does.
Hi, zeoverlord, Is this right?
<So to answer the original question, yes it does.>
I referred to 4.1.6 of glspec2.1_20061201, it says:
"When disabled, the depth comparison and subsequent possible updates to the depth buffer value are bypassed and the fragment is passed to the next operation.
"
So I think yours might not be right.
Originally posted by zeoverlord:
glDepthFunc(…); sets the test to be made against the depthbuffer, normally this should be GL_LEQUAL, GL_ALWAYS is not a good one since it will always pass, even if the fragment is behind previous written depth value.
Whether GL_ALWAYS is bad depends entirely on what you want. OP wanted to unconditionally write the depth values to the depth buffer, so GL_ALWAYS is not only a good choise, but be MUST use it. It’s only bad when it’s not the test you want, obviously.
Originally posted by zeoverlord:
glDisable(GL_DEPTH_TEST); and glEnable(GL_DEPTH_TEST); controls the discarding the color part of the current fragment, based on the above test.
I think the description is a bit misleading. It’s not about discarding color part of a fragment. It’s about the fragment completely bypassing everything that has anything to do with the depth buffer.
Originally posted by zeoverlord:
glDepthMask(…); same as above but for the depth part of the fragment.
(It should really be glEnable(GL_DEPTH_WRITE), but i guess whats done is done.)
Controlling depth mask with glEnable/glDisable would be inconsistent with the rest of the API. Compare with color and stencil for example. glDepthMask, glColorMask, glStencilMask; see a pattern?
To make it more complicated, glColorMask takes four parameters (would need four constants and four calls to glEnable/glDisable). glStencilMask takes a bitmask for an arbitrary number of (implementation defined, depends on number of stencil bits) masks; how to solve that with glEnable/glDisable?
And all depth buffer related function begins with glDepth, just as all stencil buffer related functions begins with glStencil, and color buffer functions with glColor (although it’s only one in this case; glColorMask).
Originally posted by Bob:
[quote]Originally posted by zeoverlord:
glDisable(GL_DEPTH_TEST); and glEnable(GL_DEPTH_TEST); controls the discarding the color part of the current fragment, based on the above test.
I think the description is a bit misleading. It’s not about discarding color part of a fragment. It’s about the fragment completely bypassing everything that has anything to do with the depth buffer.[/QUOTE]I guess you right, though ultimately it depends on how you look at it, one can logically assume that this is the case, but it does depend on the current and future implementations of the driver, hardware and openGL.
Originally posted by zeoverlord:
I guess you right, though ultimately it depends on how you look at it, one can logically assume that this is the case, but it does depend on the current and future implementations of the driver, hardware and openGL.
I’m writing from a behaviour point of view; what is written in the specification and what result an implementation must produce given a certain state. How they implement it is not relevant, but disabling depth test, the result must be exactly as if the depth buffer mechanism just wasn’t there in the first place.
That’s a fundamental part of the API and isn’t likely to change any time soon… :rolleyes:
Hey, guys, it doesn’t matter which kind of view you have, what really matters is that we know how GL behaviors at the moment and we know how to use it. Isn’t that right?
Originally posted by wilburn:
Hey, guys, it doesn’t matter which kind of view you have, what really matters is that we know how GL behaviors at the moment and we know how to use it. Isn’t that right?
Well, it depends on how you look at it…
Joke aside. For some ways to look at a problem you see an immediate solution that fit the problem well, but later it turns out you have to make some exceptions to the rule for it to fit other parts of the system. Some other ways to look at it fit the entire system without exceptions. So it does matter to some degree.
But looking at the observable behaviour on an abstract level is often a good thing. So in my oppinion you’re right that that’s often what matters, yes. Don’t focus on details in a specification that doesn’t specify details.
Your remarks is professional.