Soft Shadows (w/o EA) Demo (99% done, released)

[TheSHEEEP]

Okay, I played around with attenuation but it didn't have any effect on the pixelation of the shadows. Setting the Texture Size to 4096 helped alot... and decreased the fps to 10

Does the size of the original texture of the mesh have any effect? I ask because I noticed the shadows being better on another mesh (the pyramid) that has a texture with a lower resolution (600x600 in comparison to 1000x1000).

If yes, is there another way to increase the "number of pixels/squares" per shadow, other than increasing the texture size?

[nullsquared]

Hm. Yeah, I'm pretty confident the precision issues are due to the scale of the world (1 unit = 1 inch is a lot bigger in units than, for example, 1 unit = 1 meter). This is because the depth metric that was used was linear world-space distance - for me, it might range from 0-100 at the most, but for you it might range from 0 to a lot more, since your world is in inches. Out of curiousity, can you scale your world up/down? Just take the root scene node and scale it up/down. Any different results?

Once again, I apoligize for making it such a rough process when the scenes don't really match up. This is why shadows are so scene dependent, they might look perfect in one setup but fail horribly in another setup until at least 100 tweaks are employed

[SwenSin]

They're soft shadows. Whether they're correct soft shadows or not is a different story.

Yes and that's the story I was talking about. And Lol well you can believe me I'm well aware of all technical difficulties when it comes to real-time soft shadows. To see some more robust and more correct looking soft-shadows in games from what I see as a developer I say we probably need min 2 max 4 more GPU generations since there are more important features on the waiting list.

Erasing the previous development history in the whole industry by giving previously used names to different features always causes some problems.

[nullsquared]

And to be quite honest... I don't think "true" soft shadows would be too useful in games. It'll look very odd without some "true" global illumination that has soft shadows at all bounces. Which, once again, makes the technical difficulties even worse. I think the win-win situation is some basic light SSAO, combined with some fast RTGI (see Lightsmark) that doesn't necessarily need to compute any occlusion, along with some fast "fake" soft shadows.

[SwenSin]

And to be quite honest... I don't think "true" soft shadows would be too useful in games. It'll look very odd without some "true" global illumination that has soft shadows at all bounces.

You must be joking, right? If what you say is true, then Pixar would probably not use soft-shadows in their earliest animations. Look for yourself...

If what you say is true. Then all the artists in the world before the GI era would never use soft-shadows in their animations or pictures. Actually soft-shadows help pictures have a more natural even GI looking feel. Even without SSAO and RTGI. Actually SSAO can make things look pretty odd if it's not used carefully - especially on concave corners which in other words represent wall corners in buildings (in reality they don't really get that dark because the light bounces between them and redistributes the energy)

To say what feature is useful or not it's good to work with talented designers since coders... well how to say it... don't have such graphic minds

[beaugard]

You must be joking, right? If what you say is true, then Pixar would probably not use soft-shadows in their earliest animations. Look for yourself...

I don't think he's joking and I think his assessment of what is a good collection of techniques for todays hardware is quite uncontroversial.

What do you think the next technology step will bring? Clearly not real soft shadows, since they are several GPU generations away.

[nullsquared]

You must be joking, right?

