Tech Art in Tamriel: The Elder Scrolls Online's Character Tools and Pipeline

[Music] you hello I'm Richard Katz and I'll be speaking today about the character pipeline I worked on on at ZeniMax online studios for the Elder Scrolls online I'm gonna talk in detail about the character rigging pipeline in the rigging tools the animation tools and I'll wrap up the talk with a short post mortem from my perspective as a senior technical artist on a team of well over a hundred developers I'm going to compress six years of development into about 60 minutes so it might go a little

quick and yeah in contrast to the quick development cycles that Louise and Brian talked about earlier today this is a quite a long project that I've been on first let me tell you a little about myself I received a bachelor's degree in fine arts from the college of new jersey I started in the games industry in 1997 over 17 years ago back then it wasn't just it wasn't enough just to be a competent artist he also had to be a fairly competent with some of the technical aspects of game development as well my first industry job was at Sierra online working on the MMO middle-earth online I worked at the Oakhurst studio for about a year and a half until it was shut down I was a 3d generalist I touched every stage of a character from concept to game I was doing concept model you v's texture skinning animation and technical art we were working in 3d

studio max version 2.0 and the first release of max script and I built a layer system that max did not include back then max didn't have layers in version 2.0 and a sprite rendering system that cut times for getting a character from max into the game from 8 hours to 30 minutes my second job was at the 3do company in Redwood City California where I worked on three Might and Magic titles Crusaders of Might and Magic warriors of Might and Magic and shifters the parenthetical of Might and Magic since it was a secret warriors I started at 3do doing more the same thing I was doing at Sierra concept model you v's texture skinning animation and tech art within my first few months there I was promoted till I was promoted to lead artist where I ended up doing a lot less character work and a lot more of everything else UI design and scripting particle effects

and scripting and I was managing a team about between four to eight artists plus outsourcers most of what I've done since 3yo has been character technical art over the past 11 years I've worked at z-axis visual concepts secret level and ZeniMax online of those eleven years five of those years working in maya and six years working in 3d studio max some of the titles i shipped over that time x-men the official game Fantastic Four rise of the Silver Surfer and Iron Man but I'm here to talk to you about my work on the Elder Scrolls online Elder Scrolls online or ESO is a massively multiplayer online role-playing game MMORPG or just MMO for short ESO is a progression to online from the popular

Elder Scrolls single-player RPG series from Bethesda Softworks it's pathetic game studio Elder Scrolls 3 morrowind Elder Scrolls for Oblivion and elderscrolls v skyrim skyrim came out during ESO production I started working on ESO in 2008 and the game shipped in 2014 after numerous style and design revamps ESO is an MMO massive is the operative word here we had 10 playable races multiplied by two genders mostly variations on human or elf we also had two Beast races the Khajiit or headed humanoids and the argonians or lizard headed humanoids so we didn't have a huge variation in playable race Anatomy but we did need to expose to the players a system for customizing their playable characters physiques and faces we had a

very ambitious 90 yes 9 zero unique monster rigs some of those rigs had as many as 4 or 5 mesh variations these humanoid monster rigs were built on a custom rigging system and toolset we had been established as a 3d studio as a 3ds max studio but most of the animators came from a maya background early on we wanted to avoid using biped as an animation framework so we built proprietary animation rigs and tools which evolved over the first few years of the project there were several major limitations from tech we needed to render up to 200 players on screen in our player-versus-player battles so the

characters needed to be a single draw call each for most of the project DirectX 9 was our minimum spec so every conceivable potentially movable parts on a humanoid character needed to be influenced by 77 bones or less and there would be no LEDs either geometry or skeleton every different worm the formal part had to be accounted for in the 77 bone limit hair loincloths tail shoulder armor eyeballs weapons tassets etc originally monsters and NPCs were going to be limited limited to 56 bones but that constraint was removed pretty early on and everything was allowed up for the 77 bone limit we were tied to 3ds max 2010 for the entirety of production 3ds max has no useful referencing for animation there are two referencing systems in max but neither one is suitable for character animation xrefs either replace your

