Vertex_VS_to_PS VS(in Vertex_App_to_VS inputvertex,
uniform int a_maxboneweights)
{
Vertex_VS_to_PS Out = (Vertex_VS_to_PS)0;
...
...
...
float3 tmpposition;
float3 l_position;
l_position.x = 0.0f;
l_position.y = 0.0f;
l_position.z = 0.0f;
for(int i = 0; i < a_maxboneweights; i++)
{
if(inputvertex.Blendweight > 0.0f)
{
tmpposition = mul(inputvertex.Position, g_mSkinMatrices[inputvertex.Blendindex]) * inputvertex.Blendweight;
l_position += tmpposition;
}
}
Out.Pos = mul(float4(l_position, 1.0f), matWorldViewProj);
return Out;
}
Vertex Shader: Conditional on input variable impossible?
Author
Im using HLSL.
My problem is, that I can't seem to get conditional to work on the input vertex's variables. I had originally made it so the blendweight would be -1.0f if the bone wasn't being used (I did this since the Blendweight argument of the input vertex has to be constant array, while it is not possible to tell how many bones there will be - it may be fewer than the maximum allowed).
However, I got quite a surprise when I debugged this, and saw that the program just ignored my if-conditional and proceeded to add to the l_position, no matter what the value of the Blendweight[] would be.
My code looks something like this:
I omitted some irrelevant stuff, like view and light direction.
Btw, have you had a similar problem, where you use a system with a variable number of bones influencing (some vertices may be influenced by only 1-2 bones, while other are influenced by 4 or more)?
What did you do to circumvent the forced constant array?
Right now I just set the weight to 0.0f, which will make the multiplication end in a float3(0.0f, 0.0f, 0.0f), which adds nothing to the result. It works, but I would still prefer to skip the calculation entirely if there is no weight...
I'm not entirely clear on what the behavior of conditionals on lower version shaders is supposed to be, but the vs_3_0 is the only profile I'm aware of that actually supports dynamic branching based on the input parameters. So if you're not compiling for vs_3_0, you probably can't do what you're trying to do.
Author
Omg, you are a life savior!
I hadn't gotten into examining everything that closely, and I had built my shader around some examples. And the examples use - VS_1_1! I just changed to 3_0, and it worked perfectly.
Thanx alot. A stupid little thing that has been bothering me for a while now...
I hadn't gotten into examining everything that closely, and I had built my shader around some examples. And the examples use - VS_1_1! I just changed to 3_0, and it worked perfectly.
Thanx alot. A stupid little thing that has been bothering me for a while now...
Um. I'm fairly sure that the compiler can handle branches under vs_1_1 - it has to execute both paths and then pick a result based on the conditional. Still, I guess the compiler didn't handle your particular case. And of course, that wouldn't be skipping the calculation...
Quote:
Btw, have you had a similar problem, where you use a system with a variable number of bones influencing (some vertices may be influenced by only 1-2 bones, while other are influenced by 4 or more)?
What did you do to circumvent the forced constant array?
I did it the same way as the DX SkinnedMesh sample - I used static looping, that is, passing a uniform parameter for the number of bones in.
Then have passes in your techniques for 1 bone influence, 2, 3, 4 etc, just passing in the number of bone influences as the uniform parameter. Your code managing your effect selects the passes for your skinned mesh depending on their numberOfBoneInfluences annotation. But that's more complicated if more efficient.
My modeller (Milkshape 3D) only supports 1 influence per vertex anyway so I'm fine [grin]
PS: if you're going to distribute your game, using shader model 3 is probably a bad idea as not many users will have it yet.
I'm inclined to agree with superpig on this one, considering the fact that GLSL's conditionals work fine with my GF2 (exactly how superpig described it), even though my GF2 apparently doesn't support conditionals. That aside, I'll point out the real problem: loops that are executed an arbitrary number of times (those that use some varying input to determine how many times the loop executes) don't work in older shaders.
Assuming you knew how many times you wanted to execute the loops (note the plural here), you could write a function for each one (one function for 1 bone, another for 2 bones, another for 3, etc.). The only problem with this however is that the number of instructions the program (shader) ends up with will multiply very quickly. You'll also need to encase the functions in an if-else-if block, which only adds to the chaos.
Assuming you knew how many times you wanted to execute the loops (note the plural here), you could write a function for each one (one function for 1 bone, another for 2 bones, another for 3, etc.). The only problem with this however is that the number of instructions the program (shader) ends up with will multiply very quickly. You'll also need to encase the functions in an if-else-if block, which only adds to the chaos.
I have to admit that I am not familiar at all with the branching part of this discussion except to say that it seems impossible in my mind pre vs3.0.
Now, the other question about what do other people do I can answer.
When taking a model and tri-stripping it, break up your model to put vertices into different buckets based on the number of bones that influence it. Once this is done, tri-strip the data within those buckets. When it comes to drawing it, use different shaders for one, two, three or four bone weighting and render each bucket.
As an alternative, I have also simply supported 4 bone weighting and set the blend weights for vertices that have less than 4 bones of influence to zero.
I am still not convinced that branching is fast in shaders but then I have not had a chance to play with it before.
- S
Now, the other question about what do other people do I can answer.
When taking a model and tri-stripping it, break up your model to put vertices into different buckets based on the number of bones that influence it. Once this is done, tri-strip the data within those buckets. When it comes to drawing it, use different shaders for one, two, three or four bone weighting and render each bucket.
As an alternative, I have also simply supported 4 bone weighting and set the blend weights for vertices that have less than 4 bones of influence to zero.
I am still not convinced that branching is fast in shaders but then I have not had a chance to play with it before.
- S
I think you need vs.2.0a, found on nv30+ or x800+ for true dynamic vertex branching.
Otherwise, you can only branch on constants, which hlsl can unroll.
Better to just Zero out your bone weights that aren't used, and have an index that points to the zero weight ( index zero maybe? ).
And be sure that all of your remaining weights on the vertex sum to one, and you shouldn't need to branch.
Otherwise, you can only branch on constants, which hlsl can unroll.
Better to just Zero out your bone weights that aren't used, and have an index that points to the zero weight ( index zero maybe? ).
And be sure that all of your remaining weights on the vertex sum to one, and you shouldn't need to branch.
Quote:Original post by Sphet
I have to admit that I am not familiar at all with the branching part of this discussion except to say that it seems impossible in my mind pre vs3.0.
if(val1 > val2){ calc1()}else{ calc2()}becomes
<compute calc1 into r0><compute calc2 into r1>slt r2, val2, val1mul r0, r0, r2sge r2, val2, val1mad r0, r1, r2, r0But yeah, that's not actually branching, it'll just simulate it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
