FanZhang

05-30-2007, 09:51 AM

Hi,

Many thanks to those who are interested with "Parallel-Split Shadow Maps".

For your convenience, I updated the project webpage for PSSMs, you may get all related information from

http://www.cse.cuhk.edu.hk/~fzhang/pssm_project

By the way, I added some brief analysis for partioninig shadow map algorithms (like PSSMs, CSMs ...) on my project webpage. Here I want to address two highlights in my PSSMs in comparison with other partitioning algorithms,

----------------------you may see more details on my webpage---------------

Question: What are the differences between PSSM and CSM (Cascaded Shadow Maps)?

Answer: Everything doesn't come from nowhere. PSSMs are not an exception as well. The idea of using multiple shadow maps was introduced in Tadamura et al. ("Rendering optimal solar shadows with plural sunlight depth buffers") 2001 and further studied in Lloyd et al. ( "Warping and Partitioning for Low Error Shadow Maps ") 2006, and it was also implemented as cascaded shadow mapping in Futuremark's benchmark application 3DMark 2006.

PSSMs better handle the following two major problems in all these algorithms:

1) How to determine the split positions?

For this issue, we proposed the practical split scheme to achieve a better tradeoff between theory and practice. See our paper for more information. Surely, the split positions also can be sometimes pre-computed or manually adjusted. Let me share you my personal experience of studying an "practical" split scheme during the past. When I first saw the nice papers "light space perspective shadow maps (ESGR'04)", I thought the logarithmic split scheme might be the best choice. This split scheme has been implemented in "Warping and Partitioning for Low Error Shadow Maps (ESGR'06)" and "logarithmic shadow maps (Sketch paper in SIGGRAPH'06)". However, as explained in our paper, it might not be very good to EXACTLY simulate this split scheme on discrete buffers to produce the theoretically even distribution of perspective aliasing over the whole depth range. The logarithmic split scheme usually results in an "over-strong" split effect in practice. For example, for n=1 and f=1000 in PSSM(3), the first split part only occupies the first 1% of the depth range! I know this conclusion might be a little bit "subjective", I strongly recommend you to try all the three splits schemes (uniform, logarithmic, practical) to get your own conclusion. In general, the practical split scheme is more flexible for most cases.

2) How to alleviate the performance drop caused by multiple rendering passes?

For this issue, in our Gems 3 paper, we thoroughly discussed this issue. For the split scheme PSSM(m) (the frustum is split into m parts), the number of rendering passes for 1) without hardware-acceleration, 2) with DX9-level HW-accel. and 3) with DX10-level HW-accel. are 2m, m+1 and 1+1 respectively. In particular, in comparison with the standard shadow mapping approach, we reduce ALL extra rendering passes in our DX10 implementation. For more details, see the upcoming book GPU Gems 3 and the accompanying source codes.

Any suggestion will be appreciated. Thanks.

Best Regards,

Fan Zhang

Many thanks to those who are interested with "Parallel-Split Shadow Maps".

For your convenience, I updated the project webpage for PSSMs, you may get all related information from

http://www.cse.cuhk.edu.hk/~fzhang/pssm_project

By the way, I added some brief analysis for partioninig shadow map algorithms (like PSSMs, CSMs ...) on my project webpage. Here I want to address two highlights in my PSSMs in comparison with other partitioning algorithms,

----------------------you may see more details on my webpage---------------

Question: What are the differences between PSSM and CSM (Cascaded Shadow Maps)?

Answer: Everything doesn't come from nowhere. PSSMs are not an exception as well. The idea of using multiple shadow maps was introduced in Tadamura et al. ("Rendering optimal solar shadows with plural sunlight depth buffers") 2001 and further studied in Lloyd et al. ( "Warping and Partitioning for Low Error Shadow Maps ") 2006, and it was also implemented as cascaded shadow mapping in Futuremark's benchmark application 3DMark 2006.

PSSMs better handle the following two major problems in all these algorithms:

1) How to determine the split positions?

For this issue, we proposed the practical split scheme to achieve a better tradeoff between theory and practice. See our paper for more information. Surely, the split positions also can be sometimes pre-computed or manually adjusted. Let me share you my personal experience of studying an "practical" split scheme during the past. When I first saw the nice papers "light space perspective shadow maps (ESGR'04)", I thought the logarithmic split scheme might be the best choice. This split scheme has been implemented in "Warping and Partitioning for Low Error Shadow Maps (ESGR'06)" and "logarithmic shadow maps (Sketch paper in SIGGRAPH'06)". However, as explained in our paper, it might not be very good to EXACTLY simulate this split scheme on discrete buffers to produce the theoretically even distribution of perspective aliasing over the whole depth range. The logarithmic split scheme usually results in an "over-strong" split effect in practice. For example, for n=1 and f=1000 in PSSM(3), the first split part only occupies the first 1% of the depth range! I know this conclusion might be a little bit "subjective", I strongly recommend you to try all the three splits schemes (uniform, logarithmic, practical) to get your own conclusion. In general, the practical split scheme is more flexible for most cases.

2) How to alleviate the performance drop caused by multiple rendering passes?

For this issue, in our Gems 3 paper, we thoroughly discussed this issue. For the split scheme PSSM(m) (the frustum is split into m parts), the number of rendering passes for 1) without hardware-acceleration, 2) with DX9-level HW-accel. and 3) with DX10-level HW-accel. are 2m, m+1 and 1+1 respectively. In particular, in comparison with the standard shadow mapping approach, we reduce ALL extra rendering passes in our DX10 implementation. For more details, see the upcoming book GPU Gems 3 and the accompanying source codes.

Any suggestion will be appreciated. Thanks.

Best Regards,

Fan Zhang