M2C… that ain’t gonna happen that way.
In other words, once you “create” another sphere, the corresponding pixels become white, this texture is passed to the .fx, the .fx reads the white pixels and update its own texture once, since the input texture ain’t changing the already white pixels.
In order to increase x.a you should be working with white objects with an alpha, for example.
In my attached example, every frame a new sphere is created/overlaps an old one, so you get an update in the texture, leading to more solid white/red out of the .fx.
You do get then the time/number of frames needed to go from black to white into source texture = 1 / sourceAlphaValue since every frame a new sphere with specified alpha color (in my example 0.002) is added. A bit more math goes to get the time in output texture - it will be faster, since every frame adds up the new source white.
But you can easily see how the .fx is almost useless. That said, this is a way, not the way.
Actually that’s an almost nice effect the one in the destination renderer. I’m gonna treat myself, later.
Too good to be true, indeed; the path to the .fx is wrong, you should drag and drop it. No treats, I knew it.
forjulius.zip (3.5 kB)