Dev Journal 06 (10/25/18) A Simpler Solution to Controls, Intro to Animation

So, here's the deal, the reverse skeleton controls are a bust as far as I'm concerned, and while they largely improve the subtle animation quality of the model and leave me with less work overall, I can't achieve the desired effect, it's simply breaking the model at the end of the process.

Not wanting to waste our discussion of controls, I've decided to add a few in choice places, while keeping their purpose very simple. Ultimately, the point of controllers is to let the animator know "These are the parts of the model to touch, ignore everything else" and while I haven't done a good enough job to say that I could hand this off to an animator, these controls should hopefully help me out. If not, I may even get rid of some of them, and purely make use of IK handles and even the base skeleton pieces to animate, though that, while doable, will be a much more painstaking process.

I have to admit here I'm hitting the edge of my knowledge on the topic of rigging, so I'm moving forward into animation and just giving myself adequate enough controls for each major part of the model. I'm not going to go through the exact process as most of the content is not different from last update, but just know that for the eyes, I used a somewhat new but very simple technique.

For objects like eyes which should move together, you may create a LF and RT controller, then create a third 'parent' controller usually wrapping around them. Once you've individually set your constraints between the appropriate controllers and joints, the parent controller, with no constraint of its own, will affect both the child controllers equally. This is mostly important for facial rigging, but good to be aware of.

So, we're ready to animate... Except, that's a huge step, and we've only been working in a single scene so far. At this point, for every single animation we make, we're going to save a new scene with our model in its default position, separate from this animation-ready file state. We want to preserve this in case anything goes wrong down the line. So, let's save this scene, and then save a few new scenes which we'll call:

"The Horror_idle"
"The Horror_crouch"
"The Horror_crouchIdle"
"The Horror_forwardWalk"
"The Horror_backWalk"
"The Horror_forwardDash"
"The Horror_backDash"
"The Horror_forwardJump"
"The Horror_backJump"

These are likely all the basic movement options our character will have. We won't touch on attacks, blocks, or hurt animations because as you can see we already have our hands full just with the basic animation states. Each of these animations should branch from the idle pose, and while they don't need to be perfectly smooth, we want enough connection between most animations that the player does not lose the visual clarity of the character. Since we're not dealing with combat animations as well, we don't have to consider frame data just yet. I'll be taking these one at a time and documenting my progress and end results on each. I may go back and rework some depending on my satisfaction with the results, but from this point on we'll be moving forward at a more brisk pace, other than our initial introduction of the animation and keyframe systems. So, ready? Here's the first frame of our idle animation, the bedrock of the character's animation states, The Horror is ready to fight!

Dev Journal 05 (10/17/18) We Control the... Control Curves. I never watched much Outer Limits.

Hey again, so last we left off we were about to start on Control Curves. To start, we need to make another rig, something called a Reverse Foot Rig. To make it, we'll need to do what we just learned two more times on our existing joints, first from the ankle to the ball joint (no in-betweens for these) and then from the ball to the toe. Because we're making several new handles, make sure to name them appropriately, the first (ankle to ball) will be LF/RT_ball_IK_handle and the second will be LF/RT_toe_IK_handle.

Here's all our six IK handles highlighted now. That's fine, but not quite enough to make the Reverse Foot Rig. Now, we'll need reverse joints. These joints will be snapped to the forward skeleton joints, and there will be four in total: reverse_heel, reverse_toe, reverse_ball and reverse_ball, each snapped to the corresponding forward joint by holding the 'v' key while readjusting them after placement. Because the heel joint does not have a forward equivalent, we'll place it just beneath the ankle joint, where we want the heel to rotate

So once we're done, we'll have a reverse foot skeleton that mostly overlaps the forward skeleton. One last step to help orient that loose heel joint better is to select it and under the skeleton tab click, "Orient Joint" I've done some reading and supposedly joint orientation is a bit of a sore point that can break rigs, though it sounds like using the Orient Joint tool isn't in itself a solution to this. We'll keep it in mind for the future and move on for now.

The last step for the reverse foot rig is simply, to take the IK handles we made, and make them children of their respective joints. That is, move each handle under each joint like so:

