We noticed an issue where moving tracks into a child subsequence interferes (ignores?) with the hierarchical bias settings that are configured for the container level sequence. I’m not sure if this is intentional behaviour, but it feels unintuitive.
This presented an issue with structuring level sequences for shot work. As we have have departmental level sequences (ANM, FX, LGT etc), and we want departments from “later” in the pipeline to have higher hbias. However if inside (eg) ANM subsequence the user decides to partition their work into child subsequences for various organisational reasons (eg ANM_FG, ANM_BG etc), those child subsequences are no longer subject to the hbias rules configured at shot level.
This also impacts lighting, as this department works across multiple different subsequences depending on how general their change is. This behaviour of a value from a lower hbias sequence “breaking out” and taking precedence over higher hbias level seqs has lead to unintuitive troubleshooting scenarios.
I understand how this can be unintuitive. We initialize all scene sections with a default hierarchical bias of 100, so in your case, it competes and wins because it’s evaluated last. It is expected that you go through and check your bias on new subsequence creation to ensure that you’re setting it appropriately.
> It is expected that you go through and check your bias on new subsequence creation to ensure that you’re setting it appropriately.
I’d be happy to do that, but what could I even set the bias to in order for the “cheat” sequence to not win over the high hbias sequence? In screenshot below, I’ve lowered `cheat` all the way to zero and it still overrides. I would need to add a new subsequence to “ls_high” called “counter-cheat” which is at the same overall sequencer depth as “cheat” in order to evaluate as expected. But that is not a practical solution for a production.
The “deepest opinion wins, regardless of parental hbias” approach breaks a nice encapsulation we thought we had, where a departmental level sequence could internally structure their hierarchy in a way that suited them, as they can break the shot in unexpected ways if they split the wrong track out into a child sequence
Hierarchical bias changes aren’t committed until you save the scene. One thing to keep in mind, too, is that the bias values are additive up the chain. If the values are the same at the top level, the output will be blended. For example, if is_low and cheat were 50 and 51, respectively, they add up to 101, and the whole is_low chain will take priority.
Yeah, I agree. I raised these and a few other issues with Greg, the product manager, yesterday about that feedback. I’m not sure what will change, but I gave him the info. Currently, everything is working as “intended”.
Thanks Dustin. Saving the level sequence to apply the hbias rules was catching me out. The rule about hbias values being additive up the chain is good to know. Maybe we should be making our child sequences have a default starting hbias of 1/10th that of their parent to try and minimize the chances of hitting this issue in future.
> Hierarchical bias changes aren’t committed until you save the scene.
Yes, and there’s a related workflow UX trap where if you set an override in is_high (eg sunlight=red), and then switch to is_low and bind to the same property there (eg sunlight=green) using the actor details panel, you will incorrectly see the effects of the is_low (green) value in the viewport until you hit save - then it reverts back to is_high (red). So a user can be working away in is_low and then they perceive their work as “getting lost” as soon as they hit save. If you use sequencer details rather than actor details you don’t get this misleading behaviour.