3 ms·
Because in path tracing, when you have many lights, you don't want to be sampling each light each bounce - that just doesn't scale due to the explosion in numbe
by berkut 11y ago
Because in path tracing, when you have many lights, you don't want to be sampling each light each bounce - that just doesn't scale due to the explosion in number of rays you have to send to test occlusion. The whole point of path tracing (generally anyway, and especially for games I would have thought) is each progression gives fast updates, but with not necessarily great results quality (which you make up for by averaging loads of progressions). If you sample each light each ray bounce/progression you'll get much better results, but it will be much slower.
So you randomly sample/pick one, or a few (maybe vary it based on the current ray importance or throughput) to test.
So given that you can't sample all lights (efficiently anyway), you have to try and efficiently cull/find lights which are visible to the surface being shaded/lit. Because otherwise you might be sending test occlusion rays to lights that wouldn't even contribute anything even if they weren't occluded.
It's close to impossible to do this perfectly (in an unbiased way, anyway), and even if you do a pretty good job, it's extra computation, and the fact that certain lights are sometimes occluded significantly adds noise to the lighting.
- alkonaut 11y agoThese problems can be overcome (somewhat) by using more clever path tracing such as bidirectional path tracing, and mutating "successful" paths instead of creating new ones, such as in Metropolis Light Transport.