Thursday, April 10, 2014

Progression

During the development of The Last of Us I began to ask myself where I saw myself in the future. Did I have that hover board I so dearly wanted? Probably not. More specifically where did I see myself in my career. I love visual effects. Always have and always will. The problems I've had the opportunity to solve through visual effects have always proven equally complicated and exciting. I'm always trying to challenge myself. If I get too comfortable doing something then I need to push myself. If I'm scared then I know I'm on the right track. It's in the spirit of challenge that I began pursuing a shift in career direction. One that also felt like a natural progression. This is how I ended up here. Where is here? I'm being too cryptic. Plainly, here is the discipline of game design. I've always been fascinated with game design and the intricacies within. The problems to solve are vast and meticulous and require many many loops of iteration. On top of this it calls upon your collective experience in life and academics. The great thing is that each of us have unique experience to call from giving us our own special ways to pose problems and solve them. Game design is one of the most challenging and unique disciplines I've encountered and I'm very fortunate to work with some of the best game designers in the industry. This is something I have put a lot of effort and though into. After shipping The Last of Us I knew I wanted to make the shift if the opportunity were presented to me. This brings us to now. As of this post I am now working primarily in game design. I'm always a little unsure of myself but it's always been a motivational factor to prove to myself that I can do it. I look forward to creating interesting and exciting experiences for players and benefiting from the immense talent that resides in our design department. I wouldn't be where I am if it weren't for the people I look to for inspiration and support. It's because of these people that I've come this far. I'm also super freaking lucky to work in a studio that has provided me with the opportunity for such growth. My blog will naturally reflect my current work and interests and while visual effects is not my primary focus now it will always be one of my biggest interests.

I also want to mention that my wife has always been my biggest supporter and without her I'd be lost.

Monday, November 4, 2013

Molotovs in The Last Of Us

Molotovs In The Last Of Us: Part I
One of the more interesting effects I worked on in this project were the Molotovs. In action it's just some fire effects and who hasn't see that before. What I find particularly interesting is what it took to bring it all together. There are many components to the Molotovs and while working on them I learned a ton about our scripting engine and how powerful it can be. But the point of this post isn't to talk up our scripting engine, rather to walk you through how we put it together in hopes of broadening your perception on what it takes to put something like this in the game.

Rootvars and Particler:
So, jumping right into it. Particler is our in house particle authoring tool. During production our dedicated fx programmer Marshall Robin added some new, really cool functionality to how we interact with our particles at runtime. Using a system referred to as rootvars, we were able to create variables in our expressions during the authoring stage that we could set the value for at runtime and update as well.

the rootvar __root.alpha here is being used as a float to modulate the opacity value of the particles

Using these I was able to make a single effect and manipulate attributes of the effect based on conditions I set in script. An example is demonstrated in the video below. The player can obtain upgrades by reading manuals that will increase the effectiveness of Molotovs the player creates. For instance the damage radius is increased with each upgrade. Rather than create an entirely new effect based on the upgrade, I've passed the upgrade level as an int and, based on that number, at creation I set conditions so I can set values in my single effect to represent the upgrade like sprite size and emitter radius among other visual aspects.


The concept for the Molotov and its need for flexibility:
The easy way for the Molotov to work would have been the old method. In a specific file, we can define what effects to spawn specific to certain weapon types and explosions. This is an oversimplification of how that all works. For example, in this specific file there would be some definition for the general gameplay behavior of the Molotov and in this location there would be a space where we can define what single particle effect we would like to play when the Molotov explosion is triggered in gameplay. Molotov goes boom, spawn some effect. The simple way to create the Molotov would have been to simply say spawn my Molotov effect when this explosion happens. The Molotov however needed to be flexible. For instance after watching a lot of reference I noticed that the way it spawns differs greatly depending on the angle of the surface it explodes on. So we had four possible explosions that could be defined. One for the floor, one for walls, one for ceilings, and one for impacting characters directly.


Floor Impact Molotov
Ceiling Impact Molotov
Direct Hit on Enemy Impact Molotov
The fiery bits spit out by a Molotov would need to react based on the angle of the surface it impacted and take into account other information and conditions. On top of this the player would be able to upgrade the Molotov damage radius so the effects would have to reflect these upgrades. This all would have meant we would need to author a new effect for every upgrade possible for all four effects if we stuck with the traditional method. So I went with a more technical setup but far more flexible.

