Constant Buffer's Matrix Values being modified

Aug 30, 2011 at 9:56 AM

I have been reading "Practical Rendering and Computation with Direct3D 11" along with taking a look at this code base for it and I have a question for something that has me completely baffled.

The question is, are there any sort of setting on the constant buffers that would have the index 10 and 14 values being modified for matrices?

It seems like an odd question, but I was having an issue with my deferred rendering so I decided to recreate my scene in your code base (which was actually a very easy thing to do). I noticed though, that the matrix value you set to the constant buffer for the WorldViewProj matrix is not actually the same value that is available in PIX when I look at the buffers content.

In the code, specifically "ShaderDX11::UpdateParameters", the third settings of a matrix parameter, there is a setting of pBuf to the following

        [0]    1.8106599    float
        [1]    0.00000000    float
        [2]    0.00000000    float
        [3]    0.00000000    float
        [4]    0.00000000    float
        [5]    2.4142132    float
        [6]    0.00000000    float
        [7]    0.00000000    float
        [8]    0.00000000    float
        [9]    0.00000000    float
        [10]    1.0101008    float
        [11]    0.99999994    float
        [12]    0.00000000    float
        [13]    -3.6213195    float
        [14]    3.0303025    float
        [15]    3.9999998    float

However, coincidentally, when I view the buffer in PIX, I get

32    1.811
33    0.000
34    0.000
35    0.000
36    0.000
37    2.414
38    0.000
39    0.000
40    0.000
41    0.000
42    1.071
43    1.000
44    0.000
45    -3.621
46    3.214
47    4.000

For the most part, the values are the same. Except for two values. The values that are different are index 10 (42) and 14 (46), or in matrix order, 33 and 42.

I looked all over the code base to see any way possible that these values were being modified. From the constant buffer creation, vertex buffer creation, but I can clearly see the values being mapped to the resource buffer but some how being different in PIX.

Aug 31, 2011 at 1:06 AM

Also, since it may not have been clear, that matrix is different than default. I made modifications to the scene geometry and default camera position. However, that does not explain why the matrix is different from when I map it, to when I debug it in PIX (there is no rotating happening).

Coordinator
Sep 3, 2011 at 6:14 PM

Sorry for the delay in responding to this - I've been on vacation without access to a computer!

The direct answer to your question is that there should be no behind the scenes modifications after you have mapped and filled a constant buffer.  The indices that you mention are most likely originating from a change in the perspective matrix being used, since these two indices are the only ones modified for changes in the near and/or far clipping planes.  That should be a clue about where to look for possible differences...

However, there are some things that may be indirectly causing you issues without you knowing it.  The multi-threaded rendering setup will try to process render view's in parallel if the multi-threading state is enabled. When in multi-threaded mode, each parameter that is handled by the parameter manager has multiple copies of its value built into it.  This can occasionally lead to confusing situations where seemingly impossible changes are being made to parameter values.  If you are running in MT state, try disabling it (or vice-versa if you are running in single-threaded mode).  This will be dependent on how you are using render views, but could be a source of differences.

If possible, can you describe the rendering setup that you are using to generate your G-buffer, and any subsequent rendering passes?  Are you using render views?  If possible, can you take a PIX frame grab and upload it here to the site?  Then I can try to take a look and see where it is being modified.

Sep 12, 2011 at 12:09 AM
Edited Sep 12, 2011 at 12:09 AM

My apologies for the very late reply, some times things just catch up with you and you get heavily distracted.

 

I don't believe it was due to multithreading (though I am going to try disabling it and see how it goes). I tracked the variable from creation to runtime, to setting to the shader and only after it is set to the shader did I see a difference in PIX (though I am still reading about threading in D3D11).

 

My issue that I was having from deferred rendering ending being due to the way the depth texture was being created. With the help of reading the book and taking a look at this code base I was able to track down the issue I was having. I can't thank you and the rest of the team enough about just how great this book and code base is.

Coordinator
Sep 13, 2011 at 5:22 AM

I'm glad you were able to solve your issue - if you have any further problems please feel free to post them!  So is the matrix modification understood now, or is it still not clear what is happening?

Also, thank you for the comments about the book - it was a big undertaking, and I really appreciate the feedback!

Sep 17, 2011 at 9:25 PM
Edited Sep 17, 2011 at 9:31 PM

The way each matrix is being set to the device does make sense. Though I think I figured out why some of the values seemed "modified", it is because they are.

 

When rendering point lights you do a " *1.1" against the range, though I don't understand why. From what I have read from various places, I don't see this happening anywhere else. Why do you multiple the range by 1.1?

 

// Determine the scaling factor based on the attenuation
const float scaleXYZ = light.Range * 1.1f;
m_WorldMatrix.Scale( scaleXYZ );

 

EDIT: My assumption is that this due to making sure the light volume is not exactly the same size of the light range to allow for better light fall off and no harsh edges.

Developer
Sep 18, 2011 at 12:57 AM

Yes the volume geometry has to be scaled a bit past your desired maximum light range, because the convex volume formed by a triangulated cone or sphere will always be smaller than the radius you use for placing the vertices. The 1.1 is just a fudge factor really that makes the bounding volume big enough, but if you wanted you could use a little trig to calculate an actual scaling factor based on the number of vertices used to create the cone or sphere geometry.