These are some screengrabs of some kind of abstract visual art that I'm creating in real time (so, as opposed to some kind of sequencing in where stuff is rendered "offline" later, this is limited to what the computer can eek out while you're manipulating the program in real time).
I'm using Quartz Composer as my prototyping environment.

The main components in pulling this off are an openCL fluid simulation, GLSL normal rendering, and a core image kernel based blur effect. I've gone into some of the particulars of these techniques in past posts. In this, I'm also using some measuring of velocity to trigger particles via the 1024 particle warfare and v002 optical flow. I feel like I'm going to cut those out; I've developed some routines that I think could probably perform faster for me, but, these were there and quick, and I wanted to see if the look was worth refining for more speed first. I do like the look of the particle blooms happening with velocity, so I'll probably go further down that path.

Also, as noted in past posts, thanks to Chris Wright for his taking the time to find a workable solution to rendering normal maps with GLSL in Quartz Composer. Most GLSL normal map equations use tangent calculations that aren't supported in Quartz Composer's implementation. Chris came up with clever and simple a workaround.

In addition, when the 2D fluid simulation, in it's various variations was supplied by Apple, an intrepid Stonewall Ballard went down the rabbit hold of finding out how to actually (perhaps arguably, but I side with him) fix the fluid simulation to output signed float vector images. This in turn, allows a kind of processing on the velocity image which is fundamental in successfully making on the fly normal map, which, in being calculated from velocity, is limited to being somewhat convincing only when stuff is in motion.

Given that this is liquid/particles, that actually makes good sense; if there is no movement, there isn't really a need to create a normal map that looks like there's a wake to the fluid, to create a shaded area.

The technique I'm using for the realtime normal map creation utterly fails when I attempt to use Apple's implementation of OpenCL Fluid Sim. The actual composition, when using Apple's non-signed float vector, starts creating very odd corruptions, or at least failures, of some part of the rendering chain.

This implementation of the liquid sim kernel is different than Stonewall's, as I've added some Macormack advection in some versions, and also just made some tweaks that suited me. So, it's an amalgamation of his fix, augmented with some new functions from OpenCL examples that Apple has posted, with subsequent fixes.