animation controllers with an xref controller for merging copies of source controllers with no updates and no hierarchy changes possible containers still seem like a work in progress and in 2010 I don't think they've been updated much since they were pretty awkward to use with animated characters so we needed a system that embedded rigs in each max scene and that could be updated via batch was a couple major disadvantages with this custom animation scene setups get blown away when a rig is updated and embedded rigs and scenes easily become out of sync with latest master rig for a character one animator Dave Sunita authored a rough animation rig before I was hired which we used as a starting point and that's what I just

said the 3ds max scene that contained the rig already had acquired tons of cruft cuz our whorfin custom attributes unused materials and animation controllers one thing max is good at is accumulating this cruft but it's bad at allowing you to clean it out once contaminated so from the start we knew we needed a way to build brand-new rigs and fresh uncontaminated scenes I started by just disassembling and scripta fiying the rig I broke down the animation rig in the modules base torso legs arms hands head robe and cape and tail at the same time I created a template skeleton guide rig a skeleton with freely movable joint locations the guide rig could be saved out to an XML file and rebuilt in the scene from the XML

file each module in the animation rig then built along the guide rig locations once the initial generic humanoid template rig was set up rigging any humanoid was as simple as duplicating the template skeleton adjusting joint locations clicking the build rig button and then skinning it about half the animations in the game about five thousand out of about ten thousand we're authored on the standard humanoid rig for player characters NPCs and some humanoid monsters on the surface it's pretty easy to sit down and start animating with but it has a deep array of options baked into the basic rig or spine only had two bones because of our low bone limit it was FK only it had options for rotational space switching to the parent body or root you rotate the abdomen and the chest could optionally main follow it or maintain

its orientation relative to the hips or the world we also had switches on many controls in the rig so the animators could animate using Max's TCB quaternion controllers instead of the rigs default Euler XYZ controllers the head defaults to an aim system but it can be switched to animated in FK or it can be switched to and made in FK in aim mode we have an auto neck that inherits about half of the heads orientation the auto deck has an XY switch for forward-facing necks in the case of humanoids with extremely hunched shoulders or quadrupeds the eyes have independent look at target that can follow the head or world in an FK override the head aim and head and neck FK controls have space switching and oiler quaternions switching like the torso our legs Rik only but that generally

wasn't a problem the foot control could be switched from root space to body space in the case of character needed to leave the ground we have a hip fudge control to tweak the femur and hip joint the foot has a bunch of driven attributes roll at ball heel toe tip a twist with a sliding pivot and a few different tilts the arms were built with fake FK the bones thought they're in I K at all times but the FK hand control was an IKE a control that was a child of the forearm control as was the elbow pull vector control when we switched to AI kada bones constraints would blend between different sets of controls there's an AI k FK snap built-in custom attribute on the wrist config node like other modules the arm controls have space switching an euler quaternion switching the hands have two layers of finger attributes a set of meta properties and a set of finer per digit properties all the keyable channels lived on the config bar but had some

two-way wires so that we could so they could be posed in the viewport as well we used Paul Neil's pen attribute holder on the config bar it made it easy to bake safe poses into the rig at Build time for most of the project our player characters were going to be able to equip capes so our rigs had a cape module the tails for the Beast races were originally going to just follow the Cape animations then we added mutually exclusive tails so a character could either have something skinned to the cape bones or the tail bones but not at the same time with the capes unlocked from the tails we still couldn't move the capes very much because we still have to support weapon docking on the characters backs eventually we cut capes to reclaim some texture Atlas space for high resolution weapons in first-person camera view but our tails are still driven by phantom cape controls in the rig they have some

space switching to follow excuse me follow the back or pelvis depending on whether it's a cape or a tail there's also an eye camo for the Cape but I don't think it ever got any use from the player animations one feature that did get a lot of use is a procedural wave settings to drive a looping sine wave like motion with a couple of sliders as any self-respecting RPG does we have robes and dresses unfortunately we have no game side simulation so and we only had four bones allocated to the robe the animators basically just wanted it to stay out of their way so a large majority of the robe animation was driven automatically by the leg motion then the animators could clean up any outstanding issues with the FK controls that sat on top of the automation this is how we ended up driving the rope one bone in the front between the shins one bone in the back between the calves and one on each side