Understandably, this whole process is a bit obtuse, the connection line as I understand it is that we have our base skeleton, we created IK handle objects to move pieces of that skeleton together, and then made the handles children to our reverse foot rig to provide an extra degree of control and association with the forward rig itself. It's a little difficult to fully understood even to me and I made the dang thing, but the bottom line is that we're keeping everything simultaneously connected, organized, and influential over one another so that once we get to the animation step, these relationships will automatically take effect, and we can spend more time on the overall motion rather than needing to animate each joint independently.

While for the most part we've implemented all the functionality we need, there is one more step to help communicate the purpose of all these new handles and joints we've made by visually indicating their purpose and locking off certain transformation options depending on each joint. As ever we'll take it a step at a time. Maybe I should've split this into two parts eh?

So now, we're going to make Control Curves. When you look at professional rigs you usually see these red (right) and blue (left) outlines, rings, directionals, etc. around the important control points of a model. they basically provide easy to select, external controllers for the model without needing to select any joints or handles, since those aspects of the model are delicately connected. Controllers keep everything concise, organized and can be more safely manipulated by the animator.

To start, go to the Create tab, go to NURBS Primitives, and select Circle from the menu, this will make a plain circle at the base of the workspace:

This is fine, but we can shape it to resemble the foot itself. To help with this, we can select the control vertexes and shape the circle more like a foot.

