In my app I copy all the transforms matrices to my structure defined in c++ similarly to the above. I call the map/unmap functions and use memcpy in between to copy the data to the buffer.

Now, the data in the buffer has the copied values, and checking the buffer in memory, via Visual Studio gpu debugger, all the data is there. However, upon debugging the BoneTranforms array in the shader, the values are not even remotely correct.

I found elsewhere that the constant buffers need to be aligned appropriately. It states the a float4 occupies 1 register, so if I am using a float4x4, then that would be using 4 registers. I found example that help with correctly working with float arrays, but nothing with float4x4 arrays. So is there another way of defining the array above? Or am I missing something?

Share this post

Link to post

Share on other sites

I would suspect that you're either not binding the constant buffer correctly, or your shader isn't interpreting it correctly. Keep in mind that by default the HLSL compiler will assume that matrices in constant buffers use column-major layout, and will treat them accordingly. If you're storing row-major matrices in your constant buffer, then you can add the "row_major" prefix to your float4x4 array and the compiler will interpret it correctly.

Not pertinent to your question, but do you really have 96 influence bones?

Yes it does, but I have set it to a much smaller number and still get the same result.

3. In your shader, do you specify the register for the buffer? If so, do you use the correct slot in VSSetConstantBuffers?

Yes, and no. I have tried both. Same results. And set the correct slot as well.

I would suspect that you're either not binding the constant buffer correctly, or your shader isn't interpreting it correctly. Keep in mind that by default the HLSL compiler will assume that matrices in constant buffers use column-major layout, and will treat them accordingly. If you're storing row-major matrices in your constant buffer, then you can add the "row_major" prefix to your float4x4 array and the compiler will interpret it correctly.

Not pertinent to your question, but do you really have 96 influence bones?

That's nothing, we had 256 just in our heads!

Not pertinent to your question, but do you really have 96 influence bones?

96 turns up a lot, probably because it is the number of bones supported in the shader from the chapter on skeletal animation in Luna's DX11 book.

I have two test models. One with just a few bones, and the other has somewhere are 72 bones I think. But ericrichards22 is right, I sort of got the information from Luna's book. Although, I don't use .fx shaders.

I don't mean that the right values are in the wrong places, I am missing all the right values and have really large numbers in the matrix.

Share this post

Link to post

Share on other sites

Yes, and no. I have tried both. Same results. And set the correct slot as well.

Use a structured approach to debugging. Changing things "just to see if it fixes the problem" will only confuse you and others - that's called "hacking." If you don't know whether something is coded correctly, read the docs or ask how to do it, e.g., here on gamedev. Your code must be correct for the results to be correct.

With regard to the above quotation, and getting help with any problem, it's difficult to provide help without knowing what code you're actually trying to debug. So, define the register in the shader, and use the slot number in the VSSetConstantBuffers call.

Set a breakpoint and examine the contents of the SkinnedBuffer structure just before you copy it to the shader resource. Until you've found the problem, use the simplest model you have, and, for debugging, set all the final matrices to the identity matrix CPU side for the first go-around.

EDIT: With regard to a structured approach to debugging, consider following the data. In that journal entry, I assume an equivalence between programming experience and experience with debugging techniques. That offends some people and I'll change that in future. However, note in particular the importance of verifying that both code and data are correct at every step. It's easier to debug CPU code than shader code, so verify by actual examination (don't guess or assume!) that the data going to the shader is correct, before you try to interpret buffer bytes, etc.

Edited January 29, 2015 by Buckeye

2

Share this post

Link to post

Share on other sites

I know what is wrong. It's not that the values are wrong, they are just too small. That really HUGE negative number is just a very, very small number that fills the 32-bit value that it becomes a larger value. I'll have to check values when I am exporting my model data so that it doesn't have this problem. I'm sure the data types are double being down graded to floats. Thanks for the help.

Also, Buckeye, I read your following the data, it is more or less what I do until I get completely stumped. Then, I get annoyed and start trying anything. It's a good read though, thanks. Also, I hate asking questions. I usually try as much as I can by myself and ask questions when my brain is shot.