importing a kf

[fore]

facole, believe me, I had the same enthusiasm you show to find an easy solution for the 90° problem. In the meantime I have imported/exported more than 200 anims, and with that experience I have written Avoiding_Blender_animation_pitfalls. If you find inconsitancies with other guides, it's probably because these guides are older, and NifScripts have changed in between (to the worse).

 

In a very difficult case I have compared the outputs of 2 different NifScript versions, and found differences in additional NiTransData generated by the newer version, which apparently prevents every easy fix known so far, and make me find the Fix the 90° Problem "the hard way".

 

With different animations I have tried all possible combination of Bip01 and NonAccum modifications in Blender. And yes, in some (simple) cases it was possible to fix anims within Blender. But the rude awakening came shortly after: I had cases where I rotated Bip01 z from 0 to 90, and then back from 90 to 0, and got a different result (additional NiTransData) compared to the unrotated file.

 

With all that negative experience I have decided NEVER to try to fix it in Blender, and than test, and go back, and fix again. I will ALWAYS leave it in Blender as it is, because then I know that the NifSkope tweak I have described will RELIABLY work (except for backward).

 

But maybe you show me I'm wrong. :thumbsup:

 

About your Idle finding: Oblivion does not look for the file name (alone), but checks the NiControllerSequence value of each .kf, and if it finds an "Idle" there it will use it as such, no matter what the filename is. The only way to hide the idle is to change the .kf ending

[facole]

facole, believe me, I had the same enthusiasm you show to find an easy solution for the 90° problem. In the meantime I have imported/exported more than 200 anims, and with that experience I have written Avoiding_Blender_animation_pitfalls. If you find inconsitancies with other guides, it's probably because these guides are older, and NifScripts have changed in between (to the worse).

 

In a very difficult case I have compared the outputs of 2 different NifScript versions, and found differences in additional NiTransData generated by the newer version, which apparently prevents every easy fix known so far, and make me find the Fix the 90° Problem "the hard way".

 

With different animations I have tried all possible combination of Bip01 and NonAccum modifications in Blender. And yes, in some (simple) cases it was possible to fix anims within Blender. But the rude awakening came shortly after: I had cases where I rotated Bip01 z from 0 to 90, and then back from 90 to 0, and got a different result (additional NiTransData) compared to the unrotated file.

 

With all that negative experience I have decided NEVER to try to fix it in Blender, and than test, and go back, and fix again. I will ALWAYS leave it in Blender as it is, because then I know that the NifSkope tweak I have described will RELIABLY work (except for backward).

 

But maybe you show me I'm wrong. :thumbsup:

 

About your Idle finding: Oblivion does not look for the file name (alone), but checks the NiControllerSequence value of each .kf, and if it finds an "Idle" there it will use it as such, no matter what the filename is. The only way to hide the idle is to change the .kf ending

 

 

You are correct in your statement about my 'over enthusiasm' in as much as I'm an optimist. Even after I wrote that I discovered the pitfalls of a moving animations where you don't stay at the same location.

 

I can't argue that these issues do not appear to have simple solutions and the methods you describe are probably the best.

 

I do not understand what ramifications there may be but let me explain some of the tests I have done. If I import a stock Beth animation (sneakfastleft.kf for example) and then export it, the animation exhibits the 90 degree symptom - instead of sneaking left the NPC moves forward. Now, if I take that same animation and -add- a RotZ 90 to the NonAccum RotZ value of each frame, the animation works exactly as the original.

 

I then tried the "sneakbackward.kf" and found that I had to apply a -90 RotZ to the NonAccum RotZ value of each frame to make it work correctly after exporting.

 

Yeah, I'm just trying to avoid all that detailed work in Nifskope. I can't complain though because even if we end up having to do things "the hard way" we still have the means to accomplish what we want in the game. And I do so enjoy modding and tweaking.

 

I really appreciate your comments as I'm sure you know more about these things than I do. PLease let me know if using these test results is a mistake because I'm sure that there probably are things that I am unaware of or haven't encountered yet.

[fore]

I can't see any advantage ADDING 90° to ALL frames (20 to 50 or so) instead of changing just one or 2 places with NifSkope. Ok, you have to do it again when you re-export your anim. But you have to open NifSkope anyway (to change the Loop type), and the NoaAccum change is easy and automatic. Adding 90° in Blender can be pretty cumbersome, especially for turning and spinning moves.

 

Besides, I'm not even sure that changing NonAccum alone is enough. I think in complicated cases you still have to change Bip01.

 

Anyway, I'm very happy that there is someone else who is seriously looking into animation. I don't feel so alone any more. :thumbsup:

[Nadimos]

thanks for ppl to add their (first hand) experience to this topic. :turned:

 

so, if one would do an object pose and export all that stuff, everything being beneath the z plane in blender, later ideally one simply has to adjust the object in nifskope accordingly and it is done.

 

sounds better to me, then doing it the other way around. nif files are easy. they are predictable. i like them.

Edited February 9, 2011 by Nadimos

[facole]

