Sign in to follow this  

Differed shading and per-pixel shader and lighting selection.

This topic is 3864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was considering the following idea on using deferred shading: Render to texture (via FBO and glDrawBuffers), [0]--> .rgb=diffuse color, .a=free for now. [1]--> .rgb=normal .a="light selection" [2]--> .rgb=specular color, .a=specular shininess factor [3]--> free for now and to the stencil buffer, as I draw my meshes, each mesh is associated to a deferred fragment shader ID, I write this stencil value to the stencil buffer. when I actually draw to the color buffer, I bind the textures from the FBO and for each deferred fragment shader, I set the stencil test to only pass when the stencil value equals the deferred fragment shader's ID.. within each deferred fragment shader, I use the .a of [1] texture to decide which lights to use, and the lights will be stored in a 3D texture. now my worries: 1) I can turn the filtering off for the 3D texture, but this texture needs to be updated at every frame from CPU (i.e. the lights) my line of though was to break the world into zones, each zones has a list of lights that affect, and to put that data into the 3D texture, probably packed as: tex(s,t,0)= position for s'th light of t'th zone tex(s,t,1)= color for s'th light of t'th zone tex(s,t,2)= attenuation for s'th light of t'th zone tex(s,t,3)= cuttof data for s'th light of t'th zone and the fragment shader would have something like this: for(each s) { light=data from tex(s,normalTexture.alpha, *) color+=do lighting with light. } now my worries: 1) naturally the texture probably won't be a power of 2, I have vague memory that with non-power of 2 textures, the values to get the texture are supposed to be integers specifying the exact pixel of the texture to grab, or am I _totally_ wrong there, and non-power of 2 textures are used exactly like power of two textures, if so, how do I make sure that it does not use any of the mipmaps below hand?? 2) for each deferred fragment shader, I will be drawing a rectangle, which a significant portion of it will not be drawn because of stencil testing, but how much would that kill performance, we are talking for each deferred fragment shader, a check for each pixel on the screen. Any thought or suggestions out there?

Share this post


Link to post
Share on other sites
To be honest, that isn't the best way to store your lights. The first problem is that each zone probably won't have the same number of lights that affect it -some will have more or less than others. However the texture would have to be large enough to accommodate the zone with the most lights, which means you're pretty much wasting memory for every other zone that has less than this maximum number of lights. The second problem is that each pixel is going to require [i]multiple]/i] texture reads for each light. Even if you manage to aggregate attenuation and cutoff data, that's still three reads since position and color need their own RGB(A) data. On top of that, you're already using a ton of memory by having multiple render targets for deferred shading. Add on top of that a 3D texture for lights, plus traditional textures, and it's possible you could run out of memory on older cards.

Another approach might involve the use of lower-dimensional light fields. You would have a 3D texture that you overlay over the scene which stores the light at each point in space. The resolution would depend on the size of the scene as well as how detailed you need the lighting to be. Then each pixel simply samples from this texture based on its location, and regular texture filtering should give you smooth results. You add lights by rendering them into the texture. Instead of a 3D texture, you could use a 2D texture and have the alpha component store information such as depth or a packed Z-range.

Share this post


Link to post
Share on other sites

This topic is 3864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this