Hello,
I have noticed that once Null CHOP with selective cooking is being referenced in custom COMP parameters, it makes other parameters with expressions (on this COMP) cook even when their expression doesn’t require cooking. I am attaching simple scene where you could find an example with more information. I am using version 2020.22080 on Windows 10. Thanks.
null_selective_cook_problem.1.toe (4.1 KB)
Best wishes
Monty
Haven’t checked your file yet but seems related to How to reliably debug cooking? Also - best way to update resolution from an input?
This isn’t technically a bug, you just found an interesting scenario where the selective null causes more work.
So with a Null CHOP set to automatic, the nodes downstream are cooking because they have a time dependency. The parameters know whether they are time dependent or not, so and pass on their time dependency to the nodes and parameters using them. So base1’s Workingpar knows it is time dependent and Chillpar knows it is not.
When you use a Null CHOP set to selective, the nodes downstream are no longer time dependent, but data dependent on the Null CHOP. So all base1 knows is that data upstream has changed, and anything with a data dependency (both Workingpar & Chillpar) will re-evaluate because the data they use might have changed. That possibility is passed to base1/par1.
I hope this make sense. We are in the process of optimizing nodes further so that they will only cook when their data has actually changed. We don’t have a release schedule for this.
Aha, I see, thank you very much for an explanation. Should I move this thread to different category as it is not considered as bug?
I just marked it as resolved, if that works for you.
Sure, feel free to mark it as resolved, thanks.