of the lower legs the front and back bones maintained a position between the lower legs oriented to the plane between the lower legs and forced outward when necessary to preserve volume the side bones then slid around the calf centers to maintain volume there the actual lower legs themselves weren't weighted to the robe geometry weapon controls can be docked at several locations on the characters back in hips and there's an eye case system built-in built-in to plant the weapons on the ground but humanoids weren't the only characters in our game The Watcher is a take on the classic fantasy beholder character a giant flying eyeball but the Watchers most obvious feature are its 15 arms three main arms with leaf like mittens for mid-sized tentacles and eight smaller minor tentacles the main

arms had independent controls for FK ika and could also be driven procedurally with the same system we used on the humanoid tails the middle tentacles were driven mainly by the ambient procedural motion with an FK layer on top to refine the motion and fix collisions the eight minor tentacles were all driven by a single set of procedural settings with a phase setting to keep them all different different shapes at any given frame and of course like the mid sized tentacle the minor ones had an FK tweak layer on top as well we had a sneak module that we used for various creatures a plain old snake critter a giant snake monster like pictured that had a torso section that'll we stay vertical an ice Wraith that looked like a flying snake skeleton that sort of swam through the air and two different Nagas like monsters the two armed Lamia and the four armed harvester it took a lot of iteration to

iron out the kinks and the snake rig there's a spline iko unday thing but Max's spline ikj just has no consistency for up vectors so I only use the position position from the spline iCade to drive the ore and drove the orientation with another layer of helper nodes but it was easier to flip those as well when they look at targets turn 90 degrees on any axis so we ended up subdividing the chain by adding more point helpers constrained between the bones on the spline I K so that we could twist the controls at least 360 degrees before the bones started flipping when our second winged demon type character came up the animator working on it showed me a God of War three behind-the-scenes video on YouTube the rig featured in the video was for a Manticore the wings on the creature had a single master billowing control that drove the shape of the wing membrane I built something similar for a wing rig

but the wings on our gargoyle and grievous Twilight characters only had about 40 polygons so the results weren't as awesome as they could have been we ended up with two different kinds of quadrupedal eggs predators like bears wolves and cats have four legs with pretty short hand segments the majority of the limb is humerus and forearm forearm the module we used for those had an IKE a chain from shoulder to wrist like similar to a biped hoofed animals tend have much longer carpool or tarsal segments and their knees sometimes don't even come below the bottom of their torsos three or four bone I catch aims are unpredictable and Max at least so the solution I used for these kinds of limbs incorporated to Bonica chains into a larger hole the module for those limbs and some predator hind limbs had a nike chain that started at the knee and ended between the carpals and phalanges the wrist or ankle was in the middle of the

chain the thigh then had a tog toggleable aim toward the iCade control on the ground there was a neat weak control to get some specific shapes and stretch the leg a little bit which the animators tended to abuse quadrupeds torsos could switch between ika and FK depending on the shapes the animators wanted to achieve in an and in animation the body route defaulted to a position near the center of mass but could slide up and down the length of the torso so it could pivot anywhere from the neck to the tail the rig's themselves are the products of a suite of tools authored to create and edit the rigs the pipeline looks something like this a master xml metadata file that contains the locations of each character specific data relative to itself the master files called rig build that xml

each character had about 10 X and L files and one clean machine just the meshing of cruft when we build a rig it looks up the character in the rig build metadata file and finds a character's rig config file which tells us what modules to build for that character for instance we'll build the guide skeleton first the config file will just say yes build the guide skeleton the scripts look up the location of the guide skeleton XML and the rig build meta file and then runs the guide skeleton XML through some scripts that build the skeleton in the scene then we go back to the config file to see what other modules to build for this rig look up the location of the XML data for each relevant module and build the module from the XML data after initially setting up and building a rig once the rig could be constructed from these few components in just a few seconds this is

the tool we use to build the rigs the character list is built from from the rig build that XML file and when you select the character it loads character specific rig config file that can describe is what what to build for this character which modules to build the left pane is a list of rig modules in our library and the right pane is a view of selected characters rig config.xml telling the tool which modules to build when we click build the tool collects a list of modules for this character to build for this character and sends the list to a max rip function that builds each module in order along the guide skeleton and when it's done it deletes the guide skeleton this is a simple max UI floater for editing the guide skeleton also known as the proportion skeleton it builds and saves the guide skeleton and has tools for mirroring location locator positions aligning locators and globally scaling the rig via translation it has some

