I have a single image that I wish to apply 2 composite effects to: composite.multiply and composite.overlay, where each effect has a separate texture image and alpha.
I saw the tutorial for multi pass shaders:
https://coronalabs.com/blog/2013/10/17/tutorial-multi-pass-shaders-in-graphics-2-0/
But I wasn’t sure what should be the syntax when trying to create a composite effect, instead of filter.
Any idea how that could be accomplished?
That’s a great question. I’m currently trying to combine composites with sprite sheets for my shader plugin. I’ll let you know if I discover any helpful syntax structures along the way.
Hi.
Presumably you would need three textures (the two being combined in the first pass, plus whatever is being overlayed with its result in the second pass), in which case there doesn’t seem to be any documented way to supply enough inputs to the multi-pass machinery.
As for sprites, an important point is that the texture rects (whose coordinates are normalized to 0-1 ranges at the shader level) need to be known by the effect, but at the moment only one set of coordinates is exposed to custom shaders. Presumably the built-ins are no different and this in fact mirrors the underlying reality, i.e. only set of coordinates is maintained by Corona itself.
For non-sprite inputs it’s often fine that both objects receive the same texture coordinates, since the geometry is common to both and frequently the images will correspond to that. This is generally not the case with a sprite, where it only wants to draw part of the image but the overlay (or whatever) should be complete. You then have to provide that missing coordinate information, and likewise need an effect capable of using it. (Right now there’s not a lot of support for this, either, e.g. being able to conveniently grab the coordinate info on demand. I have some ideas to that effect, as mentioned in these two related pages: here and here.)
As suggested by the first link in my last paragraph, the answer to both your questions might be to put the results of your “first pass” into an equal-sized canvas (unfortunately still a little awkward in the sprite case, especially if the frames vary in size), feeding the canvas itself to one of the composite fill’s paints.
Composites of composites? I like it! They should be pretty efficient going through open GL and I believe that the canvases will also carry a low overhead for the processor. Even if it gets a little tricky with sprites I know I’m going to use this concept somewhere else. Thanks @StarCrunch!
That’s a great question. I’m currently trying to combine composites with sprite sheets for my shader plugin. I’ll let you know if I discover any helpful syntax structures along the way.
Hi.
Presumably you would need three textures (the two being combined in the first pass, plus whatever is being overlayed with its result in the second pass), in which case there doesn’t seem to be any documented way to supply enough inputs to the multi-pass machinery.
As for sprites, an important point is that the texture rects (whose coordinates are normalized to 0-1 ranges at the shader level) need to be known by the effect, but at the moment only one set of coordinates is exposed to custom shaders. Presumably the built-ins are no different and this in fact mirrors the underlying reality, i.e. only set of coordinates is maintained by Corona itself.
For non-sprite inputs it’s often fine that both objects receive the same texture coordinates, since the geometry is common to both and frequently the images will correspond to that. This is generally not the case with a sprite, where it only wants to draw part of the image but the overlay (or whatever) should be complete. You then have to provide that missing coordinate information, and likewise need an effect capable of using it. (Right now there’s not a lot of support for this, either, e.g. being able to conveniently grab the coordinate info on demand. I have some ideas to that effect, as mentioned in these two related pages: here and here.)
As suggested by the first link in my last paragraph, the answer to both your questions might be to put the results of your “first pass” into an equal-sized canvas (unfortunately still a little awkward in the sprite case, especially if the frames vary in size), feeding the canvas itself to one of the composite fill’s paints.
Composites of composites? I like it! They should be pretty efficient going through open GL and I believe that the canvases will also carry a low overhead for the processor. Even if it gets a little tricky with sprites I know I’m going to use this concept somewhere else. Thanks @StarCrunch!