CAGD 495 - Marred

SPRINT 6 (11/8 - 11/17)

Walk cycle for the heavy bot. This particular bot held the high caliber weapon.

To state it bluntly, this sprint proved to be quite difficult. Because I had caught COVID, I needed to self-isolate for the sake of my teammate's safety, and alongside allergies, this resulted in my progression going slower than I originally intended. While I desired to tackle all of the miner and robot cards, I was only able to gather around 10 points, and I couldn't finish the run animation and the melee cards on time. However, I treaded down relatively new grounds in this sprint, and tackling each card involved a noticeable amount of trial and error.

Walk cycle for the heavy bot holding the BAG weapon.

During Sprint 5, I was responsible for cleaning the rest of the mocap data, which I was able to accomplish. For this sprint, and possibly for the remaining sprints of this semester, my duty is to bake said data into each model, and equip weapons if needed. 

Walk cycle for the security bot.

I had mentioned previously that I struggled with the rigging process, and thought that resorting to the autorig feature would solve the problem. From what I have learned, the Mixamo export process to MotionBuilder actually did work. After a couple of attempts, it downloaded correctly, but I had to resize the joints so that they would be noticeable. Some models did have their axis (0,0,0) pointing at the wrong direction, or some needed to be posed differently in order to be read in Mixamo, but this was solved by adjusting their features in Maya first before starting the rigging process. 

This doesn't mean that learning the autorig feature was a waste of time, however. I plan to use that method for frame-by-frame animation (alert animations and melee attacks).

Security bot rig

After rigging the models in Mixamo, my next step was to define both the mocap animation data and rigs themselves. This definition process needs to be done so that the program can identify the joints for a successful baking session. This process wasn't new to me, but it involved a trip down memory lane and references from Frank's tutorial videos. This wasn't difficult - after all, I only had to assign the correct label with the joints, and I was able to zoom by this process fairly easily.  

A successfully baked walk cycle in MotionBuilder.

At first, I thought that was it for the baking processes and I exported them into the drive as so, but after discussions with my teammates, they requested that I parent weapons onto the rigs and keep the animations to a still frame so that Unity can move them around. It was at this point that I ran into trial and error, as I've spent the remainder of my time experimenting what methods worked with me. 

Despite there being a feature in MotionBuilder that keeps the animation working in-place, it wouldn't activate when I referred to it, so I had to research other methods. In the end, the easiest way for me to enable in-place animation was to merely mute the Z-axis feature in the channel box in Maya. This took me a couple of hours to figure out, and to think that the solution was so simple!

One of my attempts was to zero out the joints, thinking they would sit at the intersection (0,0). Instead, it created... this.

This allowed me to assign weapons onto the rigs. Some, such as the pickaxe, were very easy. I didn't have the time to properly parent controls onto the rig joints, but that was alright because parenting the weapon controls to the actual joints themselves showed the exact same results, and I never ran across errors. 

I was experienced with single-handed weapons, but others such as the High Caliber and the BG for the heavy bots required two hands. After research, I found out that the easiest way to tackle that was to parent a locator to the same weapon, and then parent the locator to another hand joint. That way, both hands are securely holding onto the weapon, with one hand being the main control. It was perfect!

Ranger walk cycle. I parented the weapon onto the actual joints, but I didn't mute the Z transformation yet.

With this process, I ran into another issue: the parenting would glitch and freak out during the remainder of the animation. This is because the parenting only worked in one frame. Sure enough, the graph editor showed that every single frame in the exported animation was keyed. I had to do heavy manipulation, which served to be a tedious process. I had to delete frames of the joints that I repositioned (ex. arm limbs) and replace them with my manipulated versions. It was a very long process, but with time and practice, it got done. Considering I will be doing this for the rest of the semester, I believe I will fly by this process quickly.

Before I fixed the frames. Each one is keyed.

After I fixed the frames. Less cluttered.

Weight painting, of course, needed to be done to ensure the models don't break or look uncanny during animations. I did not need to relearn this step, but I have yet underestimated how long the process took, especially for more intricate models such as the heavy bot. I have learned that not weight painting before the animation process actually makes it longer, especially using the same models for different animations. That was one of my mistakes. For now on, I will weight paint the original copy first, and then work on the animations.

