Modifying Model/Texture/Sound Paths Procedurally

I know that I can add directories to the model-path, sound-path, and texture-path in the etc/Config.prc file and through a local .prc file. However, I have a situation where I need to add the current working directory to the paths. My program starts up, reads a data path from the command line, and sets the current working directory to that path using os.chdir(pathname). I need the PRC paths to include that working path … That is, I need to ADD the working path to the existing set of search paths …


Thanks in advance,

you can get the current working directory by this piece of code:


(works on all operating systems)
now, if you need to load a model or something else, just type MYDIR+"/mymodel.egg" or something else.

Another way to do this:

import os
from pandac.PandaModules import getModelPath
from pandac.PandaModules import getTexturePath
from pandac.PandaModules import getSoundPath

getModelPath( ).appendPath( os.getcwd( ) )
getTexturePath( ).appendPath( os.getcwd( ) )
getSoundPath( ).appendPath( os.getcwd( ) )

You can use prependPath if you want to have the current working directory at the begining of the search path, and appendDirectory/prependDirectory if you prefer to work with instances of Filename.


Awesome, works great … Thanks so much :slight_smile:

Could someone explain exactly what you mean by “working directory” Is that the directory in which the python file with the run() function? is that where you type “ppython” into the cmd.exe box? What?

Its the directory that the process is pointed to if you do an fopen() with a relative filename.

This may help:

Thanks pleopard. But that explanation on the link was “As clear as mud” I could use that as an example on my blog as and definition of “geekese”

Current working directory may be the canonical example of ‘geekese;’ it’s an old concept, and people I’ve met who already know what it means often find that it is surprisingly hard for new people to understand.

In the days before graphical computer interfaces, the main way people interacted with the information in their computer was via a shell, which was a simple command-line program. That’s the program that gets run if you go to the Run menu in windows and execute ‘command’ or ‘cmd’. In the shell, it is convenient to have a current working directory (also known as the cwd) so when you run commands you know which files are being operated on. For example, when you run the command ‘ppython’, the ppython program actually attempts to open a file that is located at (cwd + ‘’), as opposed to a file named that is at the top of your C drive or one that is in the same folder as the ppython.exe file. In the Windows shell, the current working directory is (by default) printed to the left of the ‘>’ character on the command line. You can change the cwd using the ‘cd’ command (which is short for ‘change directory’).

Programs also have a current working directory, for much the same reason that the shell does: it allows the same code to operate on multiple different files, simply by changing the current working directory. In the case of programs run from the shell (such as by typing ‘ppython’), the current working directory is inherited from the shell itself. So in this example, it would be whatever directory your file was located in. But the program’s current working directory doesn’t have to be the same as the shell that spawned it; a program can change its own cwd, which doesn’t change the cwd of the shell it came from. In Python, there are functions in the os module that allow you to do this.

This short overview leaves some fun questions unanswered (such as ‘What is the cwd of a program spawned from the graphical interface, such as something you run by clicking its icon in the ‘Start’ menu’). But that’s the basics of it.

Best of luck!

Thank you, mtomczak. I have been working with computers since 1976 but a always assumed that the CWD was the directory that you were in when you typed a program name or command at the shell’s command line.

Incidentally, to answer the original post, the easy way to add the “current working directory” to the model-path is with a line like this in your Config.prc

model-path .

The “.” is an old-school convention to stand for the current working directory, whatever it happens to be at the moment.


I’m working on a research API on top of Panda3D that gets installed in the c/Panda3D-x.x.x/python/Lib/site-packages directory. The API comes with a couple frequently-used models and I’m trying to find a way to add the API’s directory to the ‘model-path’ list. Unfortunately, the API is not in the working directory, so something like…

loadPrcFileData("", "model-path .")

…is totally worthless. The only solution I’ve found is to hard-code the full directory path, like…

loadPrcFileData("", "model-path /c/Panda3D-1.5.2/python/Lib/site-packages/myAPI/models")

…which would have to be updated by hand every time a new version of Panda3D came out.

I noticed in the Prc file that there are variables for $MAIN (which appears to be the working directory?) and $THIS_PRC_DIR (which appears to be the directory that prc file is in. What I’d like is some way to say…

loadPrcFileData("", "model-path $PANDA_DIR/python/Lib/site-packages/myAPI/models")

Does anyone know of such a method?

Hmm, I don’t know a way to do that offhand. It does seem like a useful feature to add. We already have the convention for PRC_PATH and plugin-path, it would make sense to extend this to all Config.prc-based search paths as well. (The convention is that the prefix “” on a directory name means roughly the root of the Panda directory.)

Still, doesn’t each version of Panda ship with a prc file that puts its own models directory on the model-path? If that’s true, then you can just reference your models relative to that models directory, right?


EDIT / UPDATE: I tried referencing relative to the prc directory…

loadPrcFileData("", "model-path ../python/Lib/site-packages/myAPI/models")

loadPrcFileData("", "model-path $THIS_PRC_DIR/../python/Lib/site-packages/myAPI/models")

…but both were ineffective.

It does work if I hard-code the second line into my own prc file and place it in the same directory as the others. (Panda3d-x.x.x/etc). Not my first choice, but it’ll work, I guess.