editing functionality but we always just added joints in the text editor position the joints in Max and REE save the XML it also builds and saves the mesh skeleton to verify hierarchy and for editing additional export data so we lay out the skeleton set up the rig code additional bits if needed and build the rig some nodes get automatically placed in layers and sets but many don't so we sort all the nodes into nicely named layers sort controls into various selection sets and adjust the size and location of any controls that are hard to see now we want to save all that sorting and cleanup so we don't have to do it ever again that's where this tool comes in but unbilled rig tool it shows another view of the characters XML files from the rig build EDX and Olmedo file it has perforce integration so we can check out files click save and resubmit them now the rig is built and we need to

skin the mesh to follow it some monsters only have a single mesh and that's it some have multiple mesh parents and our dynamic characters are playable races and other humanoids there there are a whole a whole nother level of crazy the main interface for the skin weights here shows visible geometry in the scene and will tell you at future mesh has a skin modifier and shows you each each weight files per for status after we've skinned the mesh this panel lets us save the skin out to an XML file with weights per vertex it has per force integration and we can sync at it adds submit and revert the weights and XML files right from the panel when we rebuild the rig assuming the mesh doesn't get updated the saved weights file will get applied to the mesh and that only works if the meshes vertex order or vertex count don't change however the weight file also contains enough vertex and face info to

rebuild a facsimile of the original mesh when the mesh topology has to change we use another mode in this tool to get the old weights onto the new geometry the tool rebuilds the original mesh from the saved XML skin weights file and loads the per vertex weights onto the new temporary mesh it applies Max's skin wrap modifier to the target mesh interpolates the weights from the source to the temporary mesh and then converts the skin wrap to a skin modifier then it deletes the temporary mesh now we can clean up anything that didn't transfer from the skin wrap well and resave the xml with the correct per vertex weights that was what that slide was like most games we have a four influencer per vertex limit on skin weights I don't like to work with the skins preset to a four influenced limit I leave it at the twenty influenced default because I don't want max to automatically remove influence as well as I'm working so I have a weight cleaner utility which

removes weights below a threshold and removes the smallest influences above the limit of for our dynamic character part system allows players to wear a huge assortment of mixed armor sets so the geometry is broken up into body parts eight for the basic body that's torso heads upper arms lower arms hands upper legs lower legs and feet another half dozen deformable clothing bits each of those had about a dozen variations per gender at launch but we've had a mandate since launch to add more silhouette variation in the armor so we're up to about thirty variants on some body sections now on top of that we have a metric ton of hair and adornment variations and dozens of rigid armor attachments for all of this to work we needed to synchronize the seams between all these parts skin weights and vertex normals the normals needed to be contiguous for shading purposes and Max has poor support for vertex normals in general

the base editable poly doesn't have any support to view or edit vertex normals max traditionally derived vertex normals from its face smoothing groups the editable poly does support vertex normals though but you need to edit them in an edit normal modifier Coletti then collapse it down so our copy normals tool needed to apply edit normal modifiers to the source and target meshes copy the normals and then collapse them down back to weights the dynamic character meshes actually each have two sets of weights the animation skeleton bone weights and the second set of weights for customizing character's body shape and facial features both sets have to have their seams match up exactly every floor arm had to have the same exact weights where it meets the upper arms and all the upper arms had to have the same exact weights at the forearms at the same scene we created a discman templates of scene locations to

apply weights to multiple targets at once every studio I workout I end up creating a variation of this tool to do batches and max or Maya scenes it takes a list of files a chunk of Max script code to run on each file with an optional resave after the script executes it runs everything through a try-catch construct to avoid batches ending prematurely and saves out a log file with success or fail results to review after long batches we ended up doing a lot with Max's custom attributes but max doesn't provide much for viewing or editing the contents of a custom attributes parameters this tool recursos through each object and modifiers unless his view or edit data we can directly enter values for simple types or elements of complex types like vectors or matrices and pick objects for max object tabs and it automatically inserts node transform monitors for weak referencing it can grow or shrink parameter tabs to

