 |
I believe the multi light shader supercedes this |
 |
You know best, was just a suggestion for the future. Btw what does the multi light shader do? |
|
|
It's supposed to render all lights in one pass, contrary to the original D3 implementation where each light required a separate pass You can test it with r_testARBProgram 2 but it requires the shadow maps mode |
|
|
Thanks for the info, not sure if is the same thing has a forward+ render but sounds interesting, will test it right away. Btw makes me wonder, if doing them in one pass is faster, why did John Carmack made a pass for each light? Hardware limitation at the time? I'm not a graphics render guy so sorry if this question is obvious. |
|
|
It's the only way stencil shadows could work back then in 2004 AFAIK. At that time stencil shadows made much more sense than now because of GPU limitations. |
 |
AFAIK, while we defer light rendering so that it is done in one pass, we do not have a tile-based optimization phase that prevents the lights from rendering to unseen surfaces. |
 |
We do not, but we do know which light touches which surface from the frontend. Given the peculiarities of how GPUs work and what they can optimize, clustering probably wouldn't be any better than the current approach. In order to support many more lights, we'd need to simplify proceedings in the frontend and also implement different types of lights. Right now, all lights are texture projection lights, and those are relatively expensive and do not scale well. But I also don't know how important this is, as my impression is that mappers mostly use shadowing lights, anyway? |
|
|
Yeah, cluster lights would be used for mappers who use multiple ambient or "bounce" lights to fake radiosity. Having probes for ambient lighting would mostly make that workflow obsolete. |
|
|
Tracker 0004680 added for the issue of alternate projection behavior |
- Anonymous
