Databases
StackOverflow2013
Postsdbo
POOpenGL Pointlight Shadowmapping with Cubemaps
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POOpenGL Pointlight Shadowmapping with Cubemaps
    primarykey
    data
    text
    <p>I want to calculate the shadows of my pointlights with the following two passes:</p> <p>First, I render the scene from pointlight's view into a cubemap into all six directions with the scene-objects' modelspace, the according viewmatrix for the cubemap's face and a projection matrix with 90 degree FOV. Then I store the distance in worldspace between the vertex and the lightposition (which is the camera's position, so just the length of the vertex rendered in worldspace). Is it right to store worldspace here?</p> <p>The cubemap is a GL_DEPTH_COMPONENT typed texture. For directional and spotlights shadowing works quite well, but those are single 2D textures</p> <p>This is the shader with which I try to store the distances:</p> <p>VertexShader:</p> <pre><code>#version 330 layout(location = 0) in vec3 vertexPosition; uniform mat4 modelMatrix; uniform mat4 viewMatrix; uniform mat4 projectionMatrix; out vec4 fragmentPosition_ws; void main(){ gl_Position = projectionMatrix * viewMatrix * modelMatrix * vec4(vertexPosition, 1.0); fragmentPosition_ws = modelMatrix * vec4(vertexPosition, 1.0); } </code></pre> <p>FragmentShader:</p> <pre><code>#version 330 // Ouput data layout(location = 0) out float fragmentdist; in vec4 fragmentPosition_ws; void main(){ fragmentdist = length(fragmentPosition_ws.xyz); } </code></pre> <p>In the second step, when rendering the lighting itself, I try to get those distance values like this:</p> <pre><code>float shadowFactor = 0.0; vec3 fragmentToLightWS = lightPos_worldspace - fragmentPos_worldspace; float distancerad = texture(shadowCubeMap, vec3(fragmentToLightWS)).x; if(distancerad + 0.001 &gt; length(fragmentToLightWS)){ shadowFactor = 1.0; } </code></pre> <p>Notes: <code>shadowCubeMap</code> is a sampler of type samplerCube</p> <p><code>lightPos_worldspace</code> is the lightposition in worldspace (lights are already in worldspace - no modelmatrix)</p> <p><code>fragmentPos_worldspace</code> is the fragmentposition in worldspace ( * modelmatrix)</p> <p>The result is, that everything is lighted aka. not in shadow. I am sure, that rendering into shadowmap works. I tried several implementations of calculating the shadow and sometimes a saw something like shadows, that could be objects. BUT this was with NDC shadowdepths and not the distancemethod. So check this also for mistakes.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USgenpfault
    1. USFrischer Hering
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POOpenGL Pointlight Shadowmapping with Cubemaps
      1. This table or related slice is empty.
      1. VTDownMod
    1. CONo `viewMatrix` when rendering the depth values? How do you determine into which face of the cubemap the depth values go? Also, with a single export, `layout(location = 0)` is unnecessary because it's the default.
      singulars
      1. POOpenGL Pointlight Shadowmapping with Cubemaps
      1. USthokra
    2. CO@thokra No, no viewmatrix for the distancevalues when writing to the texture. In code I select my face after binding the framebuffer with: glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, face, _cubeMap, 0); face is GL_TEXTURE_CUBE_MAP_POSITIVE_X + i, where i goes from 0 to 5
      singulars
      1. POOpenGL Pointlight Shadowmapping with Cubemaps
      1. USFrischer Hering
    3. COMultiplying with viewmatrix for the distancevalues doesnt work better. Still everything lit. And additionaly with the projectionmatrix, either.
      singulars
      1. POOpenGL Pointlight Shadowmapping with Cubemaps
      1. USFrischer Hering
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload