inlife / nexrender

📹 Data-driven render automation for After Effects

Home Page:https://www.nexrender.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Name chain does not work in case last composition name matches

ivansenic opened this issue · comments

Describe the bug

If the composition name is given with the chain notation, then sometimes it works sometimes not. I will provide examples on when it does not work correctly and then it does. This relates to the nexrender.selectCompositionsByName = function(name, callback) function.

Not working

Let's say that I have a layer named myName and the following composition chain main->scene 1->container. If there is another composition with the chain main->scene 2->container also containing a layer with myName, then the first chain would select both compositions container, which exists in scene 1 and scene 2. And vice versa as well main->scene 2->container would select two compositions.

Working

Seems that everything works fine if the last composition in the chan is different. Take the same example above just strip the last composition and imagine a layer myName exists in both scene 1 and scene 2. The the chain main->scene 1 selects only one composition correctly.

Analysis

My guess is that container is used in two compositions. Thus, this peace of code:

          for (var i = 0; i < comp.usedIn.length; i++) {
            if (
              comp.usedIn[i] instanceof CompItem &&
              comp.usedIn[i].name === parentChain[parentChain.length - 1]
            ) {
              parentComp = comp.usedIn[i];
              break;
            }
          }

finds the part and the condition comp.usedIn[i].name === parentChain[parentChain.length - 1] matches for both, as only the last chain item is checked.. Since it matches both, it always takes the first parent composition for the further checks, which is wrong as it will always pass the further checks..

Proposed solution:

    function isNestedComp(comp, name, parentChain) {
        if (
          name &&
          comp.name === name &&
          parentChain &&
          parentChain.length > 0 &&
          comp.usedIn.length > 0
        ) {
          for (var i = 0; i < comp.usedIn.length; i++) {
            if (
              comp.usedIn[i] instanceof CompItem &&
              comp.usedIn[i].name === parentChain[parentChain.length - 1]
            ) {
              var parentComp = comp.usedIn[i];
              if (parentChain.length === 1) {
                return true;
              } else {
                var chainCopy = [...parentChain];
                var isNested = isNestedComp(
                  parentComp,
                  chainCopy.pop(),
                  chainCopy
                );
                if (isNested) {
                  return true;
                }
              }
            }
          }
        }
        return false;
    }

Have you had a chance to test the proposed solution @ivansenic ?
I might be wrong, but I feel like the [...] operator would not work in the older jsx scripting environment of AE

Did not test it yet, will try tomorrow. Would .slice(..) be better alternative?

Actually yeah, there potentially could work:

var chainCopy = parentChain.slice()
// or
var chainCopy = [].concat(parentChain)

Will test this today with slice() and report back once I have resulsts..

@inlife My solution does not work.. It still matches the first parent found so yea does now work.. I'll continue exploring the options..

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I will send some final resolution about this during the day.

Will be looking forward to that!

I my comment I said that the fix is not working, but that's not really true. The fix proposed is definitely a good one, however, I would like to explain in what situations it helps and why I said it's not working in the test we did.

There are two situations to distinguish. When a same composition is used in two different parents, and when two completely different compositions have a same name.

Situation 1: Same comp in different parents

In this case we have a same composition included in two different parents. So we have following situation (made up IDs in brackets):

  • First (1) -> Target comp (3)
  • Second (2) -> Target comp (3)

Now without the fix above, following happens:

  • If you target a layer First->Target comp, it will work and layer would be updated. Because it's the same comp, it will be updated in that Target comp which influences both First (1) and Second (2).
  • If you target a layer Second->Target comp, it will not work and nothing will be updated (proposed fix solves this issue).

Now important is to understand that in this situation there is no way to update the layer only in one concrete path. As composition is contained in two parents, any matched path would influence the comp and thus both parents. This is the reason I said fix is not working at the first place, as it's actually impossible to achieve once you have same comp in different parents.

Situation 2: Different comps with same name

In this case we have different compositions included in two different parents. So we have following situation (made up IDs in brackets):

  • First (1) -> Target comp (3)
  • Second (2) -> Target comp (4)

Now without the fix above, following happens:

  • If you target a layer First->Target comp, it will work and layer would be updated. Because it's the different target comp, it will be updated on in the composition contained in the First (1).
  • If you target a layer Second->Target comp, it will not work and nothing will be updated (proposed fix solves this issue).

Conclusion

Fix is improving the path based selection for sure. It's deployed in our production for over a month now and we saw no other issues or any backward incompatibility.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.