Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
280: Split-parent animations needs support for re-entry case #504
Suppose this blend file:
Version 1 (which may technically work right now):
When accessed via bpy, you'd see this as a parent-child chain of 1_AnimatedPart as the top, 2_parent_in_collection, 3_Cube_parent_out_of_collection at the bottom. As you can see this snakes in and out and back in of the collection. A niave implementation of the feature would actually handle this as a re-use case since the bone for 1_AnimatedPart already exists.
Here is version 2:
Here I've changed the name to force the algorithm to deal with this in the worst order possible. By the time the recursion algorithm gets to one_AnimatedParent it will already exist!!
We can check for that but this whole conversation is stupid.
Unless Ben or someone else tells me otherwise, this is something that needs to be guarded against, not technically allowed, supported, encouraged, or advertised.
*Note: It doesn't matter 1_ or 2_ is animated. The whole case stinks.
Related to #494
Nope! We're supporting this. The reason being that one day an artist's project could get so complicated it will snake in and out and we don't want to make artists suddenly have to re-organize their whole tree because I don't think they should have such a disorganized artist.
The fix for version two is actually very simple. When recursing down we see if that bone for that Blender Object is already in the tree and if so, use that instead of making a new one. Continue recursing from there. This "already exists" case needs
And boy does it get fun when the already exist case ALSO has a parent to walk up ("new branch"). And what if that new branch then has a "reuse" case!
Or, during the "already exist with parent", that parent is a reuse case? How crazy can we get? I'm just rattling stuff off. I'm sure that some of these case may not be possible.