Multiple BAMs in a single PVRZ

[Skye]

Is it possible to have multiple BAM files reuse the same PVRZ file? Looking at existing MOS####.PVRZ files, they all seem to function as texture atlases (sort of), cramming a bunch of different images inside them. I've started using PVRZ-based BAMs in certain cases to make my life easier and to increase image quality, but NearInfinity only allows you to select the index for the MOS file, at least as far as I can tell. Although there a great many indices to choose from, so clashes with other mods are unlikely, I would still prefer it if I could put all my spell icons into one PVRZ for instance.

[Sam.]

By the file format specs this is certainly possible, and as you point out Beamdog did this with vanilla EE resources.  However, AFAIK there is no automated way for modders to achieve the same result.  I can think of a couple hack style workarounds to do it, but they wouldn't be elegant or efficient...

[Skye]

I've taken the time to look at the specification of BAM v2 files and it seems like a rather simple matter to change the coordinates and size of the data blocks. I'll ask Ken to write us a patch function to automate this process. We've also noticed that there are now TP2 actions that allow you to find an appropriate PVRZ index and update your BAM resources, which will prevent any potential clashes.

[lefreut]

You definitely can have multiple BAMs referencing the same MOSXXX.pvrz file. I did it with NearInfinity.

In the Bam Converter, all frames you add will end up in the pvrz files (even the ones that are not used in this particular BAM). If you put the resources in the frames tab in the exact same order, it will always produce the same pvrz file.

So if for example you have file1.png and file2.png and want to create two BAMs that will use only one pvrz file, you add both png in the converter, select only the first frame in the cycles tab, choose an index and create file1.BAM. You then do the same (same pngs, same index) but this time select the second frame in the cycles tab and create file2.BAM. It will overwrite the MOSXXX.pvrz file but with the same content. Now both your files should reference the same pvrz file but with different coordinates and size.

Edited May 1, 2019 by lefreut

[Skye]

Sounds like a roundabout way of going about it, but it might be easier than doing it by script. I'll give it a shot, thanks.

[Skye]

Can anyone tell me what the point of the INSTALL_PVRZ action is? Is there relevant metadata written within the zipped PVR files? And why do you need to tell it what the original index was? I thought the page was defined by the filename.

I'm just curious as to how this differs from simply copying the file to override with the correct page number in the filename.

[Sam.]

4 hours ago, Skye said:

Can anyone tell me what the point of the INSTALL_PVRZ action is? Is there relevant metadata written within the zipped PVR files? And why do you need to tell it what the original index was? I thought the page was defined by the filename.

I'm just curious as to how this differs from simply copying the file to override with the correct page number in the filename.

PVRZ files are compressed graphics textures.  For BAM V2 files, the BAM frames are subtextures that have been bin-packed into a single large texture that is a PVRZ file.  The PVRZ files are accompanied by the actual BAM/TIS/MOS files that contain pointers into the PVRZ files of where to load the subtextures from the larger graphic.  If you rename a PVRZ file to use an unused name, the pointers within the corresponding BAM (etc.) files also need to be updated.

[Skye]

Yes, I understand that, but INSTALL_PVRZ only modifies MOS####.PVRZ files as far as I can tell. You have to update the BAMs with UPDATE_PVRZ_INDICES, which makes sense, but then it should only be a matter of copying the PVRZ file to override with the correct name, so I don't see what the point of that action is.

The documentation states: "This function copies the specified PVRZ file into the target folder and updates the PVRZ index."

So how is that different from just doing COPY ~MOS1234.PVRZ~ ~override/MOS%new_index%.PVRZ~?

[Skye]

Looking at the source code, from what I can tell, it only makes a difference if your BAMs use multiple PVRZ pages. You can then foreach through all of your PVRZs and update their indices to the new block indices that you got from UPDATE_PVRZ_INDICES. So for small images, like spell icon BAMs, you're probably better off copying them by hand to reduce the amount of unnecessary code.

[Skye]

So, I did test my theory and it turned out to be true. I also needed to update the BAM indices manually since argent's functions don't really support image resources that use the same PVRZ page. Doing so does have the added perk of being able to name your PVRZ files whatever you want though, which makes things a bit easier to work with.

LAF FIND_FREE_PVRZ_INDEX RET large_pvrz_index = free_index END
COPY ~project/pvrz/icons_large.pvrz~ ~override/MOS%large_pvrz_index%.pvrz~

COPY ~project/bam/mybam01.bam~ ~override~
  READ_LONG 0x001c data_offset
  WRITE_LONG data_offset large_pvrz_index

Something like that works just fine. Of course, if the BAM file were to have multiple data blocks or PVRZ pages, one would need to do a bit more work.