State Scripts:
State scripts are built using our internal scripting language. The syntax is based on lisp. You can think of it like Unreal Script and LUA. A state script is very flexible and can be used for a number of tasks, ranging from controlling how objects behave when attacked to setting up logic for combat. I had used state scripts loosely on Uncharted 3 and had continued to become familiar with them as I saw a lot of potential for setting up effects using them. We also have a large number of user and programmer created functions that support them. When spawning an effect in particler we can send collision events that carry information that can be used by state scripts. So I'll detail the information I used to interpret the behavior for Molotovs.

State Script Example

Collision events and the state scripts for Molotovs:
So the most flexible way I could think to setup the Molotovs was to instead have a state script spawned in place of a particle effect and that state script would spawn the particle effect and control all the aspects of its behavior. So this is how It all went down.
  • Lead Programmer Travis Mcintosh setup the lower level code to spawn the state script and pass the script a world space position and a quat that I could use when spawning the effects. He also sent an event to the script so that I could have all the variables setup before spawning the effects. This created a one frame delay but you don't really notice it.
  • I created an effect for each of the 4 types of Molotov bursts that contained fiery particles that fly out and collide with surfaces. Each time a particle collides with some geo it sends out a collision event.
  • The script listens for these events and using the information contained within the event sets up some conditions to further control how the Molotov behaves. 
  • All 4 effects spawn the same effects when they collide with geo but each script determines how those parts behave differently.
  • There are 3 parts that result from the collision of the Molotovs components. The small fire bits. The large fire bits. And the smoke, light, and scorch all in one effect.
  • Using functions inside our scripting language I was able to check for the level upgrade set on the player at the time the Molotov script spawns.
  • I set rootvars for scale and rate along with the speed at which components flew away from the center of the Molotov.
  • Additionally I check the y component of the normal that the collision takes place at. If the value is greater than 0.8 I don't spawn the normal fire bit and instead spawn another effect to creates some simple spreading. This spreading is purely a visual thing and does not contribute to gameplay but it was a nice touch.
  • I also check the surface type of the collision. If it's water I don't spawn the fire. If it's deep snow I spawn a different scorch mark entirely. So it would look like the snow was melting.

Here is a quick run through of the Molotov being used in gameplay. I have character invincibility on and I also have some infinite ammo set so I can just demonstrate how all of this looks in execution.

Gameplay Demonstration: Molotov

Conclusion:
The Molotov was a huge learning experience for me and allowed to explore all of my options for implementation. In retrospect there are some things I wish I could have done early on knowing what I know now. As with all things, I learned a lot about our scripting engine and continue to use it to implement some crazy effects. There is no greater feeling than setting up a bunch of conditions and then watching it all work and happen right in front of you. Seeing people lob these bad boys at each other and just imagining all the crazy crap going on under the hood, it's great. In part 2, I'll go over how I used some of the same techniques to control how fire spreads in infected as they walk through fire elements of the Molotov.

Friday, August 16, 2013

VFX of The Last of Us: Lakeside

SPOILERS 
This post will reveal game footage and details that will spoil the game if you haven't played it.

Winter
The winter section of the game we referred to as "Lakeside". The level posed some familiar challenges for snow based effects and some new ones. This snow had to feel hold and packed with fresh snow coming in and we also needed to reflect some changing weather patters as the level progressed. We wanted to reflect some old snow with the sun peeking through the clouds and hitting the surface. Giving off some warmth. Moving into an on coming storm and in the end a full fledged blizzard with low visibility. I spent a great deal of time on just the footprints which I detailed in a previous post so I won't elaborate on that here. Check out the video below to see some of the effects in action


Warm Calm
In the beginning of the level I wanted to convey a lot of random wind patterns as the wind moves throughout the trees and wooded area. I created some random gusts of loose snow clouds that get kicked up and flurries that blow out from small bushes. This helped to create a sense of movement while not being too heavy handed. I also created some loose snow effect that fall from branches as you move through the forest. One of the biggest issues for this area was due to the fact that once you shot the deer it would leave blood trails so you could track it. Each blood drop was ticking away at our particle memory in a significant way and at times players could use up all of the memory and the blood would stop spawning. There was no fancy trick for fixing this issue I simply had to scale back the number of effects being spawned and make the blood less frequent and larger. You might be asking yourself "Why is that deer bleeding so much?", well that's why.


