……….

you again! ?

ok well, let's try and put u out of your misery…

Right! first of all, …. i think this was the rule back then, i can't remember that very well…:

DirectX 9.0 supports Shader Model 2.0
 (256 or more constant registers)
DirectX 9.0a supports Shader Model 2.0a
 (up to 256 constant registers)
DirectX 9.0b supports Shader Model 2.0b
 (up to 256 constant registers)
DirectX 9.0c supports Shader Model 3.0 (256 or more constant registers)

so this means that depending on what card u use, you were guaranteed 256 const registers and on some other cards you could even have more than 256. To be honest, back then, I personally never came across a card that supported dx9c and supported more than 256 registers. So I will assume that you are working on an old card as well;

i will also assume that you are using the best version of dx9 which is dx9.0c SM3.0;

that means with 256 constant registers, and with each bone sized at float4x4, each bone will occupy:

// unrolled pseudo
cbuffer matrices
{ 
 // with one c reg covering the sins of 4 floats, u have:
 float4x4 bone0: register(c0);
 float4x4 bone1: register(c4);
 float4x4 bone2: register(c8);
 ...
 float4x4 bone64: register(c252);
}; 

this would give you a max of 64 bones; (256 / 4), which is 4 reg per matrix, so an outright 80 bones here if your card doesn't have more const registers is impossible;

right then, so if u use:

 // pseudo
 float3x4 boneX: register(cX);
 .. 

this would give you a max of approx 85 bones; (256/3), which is 3 reg per matrix! now your eyes are beginning to pop out -lol-

But you're thinking “i don't want float3x4 matrices, i want the float4x4 for 80 bones and I've only got 256 regs", well then mister or… mistress, this is known as a hardware limitation and the only way to break this hardware limitation is to examine at your data.

For example, if you have multiple bone matrix data looking like this one (like an “Identity Matrix”):

// let's say u have this bone X...
float4x4 boneX: register(cX);

// ... and bone X expands later on to:
float4 register(cX+0): 1,0,0,0
float4 register(cX+1): 0,1,0,0
float4 register(cX+2): 0,0,1,0
float4 register(cX+3): 0,0,0,1

then your best bet is to use 1 reg for this instead of 4. Why? because u can swizzle that 1 reg and get the other ones from it, like this:

// pseudo
float4 boneX: register(cX);
...
// and later on in your shader, u swizzle:
...  = whatever * boneX.xyyy
... += ...        boneX.yxyy
... += ...        boneX.yyxy
... += ...        boneX.yyyx

it's just basic vector and matrix multiplication after all and this way u can save on 3 registers and see how u can fit more “non-identical” bones into your const registers;

with this you can now see that you're edging to the limits of what u can achieve with this old API and should really be looking to move onto the next one; I think you should show this your boss:

"Dear boss,

please leave our brother/sister alone and please upgrade or move onto the next API as we have now run tired and out-of ideas to fix your money saving problems.

Kind regards,

The rest of the world"

you now have everything u need;

That's it … all the best ?

……….

that's a straight forward re-indexation job on the cpu side…, just go'head and re-index them;

because you now have extra space on the cbuffer u can put more info on there…

for example u can choose to store the compressed Identity Matrix either as a 1,0 only or store it at the start of your g_bonematrix[0] uncompressed or at the end of it or not at all and just pass that as an indication flag with your blendindices: if blendindices.x == -7 then expand to identity;

you can do whatever u like, but remember u are in “limited” environment so whatever can work, just go for it;

i leave it as an exercise for u to choose your path (red or blue pill) and finish it all up, if u see a White Rabbit, you're on the right path ?

Have fun ?