I was playing with the bullet samples and 03_heightfield.py initially failed to work for me – it would not load the elevation.png. VSCode was to blame – setting the cwd elsewhere. However, I realized there is an inconsistency between the loader for egg files and PNMImage and Filename.
loader.loadModel() finds files relative to the python file directory
Filename finds files relative to the cwd. IDEs like VScode are rather annoying in trying to lock you to folders and messing with the cwd. This does not break loading eggs but it does break loading images with Filename if the python file and the cwd are not the same.
Most of the provided demo code assumes the python main file location and the cwd are the same and puts images in a directory hanging off the code directory.
Secondly, Filename is unable to translate standard windows paths without an extra step. It gets stuck on things like c:\ I know Panda prefers /c/ but it should be able to cope with the Windows standard and realize it needs to convert. You can force 03_heightfield.py to behave regardless of the cwd with something clunky like this:
I think that PNMImage() should be able to cope the same way loader.loadModel() does – they should be consistent. One option would be a keyword for PNMImage() to make it behave like loadModel() or some other way to achieve consistency.
(I’m guessing that by “loadImage” you mean “loadTexture”…?)
I think that “loadTexture”–like “loadModel”–searches for files on the “model-path” (which likely includes–but may not be limited to–the Python file directory). (See this manual page for more.)
“Filename”, however, is more general, loading files simply from wherever the developer specifies–hence it having different behaviour.
That said, adding a keyword-parameter–I’d suggest to Filename–in order to specify that it search the model-path rather than assuming general usage might not be a bad idea.
It was a typo – I meant loader.loadModel (Edited above). However, the issue is unchanged. I prefer the way loader.loadModel works in that it will search standard places including subdirectories of the file where the Python itself is.
Also - I find Filename doesn’t work very well anyway – it can’t deal with standard
windows naming conventions like “c:” (see above). In my opinion this defeats the purpose of Filename if it can’t insulate users from different conventions properly.
loadModel resolves paths relative to the model-path, for anything that takes a direct path, you can use getModelPath().resolveFilename().
You can just put the cwd on the model-path, by adding model-path . in Config.prc.
The reason we don’t do that by default is to prevent users shooting themselves in the foot. Many make the mistake of loading assets relative to the current working directory, which stops working when they build their game and double-click on the built executable.