お世話になっております。
インラインで返答させていただきます。
> はい、ご指摘のとおり、無駄を省ける部分が確かにあります。特に、VectorMatrixMultiply の呼び出しについて検討してみると、Hide されたボーンの計算はスキップすることができます。これらのボーンは、親のトランスフォームをスケール 0 で取るだけなので、余計な乗算の必要はありません。この問題につきましては、開発チームが修正できるように、Epic 内部で運用されている JIRA のチケットを作成したいと思います。
Hideされたボーンに関してですが、完全に計算されないというのであればそちらの方が軽くなりますので良いと思います。その場合親のスケール0をかける必要もなくZeroMatrixで良いと思います。ただ、過去から現在のコードを見ますとHideされてスケール0にした状態でも位置は更新されていましたので、アプリ側でHideしたボーンから座標を取得するために残されていた可能性があるかなと思いました。そのためこちらに関しては現状と同じようにHideしたボーンの更新もやってしまってよいのではと自分は思っております。
> また、ReferenceToLocal がメッシュのすべてのボーンを含んでいる件 (現在のメッシュ LOD のためのボーンだけではなく) につきましては、意図されたものだと私は理解しております。このデータはモーション ベクターの計算に使用されるため、複数のフレームにわたって有効である必要があります。もし現在の LOD のボーンだけを保持しているのであれば、LOD が変わったときやボーンの数が変化したときに問題が生じることになります。メッシュのすべてのボーンを保存しておくことによって、そのような問題が回避することが可能です。そうは申しましても、もっと効率的なやり方があるかもしれませんので、この件につきましても JIRA のチケットに記載したいと思います。
ReferenceToLocalの数が全てのボーン確保されていること自体は問題ないと思っております。 更新すべきRequiredBoneIndicesに含まれないボーンもVectorMatrixMultiplyで更新がされている部分に関して高速化が可能ではないでしょうか？
> しかし、ExtraRequiredBoneIndices につきましては、冗長な VectorMatrixMultiply の呼び出しは行っていないはずです。と申しますのも、配列 RequiredBoneSets (これには LOD.ActiveBoneIndices と ExtraRequiredBoneIndices が含まれています) をループで回している間に、ReferenceToLocal で同じボーン インデックスに書き込まれ、その後にすべてのボーンについて VectorMatrixMultiply が呼び出されているからです。つまり、LOD.ActiveBoneIndices と ExtraRequiredBoneIndices で重複するボーンがあっても、重複して VectorMatrixMultiply が呼び出されることはないはずです。
LOD.ActiveBoneIndices と ExtraRequiredBoneIndices に重複したボーンがあった場合、ReferenceToLocal[ThisBoneIndex]の同じ計算が2度行われるということを伝えたかったのです。そのためmodコードではReferenceToLocalUpdatedのフラグ配列を使用して2度再度計算が行われないようにスキップしています。
またNeedsUpdateBoneIndciesとReferenceToLocalUpdatedは同じような情報を持ちますが、ComponentTransform.IsValidIndex(ThisBoneIndex)など、他の要素でReferenceToLocalが更新されない場合があるのでNeedsUpdateBoneIndciesを別に用意しています。
最終的に自分の変更点をまとめると
ReferenceToLocalUpdated … 同じ骨のReferenceToLocalを2度計算しないようにする
NeedsUpdateBoneIndcies … 最終的にReferenceToLocalが更新された骨のみVectorMatrixMultiplyする
Hideされた骨 … 位置のみ最終姿勢に更新する仕様は変更なし
という形にしてあります。
よろしくお願いいたします。