Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: CSM / PSSM - Depth comparison

  1. #11
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,124
    Quote Originally Posted by Silverlan View Post
    Everything up until 00:12 is using a static bias of 0.001. It looks alright, but can lead to unpredictable artifacts if I change the light direction.
    At 00:12, I've switched to a slope bias, which I'm using for spot-light-sources as well:
    Code :
    float bias = 0.001 *tan(acos(cosTheta));
    'cosTheta' being the dot product between the vertex normal and the light direction.
    So... Let's suppose the light and normal are aligned. This will results in 0 bias. Which may help explain why you seem to be getting really bad self-shadowing artifacts (I assume you are casting light-space front-faces into the shadow map).

    You might look into some other techniques, such as Normal Offset Shadows (just websearch for it). In my experience, it seems to perform better.

    And before you trip over some "incomplete" info on the net that says casting back-faces is the solution, take a look at this.
    Last edited by Dark Photon; 01-18-2015 at 12:14 PM.

  2. #12
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    40
    Quote Originally Posted by Dark Photon View Post
    So... Let's suppose the light and normal are aligned. This will results in 0 bias. Which may help explain why you seem to be getting really bad self-shadowing artifacts (I assume you are casting light-space front-faces into the shadow map).

    You might look into some other techniques, such as Normal Offset Shadows (just websearch for it). In my experience, it seems to perform better.
    Thanks, I will try that as soon as I've solved the problem I mentioned in my other post.
    I narrowed the problem down to the spotlight shadow map. If I bind it to my shader in any way, my cascaded shadow maps aren't rendered correctly anymore.
    I've recorded a video of it with some more explanation (Annotations have to be turned on):
    http://youtu.be/VbWpnxrS6rw

    This doesn't make any sense to me. The spotlight shadow map is a valid 2D depth texture, nothing special about it.
    The cascaded shadow maps have no relation to the spotlight shadow map at all.
    What's going on here?

  3. #13
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    40
    After some more testing, I found the issue. Here are the declarations for all of the shadow maps in my fragment shader:
    Code :
    uniform sampler2DArrayShadow csmTextureArray;
    uniform sampler2DShadow shadowMaps[MAX_LIGHTS]; // MAX_LIGHTS is set to 8 in both the shader and the engine

    I have one directional light and one spot-light.
    The 3D depth texture of the directional light is bound to 'csmTextureArray'.
    The 2D depth texture of the spot-light is bound to 'shadowMaps[0]'.

    This causes the issue shown in my previous post.
    However, if I bind the 2D depth texture of the spot-light to ALL samplers in 'shadowMaps' (from 0 to MAX_LIGHTS), the problem doesn't occur anymore.
    So, in essence, it seems that ALL of the samplers have to be bound to a valid texture, even if the sampler isn't being used in the shader during the render pass.

    This is still somewhat a problem however. If I don't have any spot-lights (and therefore no 2D depth textures), I don't have anything I can bind to the samplers in the array. This means I would have to create a dummy depth texture, which exists at all times. I would also have to create a dummy 3D texture and cubemap texture (To account for the point-light sampler array later on).

    I'd rather avoid that if possible, is there anything else I could try?

  4. #14
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Oldenburg, Germany
    Posts
    190
    I think you just need to take care that the unused samplers aren't bound to a texture unit used in the shader. To be more precise it is an error to have samplers of different types be pointing to the same texture unit. glValidateProgram will fail in such cases.
    Take a look into the wiki.
    I didn't find another solution but binding unused samplers to unused image units myself, although I never ran into problems simply not assigning them besides the ValidateProgram failure.
    --
    Edit: There doesn't need to be any texture bound to the units for ValidateProgram to succeed.
    Last edited by hlewin; 02-04-2015 at 03:23 PM.

  5. #15
    Intern Newbie
    Join Date
    Dec 2012
    Posts
    40
    Quote Originally Posted by hlewin View Post
    I think you just need to take care that the unused samplers aren't bound to a texture unit used in the shader. To be more precise it is an error to have samplers of different types be pointing to the same texture unit. glValidateProgram will fail in such cases.
    Take a look into the wiki.
    I didn't find another solution but binding unused samplers to unused image units myself, although I never ran into problems simply not assigning them besides the ValidateProgram failure.
    --
    Edit: There doesn't need to be any texture bound to the units for ValidateProgram to succeed.
    Thanks, but they're all bound to different units already.
    I didn't know about 'glValidateProgram', but it returns "Program validation succeeded!".

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •