I’m just reporting a small bug that I’ve encountered with model cacheing and textures.
On my WinXp, Panda 1.7.0, modifying the filename of a texture associated with an egg file can cause the texture to be permanently dissassociated with the egg file until the model-cache is cleared.
I have an egg file that has a texture called tex1.jpg
I accidently renamed tex1.jpg to tex3.jpg. Upon first loading this egg file, Panda will spit out an error saying that tex1.jpg can’t be located.
However, when I change the texture filename back from tex3.jpg to tex1.jpg, Panda will refuse to load the texture automatically, even though the filename is now correct.
To correct this, I have to manually clear the model-cache.
I think this is a necessary effect due to the way the cache functions. You could also solve the problem by “touching” the egg file in question, i.e. by saving it in-place, to update its modification time; this would tell Panda that it needs to re-read the egg file and re-examine its texture references.
But if you do not modify the egg file, Panda has no way to know that you have corrected a problem with its texture references, and thus has no way to know it needs to re-scan for the textures referenced by the egg file.
When you load an egg file, whatever textures it references successfully are baked into the cache reference. Any invalid textures are baked in as invalid texture references. We cannot store the cache reference any other way, because otherwise that would mean we’d have to scan the model-path for missing textures every time you loaded that particular model from cache, which rather defeats the whole point of a cache (that is, to minimize references to the disk).
So, I’d say this is a necessary and known limitation, not exactly a bug.
It was a bug for me because it took me a long time figure out why the textures were not loading correctly.
It’s just a philosophical difference but I personally feel most of the caching utility comes in bam’ing egg files rather than texture modification checks.
Hmm, maybe, but I suspect that that policy would cause the opposite frustration: people wouldn’t understand why their egg files are not caching, or why they aren’t loading at all. (Consider how many questions we get from people who want to know why their textures don’t load; imagine how much worse it would be if their egg files didn’t even load at all in the first place and they didn’t know why.)
And failure to cache is also a dangerous behavior, particularly because it’s often not obvious that it’s even happening (your program still works–but, man, Panda sure is slow).
On the other hand, I do sympathize with the problem reported. Inappropriate caching is also a frustrating problem. I just don’t see a good solution that removes frustration all the way around.
If the cache detects an error on a missing texture, the cache could touch the EGG or BAM file and try again. If the all the textures are not resolved then it could throw an error.
Would this be a reasonable modification to the cache code?
There is no missing file to detect when the model is loaded from the cache. The missing file is only detected when the egg file is loaded originally. After that, it writes a bam file to the cache that lacks any reference to the missing file.
I guess it would be possible to write a bam file that contains a reference to the missing file, even though it is, in fact, missing. That has a few problems, though, because the egg loader normally reads the texture files to gain some hints about the render state, and it won’t be able to do this if the texture doesn’t exist at the time the egg file is processed. So it could make some guesses, but they might turn out to be incorrect, and it will be too late to correct them. It could still result in a confusing and frustrating situation.