Weight painting the heavy bot took the longest amount of time.

SPRINT 5 (10/25 - 11/3)

Now that I have completed the reload animations, it was my responsibility to clean up the motion capture data so that I could later bake the data into the models. It is requested that the enemy characters move around the game and approach the player in a believable manner.

Setup for Human walk cleanup. This cleaned data will be used for the Ranger and Miner models.

Optitrak Motive, the program used to record motion capture data, was also used to clean up the data. Overall, I can say that my progress went rather smoothly - there were plenty of very clean data that took minimal effort to polish in a small amount of time, not to mention I quickly became familiar with the practice. I had a classmate who was kind enough to give me insight on how to properly fix marker occlusion, as well as relying on videos from my previous motion capture class and other tutorial videos on YouTube to greatly assist my journey. I was confident in my cleaning skills, and I made a lot of them passable for fun video game experience. 

Heavy Bot run

Regular Bot run

Miner run

Ranger run

Victory animation (seemingly for the player after a level is successfully beated)

However, some various data pieces were relatively hard to polish, as there were frequent marker occlusion (in simpler terms, it basically means that some markers have either clipped to others or vanished entirely) which caused errors in the animation as well as the skeleton itself. Meanwhile I was able to fix some of them such as the Imp Attack and the Oni Slam, some such as the Imp Lunge were relatively harder to fix and I had no choice but to export them. I only hope I can fix the animation issues on either MotionBuilder or Maya by manipulating the rigs. 

Oni attack

Imp run

Imp attack

Oni slam attack

My next task was to bake the cleaned data onto already existing models. There are a select few models already created, most noticeably the miner model, so I went and downloaded it. Before I bake models, however, I needed to have the model rigged. Considering the amount of time it took me to rig the basic human model in the previous sprints by hand, I realized that manually rigging the models myself would take to long. I had to take the risk and have them autorigged.

My first attempt was using Mixamo for autorigging. Meanwhile I was able to upload everything just and the rigs were not broken (except for origin placement, I had to go back to the original Maya file and fix its origin multiple times), there were issues with uploading the rig correctly onto MotionBuilder. For some odd reason, the skeletal joints never properly uploaded with the rigs, hence I cannot define the skeleton in order to bake the data. 

Perhaps I saved the Mixamo files incorrectly, because only the bones are imported. I wanted a new rig imported entirely.

However, I found an alternative method by using the autorig feature in Maya, which has saved a great deal of time. With the model being a basic bipedal model, the rig was clean and polished. I did some weightpainting, and I finished it relatively quickly. What also worked for me was that the skeleton is seemingly already defined, which has saved a lot of work for me to define it myself. However, if errors rise with the baking, I will go back and redefine the skeleton.

Autorig feature worked very well in Maya, and was automatically defined.

In summary, out of the eleven points that were assigned to me, I was only able to complete three points, with the other three being assigned In Progress. I take full responsibility of my inability to accommodate my hours accordingly - merely meaning that, considering motion capture cleanup can only be done with the assigned computers in Room 331, I did not go during extra hours to complete. 

Another factor for my delayed progress is the amount of time it took to clean up the harder pieces of work. I was aware that it would take me a while, but I have underestimated the timing when most of the mocap work was able to be finished quickly. I took a lot of time polishing the harder works, hence slowing me down. 

I expect to bake animations for the entirety of the next sprint, hence I must be smart about rigging each model. Luckily, I expect to not run into delays as I have 24/7 access to Maya as well as MotionBuilder, so I expect myself to progress through the cards quicker than this sprint. 

SPRINT 4 (10/11 - 10/20)

In the span of two weeks, I was met with quite a workflow. I will admit that I did not meet up to my team's expectations, mainly considering the time factor. It was required that I finished all animations within a week and get straight to cleaning the motion capture data, but I faced numerous issues and frame clipping that required more time than intended to fix them. Meanwhile I'm sorry for my slow progress, I'm content that I finished the animations by the end of this sprint. 

Nailgun Reload 

First pass of reload animation

The progression of my work went semi-smoothly: I ran into issues on hand placement and agility. I struggled to find the root of the issue at first, but my teammates recommended that I change the player hand placements on the gun, which were incorrect from the start. This, in turn, has prompted me to completely redo the animation. I was able to resolve it in a couple of days, using reference from YouTube and my teammate's advice. 

