Killian was the first character that I worked on at my time on Breakaway that I got some artistic freedom with. When I worked on Rawlins' sims, I was given very clear cut instructions on how they should look, since Rawlins was a character that was more grounded in real physics. His cape had to move a certain way. With Killian, I was given his concepts and a bit of direction from the lead technical artist, but other than that, I was able to play around with how he looked.

I was told that he was supposed to be 'chaotic' but also 'otherwordly'. With these adjectives and the concept art, I wanted to make the cloth have this slow but also busy look to it. Yet it couldn't be too busy either. So the first thing I did was section off simulations into four parts (picture below) to add to the randomness. They I made the pieces lighter and slower in motion.

Rawlins was a rig I worked on that exposed me to Lumberyard's simulation system. I worked to make the cape look like a heavy material and also added additional sims on the fringe and on the two holsters on his sides. The greatest challenge with Rawlins was making sure that the cloth wouldn't penetrate the character when he was running in certain directions.

Sasha is the first full rig I created for Breakaway. I was taught the project's internal rigging sytem and worked to re-create that rig for Sasha. There were some struggles of course, and some things that had to be re-done, but I felt like I clearly understood the rigging system after having to re-adjust components.

In addition, Sasha was my introduction to working closely with the animators to achieve the look that they had for Sasha. This required us to constantly check in with each other, and required me to provide the animators with additional secondary controls that they may have needed. It also allowed me to independently talk with modeling about possible changes to the topology that would make the character deform better and form good working relationships with all of my co-workers that were focused on getting Sasha complete.

Part of my job on Breakaway was not only producing rigs, but also creating scripts to assist in the pipeline for our game. We had a list of requests from our animation team and I got to start on some of those tools during my time on the project. One of those tools was a local to global switching script. We had a local to global switch that only worked on one frame, but the request was for something that could switch over multiple frames and would work on a timeline selection. This was where a majority of my work and research took place. I had to figure out if there was a way, through Maya, to determine which part of the timeline was being selected. I also had to figure out what type of interface would be the easiest for the animators to use. I ended up creating a quick UI using Maya's UI elements.

To extend this tool, rather than just have it switch from local to global, I would have liked to make an interface where the animators could choose what to switch to and from. Our rigs didn't support this, but for future rigs that I create or work with, I believe that they would have multiple spaces and this functionality would be highly useful. I would also like to recreate the UI in PySide. We had some restrictions with the use of PySide, so I couldn't make the interface in it, but for a future interface, I would like to recreate it in PySide, as it also gives me more control over the look and functionality of a UI.

The batch exporter is a tool that we used to help us batch our animations without an animator having to go through and manually export each file on their own. The process takes in a list of files, opens each one in sequence, and does the export command. However, the tool had a slight hitch. Every time a file was not checked out or errored out in any way, it would halt and wait for user input. This functionality is not great, of course, since it meant that someone would have to babysit the exporter to make sure that it was progressing and, if it stopped, they would have to give it the needed input before it kept going.

So instead of having it stop, I was tasked with making it so that the exporter would skip these files and would instead write the error to a log and move on. The first thing that I had to do in order to get this to work was to get the MEL function to work in Python, since Python gave me more freedom when creating a class that would let me write to a file. The reason we didn't re-write the entire exporter was because we didn't have the time in production to do so, so it was better to extend what we already had and make it workable with in these means. So I created a logger class that would write out the errors and also figured out how to check if a file was writable before attempting to export the file.