Selective Cook flag for DATs Nulls ?

Hi wondering why this isn’t a thing for the first time after using Touch for literally years :smiley:

I can’t even begin to count how many times I’ve split up a dat network and manually built a datExecute that copies the dat to another table only if it changes to keep other network areas from cooking even when nothing is changing.

This has effectively been my ghetto selective cook control for dats but it would be really neat if this was built into nulls.

Any big reasons why this hasn’t happened yet?

Thanks!

+1 and following

If should happen automatically and not require a user set flag. It is in the pipeline.

Sorry @ben just now seeing your reply from now, some time ago - wondering if you could clarify what you mean?

Here’s an example scenario that explains how I run into issues frequently:

1-
Dat A cooks frequently lets say. data changes every frame.
Dat B cooks infrequently, info is mostly static.

2-
Now I merge those two dats into 1 dat.

3-
Now I select the first row, and second row, of that merged dat into two separate dats down stream.

4-
Then I reference the data in each of those selects, into maybe chops, or sops, or anything really that gets requested down stream via render, or network etc.

Those things will cook when the dat cooks, even if the data in the dat doesn’t change. This is consistent with how chops work, where after data is merged, then separated again, a selective null is needed to stop cooks where data isn’t changing.

Here’s a photo example of something similar to the above scenario:

In that photo, both sops cook, and it would be nice if I could have two selective null dats, and turn on selective for each, so that the second sop and everything down stream of it does not cook.


A more practical, and convoluted example I had to work around today where a selective null dat would have been handy went like this:

1-
I have an op find DAT, that is searching a sub network for certain chops that match a criteria.
This op find dat then builds two columns, a standard “path” column, and also a custom name column that I use for selecting the appropriate row, in other areas:

2-
In this example, the first column I have circled, I am getting by extracting the channel name from the chop, accessing it with curOp.chans()[0].name, or something similar, and combining it with the parent name, to create a unique selector string.

3-
Because I’m accessing the name of the channels, the opFind rightfully cooks every frame, even though the end result is static data.

I guess my ideal solution is to put a “selective null” dat immediately after the op find, so that I can save a lot of performance down stream.

So, that’s kinda the long verbose version of my original thoughts in this post. Hope the extra details give a more concrete example of where I’m coming from!

Thanks a ton, sorry to revive an old thread, just missed this last time around.

What I meant was we shouldn’t need a selective null DAT to do that (nor should users ever need a selective null CHOP for the same trickery), what we need and are working on is per cell (and per channel for CHOPs) cook dependancy. It has been worked on and discussed internally since the original post I made, however there are a number of perquisites that need to happen before these changes can be started on. We keep getting closer to it, bit by bit, and now the final cooking optimizations are underway.
Cooking changes in the engine are extremely tricky, sorry I can’t offer a better timeline.

Ohh, I get what you’re saying, and awesome! Can’t wait for that. Appreciate the update and ya I can imagine how tricky this sort of optimization is. It’ll be a game changer when it’s ready.