Download Video Fire Effect ##VERIFIED##
Candy Belmont
Hi All,I'm looking for a little guidance in building an effect cue(s) for the fire barrel in RENT. I've got an Apollo MultiBeam LED unit patched as a multichannel unit; RGB + Intensity. Works well with the color pickerand such. (That was the first hurdle.)Now, I'd like to create an effect of a fire burning in the barrel.Hopefully looking like it burns with a variable rate and slowly gets dimmer over time. Then I need the fire to flare up on cue when characters throw paper in the fire.I"ve only created a few step effects in this board so far and that seems like there might be a less labor intensive method using this board. Thoughts? Suggestions? Tutorial?
I think you want to look at Absolute efffects. The way to do this with Color is to create Color Pallets of each color in your fire effect and then put the color pallets in the level column of the absolute effects screen. This will work with any channel that has that info recorded in the color pallet. Works great for lots of effects, not just color.
Along with the absolute effect that jpgagnon suggested, you could also apply a linear effect with the intensity to get the LED to flicker like a flame. I recently started using the linear effect for an Easter musical, and I love it. If you create a new effect and select "linear" as the type, then you will get the default linear effect with an intensity vs. time graph with an s-curve. Make sure to set the effect to "Random Group". Apply that effect to the LED and adjust the rate and size to get the desired look. Along with the absolute effect adjusting the color of the flame and the linear effect flickering the LED, you should have an awesome fire look.
As for getting dimmer over time, I would suggest this: start with the LED at, let's say, 60% with the two effects going. The next cue could be the LED dimming down to maybe 20% in a long fade time. The great thing about the linear effect is that it keeps the flicker going relative to what intensity the LED is set at. Now, for the flare up, just make another cue with the LED at Full with a fast fade time. The LED will keep flickering, but it will be brighter.
If someone is going for that old method is... most likely to get a quick render of fire look like image. Not necessarily looking for some physically accurate look using Bifrost. Unfortunately those tools are not even working now.
My uncle supplied me with his university text-book on the language, and I stepped to it.Unfortunately, the book turned out to be extremely thin on the subject of making fire. Also it was mainly concerned with programming the PDP-10 as opposed to the IBM PC that I was using. And so, I never learned the skill.
I've wanted to revisit this for years. Having acquired better programming, English, and web search skills, it's time to fill this gap in my education. This post contains a walk-through of the classic MS-DOS firedemo, a port of it to SDL, and an implementation of the fire effect that runs on bare-metal PCs.
According to the internet, Javier "Jare" Arévalo's firedemo from 1993 was the first implementation of this effect. He wrote a blog post about it for the 20th anniversary, which includes a version in Javascript (source on GitHub).
It began when we bought a 80387 math coprocessor and, to enjoy it, played a lot with a famous fractal generator called Fractint. Then I wanted to make a kind of plasma style fractal, but animated in a more complex way than the color rotation typical of the time. I just started writing some code without thinking much. A few bugs later, I had something that looked like small blue explosions that quickly faded to black. Tweaking the code rather than fixing the bugs got me the fire effect. We did realize how and why it looked like a fire, and JCAB's implementation in Inconexia was fully intentional and correct, but I never sat down to truly understand all the subtle bits in the original (where did the initial white explosion come from? Why was there no apparent "real" random number generator, yet it looked random?) until I recreated it in Javascript. As far as I can tell, the Javascript version is pixel perfect, it shows the exact same animation as the original did.
(I'm not sure whether this is the program I saw that night long ago, or if I saw one of the many other implementations that followed. Kirk A. Baum has collected some of them in firecode.zip, including a version that is indeed written in Pascal called Flames by Mark D. Mackey.)
By doing OUT DX,AX, the code writes the 16-bit value in AX to the port, which is effectively the same as writing the 8-bit value in AL to ec4h (Sequence Controller Index Register) and the 8-bit value in AH to ec5h (Sequence Controller Data Register). The Index Register selects an internal Sequence Controller register, and the Data Register provides the value to write into it.
With Chain 4 disabled, the programmer has to explicitly select which plane(s) to access by setting the VGA Sequence Controller's Map Mask Register (index 02h). The write of 0Fh to that register enables writes to all four planes at once, hence the "All planes" comment. This means that each byte written to the framebuffer will get written to all four planes at that address, effectively appearing as four consecutive identical pixels.
The main loop starts by reading from the 3DAh I/O port, which is the VGA's Input Status #1 Register, and checking the VRetrace bit. It loops first while the bit is zero and then while it's one, effectively waiting for it to go from one to zero, thus synchronizing the loop with the VGA refresh cycle.
Rotating the bits in AX three steps to the right leaves AL containing the previous sum divided by eight, in other words it contains the average of the eight values surrounding SI. This is the core idea in the fire effect: computing the "heat" of each pixel as an average of its neighbours.
After the ROR instructions, the three least significant bits of the sum of neighbours have ended up as the three highest bits of AH. This means that the TEST instruction effectively checks whether the two low bits of the sum were set. If they were not, we fall through to the code below. As the comment suggests, this was probably chosen somewhat randomly.
All this is effectively to decide whether to decrement AL, thereby "cooling" that pixel. If no cooling occurred, the screen would eventually fill with a single colour. Instead, the code cools pixels given the semi-random condition that the two low bits of the neighbour sum are zero (so roughly 25% of the time).
If AL is already zero however, decrementing doesn't "cool" it, but rather "re-ignites" it since the value wraps around to 255. The code only allows this for pixels in the lower four rows, which is how it "feeds the fire" from below. Note that when the program starts, all pixels are initially zero, so the low bits of the sum will be zero, and all pixels on the lower rows will ignite, causing the initial burst of flame.
With all the new pixel values in Imagen2, the program now copies them back to Imagen for next time. By starting the source pointer (SI) 80 bytes into the array, the copy effectively scrolls the contents up one line. The actual copying is done with REP MOVSW which performs 40*48 (CX) word-sized moves from DS:SI to ES:DI, incrementing SI and DI after each one. Only 40 moves are needed per line because they are word-sized, and only 48 lines are copied because the top line is discarded (by starting at offset 80) and the bottom line is all zeros.
By "ashes", the code means pixels with low heat values. Such pixels look a bit unsightly in the bottom lines, so to smooth things over, the code above loops over the pixels in the bottom six lines, looking for pixels with values lower than 15. For such pixels, the code subtracts 22 (AH), and negates the result (effectively computing 22 minus the pixel value), which brightens them up a bit.
After reading through the original firedemo code above, I wanted to re-implement it to run on modern operating systems. In the Othello project, we did some graphical programming by using the native libraries (Xlib, Win32 GDI, Cocoa, etc.), but in this case we're not trying to build a graphical user interface, we just want to paint pixels on the screen. One popular cross-platform library for doing that, often used in games programming, is SDL (Simple Directmedia Layer).
The code below (available in fire.c) is a pixel-perfect port of the firedemo to SDL2. (It mainly follows this guidance from the SDL2 migration guide.) Hopefully it's a little easier to read than the assembly version.
I don't think the firedemo above was actually the program I saw that evening in the nineties. The way I remember it, the flames were just along the bottom of the screen. What I remember resembles much more what's described in Lode Vandevorde's Fire Effect tutorial.
One important difference in how that tutorial creates the fire is that it only averages pixel values from rows below the current one. This means the computation can be performed on a single buffer, in other words, there is no need to have separate buffers for the current and previous frame.
While the fire.com demo above runs under MS-DOS, the program doesn't actually use DOS for anything. In fact, it's not so much a DOS program as an IBM PC-compatible program: it's just 16-bit x86 code, some BIOS calls and fiddling with the VGA.
There are a lot of examples of fire effects out there, but none I found that were both A) realistic enough and B) appropriate for a mobile costume. So after a lot of research, I came up with this method.
Upload the code here: You will need to modify it for your number of lights. You can also change the color scheme to whatever you want for blue fire, green, etc.! I'm not a programmer so I may not have done the best job modifying it from the original, but it works. TEST TEST TEST your code works properly before moving on!
The Fire Effects Information System (FEIS) provides synthesized scientific information about fire effects on individual species and ecosystems in the United States, so natural resource managers can easily find and better apply science to land management decisions.
df19127ead