Fix Maya-exported rigs by not trying to topologically sort glTF nodes. #17641
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
pcwalton
added
A-glTF
bushrat011899
approved these changes
Feb 2, 2025
tychedelia
approved these changes
Feb 2, 2025
tychedelia
added
S-Ready-For-Final-Review
The code added in bevyengine#14343 seems to be trying to ensure that a `Handle` for each glTF node exists by topologically sorting the directed graph of glTF nodes containing edges from parent to child and from skin to joint. Unfortunately, such a graph can contain cycles, as there's no guarantee that joints are descendants of nodes with the skin. In particular, glTF exported from Maya using the popular babylon.js export plugin create skins attached to nodes that animate their parent nodes. This was causing the topological sort code to enter an infinite loop. Assuming that the intent of the topological sort is indeed to ensure that `Handle`s exist for each glTF node before populating them, there's a better mechanism for this: `LoadContext::get_label_handle`. This is the documented way to obtain a handle for a node before populating it, obviating the need for a topological sort. This patch replaces the topological sort with a pre-pass that uses `LoadContext::get_label_handle` to get handles for each `Node` before populating them. This fixes the problem with Maya rigs, in addition to making the code simpler and faster.
|
The tests failed because I wasn't checking for cycles. I added code to do that. |
mockersf
approved these changes
Feb 2, 2025
mrchantey
pushed a commit
to mrchantey/bevy
that referenced
this pull request
Feb 4, 2025
bevyengine#17641) The code added in bevyengine#14343 seems to be trying to ensure that a `Handle` for each glTF node exists by topologically sorting the directed graph of glTF nodes containing edges from parent to child and from skin to joint. Unfortunately, such a graph can contain cycles, as there's no guarantee that joints are descendants of nodes with the skin. In particular, glTF exported from Maya using the popular babylon.js export plugin create skins attached to nodes that animate their parent nodes. This was causing the topological sort code to enter an infinite loop. Assuming that the intent of the topological sort is indeed to ensure that `Handle`s exist for each glTF node before populating them, there's a better mechanism for this: `LoadContext::get_label_handle`. This is the documented way to obtain a handle for a node before populating it, obviating the need for a topological sort. This patch replaces the topological sort with a pre-pass that uses `LoadContext::get_label_handle` to get handles for each `Node` before populating them. This fixes the problem with Maya rigs, in addition to making the code simpler and faster.
joshua-holmes
pushed a commit
to joshua-holmes/bevy
that referenced
this pull request
Feb 5, 2025
bevyengine#17641) The code added in bevyengine#14343 seems to be trying to ensure that a `Handle` for each glTF node exists by topologically sorting the directed graph of glTF nodes containing edges from parent to child and from skin to joint. Unfortunately, such a graph can contain cycles, as there's no guarantee that joints are descendants of nodes with the skin. In particular, glTF exported from Maya using the popular babylon.js export plugin create skins attached to nodes that animate their parent nodes. This was causing the topological sort code to enter an infinite loop. Assuming that the intent of the topological sort is indeed to ensure that `Handle`s exist for each glTF node before populating them, there's a better mechanism for this: `LoadContext::get_label_handle`. This is the documented way to obtain a handle for a node before populating it, obviating the need for a topological sort. This patch replaces the topological sort with a pre-pass that uses `LoadContext::get_label_handle` to get handles for each `Node` before populating them. This fixes the problem with Maya rigs, in addition to making the code simpler and faster.
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.
The code added in #14343 seems to be trying to ensure that a
Handlefor each glTF node exists by topologically sorting the directed graph of glTF nodes containing edges from parent to child and from skin to joint. Unfortunately, such a graph can contain cycles, as there's no guarantee that joints are descendants of nodes with the skin. In particular, glTF exported from Maya using the popular babylon.js export plugin create skins attached to nodes that animate their parent nodes. This was causing the topological sort code to enter an infinite loop.Assuming that the intent of the topological sort is indeed to ensure that
Handles exist for each glTF node before populating them, there's a better mechanism for this:LoadContext::get_label_handle. This is the documented way to obtain a handle for a node before populating it, obviating the need for a topological sort. This patch replaces the topological sort with a pre-pass that usesLoadContext::get_label_handleto get handles for eachNodebefore populating them. This fixes the problem with Maya rigs, in addition to making the code simpler and faster.