Properly support PSSM/CSM

ahmedismaiel · Post by **ahmedismaiel** » Wed Aug 13, 2008 4:53 pm

i'm not able to download it ,server it always busy
can you host it somewhere else or send it to me at ahmed_ismaiel [at] hotmail[dot] com ,i can test it for you on the latest version!

lf3thn4d · Post by **lf3thn4d** » Mon Aug 18, 2008 8:14 pm

sinbad is looking into the patch. so stay tuned.

Post by **sinbad** » Tue Aug 19, 2008 3:09 pm

It's committed to the v1-6 branch now. I tweaked a few things, and created a slightly more flexible version of the PSSMShadowCameraSetup which can work with a flexible number of splits and can also cope with more varied camera near / far setups (there's a tunable 'pad' factor to deal with the cracks between splits now rather than it being hardcoded). I also don't require UserDefinedObject use etc.

So far I've just demoed it in PlayPen::testTextureShadowsIntegratedPSSM since I don't have time to revise the main shadows demo just yet. It works

Thanks to lf3thn4d for the patch.

lf3thn4d · Post by **lf3thn4d** » Tue Aug 19, 2008 3:14 pm

Awsome!

I'll switch to this from my hack once I get the time. Woo hoo~! Something to look forward to

cdleonard · Post by **cdleonard** » Tue Aug 19, 2008 10:45 pm

It's really great this got squeezed into 1.6

I tried the PlayPen demo and the shadows seem to swim a lot; whenever I translate or rotate the camera. The debug overlays also seem to "jump" a lot on very small camera rotations; then come back. Is this expected? The effects decreases if I increase shadow texture resolution (default is 512).

lf3thn4d · Post by **lf3thn4d** » Wed Aug 20, 2008 3:25 am

That is the typical behavior for any PSM type shadow maps. LiSPSM has it pretty bad but it's the side effect of wanting to make full use of the shadow texture in all situation.

In a typical game, we use 1024 - 512 - 512 (6mb video ram)or 1024 - 1024 - 512(9mb video ram). However, if you are on high end machines, 1024 - 1024 - 1024(12mb video ram) fits perfectly. It's a bit taxing but way better than doing a single 2048.

But let's face it. If you have good textures and graphics for your game, nobody is going to talk about how much the shadow swims.

Caphalor · Post by **Caphalor** » Wed Aug 20, 2008 10:48 pm

Looks good, but it would be good if there was an auto param like:
param_named_auto pssmSplitPoints pssm_splitpoints
Or is this already implemented and I just don't see it?

lf3thn4d · Post by **lf3thn4d** » Thu Aug 21, 2008 8:23 am

No. there's no such thing yet. Right now you have to manually inject them into your material. Or you can do it the hacky way I did.

At any rate, the current PSSM shadow camera setup in ogre has a limitation. That is it's designed only for one camera. If there ever come to a case where you have multiple camera of different clip range, it will break.

From what I've experienced, different view clip range requires a lil tweaking to get optimum shadow. The Ideal way is to have them set inside Ogre::Camera itself. However, being that PSSM is more of an optional thing, it would be nuts to do that.

Right now, the best thing I could come out with is to make it application specific. See my Demo for more example.

beaugard · Post by **beaugard** » Thu Aug 21, 2008 9:22 am

The Ideal way is to have them set inside Ogre::Camera itself. However, being that PSSM is more of an optional thing, it would be nuts to do that.

Can't you just have a PSSMCamera class which inherits from Ogre's camera?

Post by **sinbad** » Thu Aug 21, 2008 10:01 pm

Personally I considered it extremely unlikely that you'd want the expense of 3x shadow renders for multiple cameras - scalability becomes a major issue. Plus, if your cameras are in the same world, they're likely to have the same clip distances to my mind.

Basically because the shadow camera classes are pluggable there's no way to guarantee that we can add autoparams to do this kind of thing for you. As it happens, it's really not that difficult to organise since you're really not likely to have lots of these with all different settings, all dynamically changing, it's just not remotely a normal use. I've used the new PSSM class and hooked it up to my materials easily with a single manual shader value assignment at init time. I think talk of auto params and subclassed cameras is way overkill.

lf3thn4d · Post by **lf3thn4d** » Fri Aug 22, 2008 9:41 am

sinbad: I'm thinking more along the lines of camera switching. This is especially useful for cut scenes or zooming based cameras. Usually cut scene cameras have different view distance. I dunno, i'm no artist here. I'm only just looking at some other working examples like heavenly sword.

At least that's the impression I got from this post: http://forum.beyond3d.com/showthread.php?t=41092#3

ahmedismaiel · Post by **ahmedismaiel** » Fri Aug 22, 2008 12:31 pm

I just tried it and it works great with me except for some artifacts whe switching between the LOD's, i'll post and example later once i got a reliable connection.

i was wondering why this in the 1-6 branch and not in the trunck!

Post by **haffax** » Fri Aug 22, 2008 1:52 pm

