Dealing with mocap data and Softimage

[Marc-Andre Carbonneau]

Hi,

 

although I'm working for a game studio, can you believe that my department almost never used mocap?! Our animators are THAT good! ;)

 

Anyway, here comes the time where we are asked to use mocap and get it working in XSI.

Motor seemed the way to start but apparently its buggy/unstable?

 

What's the best workflow? Anybody got advices?

 

thanks

MAC

[Christopher Tedin]

Do you have the budget for MotionBuilder? It might be worth the time to download the 30 day trial and see if it fits your needs. The old "Filmbox" was the inventor of .fbx file format, so it interoperates well with Soft, Max and Maya. Great tool for adding layers and tweaking motions brought in from Mocap. Many animators use it for their base animations and import them into their 3d packages.

That having been said, it is rather expensive. Almost $4000 per seat...

[Carl Callewaert - Fundi3D]

• Motionbuilder  and XSI :-)
  

c

[Daniel H]

MotionBuilder.

If you are on a budget and you need to do any facial mocap, then I would point you towards Zign Track 2 - http://www.zigncreations.com/zigntrack2.php
It can export as BVH, TRC and C3D and it also comes with two pre-developed Face Robot templates. Like I said though, this one would just be a budget option only for facial mocap.

[Andre De Angelis]

Hi Marc-Andre,

Have things changed at Ubi? Are there no Motion Builder licenses around anymore?

I remember putzing around with Motor, but didn't find it that reliable. 

To summarize:

1. Start with a Motion Builder skeleton and match it to your character rig so that all the joints are the same lengths and orientation.   
2. The skeleton will be driving your character rig,  Constrain your character rig to the skeleton so that it is driven by the rotations and translations of the Motion Builder skeleton.  Save these set up as  transfer set ups to plot the motion coming in from Motion Builder..
2. Export the Motion Builder skeleton (as an FBX) and bring it into Motion Builder.
3. Get someone who knows Motion Builder to help you with characterizing the skeleton and re-targeting/plotting the mocap to the skeleton
4. Export from Motion Builder as FBX
5. Import the FBX files and convert the motion to action sources (.eani files)
6. In your character transfer set ups, import your actions onto the Mtion Builder Skeleton and plot the motion to your character rigs.
7. Save out as actions sources for your character rig.

Most of these steps should be scripted to save time.

If you need any help or further explanation, feel free to ping me.

Andre

[Marc-Andre Carbonneau]

okay, yes we have tons of seats of Motion Builder but any particular workflow for using it with Softimage?
Anything we should know? I'm starting with a new team here on that one.
thanks
MAC

________________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Carl Callewaert - Fundi3D [ca...@fundi3d.com]
Sent: Wednesday, October 27, 2010 4:48 PM
To: soft...@listproc.autodesk.com
Subject: Re: Dealing with mocap data and Softimage

* Motionbuilder and XSI :-)

[Marc-Andre Carbonneau]

Okay, forget it. Just saw Andre's email. We'll try that. Unless someone thinks they have a better solution! ;)

[cte...@comcast.net]

Hey, thanks for the step-by-step work-through! I was thinking about trying this workflow out. I'd like to work MotionBuilder into my game design classes.

----- Original Message -----
From: "Andre De Angelis" <andre.d...@gmail.com>
To: soft...@listproc.autodesk.com
Sent: Wednesday, October 27, 2010 6:33:15 PM
Subject: Re: Dealing with mocap data and Softimage

[Andre De Angelis]

This was just a very brief summary.

A few points I would add:

1. I don't have XSI in front of me at the moment, but I'm not sure that the Crosswalk FBX addon no includes the FBX skeleton.  You might need to chase it up or build your own (ie.  via scripting).
2. You will need to experiment with the FBX import export options/switches as some work and others don't
3. Import the motion as nulls (you only want the transforms anyway) not bones as they come is screwed up.
4. You'll have to experiment with how you constrain the character rig to the skeleton.  You'll have to experiment with constraining up vectors.

[Andre De Angelis]

No problem.

I scripted most of these steps as I often had a lot of mocap to get through.

