Jump to content

  • Log In with Google      Sign In   
  • Create Account

Deferred shading?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 angelmu88   Members   -  Reputation: 228

Like
0Likes
Like

Posted 04 January 2012 - 04:49 AM

Hi everybody!
I'm wornking on a graphic engine. At this moment I've came across a problem, I have a very large shader with many instructions because this shader supports multiple directional lights and point lights, in a few days it's going to be even larger, because I want to add normal mapping. I think I really need to separate geometry from lighting. I was thinking of deferred shading, what do you think? is this the best solution to my problem?

Sponsor:

#2 phil_t   Crossbones+   -  Reputation: 3915

Like
1Likes
Like

Posted 04 January 2012 - 10:35 AM

Perhaps. Another alternative is multipass lighting (where you render the object multiple times - once for each light - and additively blend the results).

I kind of don't think normal mapping should be the tipping point that pushes you to deferred rendering (rather it should be that all your shaders are getting too complex needing to support all the lights). Normal mapping doesn't really add too much complexity to your shader, and the extra texture fetch may not be as much of a perf issue as you think if your shader is ALU-bound (which it may be if it is calculating lots of lights). Only one way to find out.

#3 angelmu88   Members   -  Reputation: 228

Like
0Likes
Like

Posted 04 January 2012 - 12:06 PM

Perhaps. Another alternative is multipass lighting (where you render the object multiple times - once for each light - and additively blend the results).

I kind of don't think normal mapping should be the tipping point that pushes you to deferred rendering (rather it should be that all your shaders are getting too complex needing to support all the lights). Normal mapping doesn't really add too much complexity to your shader, and the extra texture fetch may not be as much of a perf issue as you think if your shader is ALU-bound (which it may be if it is calculating lots of lights). Only one way to find out.


Thanks for the advice!
I've been searching info about multipass lighting and I think it could fit me best (they say it's very good for shadows). The only problem with this approach is that my way of working is to bound an object with a shader in 3d studio, and then my engine pipeline reads the shader associated, and draws the object with it, but I think I can't use this method anymore with multipass lighting. Am I wrong?

Also, sorry about my ignorance, but what do you mean, when you say ALU-BOUND?

#4 Frenetic Pony   Members   -  Reputation: 1312

Like
1Likes
Like

Posted 04 January 2012 - 02:15 PM

"Hi Doctor Nick!"

Sorry, couldn 't help myself. Anyway, if you have a ton of lights and geometry, or if you are planning to make your shaders progressively more complex then implementing deffered shading is probably a good idea; no sense in going for multipass lighting if you're going to end up needing deffered sometime down the line anyway.

But if you're not planning on anything like that then forward shading might still be fine. On a side note I'd look up "triple depth culling" if you're going to stick with forward, it's a nice and simple trick for eliminating a lot shading work on stuff you won't see.

#5 phil_t   Crossbones+   -  Reputation: 3915

Like
1Likes
Like

Posted 04 January 2012 - 03:43 PM

The only problem with this approach is that my way of working is to bound an object with a shader in 3d studio, and then my engine pipeline reads the shader associated, and draws the object with it, but I think I can't use this method anymore with multipass lighting. Am I wrong?


Unfortunately, I'm not familiar enough with that kind of workflow to know what your options are there.

Also, sorry about my ignorance, but what do you mean, when you say ALU-BOUND?


I mean that the performance of the shader could be limited by arithmetic operations (as opposed to texture fetches). From my understanding, the GPU can issue the texture fetches prior to actually needing the values in the shader calculations. So it is "theoretically possible" for an additional texture fetch not to have any performance impact if the value can be obtained prior to the shader needing it for any calculations. But anyway, GPU performance characteristics are so complex that the only way to know for sure is to try it out.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS