I’m trying to implement cubemap shadows where I render the scene from six directions, but I find my depth texture I read back is clamping to 1 even though I’m using a float texture.
Here’s my vertex/fragment shader to render my scene. I’m trying to write out the world-space distance from the light. If I use the default depth value, when I read the images back, I can write them to an image and they look correct.
Here’s where I attach the depth buffer to the render buffer I’m rendering to.
And here’s where I’m rendering out the distance to my light in world space. Hard-coding the outgoing depth to 2.0, I still get 1.0 back for all the values. If I set it to something like 0.5, they read back at 0.5, so it seems to be clamping.
gl_FragDepth always seems to be clamping to 1. Should I not be using gl_FragDepth? Do I need to do something to disable the clamping? Or is GL_DEPTHCOMPONENT32 not an actual floating-point format?
You don’t need depth values outside of the [0,1] range in order to use cubemap shadows. What you store in the depth buffer are “normalized” depth values, what I want to say here is that value 0 will correspond to your near clip plane’s distance while 1 will correspond to your far clip plane’s distance.
I don’t know why you want to store values outside of [0,1] in your depth texture. Can you explain it?
Well, first I’ve hard a hard time find many examples using cube maps in general. The most popular by google is nvidia’s old example from 1991. I have yet to find ANY example that actually uses the GLSL shadowCube(…) function at all, so I’m kind of trying to figure this out on my own.
I read that Stalker (http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html) experimented with a depth cube map, but they stored their distance from the light in an R32F color texture and not the depth texture itself. I guess I could also do this, but then I wouldn’t use the shadowCube() function and I’d do the lookup myself, right?
I was trying to store the distance to the light in world space in my depth buffer and then use shadowCube() in my fragment shader passing it the vector of the fragment to the light and the distance (in world space) between the light and the fragment.
vec3 lightVec = lightPosW - fragPosW;
float lightIntensity = shadowCube(depthCubeMap, vec4(normalize(lightVec), length(lightVec)).r; // not sure why a vec4 is returned
I guess if I were to use the shadowCube() I’ll have to normalize the distance between the light and fragment myself to fit between 0-1 as happened in the render buffer. Is this how shadowCube() is supposed to function? Only on normalized depth values? Are there any examples of this?
Also, reading EXT_gpu_shader4 I can’t make out what these shadow functions return. Why a vec4 and not a float?
The most popular by google is nvidia’s old example from 1991.
I’ll assume you meant 2001, since NVIDIA didn’t even exist in 1991.
Is this how shadowCube() is supposed to function?
Despite the frankly ridiculous naming of the shadow functions and samplers, they do not make shadows. All they do is perform [b]comparison[/b]-based texel fetches, rather than getting the actual pixel values. What that comparison means is entirely up to you.
So there is no way it “is supposed to function,” outside of performing comparison testing. It’s a tool; how you use it is entirely up to you.
Personally, I would say that the “clamp-and-normalize” is a reasonable solution.
Is that the same normalization that occurs with the perspective projection? Also, can I use any channel returned from these shadow functions? Is there any different between say .r and .a or are they treated just like any single-channel texture like luminance where they all return the same value? Thanks.
Is that the same normalization that occurs with the perspective projection?
Does it matter? You’re writing a value and then comparing that against a value that you compute in the same way.
The only reason you’re normalizing it at all is because the ARB hasn’t gotten their heads out to realize that clamped floating-point depth buffers are stupid and counterproductive. It’s not a solution; it’s a workaround.
What matters isn’t whether it matches what the perspective projection does. What matters is that you’re computing the value the same way when you write it and you read it. The normalization is there as a workaround for a bad bit of the spec. The near and far values you pick should be values that best make use of the available bitdepth. How much they resemble the perspective projection is irrelevant.
Also, can I use any channel returned from these shadow functions?
Well, I was going to say that the texture functions for shadow lookups return floats, but you’re still using the old-style gpu_shader4 stuff, which needlessly returns a vec4. I’d just stick with .x/.r/.s, just to be safe.
Without a really clear idea how this cube map needs to properly be configured, I’m having difficulty wondering if it’s even setup correctly since I get nothing but black right now.
The values I’m getting back from glReadPixels implies that most of the image values are 1 and all of them are at least greater than .1. Am I doing something wrong setting up the texture or connecting it to the shader?
Where’s the rest of it? You know, the part where you set up the comparison test (I didn’t link you to that for my health, you know;) )? You know, the part where you set up your GL_TEXTURE_COMPARE_MODE and your GL_TEXTURE_COMPARE_FUNC?
So, you too have fallen prey to a common OpenGL blunder. It’s understandable, and yet another reason why glTexStorage is the best idea the ARB has had since explicit_attrib_location.
You have to use GL_DEPTH_COMPONENT as the format, not GL_LUMINANCE. I know you’re not actually passing anything; that doesn’t mean that OpenGL implementations aren’t required to check and error in this case. And you should use GL_UNSIGNED_INT as the type, rather than GL_FLOAT.
But in any case, you shouldn’t be calling this every frame. You call it once, when you create the texture (technically 6 times). You then use the SubImage functions to put data into it.
Yes, they used a simple one component color texture because wide support of depth cube maps in hardware was not available at that time. But that’s slower as you cannot take advantage of the hardware depth comparision (i.e. shadow sampling), also you need a color buffer in addition to your depth buffer in order to render the shadow map itself. In case of depth cube maps you don’t store the distance, but the “normalized” depth value of the fragment. This does not need values outside of the [0,1] interval. This is how non-cubemap shadow maps work as well. I would suggest first to try to implement regular 2D shadow maps and then you’ll understand how to do cubemap shadow maps.
not sure if your shader does some magic here, but GL_TEXTURE0 is 0x84C0, when you probably want to pass 0, because the texture is bound to texture unit 0?
Yes, they used a simple one component color texture because wide support of depth cube maps in hardware was not available at that time. But that’s slower as you cannot take advantage of the hardware depth comparision (i.e. shadow sampling), also you need a color buffer in addition to your depth buffer in order to render the shadow map itself. In case of depth cube maps you don’t store the distance, but the “normalized” depth value of the fragment. This does not need values outside of the [0,1] interval. This is how non-cubemap shadow maps work as well. I would suggest first to try to implement regular 2D shadow maps and then you’ll understand how to do cubemap shadow maps.[/QUOTE]
I’ve implemented regular 2D shadow maps before. I feel most of my issues revolve around the differences between them and cubemaps. I’m doing the normalization myself now to fit into the [0,1] interval. With 2D shadow maps I’d be using a fixed matrix transform, but I’d like to avoid six of those in my cubemap and just use the lookup by light normal.
I’ve placed glGetError throughout my code to make sure everything’s correctly executed, and I believe I’ve resolved all the logged errors at least.
glBindTexture(GL_TEXTURE_CUBE_MAP, depthCubeMap);
shader->setUniformValue("depthCubeMap", depthCubeMap); // was GL_TEXTURE0
What I don’t understand now, though, is now matter I send my depthCubeMap sample, I seem to get zero back regardless of the value. Wouldn’t values beyond [0,1] be valid lookups that should return true or false?
I just found that it doesn’t matter if I set my texture comparison function to GL_ALWAYS, I still seem to get zero back. It makes me wonder if something else is wrong with my configuration, but I don’t know what. I’m setting the texture to the uniform samplerCubeShadow. The location I get back from this variable is greater than zero, so I assume the shader accepts and is using it. I have the texture bound and GL_TEXTURE_CUBE_MAP enabled even though I thought that wasn’t required for shaders. Is there anything else I could do to see if everything is setup correctly?