XeNTaX

Using aluigi's nascar_2013_arcc_files.bms script, I modified it a bit to extract only textures, and to add the missing DDS header.
UPDATE: The first 2 isses were solved thanks to deepshit.
1. Some textures are fine, some have interleaved black lines, others have black lines in mipmaps
2. Most files are bigger than what you would expect considering texture resolution, compression, and mipmap count - I'm thinking this could be related to the first issue



Below are links to a few samples and the modified script.

Original_textures.zip
Rebuilt_header.zip

They seem like xbox360 swizzled dds.
This might be a help :
viewtopic.php?f=18&t=8102

I'm not very familiar with swizzling (just have a basic idea) but could that really be the case considering that
a. these are from a PC game
b. only maps and mipmaps smaller than 64px are affected

Xbox swizzle algorithm aligns textures on 4KB and because of that any texture smaller than 128px becomes like what you see.
In your case I guess the textures are just aligned for swizzling but not swizzled.
that makes it easy to rebuild the textures.

Here is how : (for size < 128)
1.Remove the header (first 24 bytes)
2.Each mipmap takes : ((Width + 3)/4)*((Height + 3)/4) * blockSize Bytes (DXT1 blocksize = 8 and DXT3|5 blockSize = 16)
3.All parts are aligned to 256bytes.you should calculate mipmap pitch (Width /4 * blocksize) and copy that amount until the end of mipmap.
4.Now the mipmap is constructed. Repeat for other mipmaps.

There might be some program to do it but I'm not aware of it.

Thanks, #3 really helped.
It turns out DXT1 lines are aligned by 256 bytes and DXT5 by 512 bytes, so it's related to the block size.
I also found that there's a block*1024 byte alignment for each mipmap (8192 for DXT1 and 16384 for DXT5).

I've updated the script to extract DXT1, DXT3 and DXT5 maps properly.
Next I'll add support for uncompressed textures.


P.S. I've seen that formula before on msdn but I've never undestood the logic behind it.
I mean, for a mipmap of 128x64 compressed with DXT1 the formula becomes (128+3)/4 * (64 + 3)/4 * 8 = 4388.5, which is clearly not true because the mipmap size is 4096 bytes. So what gives?

Chipicao wrote: I also found that there's a block*1024 byte alignment for each mipmap (8192 for DXT1 and 16384 for DXT5).

That's exactly according to formula on #1.

Chipicao wrote: P.S. I've seen that formula before on msdn but I've never undestood the logic behind it.
I mean, for a mipmap of 128x64 compressed with DXT1 the formula becomes (128+3)/4 * (64 + 3)/4 * 8 = 4388.5, which is clearly not true because the mipmap size is 4096 bytes. So what gives?

(128+3) / 4 =32
(64 +3) /4 =16
32 * 16 = 512
512 * 8 = 4096

The division doesn't calculate floating points

deepshit wrote:That's exactly according to formula on #1.

No, it's blockSize*1024 regardless of mipmap size.

deepshit wrote:The division doesn't calculate floating points

Thanks, that explains it.

I have updated the script once more:
- support for A8R8G8B8 DDS textures
- extension is always replaced with .dds
- textures are extracted in a folder with the same name as the ARC file

That should do it. If anyone finds other issues please let me know.

I have started researching textures from Auto Club Revolution.

As opposed to Nascar, they are already extracted in .tex files, but the format is similar. There are no more alignments and each mip-map is individually compressed with zlib.
Here's a script I made to convert them to normal DDS. It supports DXT1-5, A8R8G8B8 and an additional G16B16 type.