View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005022||The Dark Mod||Graphics||public||31.03.2019 15:12||31.12.2020 20:31|
|Product Version||TDM 2.09|
|Target Version||TDM 2.10|
|Summary||0005022: Implement a forward+ render|
|Description||Right now TDM uses the original forward render of idtech4, this render, it seems, can support up to 64 point light sources (in a small demo scene, no AI, no physics) at above 60fps, this if they are small, that means they interact with few pixels and they cast no shadows. But in the future, TDM could theoretically support up to a million dynamic light sources, point and spot, by implementing a forward+ render, of course the same limitation as the normal forward render apply to shadow casting lights, the few the better.|
Here is the youtube video that made me write this:
|Tags||No tags attached.|
|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|
|31.03.2019 15:12||HMart||New Issue|
|05.05.2019 17:36||duzenko||Note Added: 0011782|
|06.05.2019 23:00||HMart||Note Added: 0011789|
|11.05.2019 07:27||duzenko||Note Added: 0011791|
|11.05.2019 15:26||HMart||Note Added: 0011797|
|11.05.2019 15:55||duzenko||Note Added: 0011798|
|11.05.2019 15:57||duzenko||Note Edited: 0011798||View Revisions|
|30.12.2020 02:14||nbohr1more||Relationship added||child of 0003684|
|30.12.2020 19:40||nbohr1more||Note Added: 0013320|
|30.12.2020 19:40||nbohr1more||Assigned To||=> cabalistic|
|30.12.2020 19:40||nbohr1more||Status||new => assigned|
|30.12.2020 19:40||nbohr1more||Product Version||=> TDM 2.09|
|30.12.2020 19:40||nbohr1more||Target Version||=> TDM 2.10|
|30.12.2020 19:48||nbohr1more||Relationship added||related to 0004866|
|31.12.2020 09:36||cabalistic||Note Added: 0013331|
|31.12.2020 09:36||cabalistic||Note Edited: 0013331||View Revisions|
|31.12.2020 15:31||nbohr1more||Note Added: 0013335|
|31.12.2020 20:30||nbohr1more||Relationship added||parent of 0004680|
|31.12.2020 20:31||nbohr1more||Note Added: 0013337|