1 - As I understand it, the bulk of the speed hit in these systems is processing the particles interaction with its neighbours (or, in fact, keeping track of who the neighbours are). The example code I've got splits the screen up into square regions and processes those for neighbours, but I gather that Box2D's broadphase stuff is likely to do a better job of this. Unfortunately, I know almost nothing about those parts of the Box2D internals. Where would be a useful place to start with getting Box2D to quickly tell me what all of a particles' neighbours are?
Right, so this is really the main reason to prefer handling things inside of Box2d instead of just applying forces from the outside - I ran another broadphase in parallel with the Box2d one (exactly as you did, simple gridding), which is a waste of time since Box2d is already doing it. What I had considered before was creating a new type of shape that represented the neighbor range for a fluid particle, stored any dynamic SPH per-particle variables, and reported a special type of fluid contact which would be passed along to the SPH solver. If that's the route you want to take, you need to figure out a lot of stuff, for instance SPH "contacts" can't be solved pair by pair like normal contacts (pressures depend on all of a particle's neighbors, and pairwise interactions depend on pressures), so you've got to store away some of the data, figure out the best time to process the group, etc, or maybe decide to use the old values, or something like that. It gets a bit messy, esp. when you realize that you have to also integrate a whole new contact type, which means digging into the internals to figure out exactly what need changing.
2 - Are the particles in your test solid? That is, do they collide with other, non-fluid, rigid bodies, and use the normal Box2D contact solver stuff, or do you have to deal with the interaction between fluids and solid bodies in some specialised way?
In that demo (at http://www.jbox2d.org/liquid/
, btw), I just used tiny circles so that they interact normally with the environment; in a real SPH sim, you want to handle fluid-solid contacts differently, because you get artifacts if you don't. You can see this in that demo as particles seem to act a little oddly near walls and corners, because they are only bouncing off of those whereas they are undergoing fluid interactions with the other fluid particles.
You'll probably have to look up exactly how to model fluid-solid terms; I think it's pretty simple, but I don't remember off the top of my head. If you use a have a circle representing the neighbor boundary, then you can use any contacts between that circle and a solid body to get the normal vector, which should be all you need for the calc.
3 - Following on from 2, and assuming that each of your particles is a b2Body with a b2Shape attached rather than some other non-Box2D representation (is it correct to assume this?),
which stuff do I need to turn OFF for these bodies and shapes - what things are a waste of time for Box2D to even consider processing for the particles?
The broadphase is the main thing that's unnecessary. The rest is what's lacking, mainly the fact that the fluid constraints are solved totally apart from any other physical constraints (they happen completely outside the solving step, even), which may lead to poor quality interactions esp. with warm starting (not sure), and that the custom neighbor handling and broadphase don't allow an easy path to setting up reasonable interactions with solids (the neighbor "circles" have to be actual shapes in the system to use them to check for overlaps with polygons, and in my setup they were not).
As a first go, as you play with the SPH algorithms, you might see if you can get decent behavior using sensors, without worrying about potential inefficiencies in the broadphase or integrating with the solver - if you get the fluid-solid pressure terms right, you may not even need a hard core, though it might be worth doing a simple raycast check to make sure things don't tunnel (or you could use a point shape, though I don't think that's in any version but the Java one).
Also, (messy) code for what I got running is in the JBox2d testbed as LiquidTest.java (http://jbox2d.svn.sourceforge.net/viewv ... iew=markup