PF_Cmd_SEQUENCE_FLATTEN is sent when my effect is first applied

[朵格Dolag]

Hello everyone,

I'm attempting to store some per-instance data with sequence data, but I have encountered several issues when using the sequence.

The most weird problem is that, when I first apply my plugin in a completely new project, the command selector was sent commands in the following order:

1. Global Setup

2. Parameter Setup

3. Sequence Setup

4. Sequence Flatten

5. Sequence Resetup (in the main thread)

6. Sequence Resetup (in another thread)

if I remove my effect and purge the cache, AE will call Sequence Setdown twice, like:

7. Sequence Setdown (in the main thread)

8. Sequence Setdown (in another thread)

The first question is why Sequence Flatten and Resetup are called when first applied to a layer. And then why Sequence Resetup and Sequence Setdown were called twice in different threads. The final question is how to use sequence data correctly.

Thanks.

[朵格Dolag]

I have used the latest SDK and tested it in both AE 2019 and 2020.

[shachar carmi]

the sequence seems strange but it is correct, assuming you've set PF_OutFlag_SEQUENCE_DATA_NEEDS_FLATTENING during global setup.

the logic behind flattening is that some data structures can't be simply copied. that struct might contain pointers that point to data that needs to be fetched and copied as well, or any other reason why a simple mempcy of the data sctruc is not good enough. hence, AE is giving the plugin the poopertunity to serialize all the required data into one copyable piece of memory.

so why the resetup in multiple threads?

1. classicaly, when AE ass for a flat sequence data handle, it required the plugins to return that handle over the unflat data handle, so you'd lose the unflat sturct while returning the flat copy. so resetup from the flat copy to the unflat copy is required.

on AE new rendering scheme where the rendering thread (and sometimes each of the rendering threads) has it's own copy of the sequence data, flattening and unflattening happen much more often. so to make the process more efficient, an new flag was introduced: PF_OutFlag2_SUPPORTS_GET_FLATTENED_SEQUENCE_DATA. that flag allows the plugin to deliver the flat copy without losing the original unflat one, thus removing the need for some of the resetup calls on the ui thread. this change is not yet complete, and currenly only applies for moving info from the ui thread to the render thread. AE still behaves in the old way in regards to actions within the ui thread alone (such as copy/paste/duplicate/save).

2. to elaborate on the separte render threads: back on 2015, AE had the ui and rendering separated to different threads as not to choke the UI when rendering. to accomplish that, the rendring threads have a separate copy of project, so that the UI can make changes to the project that won't interfere with the rendering thread in mid render. since then, the rendering threads are also forbidden from making changes to the project as well. AE updates the render copy of the project to be sycnhronized iwht the UI copy of the project when not interfering with a currently rendering frame.

some plugins require each rendering htread to have it's own copy of the sequence data. you can optionally set the PF_OutFlag2_MUTABLE_RENDER_SEQUENCE_DATA_SLOWER flag and AE will accomodate.

that would also explaing the separate sequence setdown calls on multiple threads.

so it would appear you ARE using sequence data correctly.

some other notes from my experience:

1. on sequence resetup you MIGHT receive an unflat copy! have some tag in your data saying if it's flat or not, and act accordingly before assuming the data is flat just because it's a resetup call. (unless your data doesn't need unflattening at all, of course)

2. during sequence setup or resetup, don't assume the plugin can look for it's own layer/comp. sometimes AE constructs the instance before associating it to a layer.

[朵格Dolag]

Hi Shachar,

The actual requirement I have is to store and retrieve per-effect data. My idea is to let each Effect obtain a unique instance id and store it in the sequence data. Then, I can use the instance id as the key to read a map that stores Effect data. However, due to the strange behavior of the sequence data, I am unable to handle copying, loading from disk, and other behaviors correctly to ensure the uniqueness of the instance id. Is there any method to store and retrieve data corresponding to Effects or obtain per-instance unique ids?

Thanks for your detailed answer!

[shachar carmi · Accepted solution]

sadly, there isn't. i've dealt with this issue a while back, and evetually solved it by no simple means...

for my purposes i soved it per layer, and not over the entire project. if two instances with the same id were found on the same layer, then the second one must be a copy and is therefore assigned a new id.

i guess you can do the same project-wide.

1. on sequence resetup, flag the sequence data as "requires checking the id".

2. on the first chance (because during sequence_resetup the effect might still not have an associated layer), you can scan the project for similar id's or better yet, use global data to track where instances are and what's their id's.
3. if there's a conflict, deduce which is the original (like, where was that instance last seen), and assing a new id to the new copy.

[朵格Dolag]

Oh, this is terrible. Your method sounds effective but so weird and complex. I think the better approach would be to make all the objects in the sequence data trivial, in order to avoid issues about pointer and heap memory. Another option could be to directly serialize the objects into strings and store them in the sequence data, and then dynamically deserialize them back into objects during rendering (although this may decrease performance).

[shachar carmi]

Yeah... If you can avoid the need for specific instance recognition in ae, do avoid.

I hope the overhead for deserializing your data structure is not too bad. I certainly overestimated stuff like that and it turned out to be negligible compared to the actual rendering...

[朵格Dolag]

I tried, and this method works very well! It doesn't cause any memory leaks and doesn't become a performance bottleneck either (in my scenario, the serialized data is relatively heavy).