As shown in the video, there is the instance where the player slightly moves its arms, causing a noticeable jolt when holding the gun. This is the part of the animation that I'm like the least. I'm glad I got the animation done, so then it will be easily edited and exported. 

Blocking sequence of reload animation

SMG Reload 

Final reload sequence

This assignment proved to be my proudest because my teammates were very pleased with the results. I kept track of where the hands will be placed, so I ran across very little problems with arm agility/movement. Meanwhile I ran across issues with axis rotation - which caused some frames to glitch or clip drastically, it was relatively easy to smooth out in the graph editor.

There was a section of that animation that my teammates liked, which - ironically enough - was where the glitch occurred. The item that the player puts into the smg flips in its hand unintentionally. Meanwhile this was accidental, it gave a sense of an organic-like feel, as my teammates described: "it looks like he's flipping it and that's cool". I decided to keep it regardless. 

Shotgun Reload

Final pass of shotgun reload animation

This assignment was, by far, the most difficult I had to work with, but for interesting reasons. With this particular piece, I attempted to add controllers for both the handle and the slider, and I proceeded to parent them to each wrist controller. This, in turn, made my first pass relatively easy and quick to finish. Despite this, I was pleased with my results, and I presented it to my teammates.

First pass: it was very simple and quick to the point.

After submitting the first pass, my teammates suggested that I change the camera angle because the original obstructed a lot of the player's field of vision. My original intention was to rearrange the camera angle and get on to the next assignment, but upon turning it in, the animation looked rather flat and it was heavily suggested that I add extra movements to make the animation believable and engaging. 

Second pass: I was able to tilt the gun downward, but I was encouraged to enhance the animation to prevent it from looking flat. 

Upon working on my third pass, I immediately ran into some issues, particularly with the constraints. On occasion, referring to the wrist control's W0 switch in the attributes channel did not function as it should, hence creating clippings with parenting. This caused numerous glitches, so to save time, I keyframed the slider and the bullets. It was much more time efficient, but I ran across multiple hand clippings in certain frames that I had to fix. To solve this problem, I had to completely redo the hand positions numerous times. 

Third pass: I added a more noticeable reload sequence but there was multiple glitches due to parent constraining issues.

The reason for this assignment being the most difficult was mainly due to the amount of glitching in the arms and wrist controllers. A lot of the issue was due to the rig not being in IK, so I had to control the wrists and arms manually. This made the assignment more lengthy than it should. 

Third pass: perspective form, the glitching in frames is extremely noticeable. 

My teammate had to step in to create an initial keyframe for me due to this problem, but the rig had to be "broken" behind the camera: I unlocked the transformation features on the shoulders so the arms can be manipulated, and some of the limbs had to be positioned unrealistically to achieve the best results. However, despite its difficulty, I was pleased to gain help, and I gained a lot of insight on the fps animation process in turn. 

Railgun Reload

Final splined sequence

The first pass of this animation was fast and easy to complete. Due to my experiences with blocking and fixing the in-betweens of the other gun animations, I was able to finish this relatively quickly. The only difficulty I faced was the lack of an accurate reference: while I searched on YouTube, I noticed that it had fps animations for guns that didn't match the look of this railgun, meaning that I struggled on where to put the player's hands or even what action the player should do.

In the end, I resorted to memory and reference to create a passable animation piece. My teammates, particularly the game developer, had ideas on how the reload sequence should look, and has shown it to me a number of times.

First pass of animation - minimal detail acting more like a placeholder.

My teammates offered suggestions to amp up the animation quality: adjust the size of the gun to make it bigger, and to "get creative" with it. I would say that, for this one, I took the most artistic liberties with it, as I added a small shake animation and a relatively detailed reload sequence. Adding articulate details during the blocking phase first saved me a tremendous amount of time with animating. 

Second pass of reload sequence. Drastic changes were made in this one compared to the first one, including actions and timing. 

The update took me a little bit of time, but not as long as it did with the shotgun. Considering that I got my bearings in, I worked on improving the animation quality quickly. And I was pleased to see the positive reception from the teammates - the only advice they had given me is to extend the gun shaking time. 

