• 06-19-2013, 08:16 AM
kantaki

If I understood it correct, I am just pushing my geometry though a shader stage so that I have the position normal and color information about the frontmost pixel.

This way I only have to lit pixel that are acutally visible to the camera right?

Now my university tells me that I have a complexity of #objects * #lightsources without deferred shading and with deferred shading I would have a complexity of #objects + #lightsources.

This make absolutely no sense to me.

Let's say I have a scene with 1000 cubes, but the camera only sees one cube. With deferred shading I only calculate the lighting for one cube right? (and only the pixel that are actually visible)
• 06-19-2013, 08:44 AM
Alfonse Reinheart
Quote:

Now my university tells me that I have a complexity of #objects * #lightsources without deferred shading and with deferred shading I would have a complexity of #objects + #lightsources.

This make absolutely no sense to me.
That's because you're thinking about it wrong.

The "complexity" here is a measure of the number of operations. If you render 1000 cubes, you have still rendered 1000 cubes, even if 999 of them are behind one of them. You still drew the other cubes into the g-buffers, even if their fragments were depth-tested away. So your algorithm still must iterate over 1000 cubes and render them.

The point of the statement is that, in a traditional forward-rendering system, the algorithmic complexity is per object * per-light. You must go to each object and render it once for each light. Whereas in a deferred system, you go to each object and render it once, then go to each light and render a lighting pass once. Adding more objects does not increase the number of lighting passes you do, and adding more lighting passes does not make rendering take longer based on the number of objects being rendered.

And remember: complexity is always about order-of-magnitude, not exact numbers.