Hi,

I've released a houdini version (compiled for windows x64 11.0.658) of my cuda fluid solver with the source code.
It's pretty basic, only sphere emitters and colliders, I made it to learn cuda and the HDK. It's fast though.

Little demo vid : http://www.vimeo.com/21619389 [vimeo.com]
More info and download : http://www.foliativ.net/book/index.php?post/2011/03/04/Cuda-Fluid-Solver-Plugin [foliativ.net]

I hope to improve it in the future but don't hold your breath as I don't have much free time currently.

Vincent

Thanks for sharing this. Combining Cuda and Houdini has always been a temptation for myself as well, but never got around to it. It is great to have such a practical example code to help learn it.
I will definitely have a look at your code and try it out. Could be fun to adapt it for other things in Houdini.

Do you have any idea how much the speed gains are for your solver?

Haven't precisely tested in Houdini, but it was already 5-6 times faster than maya's fluids in similar conditions, which is already a bit faster than houdini fluids. It's using 32bit float right now and could be faster using 16bit floats, but I think it required switching to the cuda driver api instead of runtime api.

It's a bit slower if you copy the data to the houdini volume instead of staying on the gpu with the opengl preview using cuda interop.

Next step is advecting particles directly in cuda
It should be possible to create several houdini cuda sops and only pass pointers to gpu memory between them, not having to go back to main memory which is a big bottleneck.

Vincent

edit : forgot to say I have a 460 GTX and a i7 920, I'd be curious to know the performance with a 580 GTX or an expensive Fermi card

first of all, great job so far!

I'm having some problems running it though. If I directly use your .dll, houdini closes as soon as it opens, opening a console window that I can't read fast enough.

So I poked around in the source code and commented out these lines in SOP_Main.C:

/*
void newRenderHook(GR_RenderTable *table)
{
GR_Fluid *hook = new GR_Fluid;

table->addHook(hook, GR_RENDER_HOOK_VERSION);
}
*/

Now I can open houdini without crashing, load the sop, run the sim, and see the volumes in the viewport. The problem is that it won't preview (using your preview switch), which I'm guessing is what the render hook was for.

any ideas?

P.S. Also, It crashes every time I go over 243 divisions. It runs stable so far anything below that. I'm running win 7 64 bit, and fermi quadro 4000

Update: it is an out of memory error in fluid3D.cu, line 1275… guess that's the limit of 2 gb ram on the card?

Thanks josh Yes as you can see, it's not production ready, not meant to either

You figured it right, the render hook is for the open GL preview.
Hum, in my experience the cuda/open GL interop is a bit touchy and I had crashes when I set up the open gl pixel buffer object and allocate the cuda memory in different orders, but this version works on my machine, maybe some driver issue ?

And yes, the video card ram limit gets hit quite fast unless you have a top of the line quadro with lots of ram. Another good reason to switch to 16 bit floats for the calculations…
There's a printf with the gpu mem info somewhere in the code, which is commented out.

I guess more error checking is in order for the next version!

Vincent

Really cool work! Genius! Works well for me! I want to do stuff like that!

Ouu, finally some competition. Do you prepare liquid version, or do you have plan only for smoke???

@ Macha : Thanks! I'm a fan of all your houdini tests!

@ Milan : I saw your vimeo vids, cool stuff
Nope I'll stick to smoke right now, juste want to make the solver a bit more useful and useable.
I was really interested into this stuff and I'm definitely jealous of the big studios fast tools, but coding takes a lot of time and I want to start again some more artistic personal projects soon!

Vincent

cybermax
Ouu, finally some competition. Do you prepare liquid version, or do you have plan only for smoke???

You know what, most (big) studios don't use accelerated fluid solutions. A lot get's done with maya or houdini and by people knowing what they are doing. Some have their own proprietary solution that is flexible but not accelerated. The issue I have with GPU solvers is that they are more of a gimmick then practical solution. And they are hard to embed in a custom pipeline where multiple facets interact and exchange data. Don't get me wrong, I love the Cuda Plugin. Had a quick look at the code and it's well made and does what is expected. And with the proper amount of time and effort could be VERY useful. But don't think most comprehensive smoke and fire effects you see are using GPU acceleration. Next to that memory is a big issue and GPU clusters are fairly expensive and hard to code for

Hehe I did it to understand the limitations and why everybody wasn't using it since the cool nvidias demos some years ago.

Now I know it isn't the ultimate for all situations, but I still think it can be quite useful.

For example I expect the speed will take a hit when/if I implement collisions with deformable objects, if the geometry has to be fetched from main memory to gpu memory each frame, but you don't always need super precise collisions, so fast collisions with proxies can do the trick.

Speaking about big studios I was mainly thinking of ILM, looks like the fire shots on Airbender were all made with their gpus tools. I also read an article about rigid bodies dones on the gpus for transformers, where they had less options but massive amount objects.

Kinda like houdini rigid bodies, slow, but precise and great at stacking, versus physx or bullet rigid bodies, fast but imprecise…

Vincent

Hi Vincent,

ILM did a great job with their fire simulation on the GPU and I guess they have a specific cluster for accelerated simming. Love their work and I guess it really depends on the scenario what system to use. Correct collisions would be a bottleneck, same as implementing quick dirty forces derived from objects. It's a flexibility vs speed issue. But in most cases you can get away with proxies. The more options the better

But keep up the good work. Like I said, love the implementation. More comments in the code would be nice though :wink:

cklosters
You know what, most (big) studios don't use accelerated fluid solutions. A lot get's done with maya or houdini and by people knowing what they are doing.

Maybe today They dont use GPU, but according emails what I get, They have a great interest. So I think that for two years GPU will be use even in small studios.

cklosters
Next to that memory is a big issue and GPU clusters are fairly expensive and hard to code for

GPU clusters(I call clouds) is not hard to program, but offcourse, uploading and downloading data from/to GPU is time expensive, so Clouds will not be fast like a “all in one GPU” solution. :?

Hi,

I added a basic hardware particles system, also in Cuda, which can be advected by the cuda fluid. You can check it here http://www.vimeo.com/22916953 [vimeo.com]

Vincent

I had a go at compiling the thing for linux, see the odforce thread (I never know where to post!) : http://forums.odforce.net/index.php?/topic/13436-cuda-fluid-and-particles-plugin [forums.odforce.net]

vinz
forgot to say I have a 460 GTX and a i7 920, I'd be curious to know the performance with a 580 GTX or an expensive Fermi card

Hello!
Kepler does not support?
Thanks