I already have an idea of the answer but I need to be sure.
I render a scene in two pass.
In the first pass, if depth test succeeds, I mark stencil bit as 1 :
glEnable(GL_STENCIL_TEST);
glStencilMask(GL_TRUE);
glStencilOp(GL_KEEP, GL_KEEP, GL_REPLACE);
glStencilFunc(GL_ALWAYS, 1, GL_TRUE);
The second pass only writes where stencil is 1 :
glStencilFunc(GL_EQUAL, 1, GL_TRUE); // Pass test if stencil value is 1
glStencilMask(GL_FALSE); // Don't write anything to stencil buffer
In fact, this works properly but I expected a huge increase in terms of performance.
The shader used in the second pass is particular : it uses discard and gl_FragDepth affectation.
That makes early-z culling impossible. Fortunately, I'm only interested in early-stencil culling.
So there is my question : is there a way to take advantage from early-stencil culling without early-z culling ?
This thread is very related to this one, but I really need to use discard and gl_FragDepth affectation in the second shader...
There is no such thing as early stencil tests. Or early Z/depth tests for that matter. There are only early fragment tests, which happen to include the stencil and depth tests, but also other operations. They cannot be performed early in piecemeal; it's all early or all late.
I've been trying to implement something like the game Antichamber (to be more precisly this trick shown below) for the past week:
Here's a video of what I'm hoping to achieve (even though it was done with the Unreal Engine 4; I'm not using that): https://www.youtube.com/watch?v=Of3JcoWrMZs
I looked up the best way to do this and I found out about the stencil buffer. Between this article and this code (the "drawPortals()" function) I found online I managed to almost implement it.
It works nicely with one portal to another room (not a crossable portal, meaning you can't walk through it and be teleported in the other room). In my example I'm drawing a portal to a simple squared room with a sphere in it; behind the portal there is another sphere, that I used to check whether the depth buffer was working correctly and drawing it behind the portal:
The problems arise when I add another portal that is near this one. In that case I manage to display the other portal correctly (the lighting is off, but the sphere on the right is of a different color to show that it's another sphere):
But if I turn the camera so that the first portal has to be drawn over the second one, then the depth of the first one becomes wrong, and the second portal gets drawn over the first one, like this:
while it should be something like this:
So, this is the problem. I'm probably doing something wrong with the depth buffer, but I can't find what.
My code for the rendering part is pretty much this:
glClear(GL_DEPTH_BUFFER_BIT);
glEnable(GL_STENCIL_TEST);
// First portal
glPushMatrix();
// Disable writing to the color and depht buffer; disable depth testing
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
glDepthMask(GL_FALSE);
glDisable(GL_DEPTH_TEST);
// Make sure that the stencil always fails
glStencilFunc(GL_NEVER, 1, 0xFF);
// On fail, put 1 on the buffer
glStencilOp(GL_REPLACE, GL_KEEP, GL_KEEP);
// Enable writing to the stencil buffer
glStencilMask(0xFF);
// Clean the buffer
glClear(GL_STENCIL_BUFFER_BIT);
// Finally draw the portal's frame, so that it will have only 1s in the stencil buffer; the frame is basically the square you can see in the pictures
portalFrameObj1.Draw();
/* Now I compute the position of the camera so that it will be positioned at the portal's room; the computation is correct, so I'm skipping it */
// I'm going to render the portal's room from the new perspective, so I'm going to need the depth and color buffers again
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glDepthMask(GL_TRUE);
glEnable(GL_DEPTH_TEST);
glClear(GL_DEPTH_BUFFER_BIT);
// Disable writing to the stencil buffer and enable drawing only where the stencil values are 1s (so only on the portal frame previously rendered)
glStencilMask(0x00);
glStencilFunc(GL_EQUAL, 1, 0xFF);
// Draw the room from this perspective
portalRoomObj1.Draw();
glPopMatrix();
// Now the second portal; the procedure is the same, so I'm skipping the comments
glPushMatrix();
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_TRUE);
glDepthMask(GL_FALSE);
glDisable(GL_DEPTH_TEST);
glStencilFunc(GL_NEVER, 1, 0xFF);
glStencilOp(GL_REPLACE, GL_KEEP, GL_KEEP);
glStencilMask(0xFF);
glClear(GL_STENCIL_BUFFER_BIT);
portalFrameObj2.Draw();
/* New camera perspective computation */
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glDepthMask(GL_TRUE);
glEnable(GL_DEPTH_TEST);
glClear(GL_DEPTH_BUFFER_BIT);
glStencilMask(0x00);
glStencilFunc(GL_EQUAL, 1, 0xFF);
portalRoomObj2.Draw();
glPopMatrix();
// Finally, I have to draw the portals' frames once again but this time on the depth buffer, so that they won't get drawn over; first off, disable the stencil buffer
glDisable(GL_STENCIL_TEST);
// Disable the color buffer
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
glClear(GL_DEPTH_BUFFER_BIT);
// Draw portals' frames
portalFrameObj1.Draw();
portalFrameObj2.Draw();
// Enable the color buffer again
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
/* Here I draw the rest of the scene */
UPDATE
I managed to find out what the problem is, but I'm still not able to solve it. It isn't related to the depth buffer actually, but to the stencil.
Basically, the way I'm drawing the first portal is this:
1) Fill the portal frame's bits in the stencil buffer with 1s; outside the portal there are only 0s
2) Draw the portal room where the stencil has 1s (so that it gets drawn onto the frame's portal
And I repeat this for the second portal.
For the first portal, I get at step 1 something like this then (pardon the stupid drawings, I'm lazy):
Then after step 2:
Then I start with the second portal:
But now, between step 1 and 2, I tell the stencil to draw only where the bits are 1s; since the buffer is now cleared, I lost track of the 1s of the first portal, so if part of the second portal's frame is behind the previous frame, the 1s of the second frames will still be drawn with the second portal's room, regardless of the depth buffer. Kind of like in this image:
I don't know if I managed to explain it right...
It's been a while now. Since there aren't going to be anwsers (probably) I'm writing about the workaround I'm using now.
I tried solving the problem using different stencil functions and not empting the stencil buffer when I render a new portal; the idea was to exploit the fact that I knew by looking at the stencil buffer where the previous portals where being rendered.
In the end, I couldn't manage to do it; in the examples I posted in my original question, one of the 2 portals always obscured parts of the other.
So, I decided to do something simplier: I check if a portal is visible, and then I draw it exactly like in the code I posted in the question (so emptying the stencil buffer each time).
In pseudo code, I do this:
for(var i = 0; i < PORTALS_NUMBER; i++)
{
// I get the normal to the portal's frame and its position
var normal = mPortalFramesNormals[i];
var framePos = mPortalFrames[i].GetPosition();
// I compute the scalar product between the normal and the direction vector between the camera's position and the frame's position
var dotProduct = normal * (currentCameraPosition - framePos);
// If the dot product is 0 or positive, the portal is visible
if(dotProduct >= 0)
{
// I render the portal
DrawPortal(mPortalFrames[i], mPortalRooms[i]);
}
}
glDisable(GL_STENCIL_TEST);
// Now I draw the portals' frames in the depth buffer, so they don't get overwritten by other objects in the scene
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
glDepthMask(GL_TRUE);
glEnable(GL_DEPTH_TEST);
glClear(GL_DEPTH_BUFFER_BIT);
for(var i = 0; i < PORTALS_NUMBER; i++)
{
mPortalFrames[i].Draw();
}
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
In my case, where I need to display 4 portals in total positioned as a cube (so I know that at most 2 portals are directly visible at a time) and only one face of the frame displays the portal while the other one donesn't, it works perfectly.
I know that there is probably a more elegant way to do this by using only the stencil buffer, but right now this works for me.
If anyone knows a better way to do this, I'm still interested in knowing!
EDIT: I've found out about the other versions of the stencil functions (i.e., glStencilFuncSeparate, glStencilOpSeparate, glStencilMaskSeparate) that allow to do different things with back and front faces. That seems like what I would need to solve the problems I described, but I won't be able to try this anytime soon. I'm just pointing it out in case someone who has my same problem wanders here.
I'm a few years late, but this question still shows up when searching for this problem, and I've had to fix it as well, so I figured I'll drop my solution for anyone else who comes by.
1. Don't clear the depth buffer (except between frames)
The main issue with your solution is that you're periodically clearing the entire depth buffer. And every time you do, you're getting rid of any information you might have to figure out which portals to draw and which are obscured. The only depth data you actually need to clobber is on the pixels where your stencils are set up; you can keep the rest.
Just before you draw the objects "through" the portal, set up your depth buffer like so:
// first, make sure you're writing to the depth buffer
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
glDepthMask(GL_TRUE);
glStencilMask(0x00);
// you can have the stencil enabled for this step, if you did anything fancy with it earlier (like depth testing)
glStencilFunc(GL_EQUAL, 1, 0xFF);
// the depth test has to be enabled to write to the depth mask. But don't worry; it'll always pass.
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_ALWAYS);
// set the depth range so we only draw on the far plane, leaving a "hole" for later
glDepthRange(1, 1);
// now draw the portal object again
portalFrameObj1.Draw();
// and reset what you changed so the rest of the code works
glDepthFunc(GL_LESS);
glDepthRange(0, 1);
glColorMask(GL_TRUE,GL_TRUE,GL_TRUE,GL_TRUE);
Now, when you draw the objects "through" the portal, they'll show up where they're needed, but the rest of the screen will still have the depth information it used to! Everybody wins!
Of course, don't forget to overwrite the depth information with a third portalFrameObj1.Draw() like you've been doing. That'll help with the next part:
2. Check if your portal is obscured before setting up the stencil
At the start of the code, when you set up your stencil, you disable depth testing. You don't need to!
glStencilOp has three arguments:
sfail applies when the stencil test fails.
dpfail applies when the stencil test succeeds, but the depth test fails.
dppass applies when both the stencil and depth test succeed (or the stencil succeeds and the depth test is disabled or has no data).
Leave depth testing on. Set glStencilFunc(GL_ALWAYS, 0, 0xFF); rather than GL_NEVER, so the stencil test succeeds, and use dppass to set your stencil instead of sfail: glStencilOp(GL_KEEP, GL_KEEP, GL_REPLACE);
Now, you could also play around with glStencilFuncSeparate to optimize things a little, but you don't need it to get portals to obscure each other.
I know that it is a very bad idea to read/write from/to the same texture/location, because this would result in undefined behaviour.
But in my case, if depth testing is disabled and I read the depth values in a shader, is it ok to do the stencil testing at the same time as reading the depth values within the same texture?
In my opinion there should not be any problems, because i'm not reading the stencil buffer values in the shader. Or, could there by any hardware related problems when the texture is bound for reading in a shader and OpenGL uses it to do the stencil testing?
This texture is filled with depth/stencil values. I wan't to avoid some heavy BRDF lighting(Directional light) calculations on specific pixels(the sky).
Example code:
//Contains the depth/stencil texture(deferredDepthStencilTextureID).
//Two FBO's are sharing the same depth/stencil texture.
lightAccumulationFBO->bind();
glEnable(GL_STENCIL_TEST);
glStencilFunc(GL_EQUAL, 1, 0xFF);
//Disable writing to the stencil buffer, i.e. all the bits is write-protected.
glStencilMask(0x00);
glDisable(GL_DEPTH_TEST);
glEnable(GL_BLEND);
glBlendFunc(GL_ONE, GL_ONE); //Additive blending. Light accumulation.
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, deferredDepthStencilTextureID); //GL_DEPTH24_STENCIL8
//Bind other textures here...
shader.bind();
//Uniforms here...
postProcessQuad->renderQuad();
shader.unbind();
//Unbind all the textures here.
...
glDisable(GL_BLEND);
glEnable(GL_DEPTH_TEST);
glDisable(GL_STENCIL_TEST);
lightAccumulationFBO->unbind();
But in my case, if depth testing is disabled and I read the depth values in a shader, is it ok to do the stencil testing at the same time as reading the depth values within the same texture?
No. Whether an operation is defined or not is based on the images attached to the FBO and read from. Not the components of said images. And no, write masking will not save you from undefined behavior.
So unless your stencil texture is separate from your depth texture, that's not going to work. And good luck finding hardware that will allow you to separate depth/stencil images.
Even with GL 4.5/NV/ARB_texture_barrier, the answer is still no. That functionality makes certain exceptions to the above rule, but only for operations that are due to fragment shader outputs. Stencil test operations are not fragment shader outputs, so they don't apply.
I was trying to configure my stencil buffer so that, when enabled, it would set when the pixel drawn is not transparent (thus creating a map of pixels that light can collide with). What I've done is:
glClearStencil(0); //clear stencil
glStencilFunc(GL_EQUAL, 0xFF, 0x000000FF); //only where alpha (mask : 0x000000FF) is 0xFF (opaque)
glStencilOp(GL_INCR, GL_KEEP, GL_KEEP); //increment if passes (if it is opaque)
render(); //withing this method I sometimes disable the whole thing to draw the floor, for example
Then, i use the following code to test:
/* TURN OFF STENCIL */
glEnable(GL_STENCIL_TEST); //re-enable
glStencilFunc(GL_EQUAL, 0, 1); //if the test is equal to 1
glStencilOp(GL_KEEP, GL_KEEP, GL_KEEP); //do not change stencil buffer
ImageInfo.drawColorSquare(0, 0, Configurations.SCREEN_WIDTH, Configurations.GAME_HEIGHT, Color.BLUE); //drwa blue square
glDisable(GL_STENCIL_TEST); //disable
However, there are two problems:
It doesn't seem to be ignoring transparent pixels, as it should;
If a region overlaps with another, then it reverses - for example, it sets to one, then another region is drawn in the same area, and it reset it to 0 again.
I don't know why that is happening. Probably something wrong with my mask, I guess - I wasn't absolutely sure how many pixels OpneGL used in the Color Buffer.
Also, GL_INCR should add up to the max, and not go back, according to the documentation. Since my stencil buffer size is one bit, it should set to one, try to increase again, fail, and keep on one (instead of reseting).
The Stencil Test is independent of what happens in the color buffer. Setting glStencilFunc
( http://www.opengl.org/sdk/docs/man/xhtml/glStencilFunc.xml )
you can specify how the Stencil Test interacts with what is already stored in the Stencil Buffer.
Setting glStencilOp ( http://www.opengl.org/sdk/docs/man/xhtml/glStencilOp.xml ) gives you the possibility of using the result of the depth test to perform the Stencil Test.
A good tutorial that explain the Stencil Test and a very instructive algorithm based upon it can be found here http://ogldev.atspace.co.uk/www/tutorial37/tutorial37.html
The stencil buffer is usually an 8-bit buffer that reserves a small portion of the memory normally used for the depth buffer and is used for advanced rejection of fragments; things like masking to arbitrary shapes rather than using rectangular scissor boxes. It has nothing to do with your color buffer, and to make sure that fragments that have a specific alpha value do not affect the pixels on screen you would use something called an alpha test.
In core OpenGL 3, the fixed-function alpha test is no longer supported, so you would have to implement it in a fragment shader and then discard if it failed to meet your condition.
I try to use the stencil buffer of a FBO in OpenGL, but I can't get it to work. I bound a depth24_stencil8 texture to the FBO both for the depth and stencil targets. As a simple test, I tried:
/* Enable FBO */
glEnable(GL_STENCIL_TEST);
glStencilFunc(GL_NEVER, 1, 0xff);
glStencilOp(GL_KEEP, GL_KEEP, GL_KEEP);
glBegin(GL_TRIANGLE);
/* Draw some triangles */
glEnd();
glDisable(GL_STENCIL_TEST);
/* Disable FBO and render it on screen as a texture. */
As I use GL_NEVER, nothing should be rendered at all, but I can see the triangles. This is like if there were no stencil at all, but I cannot understand why. Trying this code without FBOs works, so I think I use the stencil functions correctly. I don't have any idea how to solve this problem. Did anyone already use a stencil with FBOs?
My bad, I was not attaching correctly the stencil buffer to my FBO. Strange thing is that my fbo status was not indicating any error or bad attachement, so I was persuaded it was OK... this problem has driven me crazy but now it seems to work.