Showing posts with label TechArt. Show all posts
Showing posts with label TechArt. Show all posts

Saturday, September 29, 2018

Maya Create Bone at Custom Pivot

When rigging weapons or hard surface meshes with specific angles or orientations, I want to be able to quickly create a bone with the same orient of a selected mesh component. I want to ensure I have as precise a position and orientation as possible.

With the latest versions of Maya creating and manipulating pivots have become far easier with native tools. Though, I've yet to see a process to do exactly what I've been looking for. I've written a fairly simple script to achieve what I've found to be the most intuitive approach to creating a bone with the position and orientation that I desire.

Here is a brief walk through of how I create bones using a custom pivot. The script I use can be found below.
    
Character Model by Chris Wells



Sunday, August 19, 2018

Maya Override Drag & Drop Behavior


A friend of mine recently pointed out that you can change the default behavior of Maya's drag and drop files. I generally have not used this workflow but upon changing how it handles the open conditions, I have found drag and dropping far more useful recently.




I have changed the local Maya file performFileDropAction.mel, from exclusively choosing to do a file import, to giving the user the options they wish to perform.

You can find the original file in  C:\Program Files\Autodesk\Maya20XX\scripts\others\performFileAction.mel





Proper Distribution:
The best implementation of this updated procedure would of course be to package the modified code into a module. This is a far more reasonable approach for distribution if you need to roll out to a team. If you need more information on this process, check out Steve Theodore's article on Maya modules.


Here is a brief walk through of how the new behavior works & the updated code can be found below.









Wednesday, April 25, 2018

Customizing Radical Heights - Part 1



My work on Boss Key Productions most recent project, Radical Heights, focused a lot on character customization. In this post I'm going to discuss the process and creation of a customizable character for Radical Heights.

Having previously worked on Lawbreakers and the Saints Row franchise, much of my time has been focused on creating processes for constructing customization for game characters. The methods described below were no doubt influenced by my past experiences and lessons learned working on these titles.

For customization purposes it is important that your visual goals are outlined initially and the "known" technicalities are addressed before jumping in and creating clothing assets. If you change any of the base character assets during production, you will lose a great deal of time re-working any of the existing clothing assets you may have already created. Understanding the problems up front is key to defining the customization process. You want to minimize the work on the art team and maximize the quality and quantity of assets that can be created.


Character Scale


First and foremost the Character Artist and the Character TD will need to work with the level and environment team to ensure you character height will work properly in the scale of the world. In most cases it is a good idea to keep close to real world units for scale. It's likely easier to create real world weapons that work correctly with your character, if you follow this rule as well.

Play-testing your character in game running around, even early in a rough state will help you identify issues with character and world scale. It's important to nail this down early in your process.



Character Mesh Topology


We started with a fairly standard male mesh until we fully determined how we wanted to approach the semi-stylistic look we wanted the characters to have. Here you can see some stages the proportions of the character went through before we came to our current version. The overall height and proportions didn't have to change drastically from our initial construction. However, some aspects changed enough for us to have to modify the skeleton and in turn adjust and re-export animations.You can also see some of the topology was reduced to minimize the work that it would take to project onto future clothing assets and to lower the polycount overall.



From my past experiences, I found its best to have the character mesh topology to be created in a uniform manner. As you can see here, it's almost a grid-like pattern. This actually makes it easy to define notable landmarks, where clothing assets will generally start and end. If you know the type of clothing and outfits the character may wear, its usually a good idea to make sure edge loops can border these common areas. This will be necessary for hiding the geo of the underlying character mesh at run-time, using a technique I will describe below.

When optimizing the mesh, it's important to remove unnecessary edge loops where the detail doesn't need to project onto clothing assets or the detail doesn't support deformation. You may notice the nipples were removed from the topology as they may only be seen in very few assets and projecting that topology onto most of the clothing would just be too time consuming and wasteful. Only add edge loops to areas that need to support deformation and where the silhouettes of clothing would benefit from that detail.

Character model by Chris Wells



Customization Asset Topology


In the following image you will see how the clothing topology mimics that of the body mesh. This is important for deformation consistency. If the body can deform fine with the existing skeleton then the overlapping clothing assets with the same edge loops, will usually deform the same. You don't want to have issues with the body tearing through the clothing and sticking out. If the topology was different between the meshes then you would likely have to add bones to correct for the tearing and intersecting issues as a result. This is not ideal when you are creating a game that needs to run as optimal as possible and extra bones increases processing time. Fixing visual issues with solutions that would hinder performance is not the best route to take.


