Moniese' Avatars technical

[WizWom]

I tried these out, and I must say, it is a LOT of work to rework an avatar. I laud the effort and must say they look quite good.

 

I did have a few things: The unarmored female human mage (chfw1) has a shirt that isn't mapped to a player chosen color (which isn't completely unusual - the skirt of the 1PP chfw1 is leather) but instead is solid black.

 

There are some inventory PLTs that have a completely shadowed background.

 

I suppose, if you like, I can go through and list these technical issues for all the avatars.

[CamDawg]

Sure but, without Moinesse, they probably won't be fixed.

 

Unless you're offering to fix them as well, in which case you'd make a lot of folks, including me, very very happy.

[WizWom]

Oy, I had forgotten how much a mess the Avatar/Paperdoll situation really was. Paperdolls not matching avatars; Paperdoll color choices mixed up; etc., etc.

 

To rework even a single level means modifying hundreds of animation frames, and each avatar should have 4 levels or armor.

 

Bioware seems to have originally had some sort of 3d modeling going on and then rendered the frames automatically; not having that would mean a lot of hand-drawing stuff. Of course, that could have a better result - or worse, depending on your skill ;-)

 

Then comes the judgment call - do you start from 1PP paperdolls, or the base BG2? Do you import and fix/upgrade the BG1 avatars?

 

All in all, a headache - or labor of love.

[Miloch]

You can export entire sequences with BAM Workshop I, change palette entries etc. for the full sequence, and then - I think - reimport them with CRE BamIt (both on teambg.eu) without having to break them down frame-by-frame. That should save some time anyway, but yeah... still a lot of time either way.

 

Someone really needs to devise a BAM Photoshop/Paint Shop plug-in. And I'm sure there are folks who would donate their bollock of choice for that 3d prog Bioware had (there are others, but I don't know how well they work with BAMs, or if they do).

[the bigg]

Isn't there a BAM plugin at TBG?

Besides, the best way around this would be to create a render of all the frames using some 3d modelling software (E.G. Blender) and a semi-skilled programmer can write a tool to merge the various renders into the BAMs.

 

Otherwise, a more skilled programmer can decompress the BAMs, remap the troublesome pixels, and recompress them.

[Miloch]

Isn't there a BAM plugin at TBG?

It's only for PLT/MOS/TIS files. We've been bugging Seifer for the BAM plug-in but I'm not holding my breath.

Otherwise, a more skilled programmer can decompress the BAMs, remap the troublesome pixels, and recompress them.

Well, I was going to attempt it with WeiDU but you said no, so... . I don't know enough to do it in any other programming languages. Though I could maybe write a PS/PSP script to automate some of it, but I don't think it could handle the BAM decompression/reassembly.

[the bigg]

Well, I was going to attempt it with WeiDU but you said no, so... . I don't know enough to do it in any other programming languages. Though I could maybe write a PS/PSP script to automate some of it, but I don't think it could handle the BAM decompression/reassembly.

If you don't know enough of any programming language to use zlib to decompress BAMs, then chances are that you aren't really going to do anything in WeiDU save a trivial pixel-by-pixel recoloring.

[Miloch]

I don't know Java and have only a primitive grasp of C, if that. I've never claimed to be a programmer though. I was going to use WeiDU to recolour the palette, not existing pixels. And maybe split uncompressed BAMs into sequences/frames for external editing, and reassemble them again. Tedious maybe, but not as much as editing them in DLTCEP or whatever.

 

If the decompression routine is so easy, why not just build it into WeiDU?

[the bigg]

I don't know Java and have only a primitive grasp of C, if that.

You don't need to know Java to write Java, you only need Google skillz and the patience to guess which line to edit in between copy-and-pasted snippets.

 

And maybe split uncompressed BAMs into sequences/frames for external editing, and reassemble them again. Tedious maybe, but not as much as editing them in DLTCEP or whatever.

"External GUI editor" and "thousands of frames" is a recipe for disaster.

 

If the decompression routine is so easy, why not just build it into WeiDU?

I dislike doing useless work, the IESDP is inaccurate, and I don't understand neither Java nor C++ (I can write and edit Java, but I don't understand it).

 

Do you only need to do BAMC -> BAM or you also need RLE -> standard?

[Miloch]

"External GUI editor" and "thousands of frames" is a recipe for disaster.

Probably why I would just split them into sequences, then divide them further into frames only if necessary (and I wouldn't even do that if we had a BAM plug-in for PS/PSP that would let you edit and read/write the BAM without disassembling it).

Do you only need to do BAMC -> BAM or you also need RLE -> standard?

I think just BAMC > BAM.

[the bigg]

Rather than DECOMPRESS_BAMC, I'll simply make zlib accessible from WeiDU. Actual implementation might change, but you get the idea.

 

COPY_EXISTING ~whatever.bam~ ~override~
 // identify compressed BAMs, decompress them
 READ_ASCII 0 signature (8)
 PATCH_IF ~%signature%~ STRING_EQUAL ~BAMCV1  ~ THEN BEGIN
READ_LONG 0x8 ulen
DECOMPRESS_REPLACE_FILE 0xc (BUFFER_LENGTH - 0x12) ulen
 END

 // fail on invalid files
 READ_ASCII 0 signature (8)
 PATCH_IF ~%signature%~ STRING_COMPARE ~BAM V1  ~ THEN BEGIN
INNER_ACTION BEGIN
  FAIL ~Invalid BAM file %SOURCE_FILE%~
END
 END

 DO_THIS_AND_THAT

 // recompress the BAM if you feel like it.
 COMPRESS_REPLACE_FILE 0 BUFFER_LENGTH 9
 ulen = BUFFER_LENGTH
 INSERT_BYTES 0 12
 WRITE_LONG 8 ulen
 WRITE_ASCII 0 ~BAMCV1  ~ #8
BUT_ONLY_IF_IT_CHANGES

[Miloch]

That'd be great, cheers.