Fortunately, Motion Builder allows you to work with multiple takes in the one scene, which allowed me to plot all of them to the character skeleton at once and then export each take separately.  The handy thing about this was that I was able to script the FBX motion importing step to read from a directory so that it would do it as a batch.  This way you can pass the name of the motion asset to the eani file accordingly.

Similarly, I scripted the plotting of the motion from the FBX skeleton to the character rig, once again preserving the naming.

All these files mean that you have to be meticulous with asset management.  To summarize, these are the assets you will be dealing with:

1.  A scene set up file (per character) which comprises a character rig constrained to an FBX Skeleton (XSI scene).  I found that it was more convenient to use a standard FBX skeleton and re size the joints (and match position and orientation), rather than extracting the joints from the character rig.  Often character rigs have more joints than you need.
2.  An FBX file (one per rig) which is the skeleton exported from XSI. 

NB.  If you are not using the standard FBX skeleton, you will have to create a characterization template in Motion Builder.

3. The motion capture data supplied to you (ie. probably in FBX format.).  IF the data is optical data ( eg. C3D), then that's a whole lot of more grief you'll have to deal with.
4.  Plotted FBX motion files (exported from Motion Builder)
5. The action sources that are produced when the plotted FBX motion files are imported into XSI (*.eani format)
6. The action sources that are created when the plotted FBX motion files are plotted to your character rig (*.eani format)

In addition to the benefits of working in Motion Builder, the re-targeting tools a excellent as well as the motion blending tools.

As lot of this requires trial and error.  The constraining of the character rig to the skeleton hierarchy can me especially tricky.  Trying to get the IK legs and/or IK arms to match the mocap can me a pain (especially when you have to consider up vectors) , though it can be made a lot easier if your rigs have FK options enabled for arms and legs.

[Nancy Jacobs]

I've been reading this thread with interest. Just curious here, I am not so experienced with mocap, though I have done some, plus some work with motionbuilder mocap a few years ago. And im going to need to use some mocap in the near future. 

Why not just use Motor within XSI, and animation layers to tweak the mocap? It seems one of the great assets of XSI to be able to use those layers, merge and save actions, reduce data to fcurves, etc etc...

Someone has said Motor was buggy -- I haven't seen that aspect of it yet, buggy how? Plus with all the complications and non-working aspects of the Motionbuilder to XSI process, it seems this has plenty of headaches of it's own. It seems so much simpler to do it all in Softimage, and tag the rig, rather than building an additional rig, and all the additional activity required.

Just wondering why everyone is so ready to write off the mocap process and excellent tweaking tools in Softimage?

NJ

[John Richard Sanchez]

I dont have MB so I have used Motor in a pinch and it has worked well for me. I havent done anything heavy though. I also would like to know what limitations people have seen with Motor.

--
John Richard Sanchez
www.johnrichardsanchez.com

[Andre De Angelis]

Motor might get you by on small projects, but if you're looking at a large production, it ain't gonna cut it.  Apart from the fact that MOTOR is a bit flaky, it doesn't give you the precision to needed for re targetting and mo-cap editing.

Certainly if you;re doing a one off project, it is harder to justify seats of Motion Builder, but in the case of a large studio like UbiSoft (with hundreds dozens of licenses already there), then it makes perfect sense.  They also have their own in house mocap facility.

[André Adam]

We are on a similar path:

1.: Exporting the bare character + skeleton to MB.
2.: Retargetting done there, animated skeleton exported.
3.: Batch script importing all FBX files found in a folder one after the other on top of Softimage target characters. The target characters have a custom-tagged rig, carrying  the information which elements to constrain in which way. After constraining all the characters and props the data is plotted onto the target characters and saved out.
4.: From there we have custom tools in Softimage to create a rather simple IK setup on FK-driven (read: MoCap-driven) characters; the trick is to make sure the base animation is not altered at all in this step. Eg, for MoCap data I'm not a fan of 2d chain behaviours and upvectors on the legs. MB can solve them with a bit of x rotation, which is a good thing an should not be destroyed in the process of creating a Softimage control rig.
5.: Once the control rig is applied or animators do the tweaking, which is more convenient in Soft than in MB.

Cheers!

    -André

[Stefan Kubicek]

