>>2884817InverseDir is a function placed directly above the code you've been playing with the whole time, in the files that you shared in
>>2884403. It partially transposes the matrix passed to it and is used in InverseCtrl.
"Three inverted floats" refers to line 102:
> -mat._41, -mat._42, -mat._43, 1>> Were you suggesting that using an extra bone (if it's possible) to get the inverse matrix would be less efficientI was suggesting that the difference would be negligible. No idea which approach is more efficient.
>> I didn't understandThis hidden bone is originally used only as a visible vector pointer (like 先 bones) for the カメラ bone, because the PMD format cannot link to bone offsets. With PMD, if you see bones pointing in any direction other than straight up, it means they're linked to another bone. PMX does not need such bones.
>> If it's possible for a bone to inherit less than 1 of the rotation of a parent bone (and I don't know if it is), then it might be possible for it to use -1 of the parent bone's rotation, and then somehow get a chain from root to an inverse-camera-bone.>>2880353>>2880452The problem with going -1 is that it simply negates the rotation rather than inverting it (the principle used in shoulder P/C bones), and -2 will not get you a proper inverted angle either, as 720 == 360 == 0 degrees, and another big problem is that the world is divided into two halves, so any non-whole value comes with snapping between the halves. As we've already established, the only way around it is to use a Y-reversing bone morph or manually revert a bone. Visual bone vectors (links, pointers, arrows) apparently mean nothing to the effect code, and only the offsets from the default state matter. Here's a demo:
https://files.catbox.moe/9i6w8f.mp4Therefore, it comes down to either sticking with a code-inverted-rotation array or choosing the bone order/which one(s) to invert and which you would use to feed the functions that make the shader work.
