For this piece, I set out do my best to get a RealFlow fluid mesh into UDK.  The main enemy in Grapple has an ability to shoot a napalm “cannonball,” and my intention was to make it act like a liquid when it hit the ground–to have it splash and deform almost like a water droplet, only fire-y and dangerous.  Immediately after, and most likely during the splash, fire particles would also start emitting from where the cannon hit, but the biggest shape, at least upon impact, would be this fireball exploding like a liquid.

Because the gorgeous looking meshes generated from RealFlow would have several thousands (very often more than 10,000) vertices and would move with very fine detail, I wanted to capture as much of that detail as I could in the most game-efficient way.  I thought it would be neat and very doable (from a scripting standpoint) to just bake joints to every vertex, but that would be by no means a viable option for UDK.  I then wondered if I could still track all of the vertices but instead do it through the object’s shader.  Not only would it be very doable to move that many vertices in the shader, but it would likely be many times faster/more efficient while still giving me an incredible amount of detail to the object’s “animation.”

One of the challenges came in feeding the shader the complicated curves of the vertices’ animation.  I thought about storing each data point (time, x-value, y-value, z-value) for each vertex in something like an .xml file, but feeding that amount of data in to the shader every draw call would put enormous stress on the system, especially with everything else happening on screen (and potentially this shader being applied to more than one on-screen object at once).  What if I could instead create a function that represented the animation curves?  The function would only have to be read once, and I could simply feed the shader in time in order to get the xyz’s different values.  Moreover, after discussing the possibility with professors and fellow students, I decided that I could store these formulas in a texture to be read at run-time by the GPU which would be faster than reading an .xml file by the CPU (which would have to pass the data to the GPU anyway).

The shader is incomplete as of now, but the above video shows and explains the scripts and method behind driving the shader’s “animation.”