Source code for Camera Space Shadow Mapping (CSSM)

Started by
4 comments, last by kingofthebongo2008 8 years, 5 months ago

Hi everyone,

Here is the source code for the original CSSM shadow mapping API: https://drive.google.com/file/d/0Bzrpqv04ufr9d0dZX3hTdl9hbVk/view?usp=sharing

It is missing the math library but things are pretty clear (left handed system + column major matrices and order of multiplication is from left to right). Sorry about some comments on Croatian language.

Paper is here: https://bib.irb.hr/datoteka/570987.12_CSSM.pdf

Sample projects are here (DX9 and DX10): http://free-zg.t-com.hr/cssm/

I still don’t have time to start working on “CSSM with Depth Histograms” (image attached), but maybe this will kick-start something.

I should probably make some kind of GitHub project with original CSSM and then slowly start updating it to Depth Histogram version (with the help of the community) but I’m currently too busy with my current project. So, if someone is willing to help out and compose starter project that would be great…

NOTE: I wouldn’t prefer using my old sample projects because they are MFC + DX Effects (which are not that commonly used any more).

Cheers,

--

Ivica Koli?

Advertisement

Demo looks impressive. smile.png

Single-shadowmap omni lights are a particularly nice feature. Didn't see the "light in front of camera" case so well in the video but it's visible in this screenshot: http://i.imgur.com/qUQTbfm.png

One minor issue though - I noticed that shadowmaps were slightly broken in one specific location - http://i.imgur.com/DDZkFhi.png. Seems like simply a case of depth bias/depth value space mismatch, though I'm not sure how hard it would be to fix in this case.

Thank you for the links. I'm very interested in exploring this further. Regards.

Demo looks impressive. smile.png

Single-shadowmap omni lights are a particularly nice feature. Didn't see the "light in front of camera" case so well in the video but it's visible in this screenshot: http://i.imgur.com/qUQTbfm.png

One minor issue though - I noticed that shadowmaps were slightly broken in one specific location - http://i.imgur.com/DDZkFhi.png. Seems like simply a case of depth bias/depth value space mismatch, though I'm not sure how hard it would be to fix in this case.

Yep, CSSM has some issues - probably due to the way projections are packed into textures - which causes some discontinuities. Maybe you can change the focus range to some smaller value - that should fix it.

I'm hoping that most of these issues will be solved with depth histogram version, but I'm yet to figure out exactly how to apply it on all possible cases. Directional light coming from a side is most basic case (displayed on image above) is relatively easy to figure out, but others might be tricky.

NOTE: Some people have been complaining about some weird things in my math library. That is exactly why I’ve omitted it from the code (some parts are ugly), but if someone needs it I’ll share it. Just let me know.

Things like these are sometimes unclear: does matrix.Inverse() inverts the “matrix” or returns a new matrix that is inverse of a “matrix”.

Most correct answer to questions like these is: if it returns the reference, then “matrix” is changed. If it returns a new matrix then… So, use intellisense :)

And/or check for the "const" keyword....

I will look deep inside this, thank you so much for sharing it!

I have recently been doing some shadows work but i centered myself on shadows from depth basic and applied some cascades stuff.

I would like to know, if possible, how my technic and that one differs on:

- versatility (I saw it is applied on more than directional lights which is a really nice improvement).

- filtering

- accuracy

- performance

- if there are more and you feel to extend it is also well received by me biggrin.png

Nonetheless my deepest congratulations for your effort! Its a great demo.

Thank you so much.

Hello, I am reading the paper, so far one thing i cannot understand is.

1. During the shadow pass generation, it is written: Then, the perspective-correct UV coordinates can be determined, and the actual test can be performed: stretched pixel p belongs to the triangle if the UV coordinates are positive and their sum is smaller than 1.

What happens if the pixel does not pass the test. It is killed by the shader, right?

I am asking, because it can be a performance problem if hiz depth rejection cannot be used during shadoew generation.

This topic is closed to new replies.

Advertisement