Fixes: "Mipmap not found in texture" exception for textures with a height that isn't a multiple of 4 but is compressed. #321
Conversation
…ght that isn't a multiple of 4 but is compressed.
|
For the record, I do not know if this will fix this issue for the gen 9 side as it only effects the non-gen 9 code, assuming that the gen 9 format even suffers from this issue. |
|
This is interesting... I've been meaning to try and track down the root cause of textures not successfully displaying and/or exporting to .dds, and maybe this is it? |
|
Also if you're able to upload an example .dds that triggers this, it would be helpful thanks |
|
@dexyfex This doesn't actually change the texture's height, just the amount of data read which is correct to the format specification (see below link from Microsoft, specifically the information on padding) . The extra data that's read is then discarded. Attached is a plain white DDS file in DXT1 format that makes light of the issue in question. It's zipped because I guess GitHub doesn't support DDS files. Edit: Technically the specification doesn't allow for the top mipmap to be a non 4x4, at least not explicitly, but most programs that can work with DDS files do treat the top mipmap the same way and will pad it when necessary. |
|
Ah sorry, from the code preview I thought the Height variable was the texture's Height property, but it's just a local. Not sure why those are named with an uppercase letter. So yes probably this approach is the best one (it's what I was initially thinking should be done) |
|
Not sure why they are either, I just left it as it was to change as little as possible. If you come across other instances of DDS files failing and you can't find a cause feel free to ping me, I have spent far too much time studying the DDS format at this point. |
|
Superseded by an updated patch in #326 |
2 participants
The DDS specification technically does not allow textures that have any dimensions that is not a multiple of 4, though many programs will allow it anyways by filling out the extra blocks with bogus data. The game seems to support this but CodeWalker has been unable to display these after loading them from a YTD for a long time due to not loading the full image data in these circumstances. These images would be displayed fine when initially imported into the YTD off the filesystem as the data was correctly loaded. This PR aims to fix this by taking the height and adjusting to the next multiple of 4 to ensure all image data is loaded since CodeWalker was already correctly storing all of that data in the YTD. The extra loaded blocks will later be discarded anyways.