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.
I've animated all kinds of things in x and xsi, until they get into BZ2.
No longer a problem for me, btw.
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.
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
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;;;
}
}
}
I think the reason that 30..32 are needed is so that the animation looks smooth. 8 would make it choppy.
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.
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 :P)
EDIT: Darn, TwoSheds beat me to it :P
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
You learn something new every day around here. :-)
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?
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.
Well, by the looks of it, yes, anything is possible..... at least in this, our world of Battlezone...... :-D
Quote from: BNG Da BZ Fool on April 03, 2008, 12:12:56 PM
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!
Quote from: mrtwosheds on April 03, 2008, 04:25:27 PM
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)
That's a very good question. It makes me wonder now what 1.5.5 does with the rest of the animation beyond 8 keys as it refers to in the export dialogue? Also, there's apparently a 30 day trial period for using that version. Still, the mere fact that it does actually convert the file correctly is a major step in the right direction. For so long I'd almost given up hope of ever getting my hands on something that actually works in correctly formatting the more or less obselete XSI format that BZII supports. At least now I can compare side by side the same file translated by both 1.5.5 and the version output by BZ2ME just to study the differences that screw up the BZ2ME version. The difference if not totally off may yeild a way to make changes to the bad version with some basic notepad editing magic. I'm going to and I suggest a few others do some basic detective work to see where it all leads, and post updates on the results if anything helpful is uncovered. BTW, do you know about the GMAX MDL exporter that simultaneously writes out an X file along with the MDL file? I had to add a top level frame in 3DEX to the X file get it to open in BZ2ME, but it did open afterwords for conversion to XSI. That version is vastly different from the version that GSL saves in which BTW closely resembles the XSI version that BZII uses. OM, even suggested that with some basic changes the X file might work to help get the X version to work with BZII.
UPDATE
QuoteI 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.
Actually this does not work in bz2, the frame does not shrink/expand as it does when viewed in 3dex 1.5.5 :cry:
BUT what it does do is also very interesting! The frame does nothing, but the lights I attached to it go ON and OFF! Instead of rotating. I have found a way to make Flashing lights!!! :mrgreen:
Most of those numbers are 0's...and one is 0.01, u sure it doesnt move a *tiney* bit??
What kind of anim is it? strafing?
I can see from studying the Scion Recycler that 8 key frames is horribly inadequate for much of any kind of animation. Also, I noticed that for what little the 1.5.5 XSI converter does translate is horribly inefficient in terms of file size. For example, the full animated version from the data pack is 106k total verses the partially animated 1.5.5 version weighing in at a hefty 164k. My guess is that while the 1.5.5 XSI converter does indeed work; the work involved would be very labor intensive for a modeler wanting to make animated BZII models using it.
I'd have to say that it's usefulness may be limited to static non animated conversions which apparently have no animation key frames at all. I also noticed that the Sci. recycler has several individual animated sections that make up the entire file. I think that unless something else is uncovered that can shed more light the issue it may have limited usefulness for most modelers wanting to do full animations this way.
Sorry to get any body's hopes up, but apparently the search goes on again. Blender 3D, is beginning to look like the best hope for creating animations for the game. I'm also searching for older 3d model making applications made around the time of the release directx version 6, so if anyone knows of modelers released during this time period please post some basic information that I can base my search criteria on. Tanks, BNG.
reminder - 3dsmax works perfectly for animations
just start saving $$$
oh - and if anyone wants anything animated you can send it to me via pm (if i have the time i will do it for you)
QuoteWhat kind of anim is it? strafing?
Its a rotation like the power gen. rotations are weird that why I was experimenting. I still can't quite get my mind around what all four values in the data line do, at least 2 of the values need to be set to create the effect of 3d rotation, as otherwise the effect is only 2 dimensional, so I was trying to do make a 2 dimensional animation. In 3dex that anim would appear to make a 3d model flat and then inverted (left right) But this does not happen in bz2. It just made the lights flash as .8 second intervals... :-)
The first number is the tenth of a second that the line/keyframe occurs on, all values between the last and this one (and so forth to the next) are all interpolated if missing.
(http://www.overminddl1.com/image_scripts/image_sig.php?type=ODL1signitures&image/sig.gif)
Generated by OvermindDL1's Signature Auto-Add Script (http://overminddl1.com) via GreaseMonkey (http://greasemonkey.mozdev.org/)
This is interesting. I made a reference cube in GSL and saved as X. Then in 3DEX 1.5.5 I converted it to XSI; it has no animation just an untextured cube centered in the workspace. Then I did the same thing in BZ2ME to get it's version of an XSI file. What I noticed with the BZ2ME version is that it added the following entry under the SI_Coordinate entry (See it below)
SI_Angle {
0;
}
SI_Camera Camera1 {
1.297981; 2.646989; 3.466687;;
-1.766339; 1.376721; 2.805893;;
0.000000;
60.000031;
0.100000;
32768.000000;
}
SI_Ambience {
0.500000; 0.500000; 0.500000;;
}
SI_Fog {
0;
0;
0.500000; 0.500000; 0.500000;;
20.000000;
100.000000;
}
SI_Light light1 {
0;
1.000000; 1.000000; 1.000000;;
0.000000; 5.966998; 0.000000;;
}
The 3DEX version did not add this statement in the file conversion from X to XSI. As a test I opened both in notepad to do a visual file compare where I notice this difference along with the fact that the BZ2ME truncates a lot of the zero's present in the 3DEX version. Would this adding of the above listed entry cause problems for the BZII game engine; apparently it's erroneous non existent info that BZ2ME adds.
Also, as a test, I deleted this section from the BZ2ME version in notepad saved it and reopened the file to see if omission of the entry would cause a file opening error and it did not. Apparently, the extra entry in the BZ2ME version is not needed. Other then the extra entry added by BZ2ME the layout of the rest of the file is virtually identical to the 3DEX version which is know to animate okay.
What I'm going to try next is the same thing with my animated test cube and eliminate the same unneeded entry and see what happens. Wish me luck...BNG
All of that above listed data is ignored by BZ2 (literally passed right over as long as there is a close curly bracket for every open one). It will have absolutely no effect on BZ2 whether it exists or not.
That is just normal scene information for if the file is open and saved from SoftImage3D itself. It sets the camera position of the scene camera, the lights, etc... but as stated BZ2 ignores it in full.
(http://www.overminddl1.com/image_scripts/image_sig.php?type=ODL1signitures&image/sig.gif)
Generated by OvermindDL1's Signature Auto-Add Script (http://overminddl1.com) via GreaseMonkey (http://greasemonkey.mozdev.org/)
Don't use Threed. Use "X to XSI Converter"...better :)
I created a scale animation. (had no example previously)
AnimationSet {
Animation anim-flux__2g {
{frm-flux__2g}
SI_AnimationKey {
1;
3;
0; 3; 1.0, 1.00, 1.000;;,
8; 3; 0.0, 0.0, 0.0;;,
16; 3; 1.0, 1.0, 1.0;;;
}
}
}
It does nothing in bz2, but works in 3dex. :-(
From what I see, BZ2 does encode the scale animation in the .msh, whether it uses it in BZ2 itself, no clue, but it does seem to encode it into the .msh file. That number that specifies type right after the "SI_AnimationKey" line is the type of frames with 0 being rotations (quaternions in form), 1 being scale, 2 being transformation/position. There can only be one of each type of "SI_AnimationKey" per "Animation <name>", so 1 position, 1 scale, 1 rotation, if any more are specified then the previous is deleted and the latest is used. XSI files also support a forth type, a rotation based on euler angles, BZ2 does not support that one, do not try it.
Also, for note, the max range of animation frames is from 0 to 511. :)
(http://www.overminddl1.com/image_scripts/image_sig.php?type=ODL1signitures&image/sig.gif)
Generated by OvermindDL1's Signature Auto-Add Script (http://overminddl1.com) via GreaseMonkey (http://greasemonkey.mozdev.org/)
I tried the same test with my animated cube in both 3DEX and BZ2ME XSI converted files. I'm trying to get away from using BZ2ME as unless you check the box in the structure tree when editing a frame an animationset entry is not otherwise added (the one it does create does not add the original animation keyframe data anyways just some random numbers) to its XSI output file; it truly is proving to be somewhat of a worthless piece of crap. However as a test, I copied the animation data from the 3DEX version to the BZ2ME version and it animated okay. MTS, you say the animations work in 3DEX but not the game right? I wonder why? My knowledge is far too limited to understand other then to guess that the 1.5.5 version must not truly comply to the version actually used by BZII. Your notepad method and OM's exporter appear to be the only free viable options for doing any kind of actual animation. I've also still got my hopes pinned on locating a modeler released around the time of DX-6 that supports the X version that BZII is supposedly is compatible with. Do any of you guys who made the original game have a clue as to what other 3d modelers were in use around the time BZ was released. Also, another question I have is; does the original BZ use the same XSI format as BZII? Tanks BNG.
Finding a usable XSI version is proving to be quite a frustrating mystery for animating models. As I've mentioned before it does appear to work fine for non animated models as I tested one of my own models in the game, and was able to enter the unit, fly around in it, and exit from it just fine. Animated stuff, however, is beyond my current understanding of how to even begin animating anything. I'm still testing things out and have a few other areas to explore before I move on to other things as this one is merely another step in the BZII modeling saga that just seems to go on an on an...well you know what I mean. BNG, signs, scratches his head, and wipes the chalk board clean again.
I would guess that the makers of bz2 saw no need for scale animation and did not implement it in their code, there are none that I have seen in game or in the stock xsi. Or maybe its me just guessing how they would be in the xsi format... :-)
It would be cool for one player missions, a giant growing walker/monster/boss
All i'm trying to do is make a sort of glowing pulsating core for my dbpgen. the one it has currently rotates on 2 axis but still looks a bit too solid.
maybe make a geom effect that shrinks and gets bigger
BZ1 does not use XSI's, it uses something called .geo as I recall, proprietary for BZ1 only as I recall.
I would bet that, although BZ2 stores scale animation data in the mesh, it does not use it because of the variety of ways to implement it, first of all, scale around *what* point, the model origin, the frame origin, etc... and so forth, plus you can do 'scale' animation by just animation each vertex manually to do the same thing, transformation and rotation is all you truly need. Another reason is that when something is scaled then its normals have to be recalculated to get proper lighting, and this is an old engine, and that operation does have enough overhead to not want to be called every few frames back then I would guess (although animation the points manually anyway would technically need it, they don't).
(http://www.overminddl1.com/image_scripts/image_sig.php?type=ODL1signitures&image/sig.gif)
Generated by OvermindDL1's Signature Auto-Add Script (http://overminddl1.com) via GreaseMonkey (http://greasemonkey.mozdev.org/)
Quotemaybe make a geom effect that shrinks and gets bigger
Particle effects tend no to show up when they are inside buildings.