Omnidirectional Shadow Cube Texture Sample Breaking

[devmane144]

Hello all,

I was working with omnidirectional shadowmapping using cube maps in order to make point light shadows. Unfortunately they are not working. They're actually breaking my entire drawings. I create and bind the cube map successfully, draw a depth map to it, then I try to sample it in my shaders. My cube map does draw successfully (I checked with apitrace, the depth maps do draw correctly).

I bind it to the renderer and it seems to have binded to the shader fine, but I call textureCube and it returns a weird float value that is completely incapable of returning true, false, or otherwise. I think it's an error, but I don't know why.

Even if the samplerCube isn't set correctly though, textureCube would then return 0.0 I would think. So why does it return an error?

P.S. I tried to check NaN and Inf, it is neither.

[GClements]

I bind it to the renderer and it seems to have binded to the shader fine, but I call textureCube and it returns a weird float value

Weird in what way? Outside of the 0..1 range?

that is completely incapable of returning true, false, or otherwise.

What is that supposed to mean?

Are you using a samplerCube and performing the comparison yourself, or using samplerCubeShadow? The latter is not valid to textureCube (which in later GLSL versions is only available in the compatibility profile; the core profile uses overloads of texture() rather than different functions for different texture types).

[devmane144]

Sorry I was a bit frustrated posting the original. I'm using samplerCube and its not returning seemingly any float value at all on textureCube. Like returning an error (which would usually happen at compile), which I thought was impossible.
I'm using glsl 120 purposely on an intel chip and ubuntu drivers.
Its supposed to return 1..0 on a depth cube map bound to the shader and if I do anything with the returned value from textureCube it blacks out every fragment, which is weird because its additive lighting, and if it were negative it would make everything slightly darker instead of making it completely black.
I was just wondering if it was a common problem, and asking for what I might be missing in my fragment shader.

[GClements]

I'm using glsl 120 purposely on an intel chip and ubuntu drivers.

GLSL 1.2 corresponds to OpenGL 2.1, which doesn't support depth-component cube maps (§3.8.1):

Textures with a base internal format of DEPTH_COMPONENT are supported by texture image specification commands only if target is TEXTURE_1D, TEXTURE_2D, PROXY_TEXTURE_1D or PROXY_TEXTURE_2D. Using this format in conjunction with any other target will result in an INVALID_OPERATION error.

If you're using a later version of OpenGL than 2.1, then I'd suggest changing the shaders to use the version of GLSL which corresponds to the OpenGL version.

[devmane144]

So in short, I should NOT be using depth component cube maps, but instead I can draw it to the color red to get the same effect using the color attachments? But checking APITrace I can clearly see that the cube map is being drawn, is it just not possible to sample it?

[GClements]

So in short, I should NOT be using depth component cube maps, but instead I can draw it to the color red to get the same effect using the color attachments? But checking APITrace I can clearly see that the cube map is being drawn, is it just not possible to sample it?

According to the OpenGL 2.1 specification, the glTexImage2D() call should fail if you try to create a depth-format cube map. If the call succeeds, then the implementation would appear to offer some functionality over and above OpenGL 2.1, but it's anyone's guess as to what will work and what won't. Have you checked whether it supports a GLSL version newer than 1.2?

The problems with simply using the red channel are
1. You can't use it as a depth buffer for rendering; you'd need to render each face using a depth-format 2D texture as the depth buffer then copy the pixel data into a face of a colour-format cube map.
2. You're limited to 16 bits (OpenGL 2.1 doesn't have any colour formats with more than 16 bits per component).

[devmane144]

Which version of opengl allows depth cube map textures? I updated all my shaders to glsl 330 and it didn't seem to do anything to fix this particular problem.

[GClements]

Which version of opengl allows depth cube map textures?

3.0.

I updated all my shaders to glsl 330 and it didn't seem to do anything to fix this particular problem.

Then maybe the issue lies elsewhere.

Are you calling glGetError() to check that no errors have occurred? If you're having problems, this should be called at least after initialisation and at the end of the drawing code.

Have you tried reading the depth data (with glReadPixels or glGetTexImage) to check that rendering is actually working?

[devmane144]

I ran glCheckError() in a loop after everything related to drawing, and found that the error is GL_INVALID_OPERATION, given after glDrawElements.

It works when the shadowCube basically returns 0, throwing no error, but when I enable it the shadow cube returns to breaking the pixel.

I ran glReadPixels on the center of the depth cube map, which returns 0.75, which would be 1.0 if it weren't drawing everything. So I'm pretty sure the depth cube is valid. For some reason it just won't sample it without breaking the float that it returns to.

I feel it's highly unlikely that this is just a driver error. I'm not using the geometry shader for the depth mapping, but the second reason for glDrawElements returning invalid operation honestly confuses me a lot: GL_INVALID_OPERATION is generated if a non-zero buffer object name is bound to an enabled array or the element array and the buffer object's data store is currently mapped.

From what I can glean from that horrendous definition, it has to do with VAOs, but my VAOs work fine as long as depth cubes don't get used in the shader at all.

P.S. I'm also assuming that if the samplerCube has no texture attached to it, that it will just return black always...?

[GClements]

I ran glCheckError() in a loop after everything related to drawing, and found that the error is GL_INVALID_OPERATION, given after glDrawElements.

That will occur if the program itself is invalid (did you check glGetProgram(GL_LINK_STATUS)?), or if some aspect of the state used by the program is invalid. In the specification, the details aren't listed in the sections related to the drawing functions (glDrawElements() etc) but those related to the functions which manipulate the state.

GL_INVALID_OPERATION is generated if a non-zero buffer object name is bound to an enabled array or the element array and the buffer object's data store is currently mapped.

From what I can glean from that horrendous definition, it has to do with VAOs, but my VAOs work fine as long as depth cubes don't get used in the shader at all.

It refers to the case where a draw call tries to read attribute data or indices from a buffer which is currently mapped (glMapBuffer() etc).

P.S. I'm also assuming that if the samplerCube has no texture attached to it, that it will just return black always...?

A sampler whose associated texture is incomplete (§8.17 in the 4.5 specification) returns 0 for a shadow sampler and (0,0,0,1) for anything else.