I just wanted share something with the community in case anyone might have need for such a thing.
About a month ago I fell into some free time and started kicking around ideas for practical water physics that would be fast enough to actually be useful in a game. What I came up with was a rather simplified solution that favors speed over physical accuracy. You can read some of the work that inspired me here and here. I opted to run the simulation on the GPU since, again, the goal was to make it as fast as possible. This is done by treating water as a plane made of individual water columns, and then using simple equations to sum the force of surrounding columns. This approach has a number of disadvantages to traditional particle based simulations, but runs very quick even on my potato powered laptop.
Flow based on water volume
Barriers are baked into a mask texture. The mask texture itself could be drawn into with any arbitrary 2d pattern. The complexity of the pattern has no impact on the speed of the simulation.
I also spent a bit more time adding to the visuals of the water with reflections, refraction, and underwater fog. Using multiple render targets, the physics shader can spit out all kinds of surface data (normals, velocity, etc.) so that another shader pass to calculate it isn't needed. Doing so with my current setup has some drawbacks that I don't mention in the code comments, but I think are pretty easy to work around.
If you grab it from GitHub, there's a built WaterBlock.exe program you can run to try it out yourself.
There is a lot of room to grow with this project before it's fully game ready. For instance, I have no pipeline for getting surface data for use with physics objects yet. My idea would be to use transformation feedback to retrieve transformed vertex positions and avoid texture fetching on the CPU. Networking it I think would also be a bit of a challenge, but I have a few ideas on that as well. All and all I'd encourage you to read through my ugly code and comments. It should be plenty legible in terms of implementation. Integrating it into Torque (or any other engine) would obviously require more work than copying and pasting some snippets though, and I don't currently plan on getting it into Torque in the near future.