Clothing meshes mimic the body topology



Character UVs & Mesh Hiding


The first uv channel is fairly standard as you can see here. The second uv channel is what we use to hide the faces of the body mesh. We first identified the common clothing areas and broke them down into subsections depending on the types of clothing. Next we generated uv shells based on those subsections and smashed the coordinates of those uvs to a singular value in the UV space. This coordinate can then be mapped to a game-side data file and referenced to hide when marked up with corresponding clothing assets. The material on the body skeletal mesh will have a technique that can then hide the triangles, or set them to not render when the coordinates have been flagged to be hidden.

For example, if the character is wearing a shirt, we would flag the first couple of coordinates being selected below to hide, ( U 0.1, 0.2, 0.3 ) Keep in mind the mesh assets need to be created so that the overlying mesh crosses over the edge boundaries, so that holes in the body will not be visible, when the body mesh faces are hidden.



UV Channel 1
UV channel 2 coordinates used to hide body mesh faces in game.



Customization Parts


When determining how complex you want your customization system to be you have to understand the amount of work you will be taking on. In Lawbreakers we did full mesh customization. This is essentially a mesh swap for each version of customization you want to have for the character. The creation is straight-forward to build as long as the meshes follow the conventions of the original character. The in game system is not complex at all, as it is just a mesh reference change, so the programming effort to implement this system was minimal.

For Radical Heights we decided to do a relatively basic "Paper Doll" setup. We researched the type of clothing we expected the character to wear and defined the most notable areas that we want to be able to customize so we could plan our asset creation accordingly. On the surface this looks easy to create for but it can spiral out of control very quickly from asset creation to in game implementation.


Clothing Boundaries

The things to be aware when creating the clothing, are asset parts that cross the boundaries of other parts and the volume/thickness of those assets. For example, if you create a shirt and pants with the same thickness and the shirt crosses over the boundary of the top of the pants, you will get an unwanted intersection. Determining how to create these assets consistently while avoiding these issues need to be decided up front.

Clothing Layers

Layered clothing, such as the UpperBodyArmor here, has to work relative to varying levels of volume/thickness of the upperbody assets. To correct for this instance, we have a morph target on the bulletproof vest mesh, that can be adjusted per upperbody asset at run-time. Addressing a singular asset in this case to correct an issue, works out far better than generating morph targets for each and every shirt asset. Always look for the cheapest way to solve a problem.

Clothing Materials & Draw Calls

Radical Heights can have up to 100 characters and the body mesh for the character already has three draw calls ( head, body and the eyes). For customization purposes we have separated out the clothing to specific parts, and each part on its own becomes a singular draw call, this means by default a character can be upwards of ten draw calls. This is not a great start, which means we need to keep the material count low for each clothing asset. We try to make sure they sure each asset has only a single material and two in the worst case.

Customization Fixes

When you have assets crossing boundaries or overlapping other parts you also have to handle how you want to deal with other crashing issues. In extreme cases we will hide the offending assets, large helmets will hide the hair parts. In other situations, in which we identify a common issue, we will create named morph targets to fix problems. Similar to what we did with the armor we will create a common morph target for each hair asset when a standard hat is enabled. This morph target will scrunch the hair down to work better with the hat. We cannot create a custom morph target for every hat asset, that amount of work and data loading would be ridiculous. Therefore, when we create the hat model, they fit to a predefined location on the head, so that a singular hair morph will work with every hat.


We did later determine that we wanted to have headbands for our characters to customize, as they fit the time period and aesthetic we were going for. This meant we had to circle back and create new morph targets for each of the hair assets to accommodate the headband location. This was an unknown initially but it was important for us to implement this specific data fix for each asset.

These rules for how hats, headbands and every other customization part can work together are important in defining creation guidelines. These guidelines are necessary to prevent data correction bloat from permutation issues. Understanding the volumes and boundaries for each asset is helpful to reducing these data fixes and ensuring compatibility with future assets.



  Character Skeleton


Radical Heights is an online Multiplayer game with up to 100 players. This means the character itself has to be fairly simplistic in terms of run-time complexity. The number of processing skeleton joints should be fairly small even at the lowest Level of Detail (LOD). The deforming corrective deforming joints start to drop off quickly as the character starts to LOD out. The twist and corrective joints are usually the first to go, ultimately leaving only the primary body joints, when deforming characters in the furthest distances on screen.

