| Line | |
|---|
| 1 | |
|---|
| 2 | > Hi John, |
|---|
| 3 | > |
|---|
| 4 | > I know I'll forget to tell you this if I don't write it right now.... |
|---|
| 5 | > |
|---|
| 6 | > >(2) How is the receiving geometry for the shadow decided? |
|---|
| 7 | > |
|---|
| 8 | > I wrote about an LSS-test but actually performing a new VFC test (from the |
|---|
| 9 | > light's view) is the same. In both cases, here's a trick to take advantage |
|---|
| 10 | > of temporal coherence : test the world against a slightly larger than |
|---|
| 11 | > necessary LSS or frustum. Keep the list of touched surfaces. Then next |
|---|
| 12 | > frame, if the new volume is still contained within the previous one used |
|---|
| 13 | for |
|---|
| 14 | > the query, you can reuse the same list immediately. Actually it's a bit |
|---|
| 15 | > similar to what you did in your sphere-tree, I think. Anyway, now the |
|---|
| 16 | O(log |
|---|
| 17 | > N) VFC is O(1) for some frames. It's not worth it for the "real" VFC, but |
|---|
| 18 | > when you have N virtual frustum to test to drop N shadows, that's another |
|---|
| 19 | > story. |
|---|
| 20 | > |
|---|
| 21 | > Two downsides: |
|---|
| 22 | > - You need more ram to keep track of one list of meshes / shadow, but |
|---|
| 23 | > usually it's not a lot. |
|---|
| 24 | > - By using a larger volume for the query you possibly touch more |
|---|
| 25 | > faces/surfaces, which will be rendered in the shadow pass. Usually it's |
|---|
| 26 | not |
|---|
| 27 | > a problem either since rendering is simply faster than geometric queries |
|---|
| 28 | > those days. But of course, "your mileage may vary". |
|---|
| 29 | > |
|---|
| 30 | > Happy new year ! |
|---|
| 31 | > |
|---|
| 32 | > Pierre |
|---|
Note: See
TracBrowser
for help on using the repository browser.