auvy
commented
1 year ago I dumped the game again and yeah. The texture is split between 2 chunks of the same name, one being in root/chunks and the other being in root/bundles/chunks. One chunk file has the highest mipmap only, and the other file has the rest.
While merging folders, it's important to NOT replace any files with same names, because otherwise the texture data is being lost.
I slapped the decompressed chunks together, putting the larger one first, put it into ebxtoasset and got a perfect 512x512 texture of the engine with all of the mipmaps.
So I guess it's just a matter of making a function for this specific edge case, where it finds two chunks in folders, compares sizes and merges into one, and only after appends a texture header.
NicknineTheEagle
I've noticed a possible pattern in broken textures. They have "first mipmap" = 1 defined in .DxTexture and are all broken, while others that have "first mipmap" as 0 all convert correctly. Edit: apparently it's true for individual car textures, but not for all generic car textures. I have no idea how this works.
The broken textures look like a bunch of smaller mipmaps mashed together, like this
Axsis from Xentax somehow managed to convert them correctly by adding some header, but it was 10 years ago and they were online 2 years ago.
Rawtexturecooker does convert the chunk to a texture, but the resolution is two times lower (256 vs 512) than it's written in the .DxTexture. I think it could be picking up the 2nd mipmap (because first mipmap index 1 instead of 0).
I have a theory that the dds headers break for these specific textures (with first mipmap = 1, even though I couldn't make them work with any header), or that highest-res mipmap is located in a separate chunk.
Here's the chunk for the broken textures and .DxTexture: link
Edit: I added a chunk dumped with quickbms. It appears to be compressed, but even then it looks to be bigger than the one dumped with script (if it's the same chunk).