we also have a suite of tools that face the artists and animators the pipeline started simple and there was never time or reason to expand it much further later the users would just add a startup script path in three studio max preferences it was a single startup script in the target path and it built the tools menu that's in max at startup and that was about all there was to it the tools all ran from network path I would develop them in a source controlled local folder and push them to a user run network path when they were ready the toolset didn't have any dll's or other binary components so we never had any network access conflicts the coolest thing was that I could fix bugs and update scripts on the network and then the artist couldn't rerun the tools from the menu and see the updates without even needing to restart max the animators use this tool daily the

animation transfer panel it allows the animators to update rigs in single scenes or multiple scenes since our rigs have to live in each max scene and it wraps up that wraps the functionality of Max's xaf or XML animation format but with additional custom data that this tool packed into the xaf files per for status is integrated into the UI so animators can see what's up to date or who has what file checked out at a glance and they can sync and check out Max and xaf files the rigs have data-driven display panels for toggling visibility of controls in the rig they were designed to take up as little screen real estate as possible it's offered as an XML file and that file was encoded and stored in the rig when the rig is built the panel interprets the encoded data and it constructs the panel on demand the same tech is used for other panels for visibility of mesh body parts and for director George F it trajectories the animators use a pose

tool to save load and mirror single poses the poses are saved in an XML file the tool has options for working in world space or local space whole character selection and has perforce integration to show the status of the post files and sink edit and hit them into the depot 3d studio max has animation layers they were introduced around max 2009 but for my first 6 months on the project we were working in max release 9 which predated the animation layers we use Max's freeze transform system to create zero default values on controls it's a macro script included with max for many years it creates a list controller on the position and rotation tracks and stuffs the current transform into controllers at the first index of the list labeled frozen and then creates new controllers the second index labeled 0 and sets as default in Maya I would just build up a hierarchy of empty transforms however

our tools made assumptions about this frozen transform list controller paradigm when controllers when animators needed to use animation Max's Anna when Adam where when animators tried to use Max's animation layers it would collapse everything blow away the frozen transform list controllers and break our rigs and end tools so we brewed up our own version of the animation layers that respected the freeze transform list controllers the animation layer system kept track of additional list controllers and layer membership via an XML file embedded in a single string property on a custom attribute collapsing the layers work per key from keyable at refer cable tracks and distributed the values as one would expect but since they were just moralist controllers animators could replace default layer controllers with non cable controllers annoys controller for jitter or position can straight to fake a hand holding a character's head then the animator could bake the results down into keys if they wished the animation

transfer panel needed to peek into xaf files during load read some custom data into the from the file to see if there were animation layers in the saved xaf if there if there were it would need to build out the additional animation layer controllers before loading the animation data into the rig the dynamics panel was originally created with the intent of breaking characters with three studio maxes have a reactor dynamic system it allowed the animators to group rig into separately definable sets of animatable controls to keyframe independent of hierarchy and then blend to and from the normal grig behavior ultimately it did see some creative uses but mainly for keyframing instead of reactor dynamics our tools weren't tied to specific object names but they were tied to specific set and layer names which were also which were shared across all rigs if you merge in objects from another file in 3d studio max layers

with the same names get combined and selection sets don't merge at all the namespace tool let animators define a mile like name space for up to four characters in a single scene it switches a character out of namespace mode so that it can perform tool operations like low to save animation or export it was a little clumsy but was a quick solution around system X to systemic problems and the tools and rigs that would take too long to fix 3ds max is built-in ghosting only ghosts the currently selected mesh and the options are only accessible in a tab in the preferences the ghosting tool allows for color and alpha settings interval settings forward or backward ghosting and of course any specified mesh it uses it uses 3d stream access point cache the modifier which is surprisingly Responder surprisingly responsive with five to ten meshes I mentioned earlier

about our built in parallel oiler and TCB rotation tracks on many of our rig controls this is a tool to convert the Euler to quaternion and vice-versa either one to one key conversion or baked out a key per frame of an animator found weird wobbly Euler gambling and something they've already animated it's pretty easy to convert a time segment to TCB keys and smooth out their arcs our character team had a subgroup devoted to character customization one of the character ARS gave me a specifications for a rig to allow the other customization artists to sculpt body and face shapes I worked the rig into our pipeline it gets built just like an animation rig even though it has a different set of requirements and a different user base our character artists are good at what they do but on average they're a little more tech

phobic than the animators so their interface for the customization rig tries to support them with a ton of callbacks to make sure they're working in the correct pose in a rig and make sure they're not editing poses with Auto key off the customization artists work on the rig in local Maxine's and save out say about single poses to be merged into a master customization rig the UI synced scene control selection with label buttons and shaped buttons similar to the animation rig display panel the layout is authored next in an XML file encoded into the rig at Build time and then rendered by the panel when it's opened we made extensive use of 3ds Max's custom attributes in the animation rig at its simplest there maya like animatable user defined properties stored in a parameter block max then lets you embed user interfaces to interact with these user-defined properties but it's all max script so you can embed some pretty complicated functionality into these custom attributes and they live in the rig so

that makes them extremely portable I told you this was going to be a post-mortem we made a number of decisions during the course of the production that worked out pretty well the ringing system was for the most part data-driven we used XML as our data format 3ds Max's integration of dotnet made this easy everyone has system XML on their computers Jason might have been a better format for data but it would have meant distributing additional dll's to the artists it's easier to do perforce merges on text data files over binaries or even over code as I mentioned earlier we used one big metadata file called rig build that XML which is a huge file containing a flat list of characters with sub sub element pointers to character specific XML files everything

in the rig was broken down into text-based data descriptions XML files describe their skeletons layers sets skinning poses animations and where to find all that data looking forward it might be beneficial to abstract this data a little further and have the file point to character specific meta files and containing the sub element file locations for each character it would make it easier to find what you're looking for in a smaller file in this one including vertex and face data in our skin files was pure win though there is there is enough information to recreate original meshes and skin wrap to updated topologies one of our tech artists recently used that data to allow customization artists to preview part meshes and max while they construct new armor parts in the future we might add morph mesh data like UV Zoar vertex normals to totally remove the dependency

on clean mesh living in a 3ds max scene but I think we'll probably end up moving to the data over to FBX to make a future switch to Maya easier there are two types of artists the ones that give way more feedback than possible to respond to and those that bang their heads against the tools and sound frustration the artists that provide feedback are the ones that help make the tools and rigs better for everyone no tool or rig is perfect and some requests are ridiculous but listen responding and prioritizing is important we can't fix tools we don't know how frustrating they are to use in a perfect world the technical artists would be using those tools too but schedule constraints caused us to happen far less often than desirable there's also two kinds of meetings good meetings and bad meetings we had a lot of meetings and most of them were good ones solution-focused

don't bureau of topic and make sure everyone has all the information they need to make informed decisions in the meeting and on their own we had daily check-ins and bottleneck checks I think most studios do this nowadays but it wasn't always as rigged as regular earlier in my career at zooss we generically refer to it as scrum but it's not really capital s scrum producers tend to focus on checklists of tasks in the art pipeline there are just too many nested dependencies to be too flexible or agile with the schedule modular rigging made our timelines feasible we can prototype new monsters on existing modules and branch them later if we need something more unique rigging speed was king when creating 90 plus different monster rigs for the animator everything is familiar but inconsistent between rigs further along into production fixes modifications on

into behavior on one rig could propagate to older stuff for instance we made significant Fisk fixes to the snake tail rig to correct flipping issues and we were able to apply that fix to the other monster monsters that use that module i sat in the animator bullpen I could peek over my shoulder over my monitor or over the cubicle wall to communicate with the animators who are using the rigs that I was building they could do the same to ask me questions it required a minimum of energy to hop 5 feet to help someone at their desk finally we had a ton of experience on our team 2 out of 6 of our senior animators were former lead animators at their previous studios across the rest of the art team we had Sol we have so many 10 year game dev veterans when you're talking to people with this level of experience it makes explanations much easier veteran artists often have good technical chops they had to to be pretty

