Jump to content

  • Log In with Google      Sign In   
  • Create Account

Silverlan

Member Since 02 May 2013
Offline Last Active Yesterday, 11:12 PM

Posts I've Made

In Topic: [PhysX] Allow players to slide down slopes / Controller contact callbacks

Yesterday, 08:38 AM

Thanks, that works, but I still need to get rid of the default behavior.

Setting the non-walkable mode to PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING prevents me from applying any up- or downwards force while the controller is on a slope, so I can't use that.

And as I've said, PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING applies some default force that can't seem to be changed and isn't linked to the default gravity.

 

These are the only two settings available though. I've tried setting the step offset to 0 or 90 degrees with both settings, but that didn't help.

 

What I need is essentially what PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING does, just without the force which seems to be applied from PhysX itself.

 

// Edit

Actually nevermind, looks like there's no force being applied from PhysX after all, it seems to be caused from something on my part.

 

// Edit²

I found the issue, not sure what I can do to fix it though.

In my test case the physics are simulated 33 times per second. My test object is simply moved downwards by 1 unit before every simulation step.

If there aren't any obstacles in the way, the object's speed after the simulation is exactly 33, which is exactly the way it should be.

However, if the object hits a slope, the speed actually jumps up, which doesn't make much sense to me. On a slope with an 45 degree angle, the object's speed jumps up to 51.421 (Shouldn't it slow down somewhat?).

The resulting speed is then used for the next simulation step and thus keeps increasing, which leads to the massive acceleration I've been experiencing.

So, once again, I'm stuck.


In Topic: [OpenGL] Cascaded shadow mapping - Render shadows to world?

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:

9dd8a6c6b2.jpg

 

 

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
);

In Topic: [OpenGL] Cascaded shadow mapping - Render shadows to world?

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:

 

47c52eb467.jpg

 

 

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)


In Topic: [OpenGL] Cascaded shadow mapping - Render shadows to world?

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?


In Topic: [OpenGL] Cascaded shadow mapping - Render shadows to world?

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;
float GetShadowCoefficient()
{
	int index = numCascades -1;
	mat4 vp;
	for(int i=0;i<numCascades;i++)
	{
		if(gl_FragCoord.z < csmFard[i])
		{
			vp = csmVP[i];
			index = i;
			break;
		}
	}
	vec4 shadowCoord = vp *(M *vertPos);

	shadowCoord.w = shadowCoord.z;
	shadowCoord.z = float(index);
	shadowCoord.x = shadowCoord.x *0.5f +0.5f;
	shadowCoord.y = shadowCoord.y *0.5f +0.5f;
	float z = shadow2DArray(csmTextureArray,shadowCoord).x;
	return z;
}
[...]

PARTNERS