Hacker News Reader

Comment by lbenes | Hacker News Reader

>For my Masters degree project at uni I had a demo written in OpenGL with over 500 dynamic lights,

I don’t know what kind of 3D engine you wrote, but as a FPS gamer I have quite a bit of experience with 3D engines. From Doom 3 to Alan Wake, some of the worst performance hits occur in scenes with heavy use of dynamic lights. Did OpenGL 4/DX11 fix this?

Which of the modern APIs have you actually used? How do Mantle, DX12, Metal, and OpenGl Next compare?

EDIT: "as a non-3D graphics programmer, who's tried to build FPS levels for fun and familiar with all the modern engines". This article is for those of us with interest but not experts in the field, right?

View on HN

No, shaders and deferred rendering fixed this. Shaders mean you could design anything you imagined and not use the old deprecated fixed function OpenGL that only supported 4 lights.

Someone figured out deferred rendering which was a new technique that allows lots of lights. Lots of games use it. I believe one of the first was Killzone

http://www.slideshare.net/guerrillagames/the-rendering-techn...

Here's a live demo of deferred rendering

http://threejs.org/examples/webgldeferred_pointlights.html

It's using only OpenGL 2.1 features (which is all that's needed to emulate OpenGL ES 2.0 which WebGL is based on). To do deferred rendering efficiently all you really need is support for multiple render targets.

Pure OpenGL 4.0. It allowed me to do Tessellation and use Deferred rendering. This is the key - rendering the lights in a separate pass is crucial to performance, and like I've said - it allows you to have thousands of dynamic lights in the same scene. Neither Doom 3 nor Alan Wake could use this technique. I mostly work on consoles nowadays, so I use none of these APIs. On PS3/PS4 you have to do everything manually, instead of using nice OpenGL API to bind and send vertex buffer object,you have to allocate memory for it yourself and copy it over manually to the address that you want. That's where the speed lies. I have done some Xbox One programming but that's mostly regular DirectX at the moment, I haven't had a chance to play with the DX12 stuff.

There is a quite a good explanation on how deferred rendering works: http://gamedevelopment.tutsplus.com/articles/forward-renderi...

Great link and thanks for the explanation. So by using a deferred rendering algorithm you can reduces the complexity O(m+n), (m=number of surfaces, n=number of lights) where the forward lighting path renderers have complexity O(m*n). The trade-off seems higher memory usage, not working well on older hardware and with anti-aliasing and transparent objects explains why many modern engines like Unreal 3 and IW engine don't utilize it.

In case you're curious about the downvotes, it's probably because anyone who has ever done engine programming will laugh about your assertion that "as a FPS gamer" you know anything relevant about graphics rendering and technology.

It's like somebody claiming they can comment meaningfully on light bulb manufacturing standards because they've seen the lighting in a bunch of made-for-TV specials.

"As an frequent airplane passenger, I am qualified to both build build and pilot large aircraft."

Aren't you mixing forward shading and deferred shading? http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09...

Reply on news.ycombinator.com