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.
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)
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.
I think that is a very good question! One thing upfront: Should it be decided that a dynamically created flipbook is not OK, I’m totally fine with this decision.
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 I would argue, that if render targets/flip books are off the table, I already failed with my very first non-flipbook attempt. 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!
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
It’s nice workflow that you decided to buffer the animation but I liked the dynamic nature of the earlier implementation better actually 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).
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?
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
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
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?