Admittedly, the shaking segment was the most difficult because of the constant hand clipping that resorted to the animation looking choppy, and I had trouble with the hand placements. I've done the animation frame-by-frame and I think I should've used parent constraints to pair both hands to the gun to make it an easier process. 

Summary

My progress for the reload animations has been a rocky one. A huge fault of mine was my lack of familiarity with fps shooter games, which has hindered my ability to even look for accurate reference. Luckily, my teammates were patient to educate me and direct me to helpful tutorials (I also had multiple instances of looking for tutorials myself). Being a cinematic animator, it was hard to get my bearing with fps animation. 

Following this, I'm eager to finish the rest of the motion capture data. I have more confidence for this assignment considering that I know how to clean up motion capture data, although I will probably have to rack in into my brain at first due to lack of practice. I have also noted that most of the data, if not all, had clean animation, so clean-up does not have to be severe. 

My only difficulty will be having constant access to [Optitrak Motive], which is only accessible through the computer lab and does not allow outside access. I believe I will be able to resolve this issue efficiently by requesting the professors to use the computers during extra hours, if not used by other students. Aside from this, I'm confident that I will be able to finish the data clean up for the next sprint. 

SPRINT 3 (9/27 - 10/6)

My progress for this sprint proved to be slower than I intended. I expected to tackle the animation sequences very quickly, but a recent pet death in the family proved it to be difficult to focus on assignments. Luckily, after the week progressed, managing the pet death became less demanding and I was able to work on my assigned projects.

One of my assignments was to rig the player arms that were modelled by the game developer. Due to my recent project of rigging a base human model beforehand, rigging the arms was a very quick process that only took a couple of hours. I refused to use Mixamo due to the potential corruption of movement that might occur, and I faced little to no problems while rigging it myself. 

Arm rig with designated FK joints. I cannot scale or move the world axis without breaking the rig, but it wasn't too much of a concern since my main intention was to animate. 

Arm rig with visible joints. 

I created my first pass with no finger joints, but upon playtesting with the pickaxe weapon, I realized that I needed the player to grip the weapons accurately. That was a very quick process of re-editing the arm joints to allow multiple finger joints. 

My next project was working on the pickaxe swing animations. The game developers wanted that I create attack animations to further immerse the players into the game. Interestingly, this process proved to be much more difficult than I assumed it would be: me being a cinematic animator, I had to apply different rules into game animation. 

With my first pass, I applied rules of anticipation as the player raises the pickaxe - it would be executable for acting in animation. But, from what the game devs have politely critiqued me on, the main goal is to execute movement clearly and quickly. I redid my pickaxe animation again, this time eliminating the long anticipation before the attack sequence.

Luckily, the motion capture room was available for the team to use, so my next assignment was to record motion capture data for the enemies. The entire team agreed to this because motion capture will essentially be faster than traditional 3D animation and only requires basic corrections. Alongside the game devs, I was in charge of recording idles, runs, and attack animations with Optitrack Motive. 

I recorded each sequence correctly with t-poses in start and finishing points. 

There were some mishaps with the mocap skeleton, but that was easily corrected by requesting the actor, Sam, to turn in a 360 angle or deleting and reloading his skeleton altogether. Aside from that, there were no issues and the assignment ran smoothly. 

My current project is working on the nailgun reload animation. Luckily, I used the same advice that my game devs gave to me regarding the requirements for game animation, so I was able to focus my attention on whether the animation is clear or quick. 

I will admit that I encountered the most challenges in this project: very minor ones include the finger joints clipping into the weapon, but the major ones were the placement of the hands on the weapon and the overall "movement". I used references from various YouTube videos on fps reload animations, but my issue was that I was using different references than what my game devs desired.

In the end, I am eager to continue working on this project. I plan to - ideally - finish this animation by the end of Friday so I can tackle on the other reload animations, and I shall do that by hyperfocusing on the provided references that my game devs handed to me and correcting the hand positions on the weapon. 

For the next sprint, I intend to finish all reload animations by the end of next week so that I will get started on fixing any of the motion capture data. The program that edits mocap data can only be used in the computer labs in O'Connell, so I need to speak to fellow professors on computer availability. 

SPRINT 2 (9/9 - 9/22)

