Simon Trümpler: Sketch #20 WIP


Preview GIF:


Flip Book Creation Process:

Color Variation:

It’s on a plane:

The “secret”:
I’m trying to use an approach which is (I believe) common in 2D animation: Cutting out spherical shapes from the fire-particles.
In my case I use a sceneCapture2D-Actor and render a particle system looking like this into a render texture (the background must be black of course, here it’s gray for the visualisiation):

The black spherical particles serve as cut-away-shapes.

In the material I use a lerp-node to blend between 4 different colors depending on the incoming brightness values:

Obviously it’s not very smart to use such a render-to-texture-overhead for a simple fire and in addition you get no variation into the different flames.
But I thought maybe this is a good opportunity to talk about: Do you think there is a smarter way of doing this? Would maybe Niagara be able to control 2 particle-systems and use one as “cut away”-shape? I don’t imagine that this is possible but maybe some of you has a cool idea. :slight_smile:

Simon Trümpler - VFX Sketchbook
VFX Sketch #20: Winners and Badges!

I’m actualy trying to do something similar, but simulating the particles in the shader rather then in engine and rendering out :smiley:

Hmm, I’m not sure if I should join the sketch with something so similar, let me rethink :smiley:


Cool idea!

Perhaps Worley noise with threshold can be used in some way to move discs around in the shader rather than simulating the discs using particles?

Maybe a fancy noise algorithm is not needed, perhaps a few discs’ UV offsets can be offset with different pan-speeds in shader.
You seem to have two emitter points and the discs travel straight upwards with a little bit of spread, that motion should be doable (with the trade-off of being less random I suppose)


that green is so magnifi-leficent!!!

yes; animating (negative space) and masking

setting a system with the sprite masking in Unity would be my approach
positive system would exist [outside] growing negative_system

but do not know performance trade-offs

my only crit is to set a constant ball,glow,shape to hide the pop-stutter at generation point


Very creative approach. Cool!


Awesome work here! Great to see this realtime!


Thanks guys!

I created a blueprint which captures a flipbook at the beginning of the game. After this, the “real” particle system can be destroyed and only the flipbook can be used. I’ll try adding blending at the beginning/end of the flipbook to avoid jumps and I’m looking forward testing with giving every flame instance a little offset so that they don’t use the same frame at the same time.


Man that tool is sooooo cool !


Wait what? Did you create a Flipbook generator inside the engine? While this sounds awesome, how is that not cheating? :sweat_smile:


The constraint is one sphere texture input. If you’re doing math with it without inputting another texture, it’s perfectly valid. We’re good here!


Can’t follow. Pretty sure that using Rendertarget (or well, using the created Flipbook texture) is equal to reading from another texture. I’m confused :confused:


I think that is a very good question! :slight_smile: One thing upfront: Should it be decided that a dynamically created flipbook is not OK, I’m totally fine with this decision. :slight_smile:

But the question is very interesting nevertheless. Because for the effect itself I only use a circle texture and the flipbook is “just” used for “playing” the effect. Technically this is another texture, yes. On the other hand: Technically (and very over-specifically) speaking the whole rendering process uses other textures as well (like render targets, frame buffers and even particle-speeds are encoded in little textures by Unreal).

Interestingly, I already used a render target in my very first post. A camera is recording a particle system, writes it into a texture and then displays it on a plane in real-time. The difference now is, that (for performance reasons) I buffer a part of it and play it again and again.

To me, the whole noise generation feels a little bit “cheaty” because to me this is feels like a “texture” (even though it’s dynamically created) but on the other side … what is a texture? It’s a 2D representation of data as it is with for example UVs.

Ha ha, very interesting and almost meta-like discussion :smiley: I would argue, that if render targets/flip books are off the table, I already failed with my very first non-flipbook attempt. :smiley: Which would be totally OK by the way, I’m having fun building the systems and if this counts as cheating I could totally understand!

Have a great day everyone! :slight_smile:

p.s. Maybe I should try to make everything dynamic: Right now the particle system, camera etc must be manually placed so that it can be recorded. What if the Blueprint would manage everything? The used would just drag&drop the blueprint and then magically a little flame appears and the user didn’t even notice what’s going around in the background :smiley:


It’s nice workflow that you decided to buffer the animation but I liked the dynamic nature of the earlier implementation better actually :see_no_evil: Using a render target, the fade-in / out can be nicely animated with particle parameters and the animation can also be reactive, example - Wind. Perhaps there are more interesting dynamic forces that could influence the particle animation to justify the render target performance cost?
Unfortunately I don’t know the performance impact this type render texture has, I am curious to know more. Perhaps its not that expensive after all?


Yeah a dynamic system is of course a bit nicer, I agree. Regarding the wind: I’m planning to try around with a tesselated plane and deforming it depending on a wind direction. With that I could let the fire bend a little bit into a certain direction which could be “good enough”.

The main advantage I hope to get out of the flipbook-solution is, that I can start the fire with a random offset so that if you see 3 flames side by side, they don’t look/behave exactly the same (like is it now with the dynamic system where the same capture is put on all flames in the whole level).


ah! didn’t think about the frame offset - yes, buffering is probably the way to go :slight_smile:


I dont understand alot of what you did with the match etc, but it looks amazing Simon :D. Will you use the flame for a nice animation like a projectile? or keep it a single flame for now?


WOW!nice work. this reminds me of the way to make 2D flames in AE.


Legal cheating is kinda the point here in a way.

The challenge is limiting on purpose in such a way that the only conceivable way to acctualy make what you want is to find creative ways to solve your problems.


Very cool you came up with another interesting solution than using noise. A lot to take away here.
Yes, using the noise generators feels a bit cheaty, since it can be used like a common texture and doesn’t need any additional thinking.
I’d say those runtime flipbooks are a very cool invention and absolutely fine for the contest, we’d have to disqualify every noise based entry too if this was a no-go :stuck_out_tongue:


I only use fract, multiplication, addition and 1x sine with 1x cosine (there is a noise node to randomize circles size, but it can be replaced with a simpler hash function)
I think with few layers of this it shold be possible to do something almost identical to what you did with particle

generation of a flipbook is cool but too heavy and too slow

p.s. reuploaded video with better resolution