View Issue Details

IDProjectCategoryView StatusLast Update
0005022The Dark ModGraphicspublic31.12.2020 20:31
ReporterHMart Assigned Tocabalistic  
PrioritylowSeverityfeatureReproducibilityN/A
Status assignedResolutionopen 
Product VersionTDM 2.09 
Target VersionTDM 2.10 
Summary0005022: Implement a forward+ render
DescriptionRight 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:
https://www.youtube.com/watch?v=nyItqF3sM84
TagsNo tags attached.

Relationships

parent of 0004680 assignedcabalistic Falloff and projection textures replacement 
related to 0004866 resolvedcabalistic Make use of MultiDraw functions 
child of 0003684 new Investigate GPL Renderer Improvements 
Not all the children of this issue are yet resolved or closed.

Activities

duzenko

duzenko

05.05.2019 17:36

developer   ~0011782

I believe the multi light shader supercedes this
HMart

HMart

06.05.2019 23:00

reporter   ~0011789

You know best, was just a suggestion for the future. Btw what does the multi light shader do?
duzenko

duzenko

11.05.2019 07:27

developer   ~0011791

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
HMart

HMart

11.05.2019 15:26

reporter   ~0011797

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.
duzenko

duzenko

11.05.2019 15:55

developer   ~0011798

Last edited: 11.05.2019 15:57

View 2 revisions

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.

nbohr1more

nbohr1more

30.12.2020 19:40

developer   ~0013320

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.
cabalistic

cabalistic

31.12.2020 09:36

developer   ~0013331

Last edited: 31.12.2020 09:36

View 2 revisions

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?
nbohr1more

nbohr1more

31.12.2020 15:31

developer   ~0013335

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.
nbohr1more

nbohr1more

31.12.2020 20:31

developer   ~0013337

Tracker 0004680 added for the issue of alternate projection behavior

Issue History

Date Modified Username Field Change
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