Storm Chasing
For the white out blizzard I had some fun with implementation here. The biggest issue was that we needed reduced visibility and using particle for this is always a bad idea because of overdraw issues. Rather than placing a bazillion emitters and only placed a few in key places and instead attached an emitter to the player camera with the emitter oriented in world space. The emitter will update it's position with the camera but will not rotate with it. I setup a state script (ref to our internal scripting engine) that would control the whole camera parented effect. The reason for ding this was because you obviously don't want the emitter on while you are indoors. So I setup regions for the interiors and when the player walks into them I send events to the script and the script lerps values on the effect up and down respectively. this utilized some new tech we got from our dedicated effect programmer Marshall Robin. He exposed to us root data on our particle systems and in script we can set those values as long as we retain a handle to the effect in our script. Pretty cool. The issue was still that some of the larger gusts of cloud particles would still draw indoors. The solution for this wasn't perfect but worked well enough. For the shader I utilized a buffer we use for occluding rain so that rain doesn't draw indoors and under hanging objects that write to that buffer. I modulated the world space position of each pixel by this buffer which is also in world space and this prevented those pixel from drawing inside. It created a harsh edge so I had to do 4 taps to make a super super super cheap blur. Calling it a bur is almost offensive to blurring pixels because my samples are so low but the shader was getting too expensive so I tried to offset this restriction by adding some distortion to the edge as well. Again, it's not perfect but works well enough.

The Roof Is On Fire
This was another area where I employed some heavy scripting for the effects. Once David comes in and knocks over the candles this resulted in a small fire spreading. In script I set this up in stages that way the fire wouldn't progress to the next stage until the player had stabbed David once and so on. I juggled the particle effects, spawning sounds, lights, material blending, and animated curtains as they burned as well. On top of this I also kept track of where the player stabbed David. On easy you can throw a brick at David and while he is stunned stab in from the front. I spawned blood effects on his clothes based on where he was stabbed so if for some reason you turned off the PS3 while in the middle of the fight and picked it up in the second stage he would still have blood where you last stabbed him. I don't think anyone will notice that. All sorts of fun keeping track of these variables and every time you think you have accounted for all of them you've undone something else. Honestly thought I really enjoy this aspect of things. I'm not sure why but it just feels that much more gratifying when you solve it but equally as stressful when you're getting close to ship and people are still finding bugs in your code.






Conclusion
So this level was a roller coaster down to the wire. This camera parented emitter thing, while saving me time in propagation, cost some some nights while I scripted its behavior. This level also taught me to let go. To not attach myself to certain aspects of what I'm trying to achieve at the cost of shipping something half finished or buggy. I also learned not to try to script one thing that could control a lot of things. Smaller script for specific goals is easier to manage and easier for others to parse when you need help.

Tuesday, July 30, 2013

VFX of The Last of Us: Bills Town

Subtlety
This is a difficult thing to convey when working with visual effects. You want to create some movement and visible interest but it also needs to feel appropriate given the context of the environment. In The Last of Us this was particularly difficult because the weather wasn't always in some extreme state. For the most part things needed to feel calm and peaceful while being juxtaposed with horrific realities happening around you. I think it's because of this setting and tone that fools you into thinking you're safe but you know better. This brings me to Lincoln or as we referred to it, Bills Town.
Life Goes On
In Bill's Town there's only Bill, and of course the infected wandering around. No electricity, no human life. This was a constant theme throughout the game and it required us to explore other ways to create movement and life. We did this though things that weren't as obvious as animals and things of that nature. We used small swarms of flies and gnats that you end up walking through, grasshoppers that jump back and forth and loose pieces of paper trash that fly around in the wind to name a few. I personally had to really think about how to create the movement without it being intrusive or out of place. I borrowed a technique from one of our lead effects artist Eben Cook where I would take a still from the level with no effects in it yet and do some paint overs to try to imagine what effects would look good in areas. This helped a ton to see what worked and what didn't. I wanted to describe this because I think it's important to explain that visual effects in a game are not something that just get plopped down without any forethought. There are some effects that you have on hand and you know they will work well in many areas but before we lay them down we put a deal of thought into how it all fits together. This game was a great practice in restraint as well. An effects artist we could put any number of things into a scene to convey movement and so forth but you also need to be able to look at something and say "It only needs this one thing." and be alright with that. Just because we can doesn't mean we should.

