Bugfix: Don't generate different mipmap names on every run
Posted: Sun Aug 10, 2008 11:23 amhttp://svn.guildofwriters.com/pyprp/contrib/CWalther/stable r320 fixes the following bug:
When two materials in Blender use the same texture image, but with different mipmap settings, PyPRP tries to choose unique names for the two exported plMipMap objects. However, it doesn't do a particularly good job at it: Assuming a file name of texture.png, the first time it is run in one Blender session, it chooses texture.png and 1-texture.png. The second time, it chooses texture.png and 2-texture.png, the third time texture.png and 3-texture.png, and so on, counting up the number in front of the second name.
This has several disadvantages:
With the mentioned change, PyPRP generates identical output files when run several times on the same input (except for the sum file that records the modification time of the other files).
Besides, the previous method didn't actually generate unique names - it didn't check whether 1-texture.png in the example above was already taken (by a user-provided file of that name). This is fixed too.
Please review and merge.
When two materials in Blender use the same texture image, but with different mipmap settings, PyPRP tries to choose unique names for the two exported plMipMap objects. However, it doesn't do a particularly good job at it: Assuming a file name of texture.png, the first time it is run in one Blender session, it chooses texture.png and 1-texture.png. The second time, it chooses texture.png and 2-texture.png, the third time texture.png and 3-texture.png, and so on, counting up the number in front of the second name.
This has several disadvantages:
- exporting takes a long time when the same image is compressed again every time (under a new name),
- the TexCache folder fills up with useless identical files,
- the generated PRP files are different every time, even for identical input.
With the mentioned change, PyPRP generates identical output files when run several times on the same input (except for the sum file that records the modification time of the other files).
Besides, the previous method didn't actually generate unique names - it didn't check whether 1-texture.png in the example above was already taken (by a user-provided file of that name). This is fixed too.
Please review and merge.