Shadow Mapping
-
- Google Summer of Code Student
- Posts: 8
- Joined: Wed May 24, 2006 9:01 am
- Location: USA
Shadow Mapping
Hi everybody,
I'm working on the shadow mapping project for the Summer of Code. My wiki is at:
http://www.ogre3d.org/wiki/index.php/SoC2006_Shadows
So far I'm still working on getting Ogre's custom shadow mapping system up and running. Hopefully this'll be fixed soon so I can get onto the interesting stuff (the stuff I'm actually experienced with
As for community input, I'd also like to hear more about what custom shadow mapping variants people want to see. PCF, Variance Shadow Maps, etc.
People can also suggest variants for later based on changing the shadow map frustum. e.g., Plane Optimal, PSM, etc.
-- Hamilton
I'm working on the shadow mapping project for the Summer of Code. My wiki is at:
http://www.ogre3d.org/wiki/index.php/SoC2006_Shadows
So far I'm still working on getting Ogre's custom shadow mapping system up and running. Hopefully this'll be fixed soon so I can get onto the interesting stuff (the stuff I'm actually experienced with
As for community input, I'd also like to hear more about what custom shadow mapping variants people want to see. PCF, Variance Shadow Maps, etc.
People can also suggest variants for later based on changing the shadow map frustum. e.g., Plane Optimal, PSM, etc.
-- Hamilton
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Being new to Ogre you've been at a little bit of a disadvantage, especially in such a complex area, but it looks like it's all falling into place now
Personally I think regular PCF is a good place to start on the fragment end of the pipeline, and VSM is a good progression from that, although it does have precision issues. On the frustum end, I'm particularly interested by LiPSM and would love to see an implementation of that.
Personally I think regular PCF is a good place to start on the fragment end of the pipeline, and VSM is a good progression from that, although it does have precision issues. On the frustum end, I'm particularly interested by LiPSM and would love to see an implementation of that.
-
- Google Summer of Code Student
- Posts: 31
- Joined: Sun May 21, 2006 4:03 am
- Location: Sweden
- Contact:
I would like to see http://www.gamedev.net/community/forums ... _id=399014
-
- Google Summer of Code Student
- Posts: 8
- Joined: Wed May 24, 2006 9:01 am
- Location: USA
custom shadow maps
Hi, sorry, I was caught up with getting my coding done and neglected to check the message board. I've posted a (late) reply to your linked thread. I can also post the shaders I'm using, but they may take a bit of explanation (which I'm currently writing up).
-- Hamilton
-- Hamilton
-
- Google Summer of Code Student
- Posts: 8
- Joined: Wed May 24, 2006 9:01 am
- Location: USA
end of program
Well, I've committed my samples, engine code, and shadow readme to my branch of the repository.
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
review of project
I had a first look at your work.
First of all I want to say -nicely done and I really liked your paper.
here is a screen shot of your demo project:
Did you notice the hole in the shadow? (I circled it in red)
How can you configure\fix the demo\shadow so it won’t show this hole?
First of all I want to say -nicely done and I really liked your paper.
here is a screen shot of your demo project:
Did you notice the hole in the shadow? (I circled it in red)
How can you configure\fix the demo\shadow so it won’t show this hole?
Watch out for my OGRE related tweets here.
- flyswat
- Gnoblar
- Posts: 19
- Joined: Thu Mar 16, 2006 8:49 am
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
banding artefacts
What about the banding artefacts that occurs from certain angles?
Watch out for my OGRE related tweets here.
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
-
- Google Summer of Code Student
- Posts: 8
- Joined: Wed May 24, 2006 9:01 am
- Location: USA
Thanks.
Yes, the previous responses have been correct. There is a gap in the ogre model that causes some seeming artifact.
As for depth biasing, there are two parameters you can play with. One is exposed in the materials script as uDepthOffset. This effectively gives a push of uDepthOffset units in the z direction (in eye space coordinates).
The other parameter is in the custom shadow caster fragment program shader.
float depthval = postProj.z + (0.5 * dzlen)+ (uDepthOffset * ddepth);
You can change the 0.5 to something else. This affects how much offset you add that depends on the "depth slope." The depth slope is a measure of the uncertainty in the depth value you computed. If you use too large a number though, you may see specks of light bleeding through to the floor. This is because for polygons that are almost edge on to the light, the depth slope is nearly infinite (well, a very large number). So to fix this you could clamp the value you add.
I've just put a basic equation there, but I'm sure you could imagine more fancy ones that trade off the values according to your application's needs.
Yes, the previous responses have been correct. There is a gap in the ogre model that causes some seeming artifact.
As for depth biasing, there are two parameters you can play with. One is exposed in the materials script as uDepthOffset. This effectively gives a push of uDepthOffset units in the z direction (in eye space coordinates).
The other parameter is in the custom shadow caster fragment program shader.
float depthval = postProj.z + (0.5 * dzlen)+ (uDepthOffset * ddepth);
You can change the 0.5 to something else. This affects how much offset you add that depends on the "depth slope." The depth slope is a measure of the uncertainty in the depth value you computed. If you use too large a number though, you may see specks of light bleeding through to the floor. This is because for polygons that are almost edge on to the light, the depth slope is nearly infinite (well, a very large number). So to fix this you could clamp the value you add.
I've just put a basic equation there, but I'm sure you could imagine more fancy ones that trade off the values according to your application's needs.
-
- Kobold
- Posts: 36
- Joined: Wed Aug 30, 2006 2:37 pm
- Location: Bavaria, Germany
Do you have any issues compiling the current HEAD revision of the soc06-shadows branch? I get tons of linker errors with 5 unresolved externals in OgreMain: DefaultShadowCameraSetup::getShadowCamera, ctor and dtor, PlaneOptimalShadowCameraSetup::getShadowCamera and dtor.
This affects only the soc06-shadows branch (debug and release). The 'normal' HEAD compiles without errors.
This affects only the soc06-shadows branch (debug and release). The 'normal' HEAD compiles without errors.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
There is only one HEAD. You should check out the soc06-shadows branch in its entirety (cvs -z3 up -CAPd -rsoc06-shadows).
Note that if you're not using VC8, not all the project files will be up to date, you might need to add some new source files to the project files for your platform. This will be addressed officially when the branch is merged into HEAD.
Note that if you're not using VC8, not all the project files will be up to date, you might need to add some new source files to the project files for your platform. This will be addressed officially when the branch is merged into HEAD.
-
- Kobold
- Posts: 36
- Joined: Wed Aug 30, 2006 2:37 pm
- Location: Bavaria, Germany
-
- Google Summer of Code Student
- Posts: 8
- Joined: Wed May 24, 2006 9:01 am
- Location: USA
DirectX flicker
To get rid of the flickering shadows under DirectX when using the plane optimal algorithm, you have to do choose to allow double precision computations. DirectX defaults to choosing single-precision for you, despite declaring variables of double type.
You can fix this in the ogre.cfg file:
Floating-point mode=Consistent
After this, the numerical linear system solver can operate properly.
-- Hamilton
You can fix this in the ogre.cfg file:
Floating-point mode=Consistent
After this, the numerical linear system solver can operate properly.
-- Hamilton