Does buffer number matter in ID3D11DeviceContext::PSSetConstantBuffers()? I added 5 or six constant buffers to my framework, and later realized I had set the buffer number parameter to either 0 or 1 in all of them - but they still all worked! Curious why that is, and should they be set up to correspond to the number of constant buffers?

Similarly, inside the buffer structs used to pass info into the hlsl shader, I added padding inside the c++ struct to make a struct containing a float3 be 16 bytes, but in the declaration of the same struct inside the hlsl shader file, it was missing the padding value - and it still worked! Do they need to be consistent or not? Thanks.

    struct CameraBufferType
    {
        XMFLOAT3 cameraPosition;
        float padding;
    };

Well, I don't know why it worked for you with so little knowledge about your specific app. For me, I like to be very explicit about bind slot IDs for buffers and resources. I declare them in a shared header between C++ app code and HLSL shaders. Then the application uses SetConstantBuffers() with that ID and the shaders are specifying bind locations with that ID as well. HLSL is tricky because you have to concatenate the number with a string, like this:

cbuffer MyCBuffer : register(b4)

For that I am using a macro like this:

#define CBUFFER(name, slot) cbuffer name : register(b ## slot)

Regarding the padding, you are right, HLSL does automatically pad your structs when needed, but I like to keep that explicit as well, so I insert dummy data members where padding would occur. This makes it easier to share structs with the C++ application which you should also do in a shared header in my opinion.

If you don't explicitly link your resources to slots via the register keyword in HLSL, the compiler will remove all unused resources and then automatically assign them to slot 0, 1, 2, etc