We seem to have a disconnect between the VFS’s notion of the filespace and the loader’s notion. I have a model located at “Assets/models/model.bam”, which is a logical location that is mounted by the virtual filesystem (i.e. no corresponding real directory; this directory is imaged in a multifile).
This call returns ‘1’:
vfs.exists(Filename(‘Assets/models/model.bam’))
However, the loader then fails to load the file:
loader.loadModel(“Assets/models/model.bam”)
:loader(error): Couldn’t load file Assets/models/model.bam: not found on model path (currently: “./Assets/particles;/c/path/to/project/tests;”)
We do an os.chdir call to alter our working directory before importing direct.directbase.DirectStart; could that have something to do with the problem?
Additional research has shown that the loader.loadModel call appears to think it is loading from a relative path rooted to whatever directory contains the Python script that was executed—that is, loader.loadModel is loading content relative to the directory that is listed at sys.path[0]. Modifying sys.path doesn’t alter this behavior. If I craft a relative path that leads from the directory containing my script to the current working directory that was set when the vfs.mount call was executed, things work correctly (but I can’t craft those paths all the time).
Any insight as to how the loader.loadModel call could become divorced from the vfs.exists call would be very helpful!
Actually, it looks to me like the problem is that your model-path does not include the current directory, “.”.
Attempting to load a model by the filename “Assets/models/model.bam” would walk along your model-path and look for a file named “./Assets/particles/Assets/models/model.bam”, or “/c/path/to/project/tests/Assets/models/model.bam”, and so on down all the directories on your model-path. But it won’t match a file named “Assets/models/model.bam” unless you have “.” named as one of the directories on your model-path.
Excellent; we should be able to work from that angle.
This spawns a couple of questions in my mind:
When we mount something with the vfs, how does that interact with the loader? The vfs doesn’t show up on the model path, correct?
Any idea why we’d be missing ‘.’ from the model path? We haven’t edited it in-code; the initial value seems to be based on whatever source file we have launched Panda from, which seems like a strange thing for it to do.
Let me clarify the systems here: the vfs is used to define the filesystem. By mounting and/or unmounting things on the vfs, you can make files appear wherever you want in the filesystem tree, regardless of what files may or may not exist on your hard disk. The initial, default vfs mount exactly mirrors the filesystem provided by the OS, of course, but you can change that however you like.
This has nothing directly to do with the loader, or the model-path, except that the loader uses the filesystem as defined by the vfs.
So mounting a new volume into your vfs doesn’t change the model-path, and the directory you’ve just mounted is not automatically searched by the loader. However, you can load a file from any mounted directory by specifying its full path (which starts with a leading slash), or by putting the appropriate path on your model-path.
Try not to think about the vfs as something magical. The vfs doesn’t interact with any other systems in Panda. Think of mounting a multifile as being the equivalent to simply unpacking the contents of your multifile onto your hard disk in the specified directory. That would have exactly the same effect in Panda as mounting it.
The model-path is primarily defined by the model-path Config.prc variable. It doesn’t have any default value other than what is defined by the Config.prc file(s) that have been loaded. You must have set it at least partly, since it has ./Assets/particles on it, which is presumably one of your own project’s directories, right?