MAYA-123509 fix merging of normals #2387
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Normals in USD can be kept in the "normals" attribute or the "primvars:normals" attribute. This breaks the semantic-agnostic merge algorithm as it did not relate the two attributes. In addition, the "privars:normals" has higher priority. The result was that the round-trip of Edit-as-Maya and Merge-to-USD would create the "normals" attribute attribute and the resulting prim would have both attributes, but the old unmodified primvats would win. This was bad when the mesh was edited as the wrong normals were used, but catastrophic when the topology was edited as the number of normals was incorrect. The fix is to add custom logic to handle normals merging. The new strategy is to rely on the USD exportdone during merge to always author the "normals" attribute and to delete the existing "primvars:normals" from the original USD data so that it does not take priority on the newly edited normals. While fixing this, other small fixes were done: - the messages printed during merging were improved to be easier to understand. - Added support for some additional data-type during USD import: byte and unsigned int were not supported. - Added a comments about the fact that we currently do no compare metadata to determine if a prim has changed.
pierrebai-adsk
commented
May 30, 2022
pierrebai-adsk
commented
May 30, 2022
pierrebai-adsk
requested review from
boudrey and
williamkrick
and removed request for
boudrey
|
Only PF failure is a texture image comparison failure on Linux that is unrelated. |
williamkrick
previously approved these changes
May 31, 2022
williamkrick
approved these changes
Jun 3, 2022
pierrebai-adsk
added
ready-for-merge
pierrebai-adsk
added
the
ready-for-merge
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Normals in USD can be kept in the "normals" attribute or the "primvars:normals" attribute. This breaks the semantic-agnostic merge algorithm as it did not relate the two attributes.
In addition, the "privars:normals" has higher priority.
The result was that the round-trip of Edit-as-Maya and Merge-to-USD would create the "normals" attribute attribute and the resulting prim would have both attributes, but the old unmodified primvats would win.
This was bad when the mesh was edited as the wrong normals were used, but catastrophic when the topology was edited as the number of normals was incorrect.
The fix is to add custom logic to handle normals merging. The new strategy is to rely on the USD exportdone during merge to always author the "normals" attribute and to delete the existing "primvars:normals" from the original USD data so that it does not take priority on the newly edited normals.
While fixing this, other small fixes were done: