Somewhat excitedly confused about animated X to XSI model that's animated?

[BNG Da BZ Fool]

I recently updated to 3DEX 1.5.5 from version 1.5.0. Some of you may already know that the 1.5.5 version converts X files to the XSI format that BZII uses. The 1.5.0 version only reads XSI files but does not convert to XSI format. Some time back I created a simple animated X cube that slides back and forth. Some of you also are aware that 3DEX has animation playback controls for the purpose of playing back animation as well. Before, I could never get the BZ2ME X to XSI converted files to animate in 3DEX 1.5.0. This time though, using the XSI converter that's comes with 3DEX 1.5.5 the same X to XSI converted animated cube is actually and fully animating just like the X version. I think I've accidentally stumbled onto a bonified working way to create animated X models using GSL that are easily convertible to XSI format to make fully animated BZII XSI animated models. I'm so excited about the discovery that I'm absolutely dumb founded by the whole issue! Now I've got to figure out how to properly animate in GSL using it's animation creation controls. Wow! What do I do next! BNG.

I have a question about the statement in the 3DEX XSI file converter that states that only the first 8 keys of object animation can be exported in the 1.5.5 version. What does that translate into in terms of animated models? Is this sufficient for a typical BZII animated model? Tanks for any feedback as the XSI animations seem to work just fine, but will I be able to animate models like scouts, turret type units, or walker types assuming of course that I can figure out how to use the animation recorder in TS and GSL to get things right for the BZII engine?

Update: I converted the constructor and it must contain more then 8 keys as the converted version does not include the entire animation sequence as the original XSI data pack walk sequence when compared side by side, but hey it does animate the first 8 keys just fine.

The IDF mortar bike seems to animate fully, but only a fin looking part is moving in both the original and the converted version.

The IDF missile scout also seems to animate fully as well after conversion.

The IDF recycler does not animate fully it must have more then 8 keys huh?

The IDF scout does not animate fully either.

The IDF service unit seems to animate fully.

The IDF tug does not fully animate either.

The IDF turret does not animate fully either.

The IDF walker does not fully animate either.

The Scion recycler does not fully deploy either.

[Nielk1]

I've animated all kinds of things in x and xsi, until they get into BZ2.

No longer a problem for me, btw.

[BNG Da BZ Fool]

I'm really surprised that it even works at all. I converted an X model in 1.5.5 and it loads just fine in the map editor minus the skin which I should have copied into the addon folder, but I am intrigued that simple animations are now possible when converting X and COB animated models using 3DEX 1.5.5. My thanks for the heads up on alternative versions of 3DEX other then 1.5.0. I'm going to do some animation testing now to see just how much 8 keys of animation has bought me for trying my hand at animating stuff for the game.

PS: Why didn't anybody ever mention that animations were indeed possible all be it limited to 8 keyframes? Wonders never cease to amaze me that this info was never apparently made known to desperate modelers seeking to animate a few silly models.

[bigbadbogie]

because we didnt know either

all you have to do is make the animation in sections and add the 8-frame parts together in notepad

[mrtwosheds]

8 frames is not enough.
usually bz uses animations of 30 - 60 frames.
the simple solution would be to make an 8 frame animation and then renumber it to slow it down.
8 data lines should be plenty for simple animations. Lots of data lines does not improve an animation.
eg (this goes up)
  Animation anim-body {
      {frm-body}
      SI_AnimationKey {
         2;
         8;
         0; 3; 0, -6, 0;;,
         8; 3; 0, -4, 0;;,
         16; 3; 0, 0, 0;;,
         24; 3; 0, 5, 0;;,
         32; 3; 0, 11, 0;;,
         40; 3; 0, 17, 0;;,
         48; 3; 0, 23, 0;;,
         56; 3; 0, 32, 0;;;
      }
   }
}

[Red Devil]

I think the reason that 30..32 are needed is so that the animation looks smooth.  8 would make it choppy.

[mrtwosheds]

No it doesn't actually, the only good reason for having more is if you don't want it to be smooth.
If you just have two data lines, an animated object will move smoothly between them, if you want it to go slow at the start, for example, and then accelerate then you need more lines to define that change.

I have just been playing with a rotation animation.