ahmedismaiel wrote:i was wondering why this in the 1-6 branch and not in the trunck!

It will be available in the trunk when the branch is merged into trunk the next time.
When managing a repository, you need some kind of merging procedure that avoids all the pitfalls of having to work on several versions of your software. One is to apply the change on the oldest applicable branch and let it trickle down to the trunk. This is how it is done in Ogre.

iigor · Post by **iigor** » Fri Aug 22, 2008 2:26 pm

First of all thanks for excellent demo.

But i have compiled it with point lights, and spot lights, but shadow textures stayed empty, then i have red the paper of this method where was saying that it is only applyible for directional lighting, so what about other types, how to use it with them?.

lf3thn4d · Post by **lf3thn4d** » Fri Aug 22, 2008 6:09 pm

iggor: you don't.

Use another pass for your other lights. The demo is forcing only directional light in the material as it's meant to be a PSSM only demo. PSSM only works with directional light. However, this new feature addition also means you can do point light shadow with cube shadow mapping.

aguru · Post by **aguru** » Sat Aug 23, 2008 4:40 pm

I was wondering if it is possible to use PSSM with Billboard Sets? If so, what would the material have to look like?

Thanks a bunch!

lf3thn4d · Post by **lf3thn4d** » Sat Aug 23, 2008 5:22 pm

yes. definately. PSSM just means multiple shadow map per light. Internally, it's still using Ogre's shadow system. All that is needed to take care of is to make sure your material has alpha rejection set. Then in the shadow casting fragment shader, sample your detail map while applying the detail's alpha channel into the colour's alpha channel output.

aguru · Post by **aguru** » Sun Aug 24, 2008 5:17 pm

Thanks for the help, lf3thn4d. I can't seem to figure out the right modifications to the shader file, though. Maybe you can help me out?

Caphalor · Post by **Caphalor** » Sun Aug 24, 2008 11:16 pm

If you want that transparent materials cast shadows, you should have a look at grass.cg and Examples.material (Ogre samples, trunk) or search for "shadow_caster_material" in the forums.
@Topic: I am using pssm with Caelum now and it works very good. Thank you for this great feature.

aguru · Post by **aguru** » Mon Aug 25, 2008 8:53 am

Thanks for the top, Caphalor. And thanks everyone who helped with the PSSM integrationn into Ogre.

ahmedismaiel · Post by **ahmedismaiel** » Tue Aug 26, 2008 2:12 pm

i have some trouble trying integrating this in ps3.0 shader (2.0 work great)
i get this error

Code: Select all

error X6077: texld/texldb/texldp/dsx/dsy instructions with r# as source cannot be used inside dynamic conditional 'if' blocks, dynamic conditional subroutine calls, or loop/rep with break*.

btw here is a generalized PCF to define soft shadows with any number of samples.

Code: Select all

#define PCF_SAMPS 7 

#define PCFH ((PCF_SAMPS-1)/2)
#define PCFT (PCF_SAMPS*PCF_SAMPS)
#define PCFSize 5

float shadowPCF(sampler2D shadowMap, float4 shadowMapPos, float2 offset)
{
	shadowMapPos = shadowMapPos / shadowMapPos.w;
	float2 uv = shadowMapPos.xy;
	float3 o = float3(offset, -offset.x) * 0.3f;//* 0.5f;

	float c=0;
	int i, j;
		for (i = -PCFH; i<= PCFH; i += 1) {
		for (j = -PCFH; j<= PCFH; j += 1) {
		float2 sample=float2(o.z*i,o.y*j);
			c +=		(shadowMapPos.z <= tex2D(shadowMap, uv.xy - sample).r) ? 1 : 0; // top right

		 }
		}
	return (c / PCFT)* 0.5+0.5;

}

i searched for a fix but i cann't say i understand how to do it using ddx,ddy

http://www.ogre3d.org/phpBB2/viewtopic. ... 6f4e2718c6
http://www.ogre3d.org/phpBB2/viewtopic. ... 6f4e2718c6

help!

Injector · Post by **Injector** » Thu Aug 28, 2008 6:58 pm

I've seen errors like this prior to updating to the latest version of DirectX.

ahmedismaiel · Post by **ahmedismaiel** » Sat Aug 30, 2008 10:14 am

I have the latest version ,it's a problem in PS3.0 design
i'll try to update to the latest cg version and see

Vectrex · Post by **Vectrex** » Sat Sep 13, 2008 6:57 pm

Just to clarify something, from playpen it looks like you choose PSSM instead of something like LiSPSM? I got the impression that you still used things like LiSPSM or whatever, but PSSM just rendered multiple resolution versions of it.

Post by **sinbad** » Tue Sep 16, 2008 8:43 pm

The PSSM class is actually derived from LiSPSM, it just changes the focus region for each of the sections. If later on we wanted it to be more pluggable, we would perhaps wrap another ShadowCameraSetup inside PSSM, rather than subclassing from LiSPSM. But right now it's fine like this.