Wind Effects
We have a wind system in the game that controls how things like trees and other geo behave to simulate the appearance of wind. In previous games we have created effects that best match what this looks like to us, but we were always just eyeballing it. We had to orient our emitters in the direction of what we perceived the wind to be and while this was fine it could be a little slow at times and they didn't always remain consistent. In this game we decided to ask for the ability to fetch the wind direction and strength from our global wind system so that we could use those values to control some of the behavior in our effects. I created a simple script that grabbed the wind direction and intensity and passed it to one of our global wind fields we exported from Maya. This allowed us to put things like leaves falling from trees and any other particles we wanted to have flowing in the wind wherever we wanted without having to worry about emitter orientation. So in Bills town I created a number of effects to take advantage of this, like grass and dusty dirt that gets kicked up randomly.

I created the video below to demonstrate some of these concepts at play. Ranging from subtle wind effects to in you face decapitation effects for the infected. There are spoilers so be warned if you haven't played the game yet.

Tuesday, July 9, 2013

Deep Snow Prints

Spoiler Warning!!!!!!!!!!!!!!!!!!
Be aware that the video below shows some footage that would be a spoiler for someone who hasn't played the game yet. I apologize for that.

Splash!
Long ago in the before time we didn't have a way to artistically control the footprints characters could leave on surfaces. The footprints in Uncharted 2 were smaller in scope and artists were limited in what they could do with them. Since then we have had some considerable support in a system that allows us to spawn effects based on collision data from objects in the game. Using joints in the game we can cast rays from joints that probe surfaces and use that information to test some conditions to spawn effects once those conditions are satisfied. We call this system the Splasher System. Originally it was just for creating splash effects for characters in water but it's a lot more intricate now. The splashers are something I'd like to go into more detail on at a later point if I'm allowed to. It's a great system but on the PS3 it became quite expensive and we had to scale back how many characters and objects used this system.

Projected Particles
One of the greatest things we have is the ability to project materials onto objects using our particle systems to generate the projections. This sounds like a decal system and in it's most basic description, it is. Our Dedicated effects programmer Marshall Robin, during uncharted 3 developed for us the ability to spawn projected particle cubes that utilize a number of parameters to project materials that we author onto surfaces. For example we can use this system to write directly to our destination normal buffer. This buffer takes the normal value of every pixel in screen space and writes to this buffer. Out projected particles directly perturb this buffer. Our lead effects artist Keith Guerrette, used this technique when creating the sand footprints in Uncharted 3. They can animate and do all sorts of great stuff. We can also draw these projected particles to the same buffers we draw all of our other particles to. So we can draw projected color based materials onto surfaces which is very much like the decals you are used to seeing. There is a lot of overdraw cost in these projected cubes so we don't like to use them all over the place just where it will have the greatest impact visually and where surfaces tend to have a lot of deformation. In the video I put together you'll see the outline of some cubes and those are the projected particles.

The Materials
We are lucky enough to have our own node based shader authoring tool. If you've ever used UDK's material editor it's a lot like that. Knowing we can only project a flag image onto the surface I used a technique that in UDK is referred to as bump offsetting. The idea is that you can use the camera direction to bias your original uv values modulated by some constants to create the illusion of parallax. The camera direction vector is a unit vector that ranges from -1 to 1. This is ideal because uv coordinates are commonly in tangent space which typically range from -1 to 1 as well. Of course you can push the values to whatever ranges you want but you would soon find the problem with that. The camera direction is a vec3 and I really only need 2 of the components from the camera direction. The x component and the y component. So I separate all three and recombine x and y back into another vector that is only x and y.


Using these vectors I multiplied them by a texture of a deep simple impression I made in Maya. The texture is the equivalent of a displacement map. By multiplying the camera direction vectors by the texture I create a more complicated and interesting shape of parallax per pixel. Now, what to use these crazy uv's on? I used the displacement map texture to create the illusion of shadowing inside the pit of the print. One of the unique things about our shader authoring tool is that we can define how our alpha is applied. This is similar to Photoshop layer stylings. You know things like multiplicative and additive and so on. The difference being that our options don't have those kinds of presets so we need to know how that alpha blending works. The simple version of what we have to work with is the source pixel (the pixel we are trying to draw) and the destination pixel (the pixel that is already there). Then we define some arithmetic on each of those alpha blending attributes and then by default the result of those two get added together. The majority of our materials multiply the source pixel by 1 so the alpha we are trying to draw just remains as is and then we multiply the destination pixel by one minus the source alpha. So the inverse of our alpha we are drawing. I didn't want to try to create any color of the footprints beyond what was already being drawn there. So the only color in my material is the shadow for the deeper parts of the print to make it look darker. For the alpha blending I set my source alpha to be multiplied by the destination pixels color. So now my alpha has within it the color value of the pixel that is already there. Then my destination alpha is multiplied by 1 minus the source alpha. Since my source alpha has within it the color of the destination pixel I don't want twice the color value when the two values are added together. That's a little complicated I know but totally worth it.