I can't see any advantage ADDING 90° to ALL frames (20 to 50 or so) instead of changing just one or 2 places with NifSkope. Ok, you have to do it again when you re-export your anim. But you have to open NifSkope anyway (to change the Loop type), and the NoaAccum change is easy and automatic. Adding 90° in Blender can be pretty cumbersome, especially for turning and spinning moves.

 

Besides, I'm not even sure that changing NonAccum alone is enough. I think in complicated cases you still have to change Bip01.

 

Anyway, I'm very happy that there is someone else who is seriously looking into animation. I don't feel so alone any more. :thumbsup:

 

First, I've been using the idle.kf animation (with CYCLE_CLAMP) to test the animations that I modify and create. This means the animation is not in a loop but gets invoked repeatedly in succession when an NPC is in idle. What this demonstrates is that the animation itself does not have any unusual rotations at the beginning or end because you can see that the direction the NPC is facing and the direction it is moving is continuous.

 

If I create a new move forward animation from scratch that faces left and moves left in Blender's top view (NumPad7), it works from start to finish with no rotations. The NPC stops a previous animation and starts my idle animation smoothly. I'm not sure (need more testing) but I think the moving animations just have to be oriented properly to make them work. I really don't understand this since I was having all kinds of trouble making these animations (facing/movement directions) properly whan I started.

 

However, there is something odd that I just can't figure about the beth moving animations. If I import, modify to correct the -90 degree import rotation and then export an animation, there is a -90 rotation that occurs only one time at the beginning of an idle sequence and this does not occur between successive repeats of that idle animation. This occurs every time the NPC starts a new idling period.

 

Well, I have to say this is one of the more frustrating things I've come across lately. I've been involved in many different levels of programming for a long time and until now, I have always found that if you broke things down to their smallest details you would find the patterns of how the bigger pieces work.

 

I think I have found just about every way you can manipulate the critical positioning bones and I'm almost ready to conclude that Oblivion is causing that initial idle rotation.

 

You mentioned "one or 2 places with NifSkope." I have tried making those adjustments in NifSkope to the NiTransformInterpolator for both the Bip01 and the NonAccum but I couldn't get the global effect that was claimed and ended up having to make the Eular rotation on every single time key, which I found very time consuming.

 

Would you mind telling me what the adjustments are that you make in NifSkope? Maybe I was doing something wrong.

 

I appreciate the comments.

[facole]

thanks for ppl to add their (first hand) experience to this topic. :turned:

 

so, if one would do an object pose and export all that stuff, everything being beneath the z plane in blender, later ideally one simply has to adjust the object in nifskope accordingly and it is done.

 

sounds better to me, then doing it the other way around. nif files are easy. they are predictable. i like them.

 

The LocZ offset is the easiest thing to fix in Blender. These @#!% rotation things are something else, however. :wallbash:

 

What I really wish is that Blender had more support for other Ni type of blocks because I'd like to play with the particle effects.

 

I started all this because of an idea I had for a mod and I've gone further than what I actually needed. I'm just having too much fun with learning all this stuff to stop, tho.

[fore]

I think I have found just about every way you can manipulate the critical positioning bones and I'm almost ready to conclude that Oblivion is causing that initial idle rotation.

 

Hey facole, you seem to be quite close where I am. You only don't seem to admit (yet), that there are issues for which there seems to be no solution in blender :wink: This is exactly the reason why I wrote in the wiki don't ever change Rot-z on BIP01and BIP01NonAccum, if not absolutely necessary. Every change can drastically increase the work necessary for tweaking afterwards

 

 

You mentioned "one or 2 places with NifSkope." I have tried making those adjustments in NifSkope to the NiTransformInterpolator for both the Bip01 and the NonAccum but I couldn't get the global effect that was claimed and ended up having to make the Eular rotation on every single time key, which I found very time consuming.

Would you mind telling me what the adjustments are that you make in NifSkope? Maybe I was doing something wrong.

 

Look at the wiki Avoiding_Blender_animation_pitfalls. It's the Bip01 and Bip01 NonAccum z Rot. which you know very well now. And I have fond them working in every export/import I made so far, except those cases where I fiddled around with the Bip01 z Rot. I believe, the problem is caused by those quaternion keys in the Bip01 NiTransData block, which are additionally created by the export, but I'm not totally sure. You might want to look for that in your idle which you mentioned above.

[facole]

I think I have found just about every way you can manipulate the critical positioning bones and I'm almost ready to conclude that Oblivion is causing that initial idle rotation.

 

Hey facole, you seem to be quite close where I am. You only don't seem to admit (yet), that there are issues for which there seems to be no solution in blender :wink: This is exactly the reason why I wrote in the wiki don't ever change Rot-z on BIP01and BIP01NonAccum, if not absolutely necessary.

 

 

I tried making those adjustments in NifSkope to the NiTransformInterpolator for both the Bip01 and the NonAccum but I couldn't get the global effect that was claimed...

Would you mind telling me what the adjustments are that you make in NifSkope? Maybe I was doing something wrong.

 