The supplemental joints here are comprised of joints used for IK hands and feet as well as joints only used when the character is in First Person/Aim Down Sights (ADS) mode.




  Character Rig


We continued to use Epic's ART tools, created by Jeremy Ernst, to construct the player character rig for animation. The tool set allows you team to hit the ground running with a fully animation friendly rig and accompanying animation tools. I use most of the rig construction out of the box with additional custom rigging on top to satisfy our specific needs for animation and deformation.


Shared Skeletal Mesh

On Lawbreakers we chose to have two separate skeletons for First and Third Person. This required us to duplicate the customization assets work done by the character artists and double the amount of data that needed to be loaded by a character in game. The fidelity of the assets had also changed enough to necessitate this choice for that project. However, the speed at which we needed to create assets and the bandwidth we had on Radical Heights, meant we needed to be a bit more conservative and efficient with our time in asset creation. By having a single skeleton for first and third person it meant we should only have to create the clothing assets once and the same assets could be visible for both perspectives in game.
I modified the rig and skeleton hierarchy to be able to handle both aspects for animation purposes. The core of the third person skeleton remains untouched aside from various supplemental joints for controlling the camera and upperbody pitching in first person. This is handled by the rig using a single switch that modifies the visibility of various animation controls and changes multiple constraints that affect the behavior of the rig.





  Character Animation



In First Person, the camera is positioned relative to the head location, so we need to move the head out of the way for animation purposes. In the animation file we just rotate it backwards. In game we also hide the faces on the head and parts of the torso, using the UV method mentioned above, to prevent the them from rendering in the players view.

Animation by Ryan Palser

Checking Animation with Clothing Assets


The pipeline and tool set I created to work with all of the assets on Radical Heights, allows the animator to view customization items in their scene and correct poses where needed. Not every item will work perfectly with every pose, but this gives the animators the opportunity to easily address some of the worst cases scenarios as they are bugged by our QA team.

Animation by Nick Maw-Naing



Coming up Next

In the next post I will be going over the customization tool used by the character artists to setup assets for export and implementation in game.

Part 2




Sunday, April 22, 2018

Fixing Mechanical joints For Rigging


For Lawbreakers we had a juggernaut class that featured two bipedal robots. The robots had a shared base skeleton hierarchy for animation purposes. However, they had custom joints to handle the visual differences in their armor and armor plating. In most cases the base bipedal skeleton worked just fine, but there were issues when the mechanical mesh joint visual pivots and the actual skeleton joints were inconsistent. We had a couple levels of customization and we had to make sure the joints were modeled consistently to make sure they would work with the rig and animation properly.

In the video below, I go over a process on how to correct the meshes for these issues specifically on the fingers joints.



The only thing missing in the video is the clean up of the temporary joints and freezing the mesh to preserve its new modified transform. Once that is done, you can bind the meshes back to the original skeletal hierarchy.




Tuesday, January 29, 2013

Building a Scripted Plugin Modifier for Game Characters

In response to  +David Moulder I have detailed a little more of our character "referencing" and scene building process, starting with our custom character modifier. I hope this is helpful.

All of our characters and animated objects have a custom scripted plugin modifier that sits on top of the character mesh modifier stack. It stores references to the skeleton and helper objects in the parameter blocks of the modifier. To store these object references you will see below the parameter type should probably be a #maxObjectTab type.  If you are looking for something similar to the message attributes in Maya the #maxObject parameter type, or what 3dsmax calls weak referencing, is as close as you are going to get. Paul Neale has a pretty good tutorial for weak referencing.

Weak References

I went ahead and wrote up some functional code below to help provide a basic understanding of scripted plugin modifiers and weak referencing. If you evaluate this code a new modifier will appear in the modifier list named "AnimExportTest".  It does not modify your mesh/object it is only a container for storing references and variables relative to your character.
plugin Modifier AnimExportTest
name:"AnimExportTest"
extends:EmptyModifier
 
--- The id here must be unique run genclassid() to generate a unique id for your plugin
classId:#(0x2c608fe8, 0x14804a99)
 
