Friday, 28 February 2014

Go with the flow

Brief start warm-up before we get to the actual topic at hand: I love Valve. Their games are just fantastic, Team Fortress 2 was the first game I ever started to get competitive in, Half-Life is just a fantastically executed series and Left 4 Dead is one of the greatest examples of co-op games out there. They just do so much in terms of visual styles and gameplay, as evidenced by the numerous breakdowns of TF2 (including the one we watched in-class). So I'm going to overlap my interests with my love here and talk about how Valve flows.

So firstly, let's talk about the two types of water that Valve can employ: The expensive and the cheap. Basically this denotes the overall quality of the water effect because you need to trade off quality for performance in some cases. Really, the main difference between the two is that Expensive water utilizes real-time reflection and refraction which can result in some splendid effects
Just look at that beautiful effect
Meanwhile, Cheap water doesn't get these luxuries and instead uses environment mapping to generate a facsimile of a reflection. It still gets the job done and it's much cheaper, but it's not quite as nice.

Next let's talk about the over under...Or rather the above and the underwater. The Source Engine separates the water into two parts that should be rendered differently. You have the above water, which is the surface that you see when you look over it (i.e. in the picture above) and you have under the water which can affect the view of the game. There's really not much else to say about it.

Now let's talk about one of the bigger additions to the engine (Even though it did happen just over 4 years ago), the ability to control the flow of the water...Naturally this is just a purely visual effect as doing proper fluid dynamics on the scale that they would need it would be quite the challenge for most processors. The method for the actual flow is pretty similar to how one does a normal map, but rather than storing the normal of the surface in a texture we store the direction that the water is flowing in. Here's the guide they use for extracting the direction of the flow:

So how do we use this reference to make the water seem to move? Well, they actually use it to figure out how to manipulate the normal map of the water at that point, using it to denote the direction it should be moving in and how it should be skewed to match the direction. The result is quite impressive as seen in the demo: 

And that's about that on the Valve's water. As a final note, I'll put up some images showing how the flow map actually looks on the maps: 

And with that I'll call it a night. I hope you enjoyed this splashing blog and this flood of information...I almost made it to the end without making water puns but I just couldn't resist.

For a reference I used the Valve Developer Wiki, an invaluable resource for anyone working with the Source Engine whether it be coding to level editing. 

Friday, 14 February 2014

Particles 2: The Re-Particling

So I'm going to finally continue on from my previous particle post! Last time I talked about how I had set up my own particle system as well as how we could utilize the effects with a FBO. Today I'm probably just going to ramble on about a few things for improving the systems and other effects before finishing up with a joke. Without further adieu...

So one way of improving the systems is using Point Particles as opposed to the Billboard Particles. As mentioned before, Billboard Particles are just sprites rendered to a plane. Point Particles, in the mean time are a single vertex of a certain size with a sprite rendered on top of it. The advantage of a Point Particle vs a Billboard particle is in their efficiency. For a Billboard particle you can either calculate the position of the particle on the CPU and then translate the vertices during rendering (1 calculation on the CPU) or we can use the velocity, acceleration and current life of the particle you can calculate the new position of each vertex in a vertex shader (6 calculations on the GPU, bit better than the CPU). With Point Particles, we can do the calculations in the CPU like we do with Billboards or we can calculate the new position in the shader, with the difference being that we are only doing 1 calculation making it 6 times faster than the Billboard! This difference can be very noticeable when we have to calculate hundreds of particles. If we have one system with 200 particles, then that's either 200 calculations on the CPU, 1200 on the GPU with Billboards or 200 on the GPU with Points.

Knowing now how to help speed up the calculations, let's talk about something fun we can do. Like pseudo colliding particles! (For the record, this is being taken from a presentation done by Halo Reach's Effect Tech: Chris Tchou at GDC 2011) A method for creating pseudo collision particles is to sample from the depth buffer of the current frame and then check where the particle is in relation to it. If we see that the particle is penetrating then we can move it towards the camera until it is a suitable distance from any obstacles and, using the surface normals (which we should have output to a texture) we can then find the orientation of the face that the particle is hitting which can be combined with the particle's current velocity to figure out how it should bounce. This would involve being able to store the particles current information during each update step but gives us the appearance of particles bouncing off surfaces (e.g. if we were to do sparks flying off of a wire and bouncing off the ground). This is also cheaper to process than colliding the particle with the collision or environment mesh on the CPU which makes it even more interesting!

I could go on and ramble about a few other stuff but I'm not quite feeling up to it right now so I'm going to call it a night here. But before I do, I'm going to leave you with a horrible joke:

I applied Phong Shading to a pretty crappy model of Phong!...Get it? Phong Shading Phong?...
...
...
As in Phong from ReBoot?
...
...
I did say it was a horrible joke.