Box2D Forums

The particles don't have rotational inertia, or even store rotation values. I was talking about rotations for the movable rigid bodies (i.e. the box in the demo) which interact with the fluid. The approach I'm trying to get right is the one described in the paper I linked to earlier in the thread, where the particles can apply forces to rotate as well as to translate bodies.

I don't really mind what's done with the code I posted. At some point I'll continue development and won't post all of the code up here (partly because it's likely to go in directions which won't be of much interest to the Box2D community, and partly because I've got a game to write ). However, as well as checking with me, you should wait to see what ewjordan's thoughts are on sharing this further. Parts of the code are still direct ports from his original Java demo, and as I understand it there were parts of the code to handle surface tension which he wasn't entirely sure about from a copyright perspective - I've been meaning to ask about that myself but I've been busy with optimisations and other stuff for a few weeks

Took a look at this today--just from the outside, no internals--and wanted to report my observations. I've only skimmed the other posts, so this stuff might be irrelevant.

1) The objects seem to float upward pretty well and spin, but don't seem to be pushed left or right. Why is this?

2) I noticed an odd bug. If you use any sort of circle shape (can test easily with the bomb) the circle turns into a sort of teleport that sends particles that come in contact with it into the center of the map, in a ring shape, corresponding to where they came in contact with the circle. Here's a screenshot:



3) I ran some performance tests and it seems pretty speedy to me. I ran an optimized release build on VC++ and profiled with both precise and fast floating point operations. What I found is that the test spends more than 50% of its time in the applyLiquidConstraint function, mainly in the pressure and neighbors loops. 13% of the 50% is spent on this line:


(I moved vlen[a] out to see if it was a memory access issue.)

The interesting part is that the bottleneck isn't in the Box2D code. To improve performance further, you'll have to reduce the number of times applyLiquidConstraint is called, the number of iterations per loop, or organize the memory layout better to avoid cache misses.

4) You seem to have forgotten to post FluidDefs.h. Only seems to be missing b2Random. (I spent a good while trying to figure out why I only saw one dot. Apparently rand() / RAND_MAX isn't very random. *headdesk*)

Anyway, this thing is awesome so far. I'll see if I can help in few days maybe.

They should get pushed to the left and the right... The code for the interactions between the fluid and the objects is held together with chewing gum and prayers though, it's been a major source of headaches and I still don't know how to get it to work properly


Oops, yes, I found and fixed that shortly after posting the code. I'll maybe post up the changes when I get a chance (I'm not on the machine which I code on at the moment)


I'd expect applyLiquidConstraint to take up something like 50% of the processing. Box2D is hardly doing any work at all in the test (just some static geometry, one movable body which gets a couple of forces applied to it by the fluid, and a bunch of AABB tests), whereas the fluid code is still going to be quite complex and expensive. I plan on looking into it some more, because I'm sure that there are still some optimisations that can be made, but applyLiquidConstraint is always going to be expensive. It's called exactly once per frame at the moment (I don't think calling it less than once per frame is a good idea), and it's not an iterative function, so the iterations can't be turned down.


oops, FluidDefs.h was something that I've used to have some common stuff shared between a few different versions of the fluid test (nParticles, the grid dimensions, the particle structure itself). For the code I uploaded, I copied all of the contents of FluidDefs.h straight into FluidTest.h, so you just need to remove the #include "FluidDefs.h" (I forgot to). As for you not having b2Random - um, I think maybe you should have that already? it's part of Box2D, as far as I know (unless I've ended up with some wacky version of box2d that someone else has added b2Random to, and it doesn't exist in the main versions...)

It was removed recently from the engine in SVN, now you're apparently supposed to use RandomFloat which is defined in the testbed instead. (A simple search/replace of b2Random -> RandomFloat works fine.)

Does anyone else have fluid particles working?

I've implemented SPH into the engine. Check out demo #3:
http://svn.dsource.org/projects/blaze/downloads/blazeDemos.zip

Unfortunately the pair manager crashes after I add more than 400 particles.... Somehow m_freePair grows crazy out of bounds and crashes in the addPair method. Anyone have an idea of what's happening here? I'm using jBox2D's ported code for the pairManager and broadPhase.

I gave up with having the particles be handled by Box2D (see page 8 of this thread ), and one of the main reasons was because of the amount of pairs generated. You can up the maximum limits, but eventually you just run out of storage space for the numbers of pairs that can be needed in certain cases. Box2D is great for rigid bodies, but for fluids where you need a lot of particles which interact with each other in close proximity all the time, it's easy to push the limits to breaking point. My current focus is to deal with the particles myself, have them not represented from within Box2D at all (i.e. no bodies, no shapes, no problem with pairs). Getting the particles to then interact with the stuff that IS in Box2D is problematic, but for large numbers of particles, I'm pretty sure it's the way forward. I've tried 8 or so variations on the SPH implementation, and having Box2D not deal with it at all seems the best. Maybe eventually the code can be folded back into Box2D as a specific new type of shape, but for now it seems a bit out of the scope of the engine and is best dealt with seperately.

Ah, thanks for the feedback! Based on my own observations and your post, I would have to agree that the Sweep & Prune in Box2D, as implemented, may not be appropriate for large particle scenes.

BTW, it should be feasible to create a separate broad phase collision detection system for particle scenes..... A hash grid, signed distance field, or quad tree may be good candidates.

The spammers are out in force in this thread...

Bill

Banlist just got a few new entries, and I deleted the offending posts, in case anyone's wondering what the2bears is referring to.

Hey, just checking in to see if there's any updates on fluids, since I think it would be really nice if a fairly robust fluid system were to be integrated into the box2d distribution.

All I remember is I saw a Java web app that ewjordan made a while back, and I was very impressed with the speed and stability of it.

I was playing a flash game that used fluid physics earlier this week (it was like a platformer except you had a limited amount of fluid you could puke to help you complete the levels by swimming thru it and whatnot) and it reminded me of how much more awesome that java applet demo was... the flash game would slow to a crawl on my fairly decent machine at just 100 particles.