version:1
(
 -- set the file path parameter
 fn set_path &path =
 (
  local file_path = getSaveFilename filename:"C:" types:"Meshx(*.meshx)|*.meshx|ALL|*.*" 
  if file_path != undefined do (
   path = file_path
  )
 )
  
 -- add object weak references to the parameters
 fn add_bones objs =
 (
  for obj in objs do (
   -- this is how you create a weak reference to an object/node
   add_obj = (nodeTransformMonitor node:obj forwardTransformChangeMsgs:false)
   append this.p_bones add_obj
  )
 )
  
 -- object selection filter
 -- boolean check to see if the incoming object has what you are looking for
 fn bone_filter obj =
 (
  is_valid = True

  -- make sure the object is our type of bone
  if ( not superclassof obj == helper ) do ( 
   is_valid = False 
  )

  -- make sure object name has namespace identifier ":"
  if ( not matchpattern obj.name pattern:"*:*") do ( 
   is_valid = False 
  )

  -- make sure the object or object name doesnt already exist in our list
  for bone_obj in this.p_bones do (
   -- since this is a weak reference get the .node to query the actual object
   if ( bone_obj.node == obj ) do ( 
    is_valid = False
    exit    
   )
  )

  -- return bool
  is_valid
 )
  
 --- Store any variable,object references, export paths, values necessary to this modifier
 Parameters export_params
 (
  p_export_mesh type:#string   default:""
  p_export_rig type:#string   default:""

  p_bones   type:#maxObjectTab  tabSize:0  tabSizeVariable:true
  p_bone_names type:#stringTab     tabSize:0  tabSizeVariable:true
 )
 
 -- rollout ui creation
 rollout ro_export "Export Paths"
 (
  Group "Export Paths" (
   Button bn_export_mesh "Export Mesh" width:100
   Button bn_export_rig  "Export Rig"  width:100
  )

  --- Functions to set paths
  On bn_export_mesh pressed do (
   set_path &this.p_export_mesh
  ) 

  --- Functions to set paths
  On bn_export_rig pressed do (
   set_path &this.p_export_rig
  ) 

 )
  
 -- export objects menu
 rollout ro_export_bones "Export Objects"
 (
  Group "Export Bones" (
   MultiListBox lbox_bones "" width:140 height:20
   Button bn_add_bones "+" across:2
   Button bn_remove_bones "-"
  )  
   
  -- Update the rollout interface
  fn update_ui =
  (
   local bone_names = #()
   for obj in this.p_bones do (
    -- since this is a weak reference get the .node to query the actual object name
    append bone_names obj.node.name
   )

   lbox_bones.items = bone_names
  )
    
  --- Functions to add and remove bones
  on bn_add_bones pressed do (
   
   --- object picker dialog
   new_bones = selectByName filter:bone_filter
   if ( new_bones != undefined ) do (
    add_bones new_bones
   )
   
   -- update the interface
   update_ui()
  ) 
  
  -- Update the interface when the rollout is opened
  on ro_export_bones open do (
   update_ui()
  )
 )  
)

Custom Test Modifier
Custom Character Modifier
by  +Nathaniel Albright 
Our version of this modifier has many more methods, attributes and options for storing animation and other references. This is more or less the core interface for evaluating incoming animatable assets to make sure they are properly setup for animation and exporting when building an animation scene, as noted in my previous post.

You may chose to build a similar interface but rather than a modifier it can be a custom shape object that lives in your scene. It's pretty much the same thing just where it lives is different.


Custom Attributes & adding Assets
When adding an asset I will merge the entire scene and inspect this custom modifier to make sure it has everything I need for animation. If it passes the validation process I will collect a list of only the objects necessary for animation and delete the remaining unnecessary objects that came into the scene. Once I have identified the valid objects I will apply a "namespace" prefix to them based on the supplied asset name. I will then stamp additional attributes onto all of the valid objects to sort them and identify them as a unique asset within the scene. You can see my post on Tech-Artists.Org for more on custom attributes. Below is an example of setting the custom asset attributes on the incoming objects.

-- Asset Attributes
-- This attribute block should probably live in your library code
--- so that it is always accessible.
my_asset_data = attributes asset_data
attribid:#(0x6664296c, 0x5dec7a0)
version:1
(
 parameters asset_data
 (
  asset_name  type:#string  default:"none" 
      asset_id  type:#integer  default:0
      asset_type type:#string  default:"Character"
 )
)

-- Loop through all the incoming objects and apply the custom attribute

-- Apply attribute class to an object
add_attribute = custAttributes.add obj my_asset_data baseobject:True

