   Invalid constant table in an effect
  I have been beating my head against this for a few days now.  I thought I had it figured out, but it seems it is the same problem.I am loading an effect which has no default vertex shader.  I also have a set of vertex shaders compiled at load time that use different parameters (using D3DXCompileShaderFromFile with different defines).  To render, I use the effect''s SetVertexShader to set a VertexShader variable within the effec, as many of the samples do.The crux is that I get an error message when I use a skinning shader.  "ID3DXEffect: Invalid constant table encountered" and the render craps out in the Pass call to the effect.The transform routine of it looks like this:TRANSFORM_OUT SkinTransform( float4 inPos, float3 inNormal, float4 weights, float4 thingamajigs ){    TRANSFORM_OUT Out;    // cast the vectors to arrays for use in the for loop below    int4 idxVector = D3DCOLORtoUBYTE4(thingamajigs);    int idxArray[4] = (int[4]) idxVector;    float weightsArray[4] = (float[4]) weights;    float4 currentPos;    currentPos = mul( inPos, skinMatrices[ idxArray[0] ] ) * weights[0];    currentPos += mul( inPos, skinMatrices[ idxArray[1] ] ) * (1.0 - weights[0]);    float3 currentNormal;    currentNormal = mul( inNormal, (float3x3) skinMatrices[ idxArray[0] ] ) * (1.0 - weights[1]);    currentNormal += mul( inNormal, (float3x3) skinMatrices[ idxArray[1] ] ) * weights[1];    Out.Pos =  mul(currentPos, WorldToProjection );    Out.Normal = (float3) mul( currentNormal, (float3x3) NormalToWorld );    return Out;}Simple enough, right?  Well if I take out the idxArray reference from the skinMatrices access (so it just looks like skinMatrices[0] and skinMatrices[1] rather than skinMatricies[ idxArray[0]] etc.), then it runs fine (although the character is distorted of course.)  Heaven knows why taking out a local variable reference would effect the constant table, but it does apparently.  I''ve compiled the shader using fxc and it doesn''t complain about any weird syntax or running out of constant registers or anything of the like, so I don''t know what it could be.Anyone even seen this error before?  It isn''t on the MS website and Google turns up nothing in either the Web or newsgroups.Jay 
  Are you using vs_1_0 compile target? vs.1.0 doesn''t support the ARL instruction, so you can''t index using non-constant values. You can fix this by compiling to vs_1_1 or vs_2_0.If that''s not it, I don''t know what it is. ;  I''ts being compiled via the vs_1_1 profile.  That''s a good guess though.  Thanks.;quote:Original post by Jay Kint  Heaven knows why taking out a local variable reference would effect the constant table, but it does apparently.  I''ve compiled the shader using fxc and it doesn''t complain about any weird syntax or running out of constant registers or anything of the like, so I don''t know what it could be.- HLSL defines local variables in the constant table. If you think about it, that''s about the only way you can define local variables (using the def instruction, e.g. "def c23, 1, 1, 1, 1")- When you take out the idxArray references from the body of your shader, the HLSL optimizer ignores the idxArray variable (i.e. doesn''t reserve space on the constant table)- How many skin matrices are you using? Keep in mind that the number of constants is very limited, when it comes to storing things like matrices for skinning. I''d rather use quatrnions + translations and convert those into matrices in the shader (Dave Eberly has source code to do that on his magic-software website).- My guess is that your skinning matrices have completely filled the constant table, and then the local variable declaration does a constant definition (via def) that overwrites one of the matrices. I think the HLSL compiler should catch that, but who knows? No one said it''s bug-free (nothing is )- Do a compile to asm and post the listing here. (fxc /Fc asmListing.txt /E SkinTransform /T vs_1_1 your_file_name.fx) Muhammad Haggag;  Thanks.  You're right about the local variables, but as I mentioned in the original post, I did exactly that with fxc, and it came out to 72 registers.  VS 1.1 calls for 96 constant registers, so I should be well within the limit.I have found a workaround/solution.  The only thing I was using the effect for was to store the variables and then I would link and set the vertex shader with a effect->SetVertexShader call.  Since then, I've nixed the effect and just use constant tables directly.  This seems to work.  It has gotten rid of the error I originally posted about, though there are some other oddities, such as some of the variables not being set consistently.  But it is much closer to working than it was before.One thing I did neglect to mention was that I had this working just fine under the original DX 9.0 SDK.  It wasn't until I upgraded to the Summer 2003 Update that all this started happening.  Very strange indeed. [edited by - Jay Kint on February 11, 2004 1:27:24 AM];quote:Original post by Jay Kint  Since then, I''ve nixed the effect and just use constant tables directly.  This seems to work.  It has gotten rid of the error I originally posted about, though there are some other oddities, such as some of the variables not being set consistently.  But it is much closer to working than it was before.Try calling ID3DXConstantTable::SetDefaults on your constant table.  That should initialize all of your variables to whatever you set them as in your shader.For example, if you havefloat3 vDir = float3( 0.0f, 0.0f, 1.0f );in your shader, then calling ID3DXConstantTable::SetDefaults on the constant table for that shader will initialize the variable properly.  You can still have your application overwrite that default initialization if you want.neneboricua 