AnimationSet {
   Animation anim-flux__2g {
      {frm-flux__2g}
      SI_AnimationKey {
         0;
         3;
         0; 4; 0.0, 0.00, 0.000, 0.00;;,
         8; 4; 0.0, 0.0, 0.01, 0.0;;,
         16; 4; 0., 0.0, 0.0, 0.0;;;

It has only one number that isn't 0! (and its value appears to be unimportant)
The frame is 2 vertical planes crossing each other, this animation makes it shrink/expand in the xy planes and invert itself.
might be useful for some sort of energy effect.

[General BlackDragon]

Actually, only 2 lines are needed for each move.

Additional lines are needed if object changes direction during animation. Think of it as connecting the dots.

BZ2 will smoothly move object from 1st line to 2nd line within the time specified in 2nd line.

same kindof goes for strafing animations. Those are keyed in to work differently in code, only consisting of 3 lines for a rotational strafing animation. (left, neutral, right)

So, It's nothing like a GIF file (Rd's RD anim )

EDIT: Darn, TwoSheds beat me to it

[BNG Da BZ Fool]

I wonder if their's a fairly simple workaround where an animated model could be made in several sections due to the 8 keyframe limited conversion to XSI. You know, something like breaking it into multiple sections. Then after saving them all. Doing something like opening the first one in notepad, and then inserting all the other pieces one after the other together to form one single file? What do you think? I know it would require deleting redundant repetitive entries like multiple headings. Or would that involve way too much work on a modelers part to create a fully animated model?

Also, I believe that almost any modeler that saves files in the formats that 1.5.5 supports could be used to create the basic files for conversion to BZII animated XSI files; I just happen to use GSL and TS for their simplicity (basically I just understand them better then the other modelers I've tried in the past). I would think though that whatever modeler is used should comply with one basic standard; it should not require the file be converted repeatedly to get it ready for conversion by 1.5.5. My view on this is simple: Multiple conversions have the potential for screwing things up the more a model is passed from one converter to another. So far I've been able to get working animated models export/saving in X and COB (TS's native format). There may be other formats as well. I still need to more testing though.

PS: If possible a lot more feedback is needed to make sense of this new discovery. The more opinions the better to fully exploit the potential and limitations of making longer animations possible. MTS's notepad editing looks like the best option so far. There may be other as yet unmentioned ideas for doing longer animations, so please feel free to toss around any ideas you may have as I'm sure that I'm not the only modeler looking for a relatively no cost alternative to doing BZII animations short of dropping a bundle on MAX or SI. Come to think of it, so far I haven't spent a dime since I started modeling for the game unless you count the countless hours of frustration over the last 3 and a half years; that must have some value at least to me anyways. So, sound off and hopefully this thing will actually develop into something useful for the BZII community as a whole and those sure to follow afterwords. BNG    

[Red Devil]

You learn something new every day around here. 

[BNG Da BZ Fool]

One side benefit is that static non animated models can alternatively be converted as opposed to using BZ2ME and X2XSI which seemed to be the only viable option in the past. At least now we have a third option that apparently does not screw up the animation in the conversion process. I actually look forword to trying my hand at simple animations to begin with and perhaps longer ones if a practical workaround can be found. Who knows? Anything is possible to those believe. Right?

[mrtwosheds]

I may have been a bit confusing up there.

8 keyframes is not enough unless you want really fast, short animations.
like this...
AnimationSet {
   Animation anim-flux__2g {
      {frm-flux__2g}
      SI_AnimationKey {
         0;
         2;
         0; 4; 0.0, 0.00, 0.000, 0.00;;,
         8; 4; 0.0, 0.0, 0.01, 0.0;;;

8 lines of data should be plenty however.
AnimationSet {
   Animation anim-flux__2g {
      {frm-flux__2g}
      SI_AnimationKey {
         0;
         2;
         0; 4; 0.0, 0.00, 0.000, 0.00;;,
         64; 4; 0.0, 0.0, 0.01, 0.0;;;

There is probably an ambiguous use of the word keyframe going on, to me it refers to the numbers on the left of the data lines.
0 and 64 in the above example, means 64 keyframes to me.
If you are using an animation application it probably refers to what I describe as data lines, the above example has 2.

[Warfreak]

Well, by the looks of it, yes, anything is possible..... at least in this, our world of Battlezone......

[anomaly]

I wonder if their's a fairly simple workaround where an animated model could be made in several sections due to the 8 keyframe limited conversion to XSI. You know, something like breaking it into multiple sections. Then after saving them all. Doing something like opening the first one in notepad, and then inserting all the other pieces one after the other together to form one single file? What do you think? I know it would require deleting redundant repetitive entries like multiple headings. Or would that involve way too much work on a modelers part to create a fully animated model?

Also, I believe that almost any modeler that saves files in the formats that 1.5.5 supports could be used to create the basic files for conversion to BZII animated XSI files; I just happen to use GSL and TS for their simplicity (basically I just understand them better then the other modelers I've tried in the past). I would think though that whatever modeler is used should comply with one basic standard; it should not require the file be converted repeatedly to get it ready for conversion by 1.5.5. My view on this is simple: Multiple conversions have the potential for screwing things up the more a model is passed from one converter to another. So far I've been able to get working animated models export/saving in X and COB (TS's native format). There may be other formats as well. I still need to more testing though.

I'm pretty sure you can combine animation sections without too much trouble.  Just spend a little time studying the animation sections in .xsi until you figure out how the numbers work and how the combine the sections.
There's some more info on animations in the "more model questions" topic I started.

The main problem that I keep encountering is trying to find a modeler that will export animations in the first place.  Gmax only has exporters for random obscure file types. The version 7.2 of Cinema 4D that I use strangely will not export animations in any of its file formats (including .x, .3ds, and .obj) except one, shockwave 3d, and it can't even import that back in!  Though I guess it is old and .ater versions seem to have a .fbx exporter that does animations.  And Deep Exploration limits you to 8 frames.  What's with all the restrictions on animation!

[General BlackDragon]

I may have been a bit confusing up there.

8 keyframes is not enough unless you want really fast, short animations.
like this...
AnimationSet {
   Animation anim-flux__2g {
      {frm-flux__2g}
      SI_AnimationKey {
         0;
         2;
         0; 4; 0.0, 0.00, 0.000, 0.00;;,
         8; 4; 0.0, 0.0, 0.01, 0.0;;;

8 lines of data should be plenty however.
AnimationSet {
   Animation anim-flux__2g {
      {frm-flux__2g}
      SI_AnimationKey {
         0;
         2;
         0; 4; 0.0, 0.00, 0.000, 0.00;;,
         64; 4; 0.0, 0.0, 0.01, 0.0;;;

There is probably an ambiguous use of the word keyframe going on, to me it refers to the numbers on the left of the data lines.
0 and 64 in the above example, means 64 keyframes to me.
If you are using an animation application it probably refers to what I describe as data lines, the above example has 2.

I believe the first number is also the "length" that the animation takes, in tenth of seconds. 64 might be 6.4 seconds. (I think)