Irrlicht Engine

Hi everyone!

I have been struggling for quite some time to implement PSSM, having no luck I finally tried to convert the GPU GEMS 3 example to Irrlicht.

I have actually got it up and running but there is a really weird problem... When the camera position is on one side of an item (3D object) it doesn't get rendered to the shadow map and so doesn't get shadowed at all (this works for any item, they just pop out/in of view when I move around).

I might not explain myself very clearly so I made a video of the problem.
I have deactivated textures and normal lighting, there is only the PSSM shader working. The different colours (in the video) are debug colors showing which shadow map the 3D-Objects pixels depends to (red is the first, then green, blue and pink).

Debug rendertargets are rendered on screen, the 4 topmost squares a the shadowmaps (top left corresponds to the red color, then the green etc), the second line are 'final output', glow (disabled here) and the third one of the second row is the lights 'view' (crop matrix considered) from the first shadowmaps rendering, you can see (as in the topmost row) the 3D-Object popping in and out / getting culled or not.


I have made no special changes to the GPU GEMs example except those to make it work with Irrlicht, well for what I'm worth anyway.
The problem seems to occur when like the delta XZ between the camera and the object (in worldspace, the video is made at like 150.000, 12.000 so relative coordinates doesn't change anything. The problem is the same at 1500 , 1500) is X>Z (X and Z here are the 'ground coordiantes', Y is height / up).

It seems that obviously the 3D-Object is getting culled (when it shouldn't be) and that is where I'm getting lost. I have checked the matrices and other data and well, at least they don't change abruptly anyhow (the values are changing linearly when I move around, no jumps or so).

I have tried orthogonal lighting as well as 'spotlight', big lights and small ones at no avail.

I must have done some really stupid error somewhere as the PSSM works really well but only when you look at objects from one side...

Any help appreciated!

You haven't cropped near and far plane in the crop matrix???
Because you need to pull the near plane quite far back to get all the objects outside the frustum to cast INTO the frustum.

You do realize that X and Y in post matrix space go -1.0 to 1.0 and Z from 0.0 to 1.0???? So you crop to length of 2 on XY and only 1 on Z

Also you could have got your entire matrix math entirely wrong (cropping the wrong thing in the wrong direction). That way the shadows would be still in the right place but the position in the shadowmap wouldnt.

Hi Devsh!

I know about the 'shadow-casters' / 'shadow receivers' thing but here I don't even get the self shadowing (when the 'bug' is active) so I don't think that's the problem.
I don't think I do anything to the near/far values, I don't even change them (well I do use a 'light-camera' to render but the near-far values should be okay there).
I also set the AABB frustum box z.min to zero (in light space) to get 'all' shadow casters.

If I have made some error with the shadow matrix, then things shouldn't (right?) pop in and out on it so I hope it is not that.

I think it is actually might be an Irrlich related problem, not an Irrlich bug but in the GPU GEMS example, they sort out the shadow casters / receivers and render them all when needed,
in Irrlicht there are some culling involved so maybe I have to update the 'light-camera' in some sort of way to not cull things but as you can see in the video, well, the 'earth' is there and the 'house' just pops out (or in) depending on which side I am of the 'house'... (the third square in the second row).

Thanks for the time and if you have more ideas about what it can be please do tell

ps. when the camera is on one side of (say) the north-east - south-west line, everything looks really perfect, on the other side, the item gets culled from the shadowmap (this happens individually, if I have 10 trees, some are on the shadowmap, others not).

Wrong position / target for the light was one of the problems, now it's working better even if it is not perfect (the bridge isn't lit even if it is in the shadowmap).

I'll be back when I have fixed those issues and added some nice filtering, ATM it looks like this (ground isn't rendered):

The question is, VSM or ESM or SSAO+PCF (as the two should benefit from each other)...

VSM or ESM will improve over PCF in many situations, and the good thing of both is that you can blur the shadow map to get the same results as the PCF, at the same cost of the VSM or ESM algorithms. And SSAO isn't incompatible with the VSM or ESM, right?

Mel, you seem to be the resident shadow guru. Do you know of any shadow algorithm that'd work in screen space?

All the shadow maps require rendering the geometry again for each light. SSAO/SSDO isn't suitable for shadowing, and the alias-free shadows appear to need cuda/opencl. Been reading up all day, and ended up with exactly nothing

Maybe the deferred shadow maps? If you have a depth buffer, you can create the shadowmapping pass, and later, blend it with the original image.

http://www.gamedev.net/topic/615900-dx9 ... adow-maps/

That merely collects all the shadow maps together, they still have the geometry overhead of once (or more!) per light.

I suppose it's a still hard problem, unlike for lighting. Perhaps I'll just have to do SSDO with no shadows and a dark ambient. Or invent a new shadow algorithm that scales to many lights

With multiple shadow mapped lights, there is no other way. except to use raytracing, and i don't know if that would be really useful or not. But the directional lights take into consideration all the visible camera space, besides the shadow casters. And it takes a single matrix to project a point into the shadow map. So, a shadow mapping shader with 4 projection matrices maybe projected to a 64 or 128bit rendertarget to have 4 shadowmaps (one per channel) at a time in a single pass with a decent precision. Then, it is filtered with ESM, and you may have 4 shadowmaps simultaneously. Add 4 rendertargets, and using MRT, you can have up to 16 shadowmaps generated in a single pass. Other thing is to calculate the shadows with the 4/16 shadow maps, and that can't be solved other way but one per shadowmap. Using the depth buffer would restrict the shadows calculation to 16 shadows per pixel. In a rough draft. This moves completely the geometry issue to the shader level, wich is the best scenario but i can't tell exactly how costly this approach would result.

That's fun, I'm actually trying to change and use deferred shadows

This is a bit because my terrain shader uses up more than 4 textures (so in an 'ordinary' situation I can't use 4 shadowmaps for the PSSM in it) but also because it seams much neater and easier to maintain, you just need to add a rendertarget to any existing shader and output the deptht (or depth, depth*depth for VSM, I don't know enough about ESM, gotta check that out better).
It also seems that a two pass box filter will produce the same quality as PCF but at higher speed used on a screenspace "shadow" (the result from the shadowmap pass) and then just "add it" on top of the back buffer (surely there are things I haven't thought about like non shadowing lighting etc but it seems like a nice idea).

I'm not sure (I'm still struggling with the position recreation from the depth value, should I go eye-space and try to rewrite the shadowshader or go ... euh... world space and keep the already working shader...) but I also felt that with deferred shadows, it will be easier to add static shadowmaps "just" by adding them into the existing shadowmaps (if they are the same colour right? Not sure if I'm on the right track here...).

ps. I hope SSAO isn't incompatible with VSM or ESM for sure but the idea was that when you are doing say 10 PCF lookups, you can use the same looked-up values for SSAO for virtually no cost and so on (simple box filtering filtering afterwards etc.)