Sign in to follow this  

d3d10 fixed function EMU lighting

This topic is 3783 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

In the FixedFuncEMU sample, it isn't a true emulator because the light struct looks like this: struct SCENE_LIGHT { D3DXVECTOR4 Position; D3DXVECTOR4 Diffuse; D3DXVECTOR4 Specular; D3DXVECTOR4 Ambient; D3DXVECTOR4 Atten; }; In fixed func, you can have parallel, point, and spotlights. I have two questions: 1. If you added an int member to the light struct representing the type, could you do something like this in a shader: if( type == 0 ) // parallel light ... else if( type == 1 ) // point light ... else // spotlight ... And if so, how would this be handled behind the scenes? Would static branching be used? I'm a little confused on what static branching does...does it create a separate shader for each possible path? Is this done at compile time or runtime? Do you have to worry if the number of possible paths becomes too large? 2. Is the reason the SCENE_LIGHT uses vector4's for everything to prevent texture padding?

Share this post


Link to post
Share on other sites
Quote:
Original post by Quat
1. If you added an int member to the light struct representing the type, could you do something like this in a shader:

*** SNIP ***

And if so, how would this be handled behind the scenes? Would static branching be used? I'm a little confused on what static branching does...does it create a separate shader for each possible path? Is this done at compile time or runtime? Do you have to worry if the number of possible paths becomes too large?


Yeah, sure, you can do that. Depending on how you do it in terms of looping over every light in the scene, this will probably use dynamic branching. I don't think D3D10 will fall back to static branching for no reason in this case, but it might.

Static branching is when the compiler modifies your code from using a condition to using non-conditional code. Instead of using an if term, the compiler would probably place a 0 or 1 value into a variable. It would then calculate both sides of the if, and then use the 1 or 0 value to determine which side of the loop's value to choose. Naturally, this can become quite costly, but under D3D10 this should be quite rare, since all hardware supports dynamic branching.

Keep in mind that even dynamic branching has it's performance penalties, though they should be bearable.

Quote:
Original post by Quat
2. Is the reason the SCENE_LIGHT uses vector4's for everything to prevent texture padding?

As a guess, I'd say they left it as Vector4 structures since ID3D10EffectVectorVariable::SetFloatVector only takes a float4. If the structure elements were float3s, you'd have to temporarily move them to a float4 before you could set them. It might be some other consideration, I havn't looked at the sample.

Share this post


Link to post
Share on other sites
Thanks for the reply.

Quote:

Static branching is when the compiler modifies your code from using a condition to using non-conditional code. Instead of using an if term, the compiler would probably place a 0 or 1 value into a variable. It would then calculate both sides of the if, and then use the 1 or 0 value to determine which side of the loop's value to choose. Naturally, this can become quite costly, but under D3D10 this should be quite rare, since all hardware supports dynamic branching.


Hmmm I'm not sure if static branching is the same as predication. I think older hardware uses predication to emulate branching. If it were always predication, then I don't see the point of using static branching. For example:

if( bTexture )
// Do texturing

If it is going to do the texture code anyway, you might as well just do the texturing anyway (with a default texture black/white) and not pay the conditional hit.

The SDK docs say this:

Quote:

Static branching is a capability in a shader model that allows for blocks of code to be switched on or off based on a Boolean shader constant. This is a convenient method for enabling or disabling code paths based on the type of object currently being rendered. Between draw calls, you can decide which features you want to support with the current shader and then set the Boolean flags required to get that behavior. Now that HLSL supports branching, any statements that are disabled by a Boolean constant are skipped during execution.


but it doesn't really give details on how it is implemented. Since the control variable is uniform, it seems that when a shader is set, it could remove the instructions before any geometry is drawn with the shader.

[Edited by - Quat on August 4, 2007 7:56:13 PM]

Share this post


Link to post
Share on other sites

This topic is 3783 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