I had a big problem with Panda after the installation on my GNU/Linux Debian Unstable and Ubuntu Hoary, the textures had disappeared!!
Yes, the textures in ALL samples and models, DISAPPEARED!
I tried a lot of thing to fix it. Because on other Debian Unstable this problem didnāt occour. I tried to resolve it for many hours, but nothing!
I tried again and againā¦and again andā¦YEAH!! I discovered the problem!
So, why this occur?
The problem was in LANG environment variable! My LANG variable was set with pt_BR.UTF-8 and when i unset this variable, all samples e models appear with their the appropriate textures. If this variable will be set with en_US.UTF-8, the problem donāt occur.
But, i donāt know where is the problem, in Python or Panda?
But this is my solution for other people who come to have my problem.
Amazing! Itās hard to imagine how the LANG variable could have affected texture loads, but Iāve seen stranger things happen.
Were there any error messages (like āGL unable to create texture contextā or ācould not find texture fileā) when you tried to load textures and they failed, or did it just quietly come up without textures?
If you loaded a model in pview and pressed shift-L to view the hierarchy, did it list āTextureā on the ends of some of the GeomNodes, or did it not?
I figured it out. The problem is that setting the LANG variable changes the behavior of atof() and related functions, by changing the decimal point character, so that atof(ā1.5ā) no longer returns 1.5, but now returns 1! This confuses the egg loader, the Config.prc parser, and all sorts of subtle parts of Panda that want to parse numbers that are encoded with an English decimal point.
Iāve put in a fix that will be released with a future version of Panda, but in the meantime, another workaround (instead of setting your LANG variable to āen_US.UTF-8ā) will be to leave your LANG variable set where you like it, but set the variable LC_NUMERIC to āCāāthis tells the system that you want to get all of the language properties except for the numeric decoding, for which you want to use the āCā decoding (which is the same as the English convention).
Please let me know if this workaround seems to work for you, since that relates to the fix that I have put in.