1. Why 32 bit masks are used for descriptor tables in RootSignature and DynamicDescriptorHeap classes? Root indices may be in range of 0 to 63, since 64 DWORDS are allowed, right?

2. Why descriptors are copied to the gpu visible heap one at a time (all range sizes are equal to 1)? Wouldn’t it be more optimal to store staged descriptors as ranges and copy larger chunks?

3. Why are descriptor copy operation is placed in a loop? Shouldn’t we minimize api calls or it doesn’t matter in this case? All ranges could be stored in a vector and commited in one call to ID3D12Device::CopyDescriptors.

4. Is allocating one descriptor heap per command list ok? Changing descriptor heap is a costly operation that could be avoided if the heap was reused. Although thread safety could become an issue…

Cheers and thanks for the tutorials!

]]>The tutorials are awesome and I am waiting for part 5,though I haven’t reached that far yet :P. ]]>

Thank you for your kind words. If you have any questions while you are creating your engine, please don’t be afraid to ask in the Discord server:

https://discord.gg/gsxxaxc

Thank you for your interest.

I am currently busy with another project at the moment. As soon as that is finished, I will return to creating DirectX 12 articles!

]]>DirectX 12 is a bit overwhelming even for experienced programmers. I tried to make it as easy as possible to understand but ended up creating 4 articles (so far), each one about 100 printed pages.

The numbers at the end of the class indicated added functionality to the previous version of the class. The numbers are not necessarily associated with Windows 10 (Operating system) or Window 10 SDK releases (for example, the ID3D12Device1 was relased together with the Windows 10 Anniversary Update, which was the 2nd major Windows 10 update since the original release), they are simply used to indicate added functionality. The DirectX Ray Tracing API (DXR) was added in ID3D12Device5 and ID3D12GraphicsCommandList4. So the numbers are not related to API versions, but simply iterations of that class.

I hope that makes sense?

]]>There are several issues with using matrices to represent rotations:

- If you perform a 90° rotation about the X axis (causing the Z axis to align with the Y axis) followed by an arbitrary rotation about the Z axis will result in a spin around the Y axis. This is the Gimbal lock problem that rotating 1 axis to align with another causes a loss of rotation about that axis (One less Degree of Freedom (DoF)).
- Matrix multiplication is not commutative. Changing the order of multiplication changes the result.
- It is difficult to perform an interpolation between rotation matrices (without decomposing the matrix first) without introducing skew in between (try to interpolate between the identity matrix and a rotation about any axis. What happens half-way through the interpolation?).

See Understanding Quaternions for an alternative approach to using rotation matrices to represent rotations.

]]>