[Music] all right cool so hello thanks for coming out to the TA boot camp hanging out for my talk which is honey where's my wingsuit the building just cause three animation and rigging pipeline my name is Brian vanevski I'm the technical animator at Avalanche Studios located in New York City where for the past three and a half years I've been working on Just Cause 3 now I'm gonna do my best within the next hour to cover a general outline of some major points of note as well as some specifics that are hopefully useful and interesting 3 Altis II just a bit about me and Avalanche to start on myself I'm originally from the Boston area and I went to college in Boston at Northeastern University the program at the time was pretty broad but I found myself really enjoying the rigging aspect of animation I dabbled by watching digital tutors studying rigs I found on the internet and dabbling a bit in Mel scripting my first job out of
college was working on a 3d visualizations for a combat simulator and that actually ran off an open source engine so I got used to game-like content pipeline pretty early on but a year out of college I was hired at 38 studios located near my home in Massachusetts and later Rhode Island my official game dev career began as a tech artist there a 38 studios at 38 studios I learned all about automation and pipelines while getting smarter and more knowledgeable with things like Python scripting and more advanced rigging techniques in the process I was at 38 studios until its very end where I then found my way into avalanche it was an avalanche where I got to take all the power and in knowledge that I gained at 38 studios to you and use that to build the pipeline that I'm about to present to you today for those of you that may not know Avalanche Studios has been around since 2003 where the first just
causes brought to life in Stockholm Sweden in late 2011 Avalanche expanded into the US and open up the studio where I'm located at in the Soho neighborhood of New York City New York City is the location where Jessica three was created and is the first and currently only game in the avalanche catalog to actually be predominantly created outside of Sweden not only do we have the Just Cause series but we have the recently released Mad Max game the hunter and Hunter primal renegade ops and a recent jump into mobile with rumble City a few quick questions who hair is actually played Just Cause 3 Oh quite a few who here is an animator how about tech artist or rigger working with animation teams awesome so some of you might know a little bit about what I'm about to talk about some of you might be completely new with it but either way I hope that I put something together that everyone can learn something from or at least that's interesting so for those of
you that may not know what Just Cause 3 is it's a massive open world sandbox there are tons of random characters from civilians enemies allied forces and some animals including cows which for some reason people love calves now of course this talk says that it's going to be about animation and reading pipelines but taking it past that what does this talk really going to be about what challenges do we have what solutions did we come up to solving shoes to break it down a little bit there was the transition of animation software that I'm going to talk about the transition of animation software was that we had motion builder as an initial animation software and we wanted to move that into Maya some pipeline building will go through includes character setup creation of rigs and solutions
fbx data handling and motion capture dialogue animation creation and the quick post-mortem at the end so to plan the pipeline we have to figure out what we have and why we have it while we have Maya we use that for character model skeleton rag doll and skinning weight export that would get streamed to MotionBuilder where rig was created animations are created and all of the animations could be exported out to the game so why do we have this pipeline now the team in Stockholm is actually a completely motion biller animation team any tools exporter rigs etc had motion builder support and no more both a techie animator and animation team in Sweden had been using using motion builder for years dating
back to I believe the first just cause definitely the second one and Mad Max used it Just Cause 3 started with the same pipeline as Mad Max but that team but the team in New York wanted to move samaya as that was built the preference and expertise of most of the team now Just Cause 3 is also a game that's both crazy over-the-top style our main character Rico is a sports car riding wingsuit flying parachute deploying explosion making son of a gun we needed a hand key pipeline that might provides to create much of this new content we were planning to have such as the wingsuit now what do we want and why do we want it we wanted to use my as our main animation package for its benefits with hand cute animation but that includes the graph editor and tangents Euler filters and easy to find scripts and tools on the internet such as comet tools which is an oldie but a goodie and a lot of other things that you can find on a slightly creative crash it's also a
little hard to capture mocap on something like a cow or a goat or a parachute or wingsuit so we really wanted to be able to hand key the animations for those things and make them look really organic now with this setup of using Maya for rigs and animating we would also need to make sure we can get our my animation content from Maya to just edit which is our editor however we still wanted to retain the features that motion builder does so well such as story mode a take system for comparing and blending motion multiple motion capture takes of the same animation together and pretty much anything that will allow us to easily and quickly stitch and blend together all animations without having to create or need additional tools so the first
phase of our pipeline was to set up an initial workflow that allowed animators to both work in Maya and still have and get their content over for motion builder so a simple question is what do we need in order to make this move well we need a Maya rig all of our animations are on motion builder native rig which at the time was F bi K since we were using my 2012 and motion builder 2012 the time F bi K stands for full body I K which is based off the human eye case solver we wanted to make an equivalent rig in Maya that would work hand in hand we also needed to transfer animation from motion builder to Maya motion builder uses a take system which is pretty much a container that stores animation data for objects in a motion builder scene now I mentioned before that it has built-in properties that
allow you to blend the animations together and easily compare multiple versions of the same animation say you have a run animation and you have five different versions of that run you could call the file run but each take would be run version one run version two our motion builder pipeline at the time was set up to be run with within the file run base run aim 90 left run aim 90 right if you were using additives the problem is motion builder takes aren't supported in Maya now at the time I showed up at avalanche we had about 1000 animations in MotionBuilder all sorting takes no as you can see here in this pitcher we had about roughly 40 to 50 animations in this idle the animation alone we needed to figure out a way to easily extract these one-by-one as separate files and get them into Maya we also have an in-house data format for animations so
we needed to get a custom exporting process working in Maya working the same way that we have in MotionBuilder so to the Maya rig when making our first iteration of the Maya rig there was an importance on time we really wanted to get in some I as soon as possible and kind of leave motion builder behind at least for the moment we were gearing up for production and we couldn't afford to waste much time trying to figure out new things in MotionBuilder while at the same time trying to build new content in Maya so we use the existing skeleton that we already had and since time was of the essence we didn't really want to take the time to retarget and fix any content which would be a huge headache at the time since we really wanted to get into Maya and any sort of skeleton updates would be done later it also made sure that we could get one-to-one transfer of animation and not have to
worry about any sort of returning we also built a rig with straightforward features and the basic needs for animating there weren't any bells and whistles and it was really important that the animators also had something functional and usable to do what they needed at the time the animators also needed to get used to be my again at the time in New York motion builder was being used for about eight to ten months the CEO had opened and other animators on the team had been using motion builder for longer at previous jobs using the same skeleton also allowed us to debug issues there are some issues on our rig that caused a little bit of undesired behavior in the game this Meyer rig actually allowed me to take a
look at some of the outstanding issues and able to debug them in Maya versus in MotionBuilder such as I don't know if it's easy to see on this picture but the middle spine here is rotated 180 and z-one issue that we had was that the spine was in one negative 180 joint orientation which would make the top spine have to get countered in 180 in MotionBuilder you would have to retarget or go through every single new animation with the FBI kay rig to actually fix any sort of skeleton that got screwed up like this now in Maya I was able to fix the skeleton between that and on the new rig since we kept the same joint position I could easily transfer the animation over and it would sort of fix itself on the way now we need to go back to MotionBuilder
takes in order to discuss our animation transfer process since Maya doesn't use them we chose to organize our animations one per file and use folders and naming conventions for things like additive animations to organize them now how do we get the takes exporter to single files while I was busy working on the motion builder of the maya rig rather another tech artist that Avalanche at the time help me by teaching himself some Python API within motion builder also known as PI FB SDK he also helped me along the way to learn this but this allowed us to find all of our animations and takes and physically cycle through each one while batch exporting them all as single files these animation files contained only a skeleton and baked down keyframe animation on that skeleton the single files were also completely stripped and cleaned of any artifacts and rig information these data files could actually be exported straight from the game or perhaps transferred to a proper
Maya rig now here's the main function that we use to actually transfer this animation over in Maya from that FBX export from motion builder what the script does exactly is allow the animator in motion in Maya to choose an FBX it adds the rig to a fresh Maya file with the FBX animation it constrains them together and it bakes that animation data down on to a Maya rig for good measure had copied all of the keyframe animation open the fresh new file REE reference the Maya rig and paste that all of this data back onto a Maya rig this was done just to ensure that we didn't have any unneeded artifacts or data that we didn't want inside the file now just to note we did later have a batch process to do all this but of course since time was of the essence we didn't have that right now and the animators would just need to import the motion builder files on an
as-needed basis now I also mentioned the custom format at avalanche for exporting and reading the animation data originally that export process was written in C++ and using a plugin that loaded it up in MotionBuilder that c++ was converted to Python and modularized so that there would so that there was a common core used to write our custom data structures and wasn't software dependent allowing us to write our my exporter and wrap up our animation data into the proper format in Maya the same way the motion builder side of things were done so now that we have a Maya reg the ability to move our current animation content onto this rig and a way to export our animation to our editor it's time to build a proper pipeline so let's take a quick look at character setup which which will provide the base for our rigging here we have a basic mesh and our NPC character skeleton
every character model we have has a file that looks pretty similar to this which is just the bound mesh and it's skinned to the skeleton this is the file that we used to export our skinning data model information and skeleton to the game from this the game knows our default bind pose it's also the same setup that we build our rigs on now each skeleton has an accompanying doll which we use Havok technology for the rat the ragdoll itself has its own file with the skeleton referenced in now not only do we use havoc as a ragdoll solution we actually use it for our skeletal data and animation as well we had a few hundred unique characters that needed to be bound skin and export it though so we had a need for a tool that allowed the character artists to take their created characters and quickly bind them with any resulting weights that were much better than the Maya default setting and in a level good enough to see and review those models in-game the binding a mesh
for export to just edit has a few strict rules one example in particular is that even if the joint has zero influence on a whole mesh such as a reference joint it still needs to be a known object to that model in game now most of you might be aware of Maya having the setting in smooth bind called remove unused influences we needed to make sure that remove unused unused influences was unchecked but a setting like that could easily be passed over so this tool sort of did that exactly for you and that basic mesh that we just looked at was actually an envelope mesh and is used to reference into a character file have its weights copied over to the actual mesh and then it would be unreferenced the result isn't quite 100% shippable skin weighting but it got us
to maybe 80% of the way we needed to be it was good enough so that arms legs torso and for the most part the rest of the body moved around as expected without any crazy deformations and skinny and polish wasn't nearly as bad as it could be now the tool itself also had a vert weight export import feature that was run using some Maya some Python API because of its speed benefits over commands or even though this tool also has the ability to see if a mesh has over hour for joint influence maximum on T verts and allow you to auto proven that to four influences or even just check to see if anything has more than four so you might say that it's just character skinning why do we actually need some fancy tools to bind well this is why if proper settings weren't applied when binding we ran the risk of running problems like skeleton and model mismatching it could lead to something that we dubbed in the studio as the mesh
monster of doom all right time to talk rigging we used an auto build system you built in Python using my commands now auto build systems are pretty par for the course in many studios today but hopefully the look into the way that we did it could be a little different than some of you are used to so we don't have a ton of unique rigs that a game such as an MMO or a MOBA with lots of characters shapes Heights what have you would actually need an auto builder was important to us do you through to the amount of iteration we plan to do and actually did and it also held to iterate quickly due to a small rigging team size now the bind post skin character models you just saw were that base that we built the rigs on as I had said each unique rig would get a build file which is the blueprint that would tell the system how to build the rig this is where our character would be set into a rigged pose or T pose at reference controls set up secondary
animation controls color build modules save the rig out if it's not in this blueprint file it's not going to be been the rig now all rigs use the same initialize and finalize process which is where groups and nodes are created to organize everything into a single top group in the outliner in any housekeeping and cleanup was done to neatly packaged your rig together also modules were being called by the build files were the same for each character cows could use the same leg as a human for example so I'm going to do my best to take a quick look at our build files for you with all this code and whatnot going on but let's break it down to a few pieces to actually try to understand it better to start the process we would initialize all our modules and classes that we'll be calling as you can see we called the build class first up at the top which would hold all of our base rig modules
such as armor leg we then start the build by initializing and adding a meta group in master node all right the rest of the modules are then called which are later used to create things like reference controls such as a root position arrow cameras used for visual reference in Maya which would include a follow cam made to mimic the player camera that you would see in game and deformers such as like arm twist helpers now that deform module is used to set up most of her secondary and helper controls used for corrective animation setup secondary was the simplest form and we've just created a simple control on something like Rico's harness straps in order to be hand keyed you could also add a driven note to the control if you wanted to or an expression instead of driven which would create expressions
and utility nodes such as multiply dividing clamp could also be created here this allowed us to create something where we could have the arm rotate up and say multiply that by a certain value to get a translational value of a help or join the chest I had a set driven keys command written up that was an easy way to create set driven keys by stating the value of a particular attribute of a driver and giving you the values and type of animation curve you wanted these were used when we wanted more organic motion to in our corrective joints and we're able to use tangents on the in and out rather than using expressions straight forward now to finish the process we pose our rig after all the helpers interactive were created and build the core base of our setup this included the torso head arm and leg and to note the arm and leg were actually built on their own iCade limb module and just inherited that class from that next we would add hands which
for Rico included five fingers and for NPCs included three fingers which was actually the thumb index and these three fingers as one feet would come next and here we give values for a toe tip heel in slot sides of feet for foot Bank and before finalizing the rig we could save it out at a face setup if we wanted to which for cinematic rigs was just pure FK and for in game was about a ten joint face with some one cool process that we utilize was a control spy file which was used to actually build custom controls / rigged the file was full of functions like this clavicle control and allowed us to create unique curves shapes and colors based on a perp on a per rig basis shapes could be created by hand and a script would be used to convert them into a point by point form which then we
could copy and paste into this file now you can see some of those unique curves between rigs here it doesn't matter if you're a human animal or wingsuit or even a cinematic specific rig every rig gets a similar build file animals such as the cow more similar to a human biped setup which get four legs instead of two arms and two legs the wingsuit doesn't use an armor a head of course but we still set it up create utility nodes set driven keys so forth and we finalize it in the same way same goes for the parachute now for anyone who's actually a max user I recommend checking out a talk from last year I believe is Richard Katz who spoke a little bit about max a max rigging pipeline that he had set up and there's a few essential tools that accompany our rigs I mean these are pretty standard as well for the course
our eye kfk match was able to do a single frame timeline or specified range of arms legs and spine whether we're going from an AI K or whether going from FK di ke or vice versa our parents Bay switching could do the same thing and would allow any bolt tools would actually allow us to multi select controls and run the same process on up to as many controls as you wanted to at once we also had a weapon constraining tool that would allow for quick placement of weapons and props if you're a civilian into the left or right hands or holster positions you could also choose to have a weapon fall of the hands in either eff care Ike a as well as have a weapon drive the IKr mitt self any setup could easily be deleted and recreated should you choose to switch it up now going back to the rigs themselves one really cool technique that we utilize in conjunction with our set
driven keys and expression notes was joint riveting two follicles if you're unaware of what a follicle and my is you can get it from creating a hair system and deleting the actual hair node you left with a small little red crosshair like object that has UV properties that allow you to slide it along the UVs of a mesh I'm not sure if you can actually see the little red crosshairs on that picture but you can use this follicle to Rivet or constrain any object to that mesh now on the right side there's a blueish mesh that is the duplicate of rico's jacket and reco being our main character in the game of Just Cause 3 this this driver mesh or this mesh rather is skinned just to the base skeletal joints of the character which is spine shoulders and arm these follicles were set up to cup and then follicles are set up to coincide with the joints setup for the harness of Rico which you can see on the left side now this driver mesh on the right thanks to
being skinned moves with Rico along with it the follicles and in turn drive controls and joints that we have set up with the harness now this was set up in a way that the harness controls would not only move with jacket but also have the ability for extra driven keys or expressions on top of that which helped create some nice subtle offset movement and fix problems like mesh clipping on top of it all you could still tweak animation by hand on the control itself so as you can see lifting the arms up the harness will move with the body saying goes if you twist the spine left right or back and forth also taking this ribboning one step further we used it to simulate a clot like look on the wingsuit now the wingsuit mesh was duplicated as well follicles applied for joint and here we
have the duplicated mesh in wireframe form with the follicles attached to it now for the wingsuit we took a sine wave to former and applied this to that driver mesh which could be keyframed with settings like amplitude and offset to create some really nice secondary motion to simulate when some wind movement on the wingsuit adding some driven keys created from extreme poses made by an animator and with just a few animation controls we get some great movement on the wingsuit and all of these cloth-like movements was just me playing around with keyframes for like maybe four or five minutes just remember this is all simple joint based animation on a skinned mesh there's actually no sim going on and if you think about the tools like sine to former or even go further like Bend wave deformers or using ncloth to drive it a mesh you can get some pretty awesome organic looking results with this technique well now
that we can build our rigs we have something we need to and have some oh sorry now that we can build our rigs we need some essential tools to go with them it's time to tie the motion builder back into this pipeline and get to that full circle that we talked about at the begin of the talk this was mainly done with the power of this tool on top there's the import FBX to Maya rig on the bottom there's export animation for motion builder you simply choose your target in the Maya animation or FBX you want to import or export and you run it to set up our rigs for the motion builder side we could build them in Maya thanks to its integration of the human I can plug in any human or biped skeleton was characterized before their respective rigs were built done thanks to the function here on the right we
ended up building not only our Maya rig after characterization but we built an H I K rig as well when transferring animation the H I K rig here on the Left would be imported into a fresh Maya file than the Maya animation on the Maya rid you see on the right would be referenced into the same file when importing the Maya when importing to Maya the result is an FBX animation transferred in baked down to our Maya rig in motion builder you have your my animation baked down to a human eye care rig now our I mentioned that the initial rig the animation team used was an FBI K which was based off the human eye case solver so using human eye kr H I K as I'll refer to it as wasn't any different for the team and for reference anyone who may not be familiar with the human eye case solver or rig solution H I K is a system that includes manipulation controls with the ability to pin them as if you're using an AI K control and Maya set to the world it is both a full body and body part Keane solution so here we
have a short run cycle on Rico and we will run that script it would bring that H I K rig in and we would get that animation into motion builder with and that's just the same exact animation mesh hidden so it's easier to see the H I K rigged for you so now that the animation has baked out onto our H I K rig the Maya rig would be unreferenced and we can open that up emotion builder as you just saw once the animation is in motion builder the animators can then edit this animation hub compare takes bring it into story mode stitch things together do whatever they needed to that motion builder provides all they we need to do is save this file out and then use that tool in Maya to import it back now we have a way to wrangle our FBX files and motion capture using both Maya and
motion builder it's just a quick look at our motion capture solutions we did use your typical studio capture for both cinematics and anak and in game animations we also had a really great in-house workflow using XM's technology and there's just a quick picture of me putting the suit on just a few weeks ago for anyone not familiar with X ends tech there gyroscopic motion capture suits that you can use at home in studio or pretty much anywhere people won't find it weird that a person in a skin-tight sent spandex suit is moving around like a crazy person now real estate in New York is not the easiest to come by so having something that we could use right in the studio was pretty necessary for us X ends proved beneficial in the fact that it allowed us to work really quickly and we can capture multiple takes and get pickup animations on a pretty quick moment's notice
now all of our motion capture whether it was studio created or exons created was easily brought into MotionBuilder for stitch and editing and then brought straight into Maya for some hand keyed love a human eye can not only allows us to bring our animations from Maya to MotionBuilder for editing and back to Maya but we reap the benefits of its retargeting properties as well our Rico skeleton had a different proportion in size from her NPC skeleton so if an animator wanted to take a reco animation and transfer to an enemy or rebel which is what you see here or a civilian the FBX import export tool could be used to do so as you can see this is an idle on Rico in the same idle on the rebel rebels a little shorter but we target over wasn't too much of a problem and all you need to do is actually choose the target character that you want the source animation to be applied to and then the reach and pull settings on the H I K rig would be set for the arms legs and torso and kind of lock them into
place now here are those H I K reach and pull settings if you're unfamiliar with H I K there's a H I K properties node that every H I K rake has and will help the H I K work the magic of retargeting now with this in mind let's go back to our initial reco skeleton that we had during the transfer of animation for motion builder now I mentioned we would add the bells and whistles later and here's the bells and whistles while the animators were working were busy working happily in Maya let's call it our transition to Maya phase well I transitioned to Maya rigor our new Rico rig was built on a completely remade skeleton this skeleton was a little taller included slightly different proportions than the existing one which was necessary and made for better
deformation than we had an overall look of animation was better as well we were able to utilize our nice moody targeter thanks to H I K which allowed this final switch from the old skeleton to the new skeleton all we had to do was run a batch of this retarget of the FBX import export tool onto new onto a rig in a new file and rename it out now having this dual Maya and motion builder workflow was a huge win for us and gave us that original goal of being able to utilize both motion capture and traditional hand keyed animation in a pretty painless way now we also had an in-game dialogue system that we wanted to set up with an automatic lip-sync process to drive animation now we actually achieve this using motion builders built in voice device now if you're unfamiliar with it
it is similar to face effects software and allows you to create automatically generated animation based off of sounds given off from audio files now here we have a face GUI that is driving our NPC skeleton and this is showing the frame pose one frame poses that we had created and created and uses additive animations this included things like melt open/closed melt narrow wide once the poses were figured out and set to sliders we got a typical face rig suitable for animating the face up setup was pretty simple for NPCs about 10 joints and even reco had the same in-game face set up it made pretty quick to iterate and work out the way sliders draw over the face as well as width and stay within memory budget when you start populating the screen with dozens and dozens of these characters now character phase is used to set up phoneme shapes if you need a quick
refresher here are some basic shapes phonemes are basically the sounds we make when we speak the distinguish words from each other and of course I'm also move and make different shapes depending on the sounds that we're making now character face is used to set up phoneme shapes characters face is actually a node within voice device in MotionBuilder that you use to drive the face using character face we would set up cluster groups in order to tell it what controls and nodes that we wanted to create the phoneme shapes with so for this each slider controls its own custom group was it was its own cluster group now after some iteration I decide on a particular set of phonemes that seem to work really well and tweak them using our slider controls now on the right we have the and FV sounds which are made using combination of a few sliders so there are different percentages of our 0 to 100 percent a WAV file is imported to
MotionBuilder and linked to the voice device this voice device picks up phony the phonemes from the wave that does its best at least and plays them specific as we specified in the character face the result is such it's really you hi I have your old race car tattooed on my back welcome home now lucky for me this technique was sort of piggybacked off of Mad Max the tech artists there sort of helped me learn his ways of doing this and it meant that we already had a batch export solution waiting for us to use to get all this animation out and it had the tech that would allow us to drive this in a game I won't go into detail about specifics but I was able to sort of hack and slash my way through the Python code that they used to make it work for our project as well essentially the batch process for this was a C++ plugin that these Python scripts would call it proved pretty effective and we
could get thousands of lines of dialogue patched overnight in the end we had around 13,000 lines of just English dialogue now the magic of this these animation files themselves with there was in game there was actually no animation data involved at all remember those face poses that we looked at they were used in conjunction with float data the rig sliders that drove the face were hooked up to specific float tracks these float racks were from 0 to 1 and they correspondent to one frame the one frame face poses the game would read this compiled animation which at that point was just a bunch of frame by frame data from zero to one and it would stream a corresponding animation file whenever the wave is triggered both named the same thing and blends together at runtime using these poses the great thing about all this that we're using the great thing is that because we were using all these poses to drive through data in order to create Rico all we had
to do is create new poses for Rico and the same exact wave fought and the same exact animation files could be played on him as well we didn't have to make another another new template just for him so quick post-mortem what didn't go so well for us I do actually feel like we had a lot more wins during this process than we did losses and great things to come out of the process as well so I'm only gonna bring up a few things here before we get into some of the things that really went well time okay yes lack of time is always an issue in game development but there are so many things that I would have liked to have done UI beautification was the first thing the tools I made were built using PI side as a UI and it's all default PI side buttons checkboxes etc I would have loved to given the chance to give them their own specific Avalanche flavor I
wish I could have used a lot more JSON and metadata to accomplish some tasks as well at the time I started building the pipeline I wasn't super well-versed on things like JSON and I sort of learned them as I went on and looking back I wish I knew more about them before the process started if you don't really know much about JSON or using metadata to drift drive animations or within rigs definitely look up those two topics and obviously more rig features by the end we definitely had a solid rig that animators could use to create everything they needed to but there are also a handful of things that we wish we could have gotten done and added to the rig within that time but on a positive note these will all be good learnings for the future another thing that didn't go so well was the aftermath of retargeting Rico human iCade did give us an awesome way to create our my emotion builder dual workflow and allow us to retarget but
when we went through the actual process of retargeting Rico it proved to be a nightmare at some points we did manage to completely remake Rico skeleton and it was necessary but it did add a lot more time to actually having to get these animations into game without bugs the animators did spend a lot more time fixing poses for animations and I also had to go through and after a full bath these animations chase-down animations that weren't checked in to perforce and we're kind of living locally on other animators computers so in the end everything kind of worked out but chasing these things down fixing these things up took a lot of time so if you can avoid having to actually retarget animations onto a new skeleton I would completely tell you not to ever try it or think that it's going to take less time than you want it to
so what went well though well we accomplished our main goals we didn't really shoot for the moon we made our major scripts and tools that were created and we made them as needed so there were a lot more tools that I didn't get to show you just due to time but we had a full range tool set that really helped us get our work done quickly and all of these tools were just created as we needed them we didn't kind of make a tool hoping that they would it would be used by an animator or somebody else we made it when somebody said they had a need for it working closely with the animation team it was really important for me to sit down with the animators and actually see their issues or talk about a new rig feature I wanted to be hands-on as much as possible I didn't just want to take requests sit in my corner and figure out the best solutions on my own our animation team was always looking to learn how and why tools and rigs work the way they did and
it was really fun working with a group that was so ambitious and willing to do more technical related things the knowledge share with the Stockholm team most importantly the tech animator on their project was awesome not only was he on Mad Max but prior to that he had worked on Just Cause 2 as their tech animator there was some really useful tech such as the dialogue animation system that you saw in other things that he always was happy to teach me or answer my questions on and even though we had that six to seven hour time difference at times he was always there to answer my emails within the day or even get back to me right away if it was at night time for him now Maya went really well we were able to use found tools and we actually had an animator who owned our third-party toolset deployment that was separate from all our other in-house tools this way animators could gather find new tools and I wouldn't have to worry about
taking the time to add them to our toolset we utilized a lot of outside tools but one tool of note was actually studio library it's made by the creator of advanced skeleton and it actually allowed us to have a pose and animation library that was super robust and very production ready for us at least didn't have didn't make me have to take the time to actually build a full-featured pose and animation library now also managed by the animator for animation team scripts the animators actually took it upon themselves to create their own Mel scripts for processes that weren't too involved since I was busy working on sort of bigger picture things it was a huge time savings and I was pretty impressed by the scripts that they actually came up with it was super helpful and super awesome that they were really that ambitious and just the note before I conclude come say hi we're recruiting this week and hiring actually we have a number of positions open in
volt near New York City and Stockholm we need lots of programmers we have a few tech artist positions open even and I should be there midday between Wednesday and Friday if you specifically just want to come say hi to me oh and rather I should go back to that slide because we are booth CC two one two four now quick thank-yous thank you - Fred who perform use his slide templates I completely stole them off of him check out his talk on Thursday he is speaking at 11:30 in West Hall 2020 it's all about the VFX in Jake jc3 so all those sweet explosions and a lot more will be covered by him also a meal person a program in our Stockholm office oops a male person a stock programmer in a Stockholm office is speaking tomorrow at 3:30 if anybody here is interested in dx12 stuff that talk is also here in West Hall at room there 3007 just want
to thank the animation team and fellow T is that Avalanche again they were super awesome and I can't really say that enough thanks to you guys for coming out to the boot camp and just to remind anybody who plays Just Cause 3 sky fortress DLC came out today so you should probably go get that when you're home at GDC play some sky fortress it includes the vivarium jet pack on the wingsuit so you can jetpack yourself around plus wingsuit I guess the coffee break is coming up now so feel free to approach me if you want to ask any questions that you don't want to necessarily ask here and there's so much more I wish I could have like talked to you guys about that I was constrained for time so if you have anything you really want to know in terms of my pipeline or what we had at avalanche like please approach me I'm happy to talk so yeah time for Q&A if anybody has questions I had a lot of helper joints on that
skeleton did you bake all that animation out in the all had their own animations in the game engine or did your game engine had equivalent help her joints running in real time the question was baked down helper joints do we have that in game or was it all baked down and exported out it was actually baked down and exported out we didn't have any runtime features in our engine okay and then are you you're blending all those animations together did all the helper joints blends okay or did you have any issues with that yes for the most part everything did blend okay there was some issue with going in to save like ragdoll yeah it actually it wasn't awful you know it still came out okay but yeah it wasn't able to sort of twist the arm joints right if he went into ragdoll yeah yeah that was one issue that we did have thanks a lot man yeah you said there were more features you would have liked to implement into your rigs could
you give a couple examples one in particular that we had talked about to help sort of creating additive animations that I would love to implement in the future if we get the chance to was actually our animator one of our animators kind of built a set up for me and I had looked at it with him would be to have a master control that you could say create an animation where you would point say two revolvers ahead and be able to just rotate one control and sort of bring the entire body up with like a nice sort of fall-off very similar to I guess the way like a motion builder type rig would work but just more features like that that would allow animators to instead of sort of have to rotate the spine back and bring the arms up just one big master control that would allow them to sort of twist the body and bring it up to create sort of 90 degrees up or 90 degree left or right sort of additives thank you yeah hey yeah you mentioned studio library is one
of the maya tools that you guys found really helpful is are there a few off the top of your head that you think we're super awesome to have around as far as maya tools and the question is I mentioned studio library are there any other tools that I would recommend check out red nine red nine is really impressive as created by a guy named Mark Jackson there's a bunch of animation tools in there I'm actually looking into using it for metadata right now because it's it's super robust and there's actually even an animation binder in there and if you look up Mark Jackson masterclass he actually goes through retargeting using that so that's another retargeting option as well but red nine is certainly one of the tools I'm looking into right now thank you hi just curious what your experience was using Havok I don't know how much like knowledge the team had especially tech
artists and basically we're using it now and it's a lot of like emailing support and figuring it out by looking at demo projects yeah the question was what our experience was using havoc I myself didn't use havoc a ton I mean I used it to create rag dolls export them export skeletons out but we actually had a really close relationship with havoc and we used it for all of our just destruction as well so they we kept a pretty close-knit relationship with them and I pretty sure that any of the guys working on the destruction stuff had a really good like back and forth with them yeah thanks mm-hmm else all right thanks guys [Applause]
Auto-generated captions from YouTube — names and numbers may be misheard.
Game Developers Conference · 2026
Game Developers Conference · 2019
Comments