Limited Options

After finishing the modeling of the mortars, I moved on to generating the needed animations to get them into the game. With every addition of a new weapon to WWIIOL, I am reminded of the limitations we must endure to implement one.

A good example are the mortars. Because of the way we have our 1st person system set up, we have two separate model/animation sets to display one weapon. The arms are a separate rig, and the weapon is a separate rig. Although it sounded good to begin with, it really presents too many problems. The weapon needs to “attach” to the arms via attach points…because of this, I need to physically link the weapon to the arms in the animation tool (3ds Max). Instead of having the ability to use the built in link controller system for animating, that MAX has, I have to hard link the weapon’s attach bone to the arms skeleton to emulate how the two models will behave within the game engine. This restricts actions I could accomplish within each animation. A really good example that a player might see are the aim views of the weapons. If you look closely, and you are really anal-retentive, sometimes you can pick out that the sights just don’t quite line up. Well, if we start the master animation file in the default aiming position, and then build all of the subsequent animations from that, we can easily add the attach bone/point after positioning the weapon……BUT…….if the master file was set up before that little discovery, or we replace an existing weapon, we then have to painstakingly increment or decrement the offset to line up the sights, by eye-balling the whole damn thing. Believe me, it sucks! If the arm skeleton, and the weapon were included in one big file (gr2 file), then we would never have to worry about it. This is something I am really pushing with Ramp to get changed.

We’ve flirted with the idea of have multiple attach points and changing linkage, mid animation within the game, but it would be special case scenarios and just bloat the hack list of fixes.

You will see some of the aforementioned wonkiness in the mortars. The left hand will always be attached to the mortar. You, as a player, will always reload/fire the mortar with your right hand. Because of our legacy with this system, it is the only way we can do certain things. Once we change the system, we can then get animations that appear a bit more natural (the ability to perform any action with any hand…whatever we feel we need in order to animate with a tad more character).

11 Responses to “Limited Options” »»

  1. Comment by mwhitman | 06/12/07 at 9:04 pm

    So how likely is a change to the current system?

    It sounds like something you are likely to need/want when things like loadouts appear.

  2. Comment by JWilly | 06/13/07 at 2:12 am

    Heh. So the British mortarman is inherently modeled as left-handed. Interesting. 8^)

  3. Comment by Krenn | 06/13/07 at 7:47 am

    Ah, nothing like a little Erica Campbell. 🙂

  4. Comment by Bryan N. | 06/13/07 at 3:13 pm

    Couldn’t you constrain the attach point to the weapon in Max instead and key it? That way the attach point is being animated during the firing which allows for the hand to move freely. That does, of course, require that the weapon’s position/orientation be the same no matter what you’re deployed on and that they can’t move without undeploying.

  5. Comment by Toto | 06/13/07 at 3:49 pm

    The problem doesn’t exist in Max, it starts in the game. Because the weapon and arms are separate models, attach points are absolute (at this time). It’s either attached or it’s not. If it’s not, then the weapon would zoom back to it’s point of origin. Like I said, we could do it with multiple attach points and link constraints, but that takes special case code for whatever weapon we are suing it on…it’s not the proper solution and would leave a lot of clean up later when we do decide to do it the right way.

  6. Comment by Kiesel | 06/13/07 at 4:54 pm

    We need more Erica Cambell pictures… that would help

  7. Comment by Bryan N. | 06/13/07 at 8:57 pm

    I don’t think we’re quite on the same page lol. What I mean is to animate the weapon attach point on the hand model to get the illusion.

    Here’s what I’m talking about. Green null is mortar_weap_attach and red is hand_weap_attach. These are separate models with separate skeletons. Frames 1-30 show what the hand’s attach point would do during a firing animation, frames 45+ being whatever else (say undeploying) at which point the mortar would still be attached to the red null by the engine. hand_weap_attach is parented to the purple hand bone. mortar_weap_attach is the top-most bone on the mortar.

    Unless I’m misunderstanding some special requirement you have (entirely likely lol), the attach points are “absolute” in relation to each other rather than their respective skeleton, so you can do whatever you want so long as you animate the attach point to stay in the same position relative to the weapon’s. That’s what I’m used to dealing with. If that’s not the case for you guys I wouldn’t mind hearing the details. 😉

  8. Comment by Toto | 06/14/07 at 1:16 am

    Jeeesh, You are a sucker for punishment eh? hehe
    If I am understanding you correctly, you would essentially have to keyframe every frame of an animation for the weapon attach point included in the arm skeleton to achieve the desired affect. I think it would be easier with multiple attach points and code to work to accommodate those.

    Now, two things could be happening here: 1) either Maya has different sort of animation tools or 2) I am totally missing what you are doing in your avi.

    In MAX, if I animate the left hand, the attach point will follow. I can negate that by picking a point in space, and keyframing the attach point to that position for every frame of the given animation. So no matter how I move the hand, the point would stay stationary. But that is a very inefficient way of doing it (maybe MAYA has a better way of accomplishing it?).

    The best way is to include both arms and weapon skeletons (rigs) in the same animation files so that attaching is a non-issue.

  9. Comment by Bryan N. | 06/14/07 at 2:38 am

    Yeah. That’s what frames 1-30 show in the video. You’d just throw down a rotation and position keyframe on the hand’s attach point for every frame that you need it to stay in place with the mortar tube. Now, that’s a simple, yet inelegant, task in XSI – but it works within your current framework. Once the constraints are in place (couple of mouse clicks) it took about 10 seconds to key those frames. I don’t know how hard of a task that is in MAX. It could very well be a huge drawn out process in MAX. In XSI I’d just set the mortar in place, do all of my firing/reloading animations, then constrain that attach point at the end and press next frame, key, next frame, key, next frame, key…

    And you’re right. It isn’t elegant at all. It’s brute force sexy. A slightly more elegant solution would be to have an attach point parented to the pelvis so that you wouldn’t have to lay down a ton of keyframes once you’re kneeling.

    I dunno. I’m just throwing out a possible workaround. I do wonder, however, if there isn’t some subconscious reason you want to keep your hand on your big tube all the time. *shrug* 😉

  10. Comment by Toto | 06/14/07 at 2:43 pm

    I do like the big tube. 🙂

  11. Comment by Krenn | 06/16/07 at 2:42 am

    Possibly a stupid question…

    Why can the infantryman and mortar not be permanently connected by an invisible limb, so that the visible hands can both move around as needed?

Leave a Reply »»