•      Sign In
• Create Account

# jouley

Member Since 05 Apr 2006
Offline Last Active Oct 29 2012 07:58 PM

### #4981512Running your OpenGL program on an Nvidia-Optimus enabled laptop

Posted by on 18 September 2012 - 08:26 PM

Usually, the drivers can tell what's a game or application that is supposed to use the discrete GPU based on the profiles/filenames available at the time the driver was delivered. The drivers weren't released with details of applications you develop, though, so you'll probably need to add your executable to the whitelist. There's a video that walks through the process here.

Note: I haven't tried this process for an app under development, so I'm not sure what happens when the file is being constantly deleted/recreated, but it could handle it well!

### #4965829Eulerian smoke/fluid simulation

Posted by on 03 August 2012 - 06:52 AM

jefferytitan, on 02 August 2012 - 09:22 PM, said:
I heard reference to applying something backwards. Something about applying it forward makes the system gain energy and blow up. Is that what you mean about advecting backwards?
Yes. Advect all quantities by looking back in time. It makes the simulation more stable. It's discussed in the articles.

There are a couple things that you could have heard. When integrating to solve an ODE, "backwards Euler's" method is common as being the first step towards a more stable system than just using the regular Euler's method -- simple harmonic systems can blow up when using forwards Euler, but backwards is stable. This is loosely related to backwards advection, but not quite the same. Let me add a bit to what Geometrian said:

You're simulating on a grid of values. These values are moving around as time goes on. Imagine a "smoke particle" at position (x,y). At the next time step, it might be moved to position (x+1,y+1). However, it might also wind up at position (x+.9, y+.8). If that's the case, you'll have to spread the particle out to cover neighboring cells since it isn't right on the center of one. Bad news, your particle has just expanded!

Backwards advection works like this. Instead of watching where a quantity at position (x, y) goes, you look to see what winds up every position. So, you look backwards in time from position (x+1,y+1) and see that it mostly comes from, say, (x,y). However, you'll probably wind up interpolating the values from several cells, depending on where the backwards advection points (like forwards advection, it's not likely to point right at the center of a grid cell). Then, you have the value at exactly (x+1,y+1), rather than values spread out all over the place.

Like Geometrian said, this is all explained in the articles, but hopefully I've shown you that it's nothing to be scared of - keep diving in!

### #4965825Eulerian smoke/fluid simulation

Posted by on 03 August 2012 - 06:37 AM

Okay, that more or less makes sense to me. The GPU Gems article made sense to me until they brought in the mystery vector calculus operator which means 3 different things. The code snippets seem more practical, although I haven't reviewed the snippets to see what's missing (if anything).

I assume you're talking about the del operator? It only has one meaning, though it has (more than!) three important applications, depending on the operation used. There's a quick vector calc refresher on a site associated with that last link I sent, slides linked to at the top: http://www.cs.unc.edu/~jpool/COMP768/presentation/presentation.html . These slides may also give you a different perspective on things; I'd go through them all, though the calc stuff is near the beginning.

Given that the approach is intended to be calculated massively in parallel, would it be practical to perform half of the work on CPU and half on GPU, for example calculating alternating cells? The reason that I ask is I would like it to somewhat work even if their graphics card has limitations that preclude it being used for the simulation, e.g. harsh instruction limits. Also do you have any idea how one would get simulation results from the GPU back to the CPU, as fire/smoke should affect gameplay as well as graphics.

If the GPU has limitations that keep it from being used, then it won't do much good on just half the simulation! That is, you'll need an independent CPU solution in that case. However, any recent graphics card should be able to handle it; the capabilities you need aren't all that intense. That first GPU Gems article is 8 years old, after all! The performance of a CPU solution won't be nearly the as good, but once you have the GPU solution up and running, adding a fallback path shouldn't be that hard. Are you planning on a 2D or 3D simulation?

To get the results back to the CPU, you just need to read the contents of the framebuffer holding the results you want. In OpenGL, glReadPixels is a fine place to start. I don't know the DirectX equivalent, sorry! Things may be very different in that land.

### #4965667Eulerian smoke/fluid simulation

Posted by on 02 August 2012 - 04:59 PM

I can't point you to handy ready-to-compile code, but there was a discussion about this back in February: http://www.gamedev.n...uid-simulation/

The links I point to a bit down the conversation have some code snippets that are easy to understand, and also a walkthrough of the theory of fluid simulation that is the clearest I've seen.

Since then, I've found this, which may be of use: http://www.cs.unc.ed...ject/final.html

Edit: Also, if you'll post the papers you've found which are too math-heavy, we'll know what to avoid suggesting ;)

### #4914668Fluid Simulation

Posted by on 19 February 2012 - 06:04 PM

If you don't understand how fluids work in general, trying to make sense of source code is going to be a nightmare. To that end, I'd suggest a little light reading that I found useful when I was starting down the fluid-sim path:
http://www.cs.ubc.ca/~rbridson/fluidsimulation/ - These are a nice introduction to fluids and how to simulate them. Very clearly written and easy to read!
http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/GDC03.pdf - Jos Stam's paper on video game smoke. Lots of code in the paper, but you'll have to move it over to some execution environment before it'll run.
http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/smoke.pdf - Jos Stam, Ronald Fedkiw, and Henrik Wann Jensen's classic paper.

After reading these three a time or few, you should be able to teach somebody waiting in the checkout line with you more than they ever wanted to know about fluids. At that point, you should be much more able to look at the code and make sense of it.

If you've got a handle on all that already, then I apologize! However, I still suggest that you read these: they do a very good job of putting code with theory.

Once you've done that, you can get into fancier techniques. That's where the fun is, so stick with it!

- jouley

PARTNERS