-- update attribute data with your unique asset name, asset Id
-- and anything additional you need to track
obj.asset_name = obj.supplied_asset_name
obj.asset_id = unique_asset_id


A Bulk of the Work
Now that you have brought in a character asset into your scene in a clean and managed fashion the heavy lifting is done by your scene manager. Adding and Deleting should then become fairly trivial as your asset objects should be clearly identified. However, the swapping of your animated characters requires your tool to do much more in the way of saving animation, link constraints and export data defined in your scene. This of course relies heavily on your control rig system be it CAT, custom, or god forbid Biped +Brad Clark.  Once you have a proper save and load, swapping assets should become a "breeze". I will note that 80% of my Asset Manager code is handling the saving and loading of animation. You may find many cases where you have to do a lot of code to preserve the state of your animation in relation to other objects or characters in your scene.

Feel free to ask any additional questions. I will try to follow up.
Until next time.

UPDATE: Fixed some script errors in the plugin modifier. It will now refresh the ui when you reopen it.

Saturday, September 1, 2012

3dsmax Animation Referencing and Scene Building

Having worked on many game titles in the past its quite clear that scene building and having a way to reference or quickly update characters and rigs is very important. If you work in 3dsmax you are probably quite aware and envious of the referencing capabilities that exist in Maya. This functionality is clearly missing from 3dsmax and may likely never appear. Sure there are Xrefs but be my guest if you choose to use them and discover you don't get nearly what you need with the added benefits of instability.

So out of necessity I started work on what ultimately became our Animation Asset Manager ( AM ). The tool merges assets, Characters, Weapons, Vehicles, Props, Environments, etc. in a quick and efficient manner. Straight ahead file merging can result in a very messy file, as 3dsmax does not have native "namespace" functionality, and there may end up being a lot of object name collisions and rig linking errors. The Asset Manager handles all of these issues and bundles all of the incoming file objects into one "Asset". Now working in hugely complex scenes is quite easy as thousands of objects can now be represented as one Asset.

Adding an Asset
  • The artist chooses the asset type to add
  • Selects a file from a list of assets or locate a specific file on disk 
  • Provide a unique name to represent the Asset
  • Add the number of asset instances

AssetManager - Add Character Asset
What actually happens behind the scenes is a bit more complex. The incoming file is first validated to make sure it is export ready. If the AM finds everything it needs for that asset type then it will fully merge the file. After merging, the incoming objects are checked and objects unnecessary for animation/export purposes are removed, shaders are converted to standard materials, all objects are stamped with Asset Attributes, and finally object names and layers are properly namespaced. The attributes that were added to each object were done to easily classify the objects under one "Asset". When the AM updates it scans the scene and represents each asset properly by querying the object attributes. In the past I used very light-weight user defined properties but I have converted to custom attributes as these can be properly transported between DCC apps and maintained in the FBX file format.

AssetManager - Asset Objects


Swapping an Asset - Poor Man's Referencing
As characters, weapons or props are updated the animators need to be able to easily update to the new asset when necessary. Cosmetic changes don't always mean an update needs to happen but specific rig changes may require updates. Scene callbacks are put in place to verify animated assets in files are up to date in regards to explicit external file references that are checked on scene open. The AM ensures that these objects can be swapped and any animation existing in the file is maintained, this is where a great deal of the code in this tool comes into play. This includes full character animation, IK objects, morph animation, external link constraints and any other custom animations related to the asset. We employ our own save animation functions to handle everything outside of the basic biped motion to ensure keys and motions are maintained between potentially different objects. However, making sure everything transfers properly is reliant upon making sure all animated assets are marked up properly during asset creation, another topic for another time.

Weapon Updating
Weapons are connected to our characters in a specific manner and in the past allowing animator's to do this by hand resulted in inconsistent errors and issues between DCC app and the game. The AM brings the updated weapons into the file and makes sure the weapon's are aligned and linked properly to the character. Updating the weapons is just as easy as hitting the update button when necessary. The weapon is removed from the file, the source asset file is synced in source control, and finally updated into the current animation file.

AssetManager - Update Weapons

Demonstration Video
You can watch a demonstration of the scene building and swap process below. The tool and functionality was developed and improved upon over the course of a couple projects. It was used to construct animation scenes and cinematics from our latest title Saints Row: The Third

Animation Asset Manager - Randall Hess from Randall Hess on Vimeo.