facole

No, I understand what you're saying. I have 3dsmax but have the 2010 version which doesn't seem to be supported by the Civ4 exporter. I would like to find a method of exporting animations from 3dsmax without using the Civ4 exporter. If you know where I could find some help it would be appreciated. I have lots of MoCap files but don't have the knowledge yet to use them. I'm sure the data has to be converted to match the Oblivion skeleton bone names and there are skeleton bones that don't exist in the BVH bone data - I don't know if that is a problem or not. I'd really like to find out how to convert and use them. You mentioned some names. I tried to contact Seph because he specifically mentioned using a BVH file in one of his tutorials but haven't gotten a reply yet.

Really a nice feature. Could never make make much sense out of it, because nif import does not support it very well (everything is "DefaultAction"). It is also not possible to import another (kf) animation, because this can only be done via a new skeleton, and so I would have 2. I can however import it from another blend file, and then it is ok (like in the other blend file). fore, could you explain what you mean by import from another blend file? I was looking for another way to combine two animations together. I've read only a little of the NLA linking that baduk is talking about and I was hoping for something simpler. I have found one way to combine two animations but it involves importing the animations and copying poses from one skeleton to the other. Then you have to be careful how you delete the copied animation to make sure you first delete all the keyframes before deleting the skeleton.

You asked: "- why should I change z-rot for non-moving anims before and after pose changes?" You are quite right. Non-moving (location-wise) animations would not require any Bip01 adjustments. I guess I was too focused on the moving animations. Thanks. You asked: "- haven't you experienced additional problems due to (unecessary) Bip01 changes?" No, I was just trying to determine a method of importing/modifying/exporting moving animations that was reliable. There are no additional problems due to the Bip01 change because the procedure undoes that change at the end. That temporary change is just to facilitate making the modifications. I might have been trying so hard to make sure my details were correct that I forgot to mention that that was the reason I created that procedure. You asked: "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." You didn't mention which direction your imports are facing but you indicate your imports are moving in the correct directions. My imports always face the left (top view) and always move -90 degrees (rotated on the Z axis) to the direction they should be moving with respect to the direction the model is facing (the import bug). I can't account for why your imports would be different. Maybe there's something different in the way that you import. That's why I'm asking for comments - so I can learn from other's experience. I'm still quite new to all this so please don't take my statements the wrong way. In my experience, an imported, forward moving animation is facing left (in top view) and moves the model to its right (or upward in top view). A right animation moves the model backward (to the right in top view), a backwards animation moves the model to its left (downward in top view) and a left animation moves the model forward (left in top view). Therefore, my procedure rotates the Bip01 bone in Edit mode to correct the direction of movement before modifying the animation. Then, after modifying the animation, it restores the original Bip01 orientation before exporting. This is simply to make the modification of the animation easier. For example, a forward animation should have the model moving in the direction that the model is facing. However, an imported forward animation has the model facing left (in top view) but the direction of movement is to the model's right (up in top view). While not impossible, it would be hard to modify the leg motions without being able to see the forward movement as the feet get planted on the ground. Now, it would be even more difficult to modify an animation that moved sideways (right or left) without being able to see the leg motions and model movement. An imported left moving animation has the model facing left and moving left as if it were going forward. Import the sneakfastleft.kf and look at the movement of the feet in top view - they look like they're sliding as if the model is ice skating. Now look at the feet movement in front view (NumPad1) and they don't appear to move much at all. If you rotate the Bip01 bone as I described, the motion is in sync with the movement and modifications are much easier. If you're only making cosmetic changes, however, you may not need to make the Bip01 adjustments at all. That procedure is probably only needed for significant changes.

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.

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. 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.

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.

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.

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.

Unfortunately your Rot z solution does not work in all/most cases. It WAS a work-around with older Blender/NifScript versions, but is not RELIABLY working any more. I have had many anims that could not be fixed that way. So I decided not to try it and ALWAY do the NifSkope fix instead. The Loc Z fix is not necessary any more. I'm not sure if this was fixed in the actual NifScripts, or by Coronerra's skeleton. EDIT: I was overreading the NonAccum. This might be a fix for 1 frame POSES (not much experience there), but does not work for Animations. I went through all the "Blender fix" "Avoid Blender Problems" guides that refer to changing the RotZ and LocZ values for the Bip01 and the Bip01 Non Accum in Nifskope and I was getting unreliable results. However, I must confess that I ran across an Oblivion "anomaly" that caused me great frustration when implementing idle animations. I had kept recent idle.kf versions in the _male directory (renamed of course) and I found that Oblivion will simply take the first .kf file that it finds that starts with "idle" no matter what the complete file name is. Needless to say I do not do that anymore. Any way, the method I mentioned above integrates well with the other Oblivion idles for all the animations I created - falling, sitting, crawling, standing, etc. I've only found a few things you definitely don't want to do in Blender WRT some of the bones. I probably should say that I'm using the "blender_nif_scripts-2.5.5.90a8d2f" for my exports and this may have some bearing on my results as well. Still using Blender 2.49, too. I've used Coronerra's skeleton, also. For my simple motion anims I just use the vanilla skeleton instead, tho. EDIT: I just imported one of Seph's animations, exported it and it worked fine. I took a look at how the Bip01 and Bip01 NonAccum bones are positioned. The Bip01 has a RotZ of -90 and a LocZ of -6.741 and the Bip01 NonAccum has a RotZ of 92 (approx 90) and a LocZ of 6.798 (approx 6.741) which is a combination I haven't tried before. I will try that and see if that works on my anims as well. Just tried it and that combination works perfectly. I used the correct values on the NonAccum (RotZ 90 and LocZ 6.741), however.

I'm not sure if this thread is still active but I have found the way to solve both the animation height and the rotation issues in blender. You simply apply both a Rot Z of 90 and a Loc Z of 6.7414 to the "Bip01 Non Accum" and export your animation. I currently apply these when I start but you can wait and make the change just before export if that's easier.