technical to have been an art a game artist back in in the day sorry for the cliche but experienced developers are the most valuable asset a game studio has the politically correct version of what went wrong but I believe that every mistake is a learning experience we should have pushed harder to adopt Maya as our DCC working around 3ds Max's limitations is a full-time job for example 3d studio max has various UI features that are just not scriptable also certain features like skin are only accessible in script if it's selected in the UI and for speed complex rigs such as ours can be downright sluggish and Max referenced rigs would have made rig updates infinitely easier and may have made some things possible to update that we were just too afraid to do because of the time labor and potential for broken

animations after a batch update we should have pushed harder for a better game tech such as cloth dangly bits hair foot and our mic a and state machines all we had was export the entire skeleton as an FK animation and a programmer title out of it together behind a wall of code we used Rd or rad game tools granny as an animation platform but we weren't even using all the features access in though we fought against it until the end eventually pretty much every humanoid and player character used a single animation set the set grew and grew and had infinite refinement passes but at the cost of variation among race races and genders the physical and skeletal variation

between races and genders had to be reduce to almost nothing because our retargeting couldn't handle it we had poor man's arm I K for females using two-handed weapons but it was difficult to set up for edit there was a word I saw players used to describe our animation in beta Genki in my opinion our animations look pretty consistently fluid and believable in max but the animations became extreme compressed after export we experimented with flatter hierarchies but that caused issues with blending upper body upper body and lower body motion and it was during our flirtation with impacts driven by code which didn't understand a non-standard hierarchy we did have a processor written that was supposed to isolate and compress separate branches of the skeleton hierarchy differently based on the motion in each animation but I don't

think it ever made it into our pipeline compression was worst where it mattered the most feet which were supposed to be planted on the ground jittered visibly weapon arcs at the end of a long chain from the root up the spine down the arm terminating in a weapon bone became zig-zag w shapes instead of smooth arcs our exporter in conjunction with 3ds max sampled subframes making single frame modes which is problematic similarly we had fake parent space switches for sheathing a weapon temporarily to free a hand to cast a spell and that looked fine in max but never worked perfectly in the game because the sheath weapon was still a child of the hand the sheath weapon was told out of hand for a game of this caliber being limited to so few bones was harsh at launch we had no skillful Elodie's we made a lot of sacrifices and compromises for the bone

limitations we really could have used more than three bones for a cape four bones for a robe or two bones for hair or even nine bones for a hand instead of a full 16 full voice-over and first-person view were tacked on late in development and saw their scope creep wide open without getting the tech or manpower to support it we released the game at launch with only a single bone flappy jaw we finally adopted face effects for NPC conversation post launch but really should have planned better and shipped with it in the first place something I've been interested in exploring lately is some studios moving away from a rig that does everything at all times and using a later base rig with extendable control construction tools our animation rig was a monstrosity of confusing panels and

options it was heavy and slow and this built-in configure it and the built-in configuration options made Overhaulin modules impossible without breaking existing animations a lighter simple rig would basically just be an FK rig one IKr mush a button to construct an IKE a control overlay on the fly and then possibly collapse it back to FK when you're done especially if we move to adopt motion capture in the future this could be the way to go as mentioned several times 3ds max does not have usable referencing so our rigs were duplicated in every animation scene we should have implemented frequent automatic batch rig updates to ensure all of our animation scenes were always on the up-to-date rigs when things broke we would have been able to find the offending systems as soon as they failed rather than sometimes months later

always listen to your instincts otherwise known as don't believe the artists animators swore they didn't want to control picker UI for three years until they did part of that was different animators coming onto the team with different methods and styles of working always assumed animators need more than one character in the scene our name space tool had too many limitations and most tools were written with the assumption that there would only be a single rig and in a magazine again the animators said that they would never need more than one rig in a scene because there was no tech to support paired animations later on we realized we needed to sync multiple characters and cut scenes and mount writer animations the hacky name space system I put together for one-off cutscenes ended up being used for entire mount writer suites which then made it difficult to update the rigs in those scenes with tools that didn't support the namespaces

