Short and simple.
Currently the SubUV Animation looks at the alpha channel of a texture, please allow for the option to specify which channel the tool looks at.
With all the optimization I/we are doing, I tend to stick 3 different uv-sprites in the RG and B channel.
This is results in not being able to use this tool properly 
And an additional possible addition, perhaps let us control the shape of the sprite sheets it emits.
thank you 
+1! This would be very useful
Good suggestion. I tried to find the other day if it’s possible, so… +1 from me too.
I’ve added the ability to choose R, G or B channels of the source texture as the opacity input, which will make it into 4.13.
What do you mean by this? The SubUV Animation computes bounding geometry for the individual frames of the existing sprite sheet that you give it.
Can I hug you? please let me hug you!
Or at least let another awesome person from epic high-five you 
well, I also tend to use this occasionally for non-subuv animations as it also happens to improve those results occasionally.
Im not sure how the sprite-sheets are generated under the hood, but my expectations are that in theory its just a 2-poly plane.
If that is the case, the option to select or create an alternative plane would be great, especially since it doesn’t affect draw-calls as much as using actual mesh emitters.
Though… it might not be a mesh altogether, in that case… I dont think there is any decent easy-to-go-to thing to create my own.
Right SubUV Animations work fine on sprites with a single texture mapped onto them, you just have to tell the SubUV Animation that there are 1 images horizontally and vertically.
Under the hood a vertex buffer is generated containing positions of bounding vertices for each frame. The positions are 2d, so it only works on a sprite. Making particle cutouts on arbitrary 3d meshes is a much more difficult problem.
Yea, thats what I have been doing since 4.11
Allright, thanks for explaining
Is there any reason why we wouldn’t want to do this for every camera facing card? Seems like the win of overdraw vs. comp time is pure gravy… Are there video cards that have probs with this?
+1 I like!
You should pretty much always use it on CPU sprites, it will just be faster. The only case where it’s not a win is when you are vertex bound, which generally happens with millions of sparks etc.
We’re looking into making the workflow more automatic.
Hey , could you give any info if this was in 4.13, and how to set it up?
(downloading 4.13 as I am writing this )
(cant find it mentioned in the changelog)