From 373dc625f82b47096893add42c4472e4a57ab7eb Mon Sep 17 00:00:00 2001 From: Aki Date: Wed, 9 Feb 2022 22:23:03 +0100 Subject: Moved third-party libraries to a separate subdirectory --- Opcode/TemporalCoherence.txt | 32 -------------------------------- 1 file changed, 32 deletions(-) delete mode 100644 Opcode/TemporalCoherence.txt (limited to 'Opcode/TemporalCoherence.txt') diff --git a/Opcode/TemporalCoherence.txt b/Opcode/TemporalCoherence.txt deleted file mode 100644 index 8fde158..0000000 --- a/Opcode/TemporalCoherence.txt +++ /dev/null @@ -1,32 +0,0 @@ - -> Hi John, -> -> I know I'll forget to tell you this if I don't write it right now.... -> -> >(2) How is the receiving geometry for the shadow decided? -> -> I wrote about an LSS-test but actually performing a new VFC test (from the -> light's view) is the same. In both cases, here's a trick to take advantage -> of temporal coherence : test the world against a slightly larger than -> necessary LSS or frustum. Keep the list of touched surfaces. Then next -> frame, if the new volume is still contained within the previous one used -for -> the query, you can reuse the same list immediately. Actually it's a bit -> similar to what you did in your sphere-tree, I think. Anyway, now the -O(log -> N) VFC is O(1) for some frames. It's not worth it for the "real" VFC, but -> when you have N virtual frustum to test to drop N shadows, that's another -> story. -> -> Two downsides: -> - You need more ram to keep track of one list of meshes / shadow, but -> usually it's not a lot. -> - By using a larger volume for the query you possibly touch more -> faces/surfaces, which will be rendered in the shadow pass. Usually it's -not -> a problem either since rendering is simply faster than geometric queries -> those days. But of course, "your mileage may vary". -> -> Happy new year ! -> -> Pierre -- cgit v1.1