MJP

You don't have to issue Draw commands on the immediate context if you don't want to, the diagram is just showing that it's possible to do it.

Yeah GPU's can only work with a single index buffer, so typically you will duplicate vertices so that you have enough for all necessary combination of position/normal/UV/tangent/etc. If you're using a vertex shader and DX10+ it's possible to implement more complex means for storing vertex data since you can load arbitrary data from buffers, however like I said before the GPU is limited to one index buffer and your vertex shader will (usually) only run once for each vertex specified in the index buffer. Therefore it can get pretty complicated to do something like this.

The Model vertex data is loaded into vertex buffers when the model is loaded by the ContentManager. You can actually access these vertex buffers using the VertexBuffer property of ModelMeshPart.

Pre-filtering a standard shadow map won't fix visible aliasing, since the step function in the shadow map comparison will always re-introduce aliasing. You really need to filter the results of the comparison, which of course is the basic premise of PCF. VSM on the other hand don't have this step function, since it's specifically formulated to work with pre-filtering.

Ambient occlusion is essentially the shadowing that you'd get from having equal intensity lighting in all directions amount the mesh. The closer your lighting is those conditions, the better AO will approximate the shadowing in those conditions. So in other words it will probably work very nicely for an overcast outdoor scene, since in that case there's very little directionality to the lighting. However if you had just a single infinitely-small point light, the AO will be a very poor approximation since such a light would produce very tight shadowing (as opposed to the broad, undefined shadows that you get from AO). Often games will have some ambient term that's meant to represent indirect lighting bouncing off other geometry. Applying AO to this kind of lighting often makes sense, since indirect lighting is generally very soft.

In practice, applying AO to direct lighting from point/directional/spot lighting sources can have the result of making it look "dirty", since the corners will refuse to become brightly lit even when a light is shining directly onto the surface. You can actually see this in a lot of games where SSAO is applied indiscriminately.

When you call SetFullScreenState on your swap chain, you can pass a DXGI.Output to specify which display you want to go fullscreen on. To obtain an output for a display, you can get the DXGI.Adapter reference using the property Device.Adapter and then call GetOutput.

That function sets the bits of each component to the integer value of 0xFFFFFFFF. Your "if(nearEqualTest.x == 0xFFFFFFFF)" equality test will promote 0xFFFFFFFF to a float, which won't be the same value as integer 0xFFFFFFFF being reinterpreted as a float (the bits 0xFFFFFFFF actually don't form a valid floating point number, which is why you get -1.QNAN in the debugger). The reason 0xFFFFFFFF is used as the result is so that it can be used as a mask for subsequent SIMD mask operations that choose a particular value based on your conditional. DirectXMath exposes this functionality using XMVectorSelect.

If in doubt you should always look at the implementation of DirectXMath functions, since they're all inline in a the .h/.inl files.
 

Yeah I think it's a really poor move on their part. This means that if you want a free graphics debugging tool you'll have to stick to Nsight and GPU PerfStudio.

Yeah this whole thing is pretty bad. I really don't like that they've effectively killed PIX, and their replacement requires a paid version of Visual Studio.

You can't use the legacy "sampler2D" type at all in SM4.0/SM5.0 shader code. You have to use the new "Texture2D" and "SamplerState" types.

You can't just map any texture and read the data. You can only do it for textures created with STAGING usage, and that also specify that have CPU read access. Staging textures can't actually be used for rendering, generally what you will do is use CopyResource to copy the contents from a normal texture to a staging texture and then you'll map the staging texture to read the contents.

In general you should make sure that you create your device with the DEBUG flag set, and watch the native debugger output for errors and warnings. The debug device will give you detailed error messages for cases like this.

. A drawback to this method is that render targets have to be in the four 32-bit value format.

What makes you think that this is the case? You can choose whatever formats you want for your G-Buffer render targets, including those that have less than 4 components or that don't use full 32-bit precision for each component.

At any rate, I've never tried using a structured buffer as a G-Buffer and I don't know of anyone else that has. I think it should work okay, though. You definitely want to use the [earlydepthstencil] attribute, since this will not only ensure correct data in your G-Buffer but it will also enable the same optimizations used when rendering to a render target. The one major drawback that I can think of is that you would not be able to use MSAA with this setup. I would also suspect that it will not perform as well, due to specific optimizations in the hardware and driver used for writing to render target textures. But that's something you'd have to profile on different hardware to know for sure.

Shaders do need NdotL.  Division by PI should be precalculated and sent to the shader—IE the light values the shader receives should already have been divided by PI.

I don't really agree with that as general-case advice...it only makes sense for BRDF's that have a 1/pi term in them which isn't always the case.

If I had to pick one, it would be GGX. But for any non-trivial application you'll typically need more than one. At the very least you'll need dedicated skin and hair BRDF's to go with it, and you'll want anisotropy for a lot of materials as well.

Either way the BRDF itself isn't usually the tricky or expensive part for real-time graphics, it's...

A. Coming up with a good overall shading model and toolset that allows your artists to understand the parameters they're authoring and efficiently author many many materials using those parameters

B. Figuring out how to apply your BRDF to more than just point lights and directional lights

and

C. Making it not alias like crazy without ruining your BRDF

R32G32B32_FLOAT is actually an optional format for FEATURE_LEVEL_11_0. Before using a format you need to check this table to see if it's supported for your feature level. In the case of optional formats, you need to check at runtime using ID3D11Device::CheckFormatSupport.  In this particular case, I don't think there's any hardware that actually supports that format.

In general you should also create your device with D3D11_CREATE_DEVICE_DEBUG so that you get detailed error messages in these kinds of situations.