PVRTexTool mipmap quality issue

Tagged: ,

This topic contains 8 replies, has 2 voices, and was last updated by  Tobias Hector 4 years, 6 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #31214

    When i generate mimap with PVRTextTool from SDK 3.1 i get:

    The 64*64 mipmap is not homogeneous, the center is more detailled than the edges.

    And when i generate it with SDK 2.10 i get a good result:

    #36992

    Hi Bruno,

    Have you tried using different filters when generating the MIP Maps? Were you using Nearest, Linear or Cubic?

    Thanks,

    Tobias

    #36993

    Hi Bruno,

    I actually made an update to the MIP Map generation algorithm a couple of weeks before release, are you using the GDC released version? The version on the disk didn’t have that update in it. I tried to reproduce the issue, but when I generated the MIP Maps using the most up to date version, the MIP Map levels I generated were correct, and didn’t have the additional central detail in your post.

    Could you click the “Feedback” option under the help menu, and copy the version information here so I can check which version you’re using? The operating system you’re using would also be helpful. For reference, the current most up to date version is: “PVRTexTool 4.04 (SDK build 3.1@2308999)”

    Also, could you provide a link to just the original image – I was simply copying and pasting from your screenshots, so it could be inaccurate?

    Regards,
    Tobias

    #36994

    Here is the original version in 256×256, screenshots were zommed :

    Hi Tobias,

    I am using the latest version PVRTexTool 4.04 (SDK build 3.1@2308999), but in 64bits under Windows 7.

    We use only cubic fitler.

    #36995

    Hi Bruno,

    I don’t remember if I ever actually got back to you about this via email or otherwise. If I’ve left you hanging – very sorry! I’ve still not gotten to the bottom of this, and I’m not 100% sure what’s causing the difference. To all intents and purposes the algorithms *should* be the same – the only change I’ve made is to make sure that the resize operation doesn’t offset the texture to the top left by one pixel each time.

    This issue was happening both before and after this change however, so I’m a little stumped. I am guessing there’s a cumulative error somewhere as I traverse the MIP Maps, but I can’t entirely figure out where that’s coming from at the moment. I’ve still got a bug out on this so I’ll continue my investigation and let you know if I find something.

    Regards,
    Tobias

    #36996

    Wait, actually I just double checked, I was using the wrong version. The offset fix *is* what’s causing the detail shift. Well I know what the bug is, but I’m not sure how to fix it without breaking the offset shift. This is going to take a while to fix I’m afraid, but I’ll try to get *something* into our 3.2 release.

    Regards,
    Tobias

    #36997

    Hi Bruno,

    As expected this is causing a number of issues, but I believe I’m finally getting close to cracking the problem. It turns out that doing image resizing well is really, really hard. Regardless, after a few solid days of trying to get this solved, I think I may be on to something. This probably won’t make it into the 3.2 release right away, but I hope to release something not too long after the initial release.

    Regards,
    Tobias

    #36998

    Hi Tobias,

    Thank you for investigating this. You can take your time to fix this because we can use SDK 2.10 forever.

    #36999

    Hi Bruno,

    Actually, it’s now done, I still have a bunch of testing to do to ensure it’s correct but all of my test images (including yours) now appear to be resizing correctly. I basically just went through and rewrote the entire resizing code, and it’s now higher quality (I believe so anyway!), and more consistent for images such as yours. It won’t be released for 3.1, as it’s a large change, but it will be in the 3.2 release, which is targeted at the end of August.

    Regards,
    Tobias

Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic.