• Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at \$59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

27 replies to this topic

### #21Silverlan  Members   -  Reputation: 351

Like
0Likes
Like

Posted 24 September 2014 - 02:21 PM

Did you set GL_TEXTURE_COMPARE_MODE too ? eg

glTexParameterf(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_REF_TO_TEXTURE)

Thank you, that seems to be going in the right direction, but introduced a bunch of other issues:

Offsetting the 'w'-component doesn't help a lot either.

### #22vlj  Members   -  Reputation: 207

Like
2Likes
Like

Posted 24 September 2014 - 04:37 PM

I'm wondering, you're computing the shadow coord in the vertex shader : what happens if a triangle has vertex in two different cascade ?

It may explain the artifact you're experiencing

### #23Silverlan  Members   -  Reputation: 351

Like
0Likes
Like

Posted 24 September 2014 - 11:19 PM

I'm wondering, you're computing the shadow coord in the vertex shader : what happens if a triangle has vertex in two different cascade ?

It may explain the artifact you're experiencing

I've swapped it to the fragment shader, but the result hasn't changed:

[...]
in vec4 vertPos;
{
mat4 vp;
{
if(gl_FragCoord.z < csmFard[i])
{
vp = csmVP[i];
index = i;
break;
}
}
vec4 shadowCoord = vp *(M *vertPos);

return z;
}
[...]


### #24Silverlan  Members   -  Reputation: 351

Like
0Likes
Like

Posted 06 October 2014 - 03:25 PM

Update:

It looks like the issue with the shadows being cut off occurred because the area I used for the orthographic matrix was too small.

I've implemented a culling-algorithm to get the tightest area around all shadow casters and that fixed it:

There's still two problems left however. If any shadow is around the edges of a cascade, it will stretch massively (As shown in the video), and the self-shadowing looks extremely off. I'm assuming the latter is just some texture parameters I'm missing?

### #25L. Spiro  Crossbones+   -  Reputation: 14411

Like
3Likes
Like

Posted 06 October 2014 - 07:25 PM

Textures “stretch” when they reach borders. Use clamp-to-border sampling to avoid it and use a border color of 1. Or make sure the objects can’t render to the end of the shadow maps.

L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

### #26Silverlan  Members   -  Reputation: 351

Like
0Likes
Like

Posted 06 October 2014 - 11:48 PM

I had already tried the clamp-to-border parameters, but I didn't know you could change the border color like that, that fixed it.

By the way, I actually used your tutorial for the culling.

It was very easy to follow, very well explained and works like a charm! Thank you!

The last major issue is the self-shadowing:

The light is pointing straight down, so the shadow should start right below the branches (e.g. at the encircled area), but it seems to start a fair bit further down and there are some 'holes' in the shadow, which don't exist on the cascade maps.

// Edit

I tried messing around with glPolygonOffset when rendering to the shadow cascade maps, but that didn't help. (I tried fairly large positive and negative ranges)

Edited by Silverlan, 07 October 2014 - 02:52 AM.

### #27L. Spiro  Crossbones+   -  Reputation: 14411

Like
1Likes
Like

Posted 07 October 2014 - 08:00 PM

From the images of the shadow maps, it appears you have clamped the near and far planes to encompass exactly the range from the top of the highest branch to the bottom of the trunk (the tree takes the full depth range).

If you will notice, the shadow itself seems to cover exactly half of that range over the tree.

This is likely because depth values in OpenGL cover the range from -1 to 1 rather than from 0 to 1 like in Direct3D.

Since your image of the shadow map isn’t clipping off negative values, it means either you are only using the 0-to-1 range inside the shadow map or that you have accounted for this upon displaying of the shadow map.

How are you writing depth values?

If you are manually calculating depth values to write into the shadow map, stretch them over the [-1,1] range.

Otherwise you have a problem with the bias matrix, which should have its Z scale halved and the Z offset increased by an additional 0.5f.

Since the the values closer to 1 are being used progressively more correctly starting at half the range of the shadow, I would assume the problem is in how the depth values are being written.  Writing to only the [0,1] range would have such a result, whereas improperly biasing would have the opposite result (shadows would start more correct near the top of the tree and then at the mid-way point everything would become black, non-shadowed, or stretch-shadowed (depending on how you handle Z >= 1.0f in the shader).

L. Spiro

Edited by L. Spiro, 07 October 2014 - 08:09 PM.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

### #28Silverlan  Members   -  Reputation: 351

Like
0Likes
Like

Posted 08 October 2014 - 12:23 PM

From the images of the shadow maps, it appears you have clamped the near and far planes to encompass exactly the range from the top of the highest branch to the bottom of the trunk (the tree takes the full depth range).

That's correct.

If you will notice, the shadow itself seems to cover exactly half of that range over the tree.

After taking a closer look at the shadow on the tree, this seems very likely.

Since your image of the shadow map isn’t clipping off negative values, it means either you are only using the 0-to-1 range inside the shadow map or that you have accounted for this upon displaying of the shadow map.

How are you writing depth values?

If you are manually calculating depth values to write into the shadow map, stretch them over the [-1,1] range.

The fragment shader for the shadow maps does nothing but write the depth value unmodified:

gl_FragDepth = gl_FragCoord.z;


I assume by stretching it you mean:

gl_FragDepth = (gl_FragCoord.z *2.0) -1.0;


However that leaves me with:

Otherwise you have a problem with the bias matrix, which should have its Z scale halved and the Z offset increased by an additional 0.5f.

That's what I'm doing, pretty sure my bias matrix is correct:
static const glm::mat4 bias(
0.5f,0.0f,0.0f,0.0f,
0.0f,0.5f,0.0f,0.0f,
0.0f,0.0f,0.5f,0.0f,
0.5f,0.5f,0.5f,1.0f
);

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS