Week 09 - Initial Block Out - 'F' Stage

This week, I was responsible for preparing the block-out mesh for basic animation. Once I received the  is mesh, I used a default mocap skeleton as a base and placed the joints in the model by hand. During the process of placing the joints, I wrote some Python scripts in Maya to help me orient the joints and copy the transforms of the joints on the left to the joints on the right. Finally, I brought the model into Unreal engine and set up an IK retargeting system to place the character in the game using an adapted version of the default Quinn character's animation blueprint and transferred animations.

Here is the character skinning in Maya.

Here are some of the custom shelf tools I made.

"Select" is merely a hierarchy selection tool, because it is tedious to go into the menu each time. The Orient tool orients the joints and automatically detects end-joints and orients them correctly to their parents. The Symmety tool enforces symmetry on joints by copying the matrix from the left joint, finding the right joint, and scaling the left joint's matrix by -1 on the X axis in order to create mirrored transforms. The Mirror tool is the same, except it creates the joints, too, setting the parents correctly in symmetry. FInally, the Reload tool forces Maya to read my Python module again. It assists me in developing my tools in a standalone way that is portable and easy to update.

Here are the tools in action. It gives the user a text box input for the Left and Right ID's and a choice between X, Y, or Z axis for symmetry.

Some screenshots from my VSCodium project. On the left is code for the UI, and on the right is code that the UI tool calls to do the rigging tasks.

Here it is in Perforce at //CLASSES/Cohort22/Classes/Art/CommonArt/Semester_01/InteractiveExperience/TellTaleHeart/Source/Characters/Killer/killer.fbx

Here is the Killer blockout character in the game environment.

Tech Art Simple Rigging

 

Above: the archer, posed with the FK rig

And here is the joint/control hierarchy. This can't be the right way to do this? Having all these offset groups seems like a sin. And duplicating the entire hierarchy is a total waste of time. Surely there is a better way?

Here is what the joint hierarchy looks like with the constraints. 

This character is submitted to Perforce at to //CLASSES/Cohort22/Students/Joseph.Brandenburg/TechArt/josephBrandenburg_hw/Rigging/josephBrandenburg_HW5.mb

HW4 Intro To Blueprints

 I used my HW3 project. The giant Vase is the object that changes a material parameter with "G". It switches through a few different states and lerps from one to another with a timeline node. I found it very silly that I couldn't put a timeline node in the function!

The crate is the event trigger volume object. It will turn the vase by 90 degrees. It is also using a timeline node to do the turn. All of the blueprints are in the "blueprints" folder. I have submitted everything on Perforce by selecting the project folder and choosing "Mark for Add".

The Vase's construction script. The blueprint is called "bp_vase_dynamic_material". 

And the Event Graph for the vase. It uses an int variable, a "wrap" function which seems to be the same as a modulo function, and a switch statement to toggle between a few different states. Each one changes the material a little bit. The timeline provides an animated blurring between phases. The actual material parameter is set in a function graph.

Here is the function. Simple. But I thought I was gonna be able to do the timeline in here, too. It feels wrong putting it before the switch and checking the switch statement every frame. Bad performance, probably.

Here's one of the timeline graphs.

This is the blueprint for the crate. It is called area_trigger_thing.

And here it is all coming together. Notice that the vase turns when I enter the volume, and its material changes color in phases as I press the G key several times.

The map is saved to Perforce at "Cohort22\Students\Joseph.Brandenburg\TechArt\josephBrandenburg_hw\TechArt_Lighting_HW3_4\Content\maps\HW4Blueprints.umap".

Procedurally Generated Shells

 Procedurally Generated Shells. Made with Blender and 3DCoat (for the automatic retopology only).

Using the procedural generation tool to make a shell.