We're talking about games here. Games are too dynamic, too unpredictable. You'll rarely find a scene with 1 perfect area light, 2 boxes, and nicely coloured walls. Or a nice, big plane with a couple of spheres. Or a perfectly positioned torus alongside 3 steps and a teapot. No, you won't find that in a game. It'll be a long time before we get to a good technique that does correct soft shadowing (no, not a penumbra estimation with a blocker search) in complete real time for multiple lights for all visible geometry with no visible artifacts. And what about mirrors and portals and TV's and stuff? No, you won't find them in the perfect little testing scenario (which, on another point, usually does ray tracing, even though we're talking rasterization here) - but you WILL find them in games, tripling and quadrupling the cost of the final scene.

[SwenSin]

Our (mostly my) tests and expriements have clearly shown that with 3 soft-shadow techniques we were able to light even very very dynamic interior scenes with many many objects, pre-baked ligthning and ambient-occlusion as well without any really "unswallowable" artifacts/glitches (those were really really heavy, dynamic and top quality scenes... won't tell you the company's name). By my standards and standards of our designers it all blended very well together. The only problem was the speed that basically just crippled at average 0,4 to 1,8 fps (8800gtx.. well heavy heavy stunning scenes.. tests aimed at glitches and artifacts). But the results were really really great. Actually all these real-time faky faky shadow techniques will result in artifacts... soft-shadows included.. but hey we can live with "some" artifacts and looks like gamers are not really protesting...

So Nullsquared, is there something going on between you and soft-shadows? I mean you first start misdirecting the issue I posted into "uaaa soft shadows won't look good" which is something not really smart to say into "uaa artifacts" which is pretty just common knowledge and I've yet to see a perfect game with non-artifacty shadows. So let's say we agree on the all logical facts but maybe just we have like 20% disagreement on the name issue. Yes we also agree that this is not the best time to use soft-shadows throughout the whole game.. but there are always scenes which are not that heavy (ussualy indoor ones) which can run a certain soft-shadow technique very well and we're using that for the next 2 games which are in production (yes lol well not portal games).

Case closed I guess .... please continue your beautiful work and bring more features to Ogre. But give soft-shadows some rest.. please.. they deserve it I have to now spend the rest of this weekend visiting my family in Europe.. hell..

[nullsquared]

Alright, I'll call them edge-anti-aliased shadows (even though this example showed the simplest of VSM) for the sake of not bringing in new forum posters out of no where to argue with.

[TheSHEEEP]

Hm. Yeah, I'm pretty confident the precision issues are due to the scale of the world (1 unit = 1 inch is a lot bigger in units than, for example, 1 unit = 1 meter). This is because the depth metric that was used was linear world-space distance - for me, it might range from 0-100 at the most, but for you it might range from 0 to a lot more, since your world is in inches. Out of curiousity, can you scale your world up/down? Just take the root scene node and scale it up/down. Any different results?

I scaled it, but it didn't have any effect. What I'll try now is changing the texture size itself (from 1000x1000 to something else), because I noticed that the pyramid entity had a better shadow than the level entity.

Edit:

I played around with the texture itself, changing its format (jpg, tif, etc. ) and its size, but none of that had any effect on the shadows.
That really is weird.

Here is a direct comparison between the "good" shadows on the pyramid and the "bad" ones on the ground.



Any ideas on that? o.O


And this is what happens when I scale the Unit of the level entity mesh to (1 unit = 1 meter ).... Let's say it didn't quite do the trick.
I scaled the level by 4 to be able to walk on it (since changing to meter made the mesh a bit smaller in 3ds max ).

Once again, I apoligize for making it such a rough process when the scenes don't really match up. This is why shadows are so scene dependent, they might look perfect in one setup but fail horribly in another setup until at least 100 tweaks are employed

Yeah, well... we'll get it working somehow. And if not, we will just leave shadows out of the game or make stencil shadows only for the Lemmings or something else along those lines

Btw... nice cookie.
And sorry for spamming pics here.

[mix7eart]

Hi,

Thank you very much nullsquared for your soft shadow program.

I add a cube in the scene with the material metal. This cube cast shadow on the ground "plane" but it isn't lighted by the spotlight.
The ground "plane" is correclty lighted with the same material.

Moreover, if I add a another mesh from Maya with the material described below, this mesh appears completely black ?

I think there is something to do with multiple pass but I don't know exactly how. Can you help me a little?
Thank you.

material garden_earth
{
technique
{
pass
{
ambient 0 0 0 1
diffuse 1 1 1 1
specular 0 0 0 1
emissive 0 0 0

texture_unit
{
texture grass.jpg
tex_coord_set 0
colour_op modulate
scale 1 1
scroll 0 0
rotate 0
}
}
}
}

[mix7eart]

@TheSHEEEP
At the beginning, I had the same poor shadows as you. In fact, it was the spotlight which was too far from the scene.

[TheSHEEEP]

@TheSHEEEP
At the beginning, I had the same poor shadows as you. In fact, it was the spotlight which was too far from the scene.

Interestingly, that worked. I had not tried that after editing the shader files. Now I need the spotlight to "shine" on everything in the scene from the same direction... that will probably be quite hard... Though I'm happy it works now

[nullsquared]

@TheSHEEEP
At the beginning, I had the same poor shadows as you. In fact, it was the spotlight which was too far from the scene.

Interestingly, that worked. I had not tried that after editing the shader files. Now I need the spotlight to "shine" on everything in the scene from the same direction... that will probably be quite hard... Though I'm happy it works now

Wait, you mean that completely solved it? What about smaller shadow maps (like 1024x1024)? Definitely, distance from the scene will affect the shadows. Seems like you want the spotlight to have a single direction for all objects? This is simple. Open up 00diffuse.cg:

Code: Select all

// find this:
// direction
float3 ld0 = normalize(lightPos0.xyz - (lightPos0.w * IN.wp.xyz));

// and replace it with this:
// direction
float3 ld0 = normalize(-IN.sdir);

Now all objects will have the same spot light direction, regardless of the spot light's position. So just play with its position to get the shadowing looking good. Note that you can use about a 120 degree spotlight to cover a wide area with a single shadow map.

Also, out of curiousity, can I have a screen shot of what it looks like now? I like your visual style, just wanted to see how it integrates with these shadows .

[nullsquared]

Hi,

Thank you very much nullsquared for your soft shadow program.

I add a cube in the scene with the material metal. This cube cast shadow on the ground "plane" but it isn't lighted by the spotlight.
The ground "plane" is correclty lighted with the same material.

So, both objects use the same material? In that case, it sounds like the cube has incorrect normals. Verify that the cube has correct normals, otherwise the lighting will not work on it.

Moreover, if I add a another mesh from Maya with the material described below, this mesh appears completely black ?

I think there is something to do with multiple pass but I don't know exactly how. Can you help me a little?
Thank you.

The material you posted is not using the diffuse shaders that are needed to have correct lighting and shadowing - in fact, looks like it's only using the fixed function pipeline. Look at how the metal and ogre(head) materials are created, follow the same guideline for your own. Alternatively, you can write your own shaders that follow the same shadowing code from the example diffuse shaders, if you don't know about shader programming then you'll want to stick with the example diffuse shader.

[mix7eart]

So, both objects use the same material? In that case, it sounds like the cube has incorrect normals. Verify that the cube has correct normals, otherwise the lighting will not work on it.

Yes, it was normals!!

The material you posted is not using the diffuse shaders that are needed to have correct lighting and shadowing - in fact, looks like it's only using the fixed function pipeline. Look at how the metal and ogre(head) materials are created, follow the same guideline for your own. Alternatively, you can write your own shaders that follow the same shadowing code from the example diffuse shaders, if you don't know about shader programming then you'll want to stick with the example diffuse shader.

Sorry, I'm not familiar with shaders. But finaly, I have understood how your code works... and I modified my shader accordingly.
Thanks a lot !!

[TheSHEEEP]

Wait, you mean that completely solved it? What about smaller shadow maps (like 1024x1024)?

This decreases the quality of the shadows. A lot.

Definitely, distance from the scene will affect the shadows. Seems like you want the spotlight to have a single direction for all objects? This is simple. Open up 00diffuse.cg:

Code: Select all

// find this:
// direction
float3 ld0 = normalize(lightPos0.xyz - (lightPos0.w * IN.wp.xyz));

// and replace it with this:
// direction
float3 ld0 = normalize(-IN.sdir);

Now all objects will have the same spot light direction, regardless of the spot light's position. So just play with its position to get the shadowing looking good. Note that you can use about a 120 degree spotlight to cover a wide area with a single shadow map.

Doesn't quite work, all objects get their shadow from a different direction. Maybe this is because we already did some changes on the diffuse with omni -> spotlight?

Also, out of curiousity, can I have a screen shot of what it looks like now? I like your visual style, just wanted to see how it integrates with these shadows .

Sure ( best results I got so far, still requires some work with light intensity etc. ):



There are some things I noticed:

1. The farther away the light, the worse the quality. (well, we already knew that)
2. The bigger the spotlightrange, the worse the quality. (setting it to 120 resulted in the worst quality ever )

[Vectrex]

you know.. for a scene like that I wouldn't even bother with true shadow mapped shadows.
I'd just use plain old non-self shadowing texture shadows with the Lispsm camera setup. See my screenshots for an example.
Obviously it's cooler to have self shadowing but it wouldn't be as noticable in your scenes as say mine.

btw Can Lispsm camera setup be used with this Null? Wouldn't that totally solve the precision issue? I get the feeling VSM isn't compatible since I have only vaguely looked into it

[nullsquared]

btw Can Lispsm camera setup be used with this Null? Wouldn't that totally solve the precision issue? I get the feeling VSM isn't compatible since I have only vaguely looked into it

I tried it, but it came out with ugly banding artifacts at small ranges between casters and receivers. Personally, I just use a standard camera setup, no special setups.

[xadhoom]

I tried it, but it came out with ugly banding artifacts at small ranges between casters and receivers. Personally, I just use a standard camera setup, no special setups.

I also thought about using Lispsm camera setup with your technique. Do you
mean this does not work?

[mix7eart]

Hi

How can I do to select materials which cast or not shadows?

Thanks

[xadhoom]

May be this answers your question:

http://www.ogre3d.org/phpBB2/viewtopic. ... highlight=

[Zeal]

Hey im getting a strange VS2005 error at the following line (in the shadow setup portion)...

Code: Select all

    const unsigned numShadowRTTs = mgr.sceneMgr->getShadowTextureCount();
    for (unsigned i = 0; i < numShadowRTTs; ++i) {
        Ogre::TexturePtr tex = mgr.sceneMgr->getShadowTexture(i);
        Ogre::Viewport *vp = tex->getBuffer()->getRenderTarget()->getViewport(0);
        vp->setBackgroundColour(Ogre::ColourValue(1, 1, 1, 1));
        vp->setClearEveryFrame(true);
        //Ogre::CompositorManager::getSingleton().addCompositor(vp, "blur");
        //Ogre::CompositorManager::getSingleton().setCompositorEnabled(vp, "blur", true);
    }

..this one line in particular...

Code: Select all

  Ogre::Viewport *vp = tex->getBuffer()->getRenderTarget()->getViewport(0);

...is causing the following error...

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

No errors in the ogre log, and things work fine if I comment out that one line. Im using Eihort 1.4.9. Any ideas?

*heres the last bit of the ogre log, note it seems like it creates the cameras/viewports fine, then it just ends...

23:45:01: WARNING: Texture instance 'Ogre/ShadowTexture0' was defined as manually loaded, but no manual loader was provided. This Resource will be lost if it has to be reloaded.
23:45:01: WARNING: Texture instance 'Ogre/ShadowTexture1' was defined as manually loaded, but no manual loader was provided. This Resource will be lost if it has to be reloaded.
23:45:01: WARNING: Texture instance 'Ogre/ShadowTexture2' was defined as manually loaded, but no manual loader was provided. This Resource will be lost if it has to be reloaded.
23:45:01: WARNING: Texture instance 'Ogre/ShadowTexture3' was defined as manually loaded, but no manual loader was provided. This Resource will be lost if it has to be reloaded.
23:45:01: Creating viewport on target 'rtt/1898720', rendering from camera 'Ogre/ShadowTexture0Cam', relative dimensions L: 0.00 T: 0.00 W: 1.00 H: 1.00 ZOrder: 0
23:45:01: Creating viewport on target 'rtt/1899296', rendering from camera 'Ogre/ShadowTexture1Cam', relative dimensions L: 0.00 T: 0.00 W: 1.00 H: 1.00 ZOrder: 0
23:45:01: Creating viewport on target 'rtt/1899840', rendering from camera 'Ogre/ShadowTexture2Cam', relative dimensions L: 0.00 T: 0.00 W: 1.00 H: 1.00 ZOrder: 0
23:45:01: Creating viewport on target 'rtt/1900384', rendering from camera 'Ogre/ShadowTexture3Cam', relative dimensions L: 0.00 T: 0.00 W: 1.00 H: 1.00 ZOrder: 0

*I wonder, do you really NEED to set the background color to white? And do you really need to set clear every frame to true?

I have just never seen visual studio spit up this error before so im kind of curious....

[nullsquared]

Are you building from scratch using the matching libraries? The demo is compiled with mingw, so you have to make sure you're not mixing in anything mingw-related such as the DLLs.

As for clearing it to white every frame - it's not really all that necessary, I guess. I just like having pace at mind knowing that my texture will not contain any garbage whatsoever before using it

[Zeal]

Libraries? What libraries? I thought this was just a collection of shaders/materials. I am using the Ogre SDK if thats what you mean.

Now that you mention mingwm... I notice the mingwm dll being used in the demo, what exactly is that for? Sorry I saw no mention of it anywhere on this thread or in the readme..