In Conclusion
There are some other things I did to create the prints but the bulk is being done in that one material with the fake parallax. The video will quickly demonstrate how the material is being modulated by a float to control how deep the parallax goes. These prints were important because we couldn't create any dynamic displacement of the geo and the player needed to have something to clearly track the deer. I'm proud of how these prints turned out. We tried to create prints like this for Ellie and I spent a good deal of time on them but it was difficult to make it look like she was leaving long trails and tracks in the snow. So I opted for the prints that write to the destination normal buffer to make it look like long streaks in the snow. Anyway, enjoy the video.

Saturday, June 29, 2013

Cockroaches in The Last of Us

Spoiler Free I promise
(Unless you count the roaches as a spoiler)

 


These little guys might go unnoticed in the game but I am particularly proud of them. This was a tag team effort between Eben Cook and I. With a shout out to Nick Lance and Kurt Margenau a couple of awesome designers I work with. Sometimes our effects team might conceptualize an idea but we don't always have the means to create what we want as it requires support from programmers and it's hard to justify pulling a programmer on to something that most likely is not worth their time. I had been exploring our scripting engine in more depth since the end of Uncharted 3 where I had begun using it quite extensively. It's a very flexible scripting engine similar to Unreal Script and LUA based on LISP. I like it. Let me just put that out there. I love things like this because it allows me to think in ways I may not have before. I always like when there is this complex problem to solve and when I come up with a solution I like to admire it's intricacy. Our dedicated effects programmer Marshall Robin, shortly after Uncharted 3, had given us the ability to declare variables in the root data of our particle systems. These variables could be used in our expression when authoring our effects and we could set the values of these variables at runtime. What all this means is we could change the way our particles behaved on the fly. Muahaha. So with all of this in mind Eben and I thought "You know we could totally make some cockroaches that scurry away in some fashion." So Eben setup the cockroaches. They are aligned with their velocity and while they are not being affected by anything they are just randomly moving about based on some expressions Eben setup in the effect. This is where the root data variables (Rootvars as we refer to them) come into play. We basically have this boolean value in the expression that while set to 0 will have them acting normally just moving about and then when it gets flipped to 1 it triggers a condition in the expression to make them scurry in a direction along the z axis of the particle spawner. We simply add some spawners using our level propagation tool and face their z axes in the direction we want them to scurry in.

The next stage is where I had some fun. So I have all the pieces of the puzzle in front of me. I have a set of functions our designers use for other gameplay purposes but I know they will be what I need to get these roaches working. Additionally I didn't want the script I made to be something we could only use once. I wanted it to be something that any other effects artist could just throw into a level and it would do all the work. To do this I needed to be able to let the artist specify the name of the spawners in the level to perform operations on and I had to allow for any number of spawners. I did set a limit of 100 spawners in the script but if we ever had that many in a level it would be insane. I think the most we ever got up to was 8 or 10. The script spawner allows for a user to specify data directly on the spawner in our propagation tool. So the artist just enters the names of all the spawners for the roaches on the script spawner. For the artist that's it. That's all they have to do. The script itself contains two sections. The first creates a symbol array that we refer to as a group. So the script checks the data on the spawner I mentioned and if that data is specified it adds that roach spawner symbol name to the group. The function that does most of the work here is basically a while loop with a counter. The next section is where the real work is being done. Now that I have a group of symbols I use some functions to create some conditions for the script to check on those symbols every frame. I check the distance between the player and the roach spawner. I check to see if the roach spawner is within a specified radius from the center of the screen. and I check to see if the flashlight state is on. If all three conditions are satisfied it sets the boolean switch (Rootvar) on the roach spawner that has met all of the conditions to 1 and the roaches go scurrying away. The first time I saw it working I pooped a little.

