hold on... a track ammte and a mask are two different things... 1. track matte - one layer operating with the alpha/luma of the layer above it. 2. mask - a vector shape drawn on a layer with the pen tool. if your situation is the same as #1, then the mask suite is the wrong way to go as there are no masks on that layer, and then getting 0 as the num_masks actually makes sense... ... View more

honest to god, i can only theorize in regards to this question... when working with "transform world", i noticed it gave me good results when typing in a param value numerically and pressing enter, while it gave me bad results while dragging a slider. i figured it was halting the transformation process to allow for a smoother interative experience for the user, alas it ended up being unusefly. parhaps this was left around since before CC2015, where the separate rendering thread was introduced... in any case, since a lot of the suite callbacks accept a null instead of the effect_ref, and i vaguely remembered the PF_INTERRUPT macro internally uses the same effect_ref, that it allows for the transform_world callback to make that check. again, this is just me throizing here...   as for the wrong info in the docs, yes, you might encounter that sporadically. it's usually a non-issue, as codesense will tell you what you need to put in each arg, but non the less, if you tell the engineering team you found a mistake, they'll fix it. it happens from time to time. 🙂 ... View more

ok... i think i partially understand what you're aiming for... i too do some preparative re-transformations of the result, but i do this to achieve exponential replications. 🙂 anyways, here are a the consideration you should take into... consideration... 1. when you transform an image in any way where original pixels don't end up on exact "whole" pixels, the image gets degraded. for example, if an input pixel ends up half way between two output pixels, these two pixels will have that input pixel blended between them. so re-transforming several times with "lossy" transformations, will give you a degraded result (blurry or jagged) compared to a single transformation render with a single matrix containing all the transformation operations. 2. transformation matrix multiplication is VERY cheap. it's a 3x3 matrix. you do like, 20 something operations to multiple the matrix, and then you go and to 6(ish) operations PER PIXEL when rendering, summing up at the TENS OF MILLIONS of operations per 2K image transformed... (without even talking about subsampling...). so you save very little time multiplying the matrices, and spend a TON of time doing redundant rendering.   as per "never use 2 renders (transform_world)", i think you misunderstood what i wrote. never use the same buffer as both the input and the output of transform_world, as it reads the input and overwrites it at the same time, most likely resulting in a corrupted output. if you want to do repeated transformations you should: 1. create a new buffer. let's call it "temp". 2. transform the input to temp. 3. transform temp to output. 4. transform output back to temp. 5. repeat steps 2-4 as much as needed. 6. if the last transformation ended up on temp, copy it to output. 7. NEVER overwrite the input buffer... AE hands you the original, which it caches. writing to the input buffer creates the most bizarre bugs. don't ask. ... View more

you get an effect ref using AEGP_GetLayerEffectByIndex with an AEGP_LayerH and the effect index on that layer.   if you need to consistently identify a specific instance of an effect, that's a lot trickier... the way i go about it is to put some id in sequence data, and accessing it via AEGP_EffectCallGeneric. but even that is tricky as a duplicated effect will have the same id... another way to go about it, is to rename some invisible param, but that doesn't survive reloading a project. ... View more

good question... to the best of my knowledge, the number of available threads doesn't change throughout the AE session. the decision on PF_Iterations_ONCE_PER_PROCESSOR is more of an optimization decision highly relying on your algorithm. for image processing, i almost never use PF_Iterations_ONCE_PER_PROCESSOR. why? becuase if working one chunk pre processor, some threads are bound to fininsh processing before the others, and then these processors don't lend a hand with the remainig work on the other threads. so working with n iterations assures minimal loss of available cpu power for almost all of my image processing algorithms. ... View more

"i" is the iteration index. you can call iterate_generic for 1000 repetitions. it will be called on all available threads, but not with sequential values of "i". the first passed value of "i" may very well be 500, followed by 200. the reason for this is to minimize cpu cache conflicts. sometimtes it's helpful, the rest of the time it's benign. so say AE has 4 threads and are have requested 8 repetitions. the calling sequence may look like: thread 3, i 6. thread 0, i 0. thread 1, i 2. thread 3 i 7. thread 2, i 4. thread 2, i 5. thread 0, i 1. thread 1, i 3.   the thread number CAN be the same as the thread index (for example when calling 8 repetitions on 8 threads it could happen by chance), but if that's always the case for you, then something is wrong. also, calling iterate_generic from within an iterate_generic call sound like a mistake... in any case, you shouldn't call that suite from any thread other than therad 0... ... View more

the simple answer is that the anchor point goes in the place of the position with negative values. however, you can't do that all in one placement of data in the matrix. you should create a matrix for the anchor point. then multiply it by the rotation matrix, and then multiply the result with the position matrix. ... View more

well, it's not really an issue specific to AE's sdk, but rather a general programming principle. i'll start with the good news: no one will die if you'll use some global vars... especially if that data is constant and doesn't change once it's set.   global varibales are considered a bad practice for a few reasons: 1. it makes your code less readable, because functions rely on data other than the args passed into them. so when reading your code, it won't be apparent how the result is reached via the passed args and you'll need to dive into the function. 2. it's might perform slower, because the cpu cache holds the passed args from one ram segment, and then needs to get the global vars from another ram segment. 3. in read/write scenrios, it means that your code is not multithreadable, or must require mutexes that take a performance tax. 4. it's just generally frowned upon.   having said that, i'll just note that WE ALL DO IT! yes, even the purists sectretly wat to "just store a couple of bytes"... there are a couple of things to consider though: 1. if you're using std::vectors, you're not using AE's ram allocation but rather going straight to the system. it's highly recommended that you let AE decide about ram allocation and it's prioritization, so you won't eat more memory than AE wants to use. it's about the user's overall experience. 2. that global will be used by all instances of your effect. if you're cool with that, then fine. 3. that memory will be deallocated only when AE shuts down, even after global_setdown. so even if you allocated memory using AE's suites, at that time, you won't be able to release that memory using AE.   if you want to play nice, you can allocate some memory and store it in some pointer on your global_data handle. this would be the most "ram friendly" solution, and would give the appearance of a pro programmer that doesn't use global vars (THOGH WE ALL DO IT!!!). ... View more

as far as i know, indeed AME runs some invisible AE instance for the rendering. i tihnk that if you take a look at the windows task manager and you'll see the these processes. if that's the case, you can attach your debugger to an already running process like so: https://learn.microsoft.com/en-us/visualstudio/debugger/attach-to-running-processes-with-the-visual-studio-debugger?view=vs-2022 ... View more