The second sprint has gone successfully. As the team couldn't start modeling the enemies without decent concept art, I have pitched in to sketch each individual character that will be used for the game. My last sprint involved working on the imp concepts, but there were a total of six extra characters who, albeit different species, needed to fit the eeriness of the game: the security bots, oni, corrupted ranger, corrupted miner, heavy security bots, and a shopkeeper bot. The shopkeeper bot is not the enemy that the player has to kill, but rather the merchant for the store where the player can upgrade and buy new weapons. 

Similar to the last sprint, the following concept arts were not colored in and are drawn rather quickly so the initial shapes can be captured for easier modelling. However, they contain more details to their designs to help Jen, the game developer for Marred, to reference off of for accurate modelling. 

Because Jen was very helpful in providing me the attributes and themes for the extra characters, I had little to no issue completing this portion. Communication between the two of us was very strong, and we often communicated outside of school hours to discuss more ideas that needed to be presented. 

I was also in charge of rigging a base human model as a beta test before rigging the enemy models, specifically the miner and ranger rigs. I ideally want to transfer the rig data to said models, considering the base model will act as a foundation point for the enemies (taking note of the PlayStation 1 graphics to add to the nostalgic charm), so I will gather insight if that is a possibility. If not, then this task has tremendously assisted me on the ins and outs of rigging - what portion took the longest, which were the easiest, and which are at the highest risk of preventing hiccups in animation. 

Due to my previous experience with human rigging, the task wasn't entirely new nor was it extremely challenging, but time-consuming. I will be very weary of this when rigging the the player's fps model and other enemies for the game.

Rig with spine error. Skin wasn't bined, so it was easy to make a new one.

The arms, legs, spine, and head were the easiest and took the least amount of time to rig, while the feet had very precise steps, so it took the longest. But even when it remotely felt like a breeze, and I enjoyed it, I was still at risk for hiccups. 

Primarily, the biggest issue was weight painting. Meanwhile it was more time-consuming than an error risk, there were buffers in my computer that prevented me from accurately weight painting. This is an issue because it will leave me at risk for weird animation graphics and therefore ruin the quality for the player. I ran into some other small issues, like unnecessary joints for the torso and mixing up direct keys for the feet, but they were easily fixed.

Foot controls with custom attributes to allow heel/toe manipulation

Not that Sprint 2 is complete, I plan to complete the next following steps:

• rig arm model provided by Jen 
• collect mocap anim data for enemies 
• Animate weapon swap for rig arm model 

Depending on how quick the enemy characters are modelled, I will be either transferring the rig data onto them or rigging them from scratch. Considering that Sam, Jen, and I will be collecting motion capture data on early October, it's very likely that I'll be starting the animation stage. I expect myself to be busy by the next sprint. 

SPRINT 1 (8/30 - 9/8)

For this semester, I am advancing my skills into the game development field. By doing so, I am collaborating with other student producers to create an indie video game, Marred. I'm very excited to be working on this game, considering it involves lots of communication, structure, and I get to showcase my skills! 

Because I am the designated animator for the game, it's my responsibility to animate they player and each individual enemy. In order to do so, I have compiled a document filled with all the animation references I needed. I've extracted clips from video games that I enjoy as well as other suggestions. Jen, the game designer, was extremely helpful in that they communicated to me what kinds of animations they were looking for. 

The document is included in this link. 

Considering that this is only a team of ten, I'm also pitching in as an assistant concept artist. It was decided that the game developer is in charge of creating concept art, but knowing the amount of help I'm able to offer my team, I will be sketching initial designs for the enemies. 

These concept sketches are not colored in and appear to lack detail, the reason being that I first wanted to capture the initial stance and shape for the modelers to easily reference. I will still create more designs for the other monsters until the team picks which design they like best. 

Because I cannot animate until the models are ready to be rigged, I have sketched key poses to assist my animation process for the future. Like the concept art, these drawings are not colored in and do not focus on detail. This is so I can easily capture key poses for enemy run cycles, idle stances, and alert movements. With these key frames sketched out, I will be able to easily reference off of these to create convincing animation to enhance an engaging experience for the player. 

For the next sprint, I plan to finalize all concept art for the enemies in game and, if models are not complete, I will test rig a human model to decrease risk of errors on the actual models.