Look at the wiki Avoiding_Blender_animation_pitfalls. It's the Bip01 and Bip01 NonAccum z Rot. which you know very well now. And I have fond them working in every export/import I made so far, except those cases where I fiddled around with the Bip01 z Rot. I believe, the problem is caused by those quaternion keys in the Bip01 NiTransData block, which are additionally created by the export, but I'm not totally sure. You might want to look for that in your idle which you mentioned above.

 

Like I said, I'm an unabashed optimist. :wink: However, you are convincing me. That document, Avoiding_Blender_animation_pitfalls, was the same one I used. I followed the examples verbatim and got mixed results. I also played with those quaternion keys. In my defense <cough>, it was very early on in my learning curve when I tried this approach so it wouldn't surprise me if I were to get different results now. At least now I have a much better understanding of what I'm doing.

 

I will try it again as that would definitely be the simplest solution.

[facole]

Ok, I did a lot of testing and would appreciate your comments on what I've found because I really would like to know if I've missed things or made mistakes.

 

I wondered if the Blender import rotation bug could be circumvented by applying a -90 Euler rotation before importing. The kf importer for Blender seems to ignore the Bip01 quaternion Euler rotation value and sets it regardless of its initial value.

 

After exporting a modified (imported) animation, I found that I only had to make one change in NifSkope to correct the Blender import bug (Bip01 Euler rotation). The

"Avoiding_Blender_animation_pitfalls" guide indicates adjustments to both Bip01 and the NonAccum bones so I assume there must be some exceptions.

 

I tested just the vanilla right/left/forward/backward sneak and walk animations and found the following for the tool versions I'm currently using.

 

Current versions:

Blender 2.49b

blender_nif_scripts-2.5.5.90a8d2f

Oblivion 1.2

 

Procedure to modify an existing animation:

1) Import a body mesh.

2) Import a skeleton and the desired keyframe (kf) file.

3) In Edit mode, select and rotate the Bip01 bone 90 degrees about the Z axis (r,z,90) so that its axes line up with the global axes.

4) Use Pose mode to modify the animation.

5) In Edit mode again, rotate the Bip01 bone -90 degrees around the Z axis (r,z,-90) to restore its original orientation.

6) Export animation.

7a) Open the exported kf file in NifSkope. Fix the value of the Bip01 Euler rotation in the NiTransformInterpolator block. Select the NiControllerSequence block in the List pane, expand the "Controlled Blocks" in the Details pane, locate Bip01 and expand to find the block number of its NiTransformInterpolator block. In the List pane, scroll down to the Bip01 NiTransformInterpolator block and edit the Rotation Quaternion values to apply a -90 Euler rotation (double-click the values to edit, change "Axis" to "Euler" and subtract 90 from the R value).

 

7b) In NifSkope, edit the name/value of the "0 NiControllerSequence" block as needed.

7c) In NifSkope, change the "Cycle Type" in the "0 NiControllerSequence" block as needed.

 

Procedure to create a new animation:

1) Import a body mesh.

2) Import a skeleton.

3) Select Pose mode, use wireframe view (z) to locate the Bip01 NonAccum bone and select it. Rotate it 90 degrees on the Z axis (r,z,90) and elevate it to 6.741 on the Z axis (g, z, 6.741) and then (i, LocRot) to save the changes.

 

[N.B. In top view mode (NumPad7), my mesh/skeleton always faces up after importing. If yours faces a different direction then the 90 degree Z axis rotation mentioned above would be wrong. Just make the model face the left side of your monitor.]

 

4) In Pose mode, locate the Bip01 bone and select it. Lower it to -6.741 on the Z axis (g, z, -6.741) and then (i, LocRot).

5) Create your animation moving whatever direction you wish.

6) Export.

7a) Open the exported kf file in NifSkope. Edit the Name value of the "0 NiControllerSequence" block as needed.

7b) In NifSkope, change the "Cycle Type" in the "0 NiControllerSequence" block as needed.

 

In other words, fix the height and rotate the NonAccum bone so the model always faces left before starting to work on your animation.

Edited February 13, 2011 by facole

[fore]

facole, you are very analytical and systematic. Your findings like "Bip01 axes have to line up with global axes" and "model has to face left side in top view mode (NumPad7)" might be very valuable in reaching the best possible approach.

 

For creating new animation (most likely poses) you might be right already. I have hardly any experience there. But for your existing animation procedures I'm in doubt:

- why should one ALWAYS rotate before and after animation changes? Left and right are moving correctly in Blender, so after a 90° rot these anims would move to the side.

- why should I change z-rot for non-moving anims before and after pose changes?

- haven't you experienced additional problems due to (unecessary) Bip01 changes?

- what are you doing with anims that have a tilt (like Idles or h2h attackleft). When do you change to the original tilt?

- why do you think it is easier when you save 1 change in NifSkope, but have to do 2 more steps in Blender?

 

I can't "prove" that my method is superior, because I didn't evaluate as systematic as you are doing. It was simply the easiest way I found so far, and I am not yet convinced I should change it. :wink: