3DS Max Friendly version of the Open Motion Capture Library!

[Springheel]

I think only problem is speed of the animation that's why it looks like jogging

 

It's not speed--both runs have the same speed--it's the way the arms move, among other things. Our current one just has more of a sense of urgency somehow. Still, this one would be a great alternate.

[Springheel]

and they will be replaced:

 

Please don't replace any existing animations without a clear consensus from the team.

[Arcturus]

There's a strange bug. When I put on the NPC spawnarg:

replace_anim_run  run_jog

run_jog is played at higher framerate. This happens only with animations from Blender. MD5 produced by Blender is noticeably bigger, but I don't know what can cause this bug. It's the same with Blender 2.49 and 2.59. Someone with Max, Maya or Lightwave should try importing animations and reexport it.

[Springheel]

MD5 produced by Blender is noticeably bigger, but I don't know what can cause this bug.

 

I don't know how Blender exports, but I know when we export with Maya we have to scale the animations by .97.

 

Someone with Max, Maya or Lightwave should try importing animations and reexport it.

 

Do they exist somewhere in a format that Maya can read? The md5importer for Maya has never worked for me.

[Serpentine]

<p>

There's a strange bug. When I put on the NPC spawnarg:

replace_anim_run  run_jog

run_jog is played at higher framerate. This happens only with animations from Blender. MD5 produced by Blender is noticeably bigger, but I don't know what can cause this bug. It's the same with Blender 2.49 and 2.59. Someone with Max, Maya or Lightwave should try importing animations and reexport it.

Can you upload one? sounds like it's exporting duplicate/extra frames, and then using a higher framerate setting.

Also, I think the scale for maya is 0.93

Edit - This forum software's abuse of scripts to magically do formatting is getting old, fast ;/

[Arcturus]

I assume maya model is bigger than in game and it needs rescaling, but I imported md5mesh from game so I worked on destination size. Scale and speed are ok, except when I swap animation via spawnarg, only then it's played faster. I exported proguard with one animation to fbx format: I can't check if it's ok.

http://www.sendspace.com/file/cu01ay password: md5anim

 

md5anim is different perhaps because it's meant for Quake? It has correct FPS and number of frames but frames have much more data than our current animations. Here's the run animation:

http://www.sendspace.com/file/pooov5 password: md5anim

[Springheel]

Maya 7.0 doesn't seem to recognize .fbx files.

[Serpentine]

It looks like the script is exporting a lot more components per frame than the current one. 430 vs. 75 or something. I think a lot of this is just 0.00003's being slopped to 0, and 0's being removed. But I havent looked at the code or anything.

 

I have a feeling that this 'removed' stuff would just be populated by the engine either as 0's or an average of something else, so the extra detail might actually be a good thing and come at no reduction in performance or memory(once loaded). Once again, I really havent looked at it, but that's my guess.

[Arcturus]

Maya 7.0 doesn't seem to recognize .fbx files.

I think a plugin is needed. What about .dea .dae? I can export to it, but quick test with this format gave some awkward results. There's also .bvh which seems to store only skeleton.

[Arcturus]

I meant .dae (Collada) not .dea.

 

I imported run_charge into Blender 2.49 and then exported back. The file is bigger but it's played normally. So it's not exporter's fault, it's something else. It's really weird.

[Springheel]

I'll see if I can download a plugin for .fbx.

[Arcturus]

The animation files are fine. If I swap filenames in tdm_ai_guard_proguard_devel.def or swap file names, jog will be played normally and charge will be faster. That means no matter what animation file, replace_anim_run run_jog will always be played too fast. Are animations defined somewhere else beside tdm_ai_guard_proguard_devel.def? Why would name of the definition make such difference?

[Springheel]

There are spawnargs that can affect the animation rate. It's possible there is one in the humanoid def file controlling the run speeds...I have a vague memory of that but haven't looked at it for a long time.

[Arcturus]

There is this:

 

"anim_rate_run" "0.8" //slows down AI so they are slightly slower than player
"anim_rate_run_torch" "0.8"

 

This sounds like it slows down the animation from 24 fps to 19,2 fps. But the swapped run_jog looks like it's played at 32 fps.

[Arcturus]

There's also tdm_ai_humanoid_newskel.def, in which there are:

 

"anim_rate_melee_attack_lr" "1.15"
"anim_rate_melee_attack_over" "1.1"
"anim_rate_run_charge" "0.8"
"anim_rate_run_charge_torch" "0.8"

 

Adding line "anim_rate_run_jog" "0.8" fixed the speed issue. Ok, so which def should I put it in? Or it doesn't matter?

Also I see I will have to put the same definition with different rustle sounds to other def files.

[Springheel]

Adding line "anim_rate_run_jog" "0.8" fixed the speed issue. Ok, so which def should I put it in?

 

tdm_ai_humanoid_newskel.def

[Arcturus]

Current run_charge:

 

 

My proposition:

 

[Springheel]

There's not a huge difference between the two, but I prefer the way the weapon is held more in front of the body in the original rather than leaning outwards. The original run also has the characters looking more straight ahead, which I think is better.

 

Is there some general dissatisfaction with the run animations that I'm not aware of? There are dozens of new animations we could benefit from, but you seem to be spending a lot of time trying to replace animations I've never heard anyone complain about.

[New Horizon]

I actually like the new run better. It feels much more life like to me.

[Serpentine]

I like both, but there's a little problem with the second in practice.

 

The outward held weapon is realistic, since it gives you a good initial place to start swinging from, and keeps the weapon from harming you if dropped. However it'd only really be used outside. While the current, inward hold is slightly unrealistic, it is more practical for a game, since you dont want to have the weapon intersecting with geometry wider than the character all the time. It makes sense inside and doesn't look bad outside, while the other would look very awkward in many situations like passages and average sized rooms.

 

If it's somehow possible to determine these things, I think both would have their places.

 

Or if the proposed one however can be shown to not look strange in inside gameplay - I'd be happy with that too!

[Arcturus]

Animations in game aren't displayed accurately, probably because of the inverse kinematics, I don't know. It's not that visible in the old animation but it happens. I tried to compensate it, but even though in animation right foot is slightly below the ground in game it floats above. Back is now less bent:

 

[Springheel]

Just from the video I think that addresses all the problems I had with it. How badly does the foot float?

[Arcturus]

It touches the ground but it looks completely different. Right foot in Blender, two following frames:

 

 

Game, in slow motion:

 

http://www.youtube.com/watch?v=q2jCVVPI5MU&feature=youtu.be

 

The animation is on the repository.

[Tels]

It touches the ground but it looks completely different. Right foot in Blender, two following frames:

 

 

Game, in slow motion:

 

The animation is on the repository.

 

It might be the game adjusting for the floor. Have you tried them running up and down a ramp or stairs?

[Arcturus]

Probably it is caused by IK. I've just checked and walking on stairs looks ok.