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:
Hi Bruno,
Have you tried using different filters when generating the MIP Maps? Were you using Nearest, Linear or Cubic?
Thanks,
Tobias
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
Here is the original version in 256x256, 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.
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
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
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
Hi Tobias,
Thank you for investigating this. You can take your time to fix this because we can use SDK 2.10 forever.
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
