Use v2 bam for character animations

[Shekn]

I tried to use the animation sprites collected in the bam file of version 2 (which stores the data in pvrz files) as animation for the character, and failed. I simply replace ZHMW1 in avatars.2da of the demo with the new name of the bam file. The game then fails to start. No errors in the console, the application closes without any message. If I use this bam-file as a resource for the cursor or a static element on the area, then everything works fine. So do I need some additional setup, or is the v2 format not supported for characters?

[lynx]

Did you put just the prefix in the file or a whole filename? Please share the files, so I can test what assertion or bug you hit, if nothing is wrong with the data.

I can't think of any reason why it shouldn't work, the underlying format is opaque to the users, they just request an animation. Because it's all in the override folder, the fact that there's no entry in chitin.key should also not matter.

 

[argent77]

BAM V2 only works for UI-related stuff (afaik). If you need alpha blending then you can still use the conventional BAM V1 format with an alpha-blended palette.

[lynx]

That's for the EEs; like I said, I don't see any reason why it wouldn't work out of the box on GemRB. We've used it in the demo for an area animation since the start of our BAMv2 support and if there are any technical limits for use with avatars, we should just remove them.

[argent77]

6 minutes ago, lynx said:

That's for the EEs; like I said, I don't see any reason why it wouldn't work out of the box on GemRB. We've used it in the demo for an area animation since the start of our BAMv2 support and if there are any technical limits for use with avatars, we should just remove them.

Interesting. How do you deal with palette-specific behavior (like false color replacement, semi-transparent shadows, special effects, etc.)?

[lynx]

None of that has cropped up so far, that's all. Since it's for new content, we also don't need to support everything.

Btw, why would shadows be a problem? The format supports more than one level of transparency, so no special blending is required, whether the shadows are in a separate file or baked in.

[argent77]

I thought more about backwards compatibility with the old format (e.g. for mixing BAM V1 and BAM V2). But I agree that it shouldn't be an issue for new content that is specifically tuned to BAM V2.

[Shekn]

This is a simple ball jumping animation. File contains 80 identical cycles. It should be used as type = 1 animation. I would like to use v2 format, because it allows to use pre-rendered soft shadows.

ball.zip

[lynx]

That animation type did require two more guards, but it seems to work fine now.

[Shekn]

Great. I download the latest build, and now it works.

[lynx]

Glad to hear. Let us know if you hit any other hiccups.

Also, we want to make the creation process as smooth as possible, that's why I asked if you followed the notes on the wiki. Anything you can share, so we can improve the docs, script more of the process or otherwise streamline it, would be helpful.

[Shekn]

For me, the process of creating sprites is fairly straightforward. Render the sprites in any DCC and then collect them into a bam inside NearInfinity. This is fine for UI sprites or static sprites for areas.

What is not clear is the format for character animation. The GemRB supports several formats (types 0 - 19), but I don't understand the complete description of each format. I am interested in animations with 16 orientations without mirroring. It would be better if all of them were packed into one bam or maybe each action would store in a separate file. I tested type 1 and it use only 8 orientations. Also, it is not clear what the cycles inside a bam mean for different types. For example, the character animation in the demo is stored in files ...A1 - ...G17. The file ...G1 contains 18 cycles (0 - 17), but the first 9 are empty. Why does this happen? Is this necessary for the format or are these cycles optional? If so, what should be stored in those cycles?

[lynx]

The best docs on the original formats are here:

https://gibberlings3.github.io/iesdp/file_formats/ie_formats/ini_anim.htm

But good point that we need to map them, add anything missing. So far people mostly used the main iwd format, since it's easier to grasp.

Why some are oddly packed is beyond me, maybe it was an optimisation for loading into a joint memory representation.

[lynx]

Looking at the code, type 1 is the only one that stores everything in a single file and I don't see any orientation reduction at play (16 -> 9 - > 5). How are you testing?

[Shekn]

I apologise for not telling the whole truth. Type 1 animations do indeed use all 16 orientations. But there is some strange behavior. After a walk cycle in one direction, it starts another cycle, and after that it starts the walk cycle again (instead of the idle cycle). Here is a gif with the recording

For the north direction, cycle 24 is used, then it switches to cycle 8 and then back to cycle 24. Is it OK or not?