We'll want to freeze the control curve's transformations, so that the animator can understand this as the default position for the foot at 0, 0, 0, so that they can reset their position easily when needed. Then, we can duplicate the object and inverse it by scaling -1 on the X-axis (and freezing that transformation as well once it's snapped over the other leg). I noticed the pivot of these curves were slightly offset as well, so when needed you can go to the Modify tab and select "Center Pivot" to keep your object centers... Centered. There's our first controls, RT_foot_CTL and LF_foot_CTL, now let's create ones for toe_pivot, toe_wiggle and ball_CTL. Again, we can use 'v' to snap these controls to the general location of what joint they'll be affecting.

Here's the full set, for now they're just curves, but shortly we'll tie them to our actual rig. First though, let's distinguish them from one another. For each object, move into the Attribute Editor, under the Shape tab, go to the Object Display dropdown, then the Drawing Overrides dropdown that expands from there. Click the Enable Overrides option, and select from the Index Colors for your curves. Standard practice is to use bright red for right, true blue for left.

Now that everything is in place, we move to our final step, utilizing constraints to tie our control curves to the rig. There are different types of constraints and we'll be using a few of them for our curves. The ball and toe pivot require orient constraints as they'll be rotation-only controls, the toe wiggle control will be translate only, as will the foot.

When creating constraints, we want to select the control first, followed by the joint it is affecting. In every case, the controls will be constraining the reverse joints we made. Let's start with the toe pivot, which is the small, diamond-shaped control. Select it, followed by the reverse_toe_JT

Click the box next to Orient and check the properties of this action, we'll want to check the Maintain Offset box, as it will allow our joint and curve to maintain their relative positions. This will prevent the control from snapping to the joint and causing any unexpected issues.

Now, when we rotate the toe pivot control, the foot will rotate along with it, and we can see the connection by the red chain orientConstraint in the hierarchy. As one last consideration, because we only want to use this constraint to rotate by the Z-axis, we can lock the other transform attributes in the channel box to prevent using the constraint for anything but its intended purpose.

We can do this for each constraint, simply considering the type of movement the control will be doing, and locking off the transformations that don't apply. Try doing the same for the ball control curve, figuring we will only need the X-axis rotation for its function. Select LF_ball_CTL > LF_reverse_ball_JT, go to the Constrain tab, and select orient once again.

Next, we're going to use a Point Constraint on the forward skeleton's toe joint. This one uses Translation on the X-axis. Again, make sure to check Maintain Offset when you create the constraint!

To make things more simplistic we can also use the Channels tab in the Channel Box to hide our locked transform fields after we've locked them. It's not required but it does clean up the interface.

Finally, we'll use a Parent Constraint for the Foot Control. The Parent Constraint provides control over both the translation and rotation of its affected joint. We'll be constraining this one to the reverse_heel_JT. We won't need to lock or hide any of the translations or rotations, but if we want we can hide the scale tool. In my case I'm going to leave them alone however, as some fighting games will actually scale appendages during attacks to emphasize a punch or kick by enlarging the related limb.

So two corrections, I realized that I've been calling both the reverse joints and curve controls we've been working with LF when actually they should be the RT joints, we even colored them red and I still didn't notice! Honest slip-up on my part, thankfully we can just rename everything properly. Sorry about that!

The other slip-up is that when we created the reverse joints, I created them in the wrong order. The hierarchy from parent to child should go:

reverse_heel_JT >> reverse_toe_JT >> reverse_ball_JT >> reverse_ankle_JT

Anyways, the foot_CTL will be set up to the heel, but we also want it to affect every other curve (thus why it's important that the heel is the parent of the reverse joints). In fact, we've got a few relationships to set up here. Let's parent our controls in this order:

foot_CTL >> toe_pivot

toe_pivot >> ball_CTL

toe_pivot >> toe_wiggle (both ball_CTL and toe_wiggle are childed under toe_pivot)

Changing these with everything we've done up to this point is causing the foot mesh to distort strangely and permanently unless I back up several steps. I don't know why this is happening but seemingly as soon as I move these control curves the primary skeleton actually breaks, as in the joints are literally removing themselves from the skin they're bound to. Very weird. I'm going to go back and redo a lot of this to try and correct the issue. In fact I may go back to the initial rigging and try to make a more optimized skeleton, just because I've been running into so many little issues along the way here.

UPDATE: After redoing the entire rig with some improvements, (I added a few extra facial joints to attempt mouth movement) I'm still having model instability issues when trying to create the control curves. Maybe I followed the tutorials wrong? I can't say for sure, but for now I'll leave it out with what I have left in place so far. I hoped by documenting everything it would be easier to troubleshoot, but Maya can be very fickle and there's probably something I'm missing here. I think this is an okay point to stop off for the midterm presentation, and once we figure things out we'll move forward to spend the remainder of the semester animating. I've created everything we made over the course of the post, but I'm going to postpone connecting anything or creating constraints until we know what's causing these issues.

Dev Journal 04 (10/16/18) No Cinematics Without Kinematics!

Oops! I've forgotten two big parts of the process, and we can't do animation just yet because these steps will be a major help once we go full-on into animation. We have a skeleton in place, but we can potentially save ourselves a lot of time and headaches if we tie some of our joints together using Kinematics and create a reverse foot rig and control curves to assist in automating limb movement.

Kinematics allow joints moving up the line to depend on a single joint to move themselves. As an example, when you lift your foot, your knee naturally bends with the upwards motion, you generally don't keep your leg stalk straight. With Kinematics, we can make it so that our joints have proper bending points. Thankfully, we can make this effect automatic, so that with a small control rig, posing our character's feet will also bend the knee in a logical manner using kinematics or inverse kinematics, depending on the joint relationship and how it needs to bend. It's kind of hard to explain and I'm pretty rusty but I have tutorials from my last computer animation class so let's jump into it and I can relearn while I do it!

Also, while testing my rig, I realized I made an error in how I created joints. Because The Horror is a shapeshifter, he can manipulate his limbs in normally impossible ways, so I wanted to give him extra joints in his arms and legs. What this ended up doing however was making his skin weights distribute strangely, and the several joints weren't working right at all. Here's rotating the stomach joint:

Sometimes Maya does things that make very little sense and this was one of those instances. Because of this, I unbound the skin, deleted the extra joints, and redid the weight painting process a few times. Now, we've got a more efficient rig that will better serve our purposes. I also took the opportunity to make the model slightly taller, because his legs were a tad on the short side. Here's what we've got at this point:

No big changes overall, but the joints bend more naturally now.

Let's get on to implementing some IK Handles! Head on up to the Skeleton tab again, and drop down to "Create IK Handle, this will show up a new crosshair similar to when we were creating joints.

Now, we're going to select the topmost joint we want affected by the IK handle, followed by the bottom joint that will do the affecting of each joint up the line. In our case, we want to start with the hip joint, followed by the ankle joint.

Once you've selected the two joints in that order, you'll have two new hierarchy objects, an IK handle (which I've renamed to LF_ankle_IK_handle) and an effector which is a child of the knee joint.

First let it be clear that we don't want to touch that effector at all, it's fine where it is and is doing what we want it to do. Second, we haven't actually changed the properties of the joints themselves, but rather have created a new object that affects the joints based on their relationship in the hierarchy. By selecting the hip (beginning) and ankle (end) of the hinge joint (the knee) we've told the handle that when we move the ankle, the knee should readjust and bend in a logical way between ankle and hip. This makes movement such as walking much easier for us to animate.

See? By translating the ankle up, the knee bends forward automatically. You do have a limitation on this handle however, as if the ankle is raised too high, your joints will become volatile quickly.

If you run into this issue when animating, remember to give your joints enough space, this occurs because we're squashing the space between the hip and ankle joints, and in trying to orient itself the knee joint goes crazy trying to accommodate and does not maintain its frontward orientation. To fix this while mostly maintaining the height of the ankle, we can move the ankle forward as well to open up more space between it and the hip, and the knee will fall in line.

Much better! You can see already how much control this gives to a part of your model, which is exactly what we want. Let's do the same thing to the other leg, then we'll talk about controllers.

Oh! We also need to consider this situation, depending on the orientation of your leg joints, that white orientation arrow may not point forward. Let me demonstrate on our second leg, On our first IK handle, the knee sat slightly forward from the hip and ankle joints, but what if the knee was oriented furthest to the back?

The stretch/distortion of the leg is because I moved the knee joint while bound to the model's skin, but the main point of interest is that the white arrow now faces backwards. Let's try lifting the leg and see how it bends now.

Either we've made a centaur or that's a very broken knee. There's an old Adult Swim show called Xavier: Renegade Angel that this is giving me flashbacks of...

That's the spice.

Anyways, my point being, be careful how your orient your joints when you're planning on creating handles with them. I had this issue to a more frustrating extent because my knee was offset from the hip to the side, and the arrow pointed out at a 45 degree angle which made the way it bent much worse. A good lesson here is to keep your joints as straight as possible in relation to one another except for putting the hinge joint at a slight bend of what direction you'd like it to bend in via the IK handle.

So at this point we have two properly bending IK handle legs. We could cover the arms but they should be a relatively simple matter, just reapplying similar logic to new joints. The elbows for instance, would want to bend to the front, not the back, so we'd create a hinge from shoulder to wrist. That said, we still need Controllers. As I discovered however, it's a pretty involved process, so we're goiing to save it for its own post.

Preliminary Consolidated Genre Research & Annotated Bibliography Part 1

Introduction

Due to the nature of my thesis covering 3D art and animation from within the specialized genre of fighting games, I have opted to research successful industry examples, as well as a variety of informed sources both on a community and professional level, writing or speaking on the genre in terms of a quality fighting game’s use of, and self-imposed limitations of animating characters in context of mechanical systems. These systems, heavily grounded within visual feedback, responsive controls, and balanced frame data, (i.e. advantages, disadvantages, safe/unsafe on block) are essentially aspects which rely on both art assets and deeper understanding of what makes fighting games satisfying to play.

In my own research for my thesis project, the most important aspect once I have functional, rigged models to animate will be to understand the universal rules of heavily frame-based animations. I will need to consider the speed of attacks, their duration and recovery times in terms of strictly kept frame data, their range and effective hit/hurtboxes, though those would not come into play until a prototyping stage, which I am not intended to approach until next semester at best.

I would like to make very limited use of tweening for more impactful, snappy animations (a personal aesthetic choice based on existing 3D games in the genre such as Guilty Gear Xrd). With that in mind, here is my consolidated list of influential genre examples and articles/videos to aid me in researching effective methods to animate for a fighting game.

Influences (Visual Approach/Aesthetic)

Guilty Gear Xrd: Use of keyframing on 3D animation to replicate the look and feel of sprite-based 2D animation of previous entries. Sacrifices smoothness for impactful gameplay feedback and makes hitbox/hurtbox data simpler to create and follow.

Punch Planet: A Sci-Fi fighter developed in Unity, this project most closely resembles my end goal for this project in the long-term. As an inspiration template to model my own mock-up out of it’s a great influence to set a general bar for myself.

Late 20^th Century Pop Art: A boldly colored, sometimes filtered and comic book influenced art style, pop art is loud and eye-catching, which is important for designing visuals for fighting game characters, they should stand apart from the background and be easily recognizable, not just by their silhouette, but by their color palette, texture and subtle detailing.

Neon Lighting/Dystopic Future Cities: The contrast of bright neon coloring washing damp, nighttime streets is a physical identity I’m especially fond of from the classic film Blade Runner, and has influenced many settings thereafter. My own world setting takes place in the Martian colony of Neornot City, and I wish to create a similar atmosphere, should I have time to work on backdrops for my mockup scene. This may end up being a stretch goal however, as it implies a lot of rendering techniques and environmental art that I haven’t yet considered for my project.

Sea Shell Aesthetic: The depths of the ocean hold some of the most hauntingly beautiful examples of life, much of which remains alien to us. Creating a sci-fi world, I feel the descriptor of hauntingly beautiful fits in very well with the dystopic, neo-noir style of Blade Runner’s Los Angeles. Given my story exists offworld, and far in the future, I would like to give it a fantastical flair with architecture and technology developed and inspired by the natural and complex spiraling designs of shells: conches, spires, nautilus, venus combs and other mollusks. Even hovercars adapt the sleek designs of these shells. I believe this aesethetic will provide Temp Work Mercenary’s world its own distinct look apart from its peers in the genre, both in terms of fighting games and sci-fi media.

References

Text:

Animation of a High-Definition 2D Fighting Game Character:

¹ Rantala, Tuula. “Animation of a High-Definition 2D Fighting Game Character.” Theseus.fi, Spring 2013, www.theseus.fi/bitstream/handle/10024/59254/Rantala_Tuula.pdf.

Tuula Rantala (http://tuularantala.com/) is a Finnish Game Artist who coincidentally created his own in-depth thesis researching fighting game animation a few years ago, and ultimately created his own sample character to demonstrate the process using open-source fighting game engine M.U.G.E.N. and within his thesis he lays out many of the same discussions I have been considering in conceptualizing my own project. While perhaps redundant to source another thesis for my own thesis, I’d argue there’s no better resource than someone who has written extensively on the topic and gone on to do their own projects in the medium. Rantala’s conclusion ultimately states that 3D animation is the ‘most versatile and practical approach’ which gives me hope that my own project is built on a solid foundation to succeed on. This is a vital and exhaustive resource for me to reference as I move forward. Additionally, a select few of his listed references are quite applicable in my own.

² Keits. “Seth Killian Explains Why 3d Graphics Give Fighting Game Developers Flexibility.” Shoryuken, 28 Sept. 2011, http://shoryuken.com/2011/09/27/seth-killian-explains-why-3d-graphics-give-fighting-game-developers-flexibility/.

Seth Killian has been a competitive fighting game player, esports commentator, and developer both working at Capcom and independently, and has been a part of the community and the industry for years. In this short interview excerpt, he expresses that the fundamental differences between 2D and 3D are ultimately less significant than the process of creating them, ‘cheating’ to achieve effects or save time where necessary to keep on track, and the subtle care put into adding personality into animations to communicate character in a genre that doesn’t take much time for exposition or plot. In the end, Killian identifies that 3D provides more flexibility for what designers can do with their characters, iterating designs quickly and reworking animations if necessary, which with sprite-based characters can be an exhaustive, painstaking and time-wasting process.

³How to read frame data: Super Street Fighter 4 Arcade Edition

EventHubs Community, “How to Read Frame Data: Super Street Fighter 4 Arcade Edition.” EventHubs, 10 May 2010, www.eventhubs.com/guides/2009/feb/17/how-read-frame-data-street-fighter-4/.

User Ashn0d lays out some general terminology to aid in reading fighting game terms and understanding the concept of frame data, that is, the duration of animations, their properties and how they effect or are affected by other mechanical aspects in the game.

⁴What is a Hit Box

EventHubs. “Guide to Understanding Hit Boxes in Street Fighter.” EventHubs, 21 Sept. 2009, www.eventhubs.com/guides/2009/sep/18/guide-understanding-hit-boxes-street-fighter/.

An anonymous EventHubs user does a nice job laying out how hitboxes function, interact with one another, and unique properties such as move invincibility. Just a good personal reference for my own purposes.

⁵Designing a 2D Fighting Game

Ketonen, Miikka. “Designing a 2D Fighting Game.” Theseus.fi, 2016, www.theseus.fi/bitstream/handle/10024/118514/Thesis_Miikka_Ketonen_KAT13PT.pdf?sequence=1.

Another thesis, this one is more focused in contextualizing the history of fighting games, and goes a little more into the mechanical depth of control layouts, attack strengths and so on rather than the artistic considerations, a good alternative angle to read up on, as each aspect informs the other.

⁶“I Wanna Make a Fighting Game!”

Demetrio, Andrea "Jens". “I Wanna Make a Fighting Game! - A Practical Guide for Beginners (Part I).” IndieWatch, 14 Apr. 2018, https://indiewatch.net/2017/04/11/wanna-make-fighting-game-practical-guide-beginners-part/.

Andrea provides a 4-part introduction and tutorial to beginner game developers who wish to create their own fighting games, going not only into the fundamentals discussed several times prior in this document, but providing excerpts of programming in order to actually implement these things in a development environment such as Unity. Andrea also uses a personal project for many of these examples, showing qualification and past experience working with the genre.

Video:

⁷Why Animation Matters – The Fighting Game

Poonian, Sandeep. Why Animation Matters - The Fighting Game. YouTube, Zenvizi Games, 19 Apr. 2016, www.youtube.com/watch?v=DnASbvheF4A.

In this video, narrator Sandeep takes a quick but detailed look at the importance of animation for feedback, hitboxes, and the consequences of sloppy alignment of animations to hitbox data. Of particular interest he does bring up the 12 principles of animation, a universally accepted resource for creating quality animation, and a good stepping stone to follow on any animation-centric project.

⁸A.B.I.torial 14: Injustice 2’s Animation

SugarPunchDW. “A.B.I.torial 14: Injustice 2's Animation ALSO SUCKS.” YouTube, SugarPunchDW, 14 Feb. 2018, www.youtube.com/watch?v=gbNWb-vmlB4.

While I’m not a huge fan of the uploader’s cadence and asides, this video contains some great indication and call-out of cut corners in the animation department on a AAA title that one might otherwise not readily notice. He makes his points well, uses other recent and relevant examples of the genre that do animation right, and does concede where Injustice 2 succeeds, so ultimately just a good resource to reference the do’s and don’ts of fighting game animation.

⁹How to Animate a 2D Fighting Game

Root, Dan. How to Animate a 2D Fighting Game. YouTube, Rootay, 18 May 2018, www.youtube.com/watch?v=MBfPWyVpIjM.

I’ve been a fan of Dan Root for a while, as he explores a mix of mechanical, thematic and artistic aspects in the games he covers in great depth. In this particular video, he’s covering a lot of familiar ground to us by this point, but very efficiently does break downs with visual aids for fighting game animation that follows concepts quite a bit differently than the typical 12 fundamentals of animation coverage. Instead, Root opts to list out more specialized techniques in animating fighters, that is: keyframing, anticipation, follow-through, smears, overshooting and exaggeration/breaking as the main aspects of fighting game animation. Keyframing references the most important parts of the animation, the beginning, middle, end and general key points of movement in a given animation, follow-through is what one would think of as the recovery, where the player returns to their idle state after an attack, block, knockdown or any non-neutral pose. Overshooting is the idea of ‘stretching’ joints beyond their normal range before returning to the expected position, creating a smoother, snappier attack. Paired with overshooting are smears and breaking, where the illusion of motion is implied through a character’s movement being blurred or replicated several times at different positions in a single frame, as through photographed with a high shutter speed. Breaking as the name implies will bend or even break a character’s limb position in impossible ways to create a flexible, dynamic motion. Root references The Animator’s Survival Kit and its consideration for walk cycles, that you may 'break the leg’ to exaggerate and accentuate walking motions with character and life. Root ends with an interesting viewpoint of 2D vs. 3D, and how many of these techniques can become lost in the transition from traditional 2D art to 3D, but that in considering these techniques, a 3D game can mimic and ‘cheat’ out these techniques with a little extra care to bring them out.

¹⁰Making Animation Rock While on the Indie Clock

Dawson, Tim, director. GCAP 2017: First Pass Final Pass: Making Animation Rock While on the Indie Clock. YouTube, GCAP, 3 Dec. 2017, www.youtube.com/watch?v=9DsKgUfpYJo.

Tim Dawson, one part of the three-man team at indie game company Witch Beam, has worked in the industry since the early 2000s, and in this talk expresses fantastic insight into the concepts of gravity and energy, and how it is distributed by motion. His decade plus of experience shows in his published work, and the several examples he uses during this talk further solidify him as someone worth taking as many tips as possible from. In fact… Here’s a text resource from him to supplement this video!

¹¹Assault Android Cactus Dev Blog – Birth of a New Queen

Dawson, Tim. “Assault Android Cactus Dev Blog - Birth of a New Queen, Part 2.” Assault Android Cactus, Witch Beam, 28 June 2013, www.assaultandroidcactus.com/2013/06/birth-of-new-queen-part-2.html.

Graciously, Tim did a lot of documentation while Witch Beam’s first title, Assault Android Cactus, was under development. This includes the full design process from concept sketches through modeling, UVs, rigging and animation, plus plenty of other tricks along the way. This guy really did it all, and his work here helps inform me as I work on my own documentation. I especially enjoy his witty captions! Jokes aside, this is some really valuable stuff, and more than just the one link above, every blog entry provides a different part of the process with some really cool samples along the way. http://www.assaultandroidcactus.com/2013/07/birth-of-new-queen-part-3.html

http://www.assaultandroidcactus.com/2014/05/there-will-be-justice-part-2.html

Something I particularly enjoy from that dev blog is this boss's running animation done by Tim, shown in multiple iterations improving detail with each pass:

^{Cool stuff.} 

¹²Low Poly Modeling: Style Through Economy

Redd, Ethan, director. Low Poly Modeling: Style Through Economy. YouTube, GDC, 3 May 2017, www.youtube.com/watch?v=H1oNuKChsdU.

Ethan’s body of work exemplifies the quality and merit of stylized graphics succeeding to get across visual clarity without the need for high fidelity, intensive processes common at the AAA level today. By making economic use of geometry, effective workarounds for shading, texturing and rendering scenes, as well as faking it to make it, as he shows with the idea of scrolling UVs, he provides some very cool, and very uplifting alternatives to stuff that often times is restricted only to the big, well-established businesses of the industry. A great reference to keep my goals attainable while still striving to create something of quality.

Dev Journal 03 (10/10/18) Spooky Scary Skeletons: Rigging & Weight Painting

It's October so I had to make an obligatory skeleton joke.

Hey though, we're getting close to being animation-ready! There's just a few more major steps and we can start putting things together. First though, we need a little change of scenery on Maya's toolbars. Until now we've been getting by with the Modeling template, but Rigging has its own template, which we access from a dropdown menu on the top-left side of the screen:

The rigging menu option is highlighted in blue. Now we've got some different tabs to choose from, we'll head on over to "Skeleton" and select "Create Joints" from that menu.

Now we've got a crosshair, basically we click where we want joints, and the connections in-between them become the bones. Keep in mind though that your first bone may not go quite where you want it, so after placing it, rotate the perspective view to see where it was placed, and realign it to your character. This first joint will branch into all our other joints, and is considered the Core of the skeleton, so we'll call it Core_JT

'

Yep, that's way off-center. I'm going to move into side view so we can realign the Z-axis to overlap our character. Once it's aligned all following joints will align generally to where we place this one.

It doesn't need to be in a completely exact position, but keep it centered and a little above the hips, in anatomical context this is the best spot because we distribute much of our weight from the core of our body, and in general we want a central joint that all the others will grow out from. Just one more thing before we move on, you'll want to return to perspective or front view to see that the joint may also be off-center on the X-axis, so we'll want to hold the X button to activate "Snap to Grid" and move the model toward the center to snap it to 0 on the X-axis. You can only directly fix the position values from the Channel Box tab on the right if you prefer.

There we go, now we can get on with the rest of our rig. The process from here is pretty simple, anywhere you want to be able to bend, twist or stretch your character, you can add a joint and once we've bound the skin, each joint will control parts of the mesh based on its weight/influence over its assigned section of the model, which we'll need to ultimately fine-tune either with the Weight Painting tool or through the Component Editor, optimally a combination of the former, then refining the nitty gritty numbers via the latter.

With some time spent (and reusing/readjusting a copy of the newer model's rig) we have a full skeleton for this model. Now we're going to shift+click to select both our model and joint systems (the parent objects are fine and will select all children below them in the hierarchy) go to the "Skin" tab and click "Bind Skin" if there are no problems, your rig should become color-coded by each joint as shown in the picture above, and if you try moving the joints your model will move with them! Albeit maybe not in the most optimal forms.

Success! Our model can share in our moment of triumph, or maybe he's doing yoga, either way, this is pretty awesome. Still, I can see some issues with what joints affect what, our shoulder joints are making The Horror's jaws stretch slightly, which shouldn't happen and will be accentuated if we need a lot of shoulder movement down the line, so let's fix it up. The first tool we need is easy to access and becomes available once our rigged model is selected. The option "Paint Skin Weights Tool" will appear by holding right click, situated diagonally up and to the left from where you opened the menu. Select that and a new window will appear, and your model will turn black and white, where black represents areas unaffected by the selected joint, and white represents areas that are. As the name implies, all we need to do here is paint the logical areas we want to be affected by that joint. The knee joint for example should be a ring around the knee areas. Again, this isn't an exact process, just get a general gist of where things should go. You can adjust the brush size via Stroke>Radius(U) though it's very touchy depending on the size of your model, so make small numeric changes if you need a smaller brush to paint small areas. The paint sensitivity is also dependent on how dense your model's subdivisions are. If it's a pretty low-poly model, affected areas will be larger, essentially each square being a paintable spot, while a high-res model will allow for much more precise painting. Let's get a picture of what's happening with those shoulders:

The nose, mustache and ponytail appear grey because technically I've selected the base model and not those pieces of the model, so we can ignore them (though they may still adopt weights from the base model, one thing that the component editor will be very good at fixing). As for our shoulder though, it looks mostly in order, except for that very subtle smudge of gray on the side of the chin. It may not seem like much but it does have an impact, so let's get rid of it. While we're at it, we can shorten the effect radius of the shoulder joint, to leave space for the other joints to have influence. To remove this joint influence paint, hold Ctrl or Cmd while clicking, the "R" on the red selection circle should change to R-Inv, or inverse painting to remove influence between joint and mesh.

There we are, now the selection is much sharper and cleaner, not riding up on the neck or ribs joints and no longer smudging the chin. This is a tedious process but it makes a difference, we go through each joint and paint it so that its influences are clean and accurate as possible. By the end, if you scroll through your joints, their skin weights will look like this (At this point I'm switching back to my low poly model because we've caught up to it progress-wise).

Man that's fun to watch.

So what else is there? The component editor! First though, we need something to edit! I'm selecting our old model's nose, since this might provide insight to the joints influencing different objects as I mentioned before. We'll want to select the nose object, right click and select Vertex, then double click a single vertex on the nose (the small purple points) which should then highlight all vertices on the nose in yellow. Now, we'll go to the tab listed Windows>General Editors>Component Editor, this is available whether you're in the Rigging template or Modeling template.

Once the component editor opens, you'll want to scroll right until you find the Smooth Skins tab, and select it. This is where all the skin weight info is kept on a numeric level based on each vertex on our model, though because we've only selected our nose, we only see the objects affecting the nose. What may seem weird is that our ribs are affecting our nose. Yeah, that doesn't make sense! Of all our joints, the only one that should have any influence on the nose is the head joint, since it's the closest and makes the most sense (unless we made a nose joint, which would be silly).

Speaking of silly, just to make an aside, what would happen to the nose if we moved our ribs joint far off to one side?

Well that's interesting. Appears we've got some influence going on in the chin as well. Basically, the ribs joint is pulling the other objects along with them, because it has marked their vertices as affected by it. Again, most of this can be viewed and handled via the weight painting method, as it's more visually informative, but this is hands-down the best way to troubleshoot weird rig movement if it isn't immediately obvious what's causing the issue.

There's a lot of numbers on here and it may seem like a pain to fix at first, but actually it's super easy. Take each questionable joint, click and hold to highlight the top value, then scroll down all the way to the bottom. Once you release the mouse, the bottom value will be highlighted to enter a new value. Type in "0" and press enter, if done right, the suspect joint will be removed from the nose object's vertexes/smooth skin menu.

Now, our nose is free from all influence other than by the head joint itself. Let's take a look!

Viola, the chin's still looking worse for wear when we stretch the ribs joint, but the nose is immaculate! That's... Pretty much everything I wanted to cover! I don't know exactly why I went for the in-depth tutorial, but I suppose explaining my process as though I was teaching someone else is a decent way to do documentation for a project. Next time we'll look into animation, but maybe I'll approach it as a bit more of a showcase while explaining the method behind my animations, I don't think we need a presentation on how to keyframe an animation, but at the least I can explain what sort of look I'm going for, where I'm getting my timings from, what I'm moving where to achieve the best effect, etc.

For now though, I'm going to call this a post, and we'll pick this up again real soon!