diff options
author | dan miller | 2007-10-19 05:15:33 +0000 |
---|---|---|
committer | dan miller | 2007-10-19 05:15:33 +0000 |
commit | 79eca25c945a535a7a0325999034bae17da92412 (patch) | |
tree | 40ff433d94859d629aac933d5ec73b382f62ba1a /libraries/ode-0.9/OPCODE/TemporalCoherence.txt | |
parent | adding ode source to /libraries (diff) | |
download | opensim-SC-79eca25c945a535a7a0325999034bae17da92412.zip opensim-SC-79eca25c945a535a7a0325999034bae17da92412.tar.gz opensim-SC-79eca25c945a535a7a0325999034bae17da92412.tar.bz2 opensim-SC-79eca25c945a535a7a0325999034bae17da92412.tar.xz |
resubmitting ode
Diffstat (limited to 'libraries/ode-0.9/OPCODE/TemporalCoherence.txt')
-rw-r--r-- | libraries/ode-0.9/OPCODE/TemporalCoherence.txt | 32 |
1 files changed, 32 insertions, 0 deletions
diff --git a/libraries/ode-0.9/OPCODE/TemporalCoherence.txt b/libraries/ode-0.9/OPCODE/TemporalCoherence.txt new file mode 100644 index 0000000..fb85931 --- /dev/null +++ b/libraries/ode-0.9/OPCODE/TemporalCoherence.txt | |||
@@ -0,0 +1,32 @@ | |||
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 | ||