it was like an animator tools arms race I started out with good intentions and keeping our maxscript tools strictly layered between library functions tools functions and UI functionality but eventually random functions in the tools layer ended up being cross used in other tools encapsulation of functions and two struts was it's a thing that was obvious in 2008 but became standard across the tech art forms by 2011 some of our tools especially UI's were updated to this format but many old tools and libraries remain as big clumps of global functions the iteration cycle on our customization rig was pretty bad it took 20 to 30 minutes per iteration from a max I'd fix to seen it in-game especially if I had to rebuild the rig building the template skeleton building deformation rig building the animation skills in emerging in the raw matches only took 30 seconds the slowest part of the build was loading the skin weights on to

dozens of meshes it took 10 minutes I think part of that huge limitation was part of that was the huge limitation in max the skin modifier requires that it is active in the modifier panel to do any scripted modification even with redraw off it's slow then the export took five minutes and there is no hot loading of the customization rig in-game so we needed to fully quit and restart the game which took another five to ten minutes on our dev server finally the most foremost of the project there was no technical art team and what did exist was not seen as being at the same level of the other art sub disciplines we needed more tech artists earlier for three years it was just me and I was assigned to report to the lead animator for the next two years after that it was just me and a junior tech artists both owner of the lead animator we were not

seen as people as other disciplines and therefore had little voice we're advocating in the studio finally just a couple months before launch we hired a lead technical artist merged one tools programmer and one technical modeler onto the team and hired another technical artist with a programming background but it was too little too late by the time this happened we were encoding art lock for launch the Elder Scrolls online has been in release for eleven months but as a live MMO we've released tons of new content and features since launch ZeniMax recently announced that we're going to transition to by to play which means it will no longer be a monthly subscription required to play and we're going and we're looking forward to our imminent launch for PlayStation 4 and Xbox one I where to give a shout out to these fine folks who contributed to the game and

what time is it ten minutes left anybody have questions [Applause] okay thanks thanks for coming and we didn't put anybody is asleep hello Hey oh hi how you doing good talk thank you very much yes so you're talking about trying to push for Maya and adopting that what do you see that as a realistic goal this far into the project I'm assuming it's a live game that's gonna have continual support right well we are looking forward to a future prod product and you know

nowadays with FBX it's fairly easy to get stuff from Max to Maya as long as the rig on the other end kind of supports the input so we thought we're talking about doing some of that just like rebuilding our system in Maya and then loading all the animations into it and see what happens yeah so furthering that I've worked in environments where 3ds Max and Maya both used in the same environment and it can be a little tricky yeah so if that was adopted for the animation pipeline would you also push for that being adopted by the environment the rest of the studio probably not it's yeah okay thank you very much you mentioned all actions so which mess are you used to solve take a problem which what I mean you use which Messer to solve a universal kinematic problem you use you only use the beauty

and okay handler or you have your own now this built-in solver or whatever the okay the hierarchy dependent or whatever it's called and another question is I heard us saying that if you want to import your animation in your game you need to remove the IQ before you do the import well just it just samples the the skeleton as as if the whole thing was just an FK so I mean I know you need to pay all the end missions the frame and alien port do you need juicing it in necessary to remove zik before you in for the know the exporter just just samples whatever the whatever the skeleton is doing at any particular friend doesn't matter how the skeleton is driven like I have that one tool the dynamics tool where I'm you know changing constraint on the skeleton to go from you know from the regular rig behavior to a whole separate set of controls that have no hierarchy whatsoever so that you can break

skeletons up or you know did some crazy stuff with you know with golems that are made of rocks and stuff make the rocks all fall apart and tumble around and the hierarchically in max that's still a hierarchy but controlled entirely by a separate set of controllers controls the thing is that I think if it's down whether IKS existing is doesn't affect animation itself but they also take some CPU time so I think to the efficiency part maybe I heard of seen that if you wanna like improve your efficiency you need to remove the okay but I don't know yeah we don't have any I cave in anybody else there's a lot of a dialogue for MPC

and I know they have it and that animation was like manually created by any major or there was like kind of a technical thing yeah well at launch we all we had was the jaw flapping like one bone and that was driven by just audio waveforms the after launch we implemented face effects and that was all generated procedurally datang automatically by the face affects system okay thank you [Applause]