Most has already been said. Two more things that proved helpful when I was working with Motion Builder:

1.) Export your character mesh and skeleton to Motion Builder in a T-pose for proper characterisation. I know many studios prefer arms angled 45ￜ
from the body instead of 90ￜ because it deforms better in the most commonly used poses throughout animation when only straight-forward skinning is used, but MB does not like that when it comes to characterisation. At least I have found no workaround for this so far, let me know if you find one.

2.) Camera navigation gets really painful on too small or too large scale scenes in MB. Make sure to export the scene in real-world scale -> characters ~180cm-ish tall. Not 180mm, or 180 meters. Either build it to human scale or scale it at export, before export, or after import into Motion Builder with an extra Null). Again, there might be a way to fix this, but I haven't found any. The most predictable way to work has been to work at a "real-world" scale. Mayabe this has been improved in versions later than 7.5, I don't know.

3.) Hands off any MB version later than 7.5 SR1, unless you need to mocap and solve fingers and/or need to work with ragdoll simulations. 7.5 was the last stable version, all the others (again: at least for me) crash a hell of a lot more often. With 7.5 I was able to wade though hours of mocap data throughout several weeks in production and had maybe 1 or two crashes a day. There are a few things you shouldn't do (like leaving the story mode when one of the clips is still selected), but you'll find those quickly. Some of the glitches also seem to be dependent on graphics cards.
MB is generally very fast, you should get around 60 to 100 fps even on heavy meshes, depending on whether your video driver is configured to use vertical sync or not. I had situations where MB would have bad frame rates when Maya was opened before MB was started (in the 10fps range, which is mostly unworkable for animation). This might apply to other Application (Softimage, or whatever also uses OpenGL) as well. If you are using an NVidia card you should have a smooth ride as long as you use default settings in the drivers. If you have a certified card and drivers: even better.

4.) Workflow: I found it easier to always characterise the character (the character template can easily be reused later for characters that have the same joint naming) and do fixes and modifications directly in Motion Builder. Then I exported the final animation back to the main application (in our case Maya) for rendering and/or game export only. If you plan to tweak animation in Softimage the hardest part is probably to get the motion from the incoming joints (from MB) onto you animation rig in Softimage (which, most likely, is not the skeleton that you exported to MB previously and which actually deforms your character mesh). One of our animators has written his own scripts to do that in Maya. In Softimage there is Motor, but I have never used it so I can't comment on stability. You might end up having to write your own stuff as well.

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Andre De Angelis]

Good summary.

Personally, I would try and avoid using mocap only rigs.  There are too many instances where one will want to mix mocap with keyframe animation.

RE the 2d chain behaviours and upvectors, if the rig is properly set up so that the IK/FK blending is well implemented, it's not a big problem.

[Andre De Angelis]

At Ubi, you'll find that the mocap studio often provides the mocap data in the form of enveloped characters.  If not, one can script this step so that the deformation rig is copied to the FBX skeleton, along with a copy of the weighted mesh.  I wrote a script a few years ago to do this which did the trick.

On Thu, Oct 28, 2010 at 5:51 PM, Stefan Kubicek <s...@tidbit-images.com> wrote:

Most has already been said. Two more things that proved helpful when I was working with Motion Builder:

1.) Export your character mesh and skeleton to Motion Builder in a T-pose for proper characterisation. I know many studios prefer arms angled 45°
from the body instead of 90° because it deforms better in the most commonly used poses throughout animation when only straight-forward skinning is used, but MB does not like that when it comes to characterisation. At least I have found no workaround for this so far, let me know if you find one.

[André Adam]

Oh, we do mix keyframe with MoCap. While we have a full-blown keyframe rig, in the end we always plot the data down to the skeleton, this is the data aimed at the game engine. This plotted data is 100% compatible to the MoCap data and can at any point later on be converted to the simple IK rig allowing it to be further processed exactly like the native MoCap animation. This cross-compatibility is pretty neat, we can refine the animation up to infinity using this system, without ever ending up in a dead end.

[John Richard Sanchez]

Yes It would def make sense for a large studio. Not for me because usually dont have time to learn MB on a deadline. However I would like to give it a try one day. When free time comes my way.:)

John