ofxFlame

extend
#1

So, I’ve been working on an OF addon I call “ofxFlame”, with the purpose being to create a dynamic flame simulation based on fluid physics and other advanced concepts, with the ulterior motive being to never have to use a textured sprite.

The primary problem is that I’m still in high school (woohoo OF for being so easy to learn yet hard to master), and I have only a basic knowledge of calculus and dynamics.

I have been poring over the works of Nguyen and J. Stam, and I have come up with a basic architecture of how I want it to work.

The flames will use a dynamic fluid cell array, something I am also working on involving a threaded manager object (think renderer device), a “fluid patch” (think vertex pool), and a bunch of “fluid cells” (think vertices). The manager hooks into and locks the fluid patch based on a timescale, processes fluid dynamics (straight out of J. Stam’s paper, “Real-Time Fluid Dynamics for Games”), then unlocks, allowing the other threads to access or modify the cells using their member functions.

But in my version (as opposed to Stam’s example), the cells are not exactly preallocated, but are allocated by the fluid patch when they are referenced by member functions of the patch, then dereferenced if their values reduce to 0. This process cares for the application-side fluid shape and state of the flame (and can probably be adapted to similar uses!), but does not account for the rendering.

This brings me to the render process. I’m thinking about a raytracing algorithm (as in V. Pegoraro/S.G. Parker’s paper, “Physically-Based Realistic Fire Rendering”) which accounts for the appearance of the fire due to absorption, emission, and scattering of light particles, as well as the radiative properties of the materials used. This is all fine and good, but I don’t exactly want to take it as far as being accurate in chemical composition. This leads me to my first real problem.

I have next to no clue what most of the equations represent, much less how to incorporate them into code. Plus, I don’t even know how to implement a recursive raytracer.

If anyone could offer some articles, code examples, or explanations, please do so. Because, in the words of Frankenstein’s monster, "FIRE GOOD :stuck_out_tongue: "

#2

cool, I don’t know these papers but maybe the processing smoke simulations will be helpful to get you started:

http://processing.org/discourse/yabb/Ya-…-1045166270

I have done some research on snowdrift simulation and I am going to work with a glacier-simulation-physics guy on it. Would be cool to have ofxFire and ofxSnow :wink:

/stefan

#3

I was going to have you check out memos fluid stuff here…
http://addons.openframeworks.cc/project-…-fxmsafluid
but there are no files up yet. There is some discussion here with some articles and some of memos code.
http://www.openframeworks.cc/forum/view-…-ight=fluid
or you can have a look at my fluid dynamics stuff here…
http://code.google.com/p/ofxding/
it is not finished and not threaded yet.

#4

also, a little bit hidden :slight_smile: but in this post:

http://forum.openframeworks.cc/t/of-at-summerlab/976/0

there’s a version of lasertag with a fluids brush that has jos stam’s fluids algorithm threaded.

#5

also, heres another post from theo from a while ago where he got a ray tracer going in OF

http://www.openframeworks.cc/forum/view-…-ay+tracing

#6

I was going to have you check out memos fluid stuff here…
http://addons.openframeworks.cc/project-…-fxmsafluid
but there are no files up yet.

yea sorry bout that, been meaning to put up but wasn’t 100% happy with the way everything was structured. I’ve put it up now as it stands,

http://addons.openframeworks.cc/project-…-fxmsafluid

no docs but briefly:
The solving is essentially same as before, but organized better. Now there is a solver class, and a separate drawer class. You can do everything via the drawer class (i.e. create a drawer, update and draw it. it will create a solver in the background). Or you can create a solver explicitly, and optionally attach it to a drawer. I separated because theres many different ways of drawing the fluid (dye, velocity, motion etc.), and sometimes (usually) I dont even wanna draw the fluid at all, only draw in debug mode to see the velocities, but use it internally as a forcefield for particles and other things. I’ve also got a class which interfaces the fluid with ofxMSAPhysics. You create an instance of ofxMSAFluidParticleUpdater, pass it an instance of fluid solver, and add it as an updater to your instance of ofxMSAPhysics.

What i’m not too happy about, is currently you need ofxMSAPhysics in order to compile ofxMSAFluid - which is not ideal. I’d rather have it so that if you DO have ofxMSAPhysics then the ofxMSAFluidParticleUpdater class is compiled as well, otherwise ofxMSAFluid compiles without that class, currently I only managed to do that with a “MyAddons.h” with all the “define OF_ADDON_USING…”. But apart from that I think the code works fine…

oh yea, also currently the solver extends ofxMSAThread, which allows you to run the solver in a separate thread or manually in the main thread. I had to create a separate class for this because if a thread wasn’t running, the lock() function never returned true. This is a separate post on here somewhere and has already been resolved, but I haven’t updated the fluid code yet as it involves changing ofxThread source… so I’ll leave that for oF 006. until 006 and the updated ofxMSAFluid, you’ll need ofxMSAThread as well…

#7

Thanks for the updates, I had seen the ofxMSA* stuff you put up before (including the bad ofxMSAFluids DL), and I have found it all very useful.

But I am still a bit confused as to how one would make a raytraced renderer, with the proper diffusion and refraction of light to produce the “curvyness” of light around a heat source.

I have also speculated upon some things involving the aforementioned “fluid patch” class, such as specifying multiple fluid patches and relationship chains between them (i.e. between water and oil, between solids and liquids…) so that the actions of intersection are modifiable.

#8

I think the complication in what you want to achieve does not lie in the coding but the actual physics/maths. The ray tracing for diffusion/refraction effects would be just like any other ray tracer, you have a sprite in your 3D scene with the fluid solver running in it (modded for motion to behave like fire, +heat etc.), shoot rays from the camera and if/when they come in contact with pixels from the fire sprite, bend them depending on the density / heat of the fluid at that point.

Of courses chance of that running real-time are pretty slim. If you want realtime performance your best bet is to fake it. Render your whole scene to an FBO, render a ‘heatmap’ which shows where the heat is, feed the two to a pixel shader which just deforms the rendered image in 2D. Quite a common technique in video games. Also for fire, you might get better/quicker results with a particle system and a healthy dose of perlin noise (you can still use the fbo method mentioned above to deform the whole image in post). Again it won’t be super realistic, but judging by the fact that apps like Maya / Houdini can’t even produce perfectly realistic fire, and can take hours to render, and are written by some of the smartest brains in the field… don’t have very high expectations :stuck_out_tongue:

www.gamasutra.com could be useful for tricks like these…