We’re making a Paper2D-based platformer and I’ve spent the last day or two trying to figure out how to achieve a ghost trail effect as seen here: https://www.youtube.com/watch?v=pXJShS2x60w
My initial thought was that I could do this by creating a particle system and dynamically changing the source texture of the emitter to the texture of the character’s current flipbook sprite with. This ended up being a dead end because there doesn’t appear to be a way to get the texture out of a sprite Blueprint node at runtime. In any case, I quickly realized that what I actually want is the final rendered frame of the character, not the input texture (which in this case would be a sprite sheet).
I then spent some time trying to figure out how I might pipe the output of the character’s flipbook’s material into the particle system. The closest thing I could find that seemed like it might do what I want was a RenderTarget2D. I tried setting this up - I made a new render target, set that as my particle system’s material texture, then added a SceneCapture2D component to my character, set to capture to the render target I created. For whatever reason that doesn’t seem to work either, but I suspect that this approach isn’t ideal from a performance stand-point anyway.
Any thoughts or suggestions about how to approach this?
have not used paper2D much, but is there any reason you are not just spawning more sprites at the players previous positions and offset the flipbook animation accordingly?
Actually this is probably the best way to do it to avoid spawning more sprites but I wouldn’t know what the next best step for you to take is. Like DIVI mentioned, you can just simply make a blueprint that spawns the sprites for ya and manages its opacity, no collision etc and destruction and add enough settings for timing and what not.
Well I was hoping to be able to take advantage of all the cool features of Cascade, since it is a very “particley” sort of effect.
Since posting this I did get it working with a RenderTarget2D and it looks pretty awesome! As I feared, it is definitely making us take a performance hit, but we’re probably fine since it’s a Paper2D game with not a whole lot else going on ATM. If it becomes a real problem I will probably try the alternate approach you suggested to see if we fare any better with it.