Timeline for Is there a way to use an arbitrary number of lights in a fragment shader?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 25, 2016 at 14:27 | history | edited | Nicol Bolas | CC BY-SA 3.0 |
added 61 characters in body
|
| Nov 9, 2011 at 21:53 | history | edited | Nicol Bolas | CC BY-SA 3.0 |
added 1610 characters in body
|
| Nov 9, 2011 at 21:31 | comment | added | Nicol Bolas |
@JonathanDickinson: But we're not talking about rendering a wireframe, are we? We're talking about rendering the same triangles as before. OpenGL guarantees invariance for the same object being rendered (as long as you are using the same vertex shader, of course, and even then, there's the invariant keyword to guarantee it for other cases).
|
|
| Nov 9, 2011 at 21:24 | comment | added | Jonathan Dickinson | @NicolBolas just try and render a wireframe over your actual rendered objects and tell me how that goes - it's a real problem, today. | |
| Nov 9, 2011 at 21:12 | comment | added | Nicol Bolas | @JonathanDickinson: "Also, with the z-buffer pre-pass trick you are going to struggle to eliminate z-fighting with the objects that should be drawn." That's total nonsense. You're rendering the same objects with the same transform matrices and the same vertex shader. Multipass rendering was done in the Voodoo 1 days; this is a solved problem. Accumulating lighting does nothing to change that. | |
| Nov 9, 2011 at 21:10 | comment | added | Nicol Bolas | @JonathanDickinson: This is talking about WebGL, so any discussion of "shader models" is irrelevant. And which kind of rendering to use is not a "religious topic": it is simply a matter of what hardware you're running on. An embedded GPU, where "video memory" is just regular CPU RAM, will work out very badly with deferred rendering. On a mobile tile-based renderer, it is even worse. Deferred rendering is not an "instant win" regardless of hardware; it has its tradeoffs, just like any hardware. | |
| Nov 9, 2011 at 20:56 | comment | added | Jonathan Dickinson | @NathanReed I just disagree with forward rendering with 16+ lights - game have enough problems with limiting 'Draw' calls as it is; without having to worry about each 'Draw' being effectively being duplicated, but I think it remains a religious topic (my vote stays in place). Unrolled loops are 'fine', but an instruction limit is an instruction limit: it doesn't matter if it was going to do useful work - DirectX/OpenGL/WebGL won't compile it and the graphics card won't run it. You would be surprised how little you can do in the SM2.0 limit. | |
| Nov 9, 2011 at 20:45 | comment | added | Nathan Reed | @JonathanDickinson I think his point was that the memory bandwidth for deferred / light pre-pass is typically several times larger than for forward rendering. This doesn't invalidate the deferred approach; it's just something to consider when choosing it. BTW: your deferred buffers should be in video memory, so PCI-X bandwidth is irrelevant; it's the GPU's internal bandwidth that matters. Long pixel shaders, e.g. with an unrolled loop, are nothing to freak out about if they're doing useful work. And there's nothing wrong with the z-buffer prepass trick; it works fine. | |
| Nov 9, 2011 at 20:39 | comment | added | Jonathan Dickinson | (Damn 5 minute comment edit limit). Finally, anything pre-DX9.0 can't do loops anyway - SM2.0 doesn't have flow control: so loops simply can't be done because the HLSL/GLSL compiler will expand the loop and blow your instruction limit. | |
| Nov 9, 2011 at 20:33 | comment | added | Jonathan Dickinson | Also, with the z-buffer pre-pass trick you are going to struggle to eliminate z-fighting with the objects that should be drawn. Deferred rendering is the only route that will maintain your sanity, and AAA games that didn't do it limited themselves to 8 lights for very, very, good reasons. | |
| Nov 9, 2011 at 20:29 | comment | added | Jonathan Dickinson | -1: failure to mention LPP/PPL. -1 deferred: rendering is an instant win on any DX9.0 hardware (yes even on my 'business' laptop) - which is baseline requirements circa 2009. Unless you are targeting DX8.0 (which can't do Deferred/LPP) Deferred/LPP is default. Finally 'a lot of memory bandwidth' is insane - we generally aren't even saturating PCI-X x4 yet, furthermore, LPP drops the memory bandwidth substantially. Finally, -1 for your comment; loops like this OK? You know those loops are happening 2073600 times per frame, right? Even with the parrelism of the graphics card, it's bad. | |
| Nov 9, 2011 at 19:48 | history | answered | Nicol Bolas | CC BY-SA 3.0 |