Simon Trümpler: Sketch #20 WIP


#1

Preview GIF:
sketch20_08d_followSpline_preview

sketch20_08c_preview

Flip Book Creation Process:
sketch20_05b_preview

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!
#2

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:


#3

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)


#4

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


#5

Very creative approach. Cool!


#6

Awesome work here! Great to see this realtime!


#7

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.


#8

Man that tool is sooooo cool !


#9

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


#10

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!


#11

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:


#12

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:


#13

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?


#14

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).


#15

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


#16

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?


#17

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


#18

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.


#19

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:


#20

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