So that's how all that works. It might sound expensive but it was all actually relatively cheap to run because it wasn't all that complex on the runtime side. Of course the more spawners we iterate over the more expensive it would become but it never got to that point and we were always mindful of that. The reason why I loved this whole setup so much was because of what it represents. It represents how flexible our tools have become to allow us to fully realize an effect without having to request any tool support. All the pieces to solve the puzzle and many others like it are at our disposal. While the end result is just some roaches, the concepts we learned and put into practice here have larger applications across other areas when creating effects and completing effects related tasks. This level of creative problem solving takes shape when the tools expose more access to the inner workings of the effects to the artist. I will say that we are super freaking lucky to have the support we do because if it weren't for Marshall exposing the root data to us we couldn't do this and a lot of other things. Also big thanks to Kurt and Nick for showing me cleaner and smarter ways to write the code for the scripts.

Wednesday, June 26, 2013

Visual Effects in The Last of Us: Hometown

VFX TLoU
Spoiler alert!!!!!
The visual effects in The Last of Us consisted of a wide variety of things ranging from subtle ambient wind effects and insects to in your face molotov explosions. Each artist typically will own a handful of levels and will be responsible for creating the effects needed for that level. Additionally we have to create gamewide effects such as weapon effects and melee effects based on animations that happen all over the game. So just like I did with Uncharted 3 when we finished I'm making some videos and posts detailing what we worked on in the levels we were responsible for but I will also be going more in depth in later posts on some gamewide things that I thought were interesting struggles and the solutions we came up with to make it all work. I really want to shed some light on how we go about creating the effects we do and talk up my teammates because they are amazing. So in short I'm going to be creating a series of videos I'm just gonna call "The Visual Effects of The Last of Us".


Hometown
Originally when I was told how this level would play out I thought "That's cool I can handle this.". Wrong. But I'm super lucky to have the people I do to work with. Keith Guerrette really stepped up and helped to get this level done. The effects in this level were much more chaotic compared to other areas of the game. This is where the "Uncharted" in me went wild with explosions and sparking wires. I know a downed power line wouldn't spark like that but just go with it.

Joel's House
The first thing I worked on was the burning house on the side of the road and the barn. I used this area to prototype the fires I would use in other areas of the level. I used a lot of those concepts I worked out there for the burning buildings in the town. From there I created the explosions seen upstairs in Joel's room and the fire effects in the video with the reporter on screen. It's funny because I spent a good amount of time on that even though I knew it was going to end up on a small screen in the game. It's also worth pointing out that one of our rendering programmers Ke Xu worked out a way to increase the resolution of the runtime reflections without increasing the cost to render them. So the smaller the object with a reflective material the higher the resolution of the reflection. I constantly would joke with him saying "Reddit will love you for this." Keith stepped up to handle all of the other effects for the downstairs area of Joel's house and the effects for the drive into town. He also made the lens flares for the tops of the cop cars which was really cool. I used those lens flares on the helicopters flying around. We worked together to create some scripts to control the dirt kicked up by the car as it drives so that when the car would brake the smoke would look like it was being lit by the tail lights of the car.


In Town
With Keith's help on the other areas I was able to focus on the chaos going on in the town. It starts with their car being hit by a truck and I must have changed those glass particles like 30 times. The final result came out good though. I created a script to handle all of the events in the town that needed effects. For example the glass as Joel kicks it to each new horrible thing that happens as you move through the town. The gas station explosion had some amazing concept art to go on and I made a material that I thought worked fairly well for gas that shoots out during an explosion and then that gas ignites in mid air. This all happens really fast but it created a nice result. As you approach the end of the street near the theater there's a car that goes rolling by on fire and then explodes. I have the car leaving a trail of gas fire behind it as it rolls but like a lot of things in the level you can't take your time and look around less ye be attacked. As you run out the back of the bar I made some lingering dirt dust where the ambulance went off the road. These kinds of effects are subtle but add a lot of atmosphere to the environment.








The Sad Ending
When we work on cutscenes we have to watch them over and over again typically frame by frame. We don't hear any dialogue or anything but after enough viewings and having seen the mocap from the stage capture you know whats going on. I worked on the typical stuff like blood when the soldier is shot in the head by Tommy and dust as Joel rolls down the hill and scrambles towards Sarah. One of the interesting things I was able to work on was the tears on the characters. I created a hacked together kind of tool that allowed our animators to animate tears running down characters faces and we also used it to apply bloody hand prints from Sarah onto Joel's shirts where she grabs him on the shoulders. This cutscene is very emotional and the tears did a good job conveying that sadness. I'm glad we spent the time on that. Of course The scene wouldn't be what it is without Troy Baker and Hana Hayes. They did such an amazing job portraying those characters. I'll be adding more posts in the coming weeks.