お世話になっております。
UE5.7 の Cook 差分調査で、StaticMesh の Lumen Mesh Card 由来と思われる差分を確認したため相談させてください。
同一データで2回 Cook した結果を比較したところ、コンテナ生成ではなく cooked package 内に差分が出ています。
差分は FCardRepresentationData / FMeshCardsBuildData::CardBuildData / FLumenCardBuildData 周辺と思われます。
既存投稿「Cook non-determinism in UStaticMesh::RenderData.LODResources.CardRepresentationData」と関連する可能性があります。
[Content removed]
ただし本件では LandscapeNaniteMesh の rename ではなく、通常 StaticMesh の CardRepresentationData 内部差分も確認しています。
疑っている箇所は MeshCardRepresentationUtilities.cpp の LimitClusters() で、cluster sort が WeightedCoverage のみを比較している点です。
WeightedCoverage が同値の場合、順序が不定になり、runtime 上は等価でも serialized cooked data が揺れる可能性があると考えています。
このため、WeightedCoverage が同値の場合に Coverage、NearPlane、Bounds、SurfelIndices などで deterministic な tie-break を追加する修正を検討しています。
確認したい点:
1. 既存投稿の CardRepresentationData non-determinism 修正は UE5.7 に取り込まれていますか？
2. CardRepresentationData が生成済みの場合でも、LimitClusters() の WeightedCoverage のみの sort は Cook 差分の原因になり得ますか？
3. 同値時に deterministic な tie-break を追加する方針は妥当でしょうか？
4. この変更では CARDREPRESENTATION_DERIVEDDATA_VER の更新が必要でしょうか？
お手数をおかけいたしますが、何卒よろしくお願いいたします。
まずLimitClustersでのソートの不安定性に関する懸念についてです、幾つかメッシュを作成しMeshCardを作成してみましたがLimitClustersでクラスター無いに複数のSurfulがある場合でも完全に同値のCoverageWeightを持つケースは再現できていません。
凹型のメッシュで内側に同じ方向かつ同面積の面が複数あったとしても、レイのトレースによるVisibility判定で微細が誤差が発生するため完全一致には至りにくいです。
ただしもし実際に完全に同値が入力された場合にはソート順序が不定になる可能性がないとは言えません。可能であればこの現象が発生し得るメッシュをご共有いただけますと幸いです。
以下は連番でのご質問に対する回答になります。
- CardRepresentationData non-determinismの修正はUE5.7に組み込まれていないように見えます。担当者に確認中ですので少々お待ちください。
- CardRepresentationDataが生成済みというのはDDCが既に存在すればと解釈しましたが。DDCがあった場合LimitClusterに到達しないため再生成されないはずです。
- 完全に同値が入力されている場合に第二の条件を追加することは適切だと思います。恐らくBoundsを用いるのが適切かと思います。
- もしこのアルゴリズムを変更された場合にはCARDREPRESENTATION_DERIVEDDATA_VER を変更することをお勧めします。DDCをリアする手段も考えられますが選択的にクリアすることは難しいので、全消去になります。
ご回答ありがとうございます。
上記ご回答内容、承知いたしました。
完全同値時の tie-break 追加は妥当であり、Bounds を用いるのが適切そうとの点、また変更時には CARDREPRESENTATION_DERIVEDDATA_VER の更新を推奨との点、理解いたしました。
一点補足させてください。
質問内の「CardRepresentationData が生成済み」という表現は、DDC が既に存在するという意味ではなく、CardRepresentationData が null/非null で揺れているのではなく、両方の Cook で CardRepresentationData は生成されており、その内部 serialized data が揺れている、という意味でした。
今回の検証は DDC を不使用に設定して行ったものであり、DDC hit により LimitClusters() を通らないケースではなく、再生成される条件で確認しています。
対象メッシュについては社内データのためそのまま共有は難しいですが、可能であれば再現用の最小データを作成できるか確認いたします。
引き続き、UE5.7 への既存 CardRepresentationData non-determinism 修正の取り込み状況について、ご確認いただけますと幸いです。
> 引き続き、UE5.7 への既存 CardRepresentationData non-determinism 修正の取り込み状況について、ご確認いただけますと幸いです。
こちらやはり取り込みがなされておりません。もし提案された修正が問題を解決し得るのであればリンク先の修正をお試しください。
DDCをクリアにして作り直した場合に生成されるデータが不安定という件承知しました。
ちなみにDDCをクリアせずに利用し続けた場合、キャッシュされたデータを再利用する形になり差分の発生を回避できるという認識ですが間違いございませんでしょうか？
ご確認ありがとうございます。
UE5.7 に既存 CardRepresentationData non-determinism 修正が取り込まれていない件、承知いたしました。
リンク先の修正についても確認いたします。
DDC をクリアせず、同一の DDC key に対してキャッシュ済みの CardRepresentationData が正常に取得できる場合は、LimitClusters() 以降の再生成処理には入らないため、その範囲では差分の発生は回避される認識です。
一方で、今回問題として見ているのは、同一入力・同一 DDC key であっても、DDC を使用しない設定、DDC クリア、または DDC fetch miss/failure などにより再生成が行われた場合に、生成結果が非決定的になり cooked package に差分が入る可能性がある点です。
そのため、DDC により結果が固定されることは回避策にはなり得ますが、DDC が取得できず再生成が行われるケースも考慮すると、根本的には CardRepresentationData 生成処理自体が deterministic である必要がある、という認識です。
ひとまずご回答いただいた内容を踏まえ、こちらで tie-break 追加および CARDREPRESENTATION_DERIVEDDATA_VER 更新の修正を試してみます。
ご確認いただきありがとうございました。