Yeah you are on spot about my source of confusion:) We are on the same page about q^* by the way. It was a bit confusing at rotation formula only, where it is qpq^-1 but since your explanation everything is clear now thanks!

Best.

]]>I checked several sources for quaternion notation and this is what I found:

- Quaternions for Computer Graphics (Vince, 2011) (the primary reference for this article) uses \(q^*\) to denote quaternion conjugate and \(q^{-1}\) to denote quaternion inverse.
- Quaternion – Wikipedia (https://en.wikipedia.org/wiki/Quaternion#Conjugation,_the_norm,_and_reciprocal) uses \(q^*\), \(\bar{q}\), \(q^t\), or \(\tilde{q}\) to denote quaternion conjugate and also points out that the conjugate of a quaternion is also its own inverse (conjugating an element twice returns the original element).
- Mathematics for 3D Game Programming & Computer Graphics (Lengyel, 2012) uses \(\bar{q}\) to denote quaternion conjugate and \(q^{-1}\) to denote quaternion inverse.

So from these references, I think it is safe to say that there is no ambiguity using \(q^*\) to denote the quaternion conjugate. Perhaps your confusion comes from the fact that the unit norm quaternion conjugate is the inverse. This is equivalent to the fact that the transpose of an orthonormalized matrix is its inverse.

]]>One more thing, why don’t you store resources states in the directly Resource class? Having it as a global map costs some performance. Subresources count could be stored too.

Is there a reason why not to do it?

]]>I would like to point out an ambiguity in notations. In rotations section, \(q^{-1}\) is actually the conjugate if I am not mistaken, not the inverse. Thus, it creates an ambiguity with the definitions made before and other articles about the topic. I would humbly suggest changing the rotation formulation to \(qpq^*\). Again ofc. if I am not mistaken:)

Best

Barış

Thanks for pointing this out! I’ve corrected the text 🙂

]]>Wow, I’m really surprised that you picked up on this. This is still an issue that I need to fix. I have to think about how to fix it correctly. I tried appending a transition barrier for ALL subresources (to the correct state) but I think I got a warning when the debug layer is enabled stating that there are multiple barriers transitioning the same resource to the same state. I think I’ll need to do the transitions using a 2-phase approach (first transition all of the subresource that are not in the correct state, flush the transition barriers to the command list, then transition the entire resource using a seperate barrier). Since there were no side effects (in my case) when *not* appending a resource barrier for ALL subresources, I left it as-is. I still need to go back to this some day…

But thanks for pointing this out! It means that you’re really reading (and understanding) the code examples!

]]>Thanks for pointing this out. I only realized that this issue when I enabled GPU validation in the debug settings. It is not detected when you simply enable debug settings (without validation) so I didn’t even realize it was an issue.

I have since fixed this issue and you can see this in the DX12Lib project but I did not go back and update this tutorial (yet). To fix it, I always create the resource in the COMMON state (regardless of command list type) and always transition to the correct state depending on how the resource is being used (see the 3rd tutorial for the class that I use to manage resource states across multiple command lists: Learning DirectX 12 – Lesson 3 – Framework)

]]>