Blender relative paths of doom

Well, this is an issue that caused a lot of headaches to many blenderheads, RELATIVE PATHS, WTH they doesn’t work as expected???!!!

for example i have /home/user/whathever/foo.blend that needs to load a sound from /home/user/whatever/sfx/goo.wav with a python script (for pygame), but the problem is, when i tell the blend file to load “./sfx/goo.wav” blender searches in /home/user/sfx/goo.wav !!!

is there any python function to retrieve the path of the currently open blendfile??

is there any chance to get this corrected for 2.46?

Your code will work in a runtime. When your running a .blend its basing the relative path off of blender.exe not the .blend file.

thats the answer i expected (yes, i used the search feature). But, what if i use a “blank binary” and the blendfile is located in another folder? eg: the runtime (/home/user/something/game) calls a file that is located in /home/user/something/levels/, the cwd would be ALWAYS /home/user/something regardless the blend file i load later with the game actuator

also, that means tha i will not be able to debug my game running it for blender? this problem just needs to be solved

Does using os.getcwd() or os.chdir(path) work in the game engine? You might be able to work with those to make the relative paths work the way you want them too.

yea, but i dont have a way to know were the last .blend file is located (without having to set it manually)


Relative paths are tricky. They work differently on each platform. os.getcwd() can always show you the working directory, which is useful since relative paths are relative to the working directory. Anyway, here’s the breakdown:

On Linux:
If you open Blender directly, then os.getcwd() will return /home/currentuser. So all paths are relative to home/currentuser. Also, if you open the .blend by double-clicking it, os.getcwd() will still return /home/currentuser (at least in Nautilus on Gnome it works that way… don’t know much about KDE, etc.).

However, if you open a terminal and navigate to the directory the .blend is in, then run Blender from that directory, os.getcwd() will return whichever directory you started Blender in. So using your example paths from above, you should do this this:

user@computer:~$ cd /home/user/whatever
user@computer:~/whatever$ blender foo.blend

Blender will then be able to find goo.wav from the relative path ./sfx/goo.wav. Also, as someone else mentioned, if you make a runtime, the relative paths will be correct.

It is important to note that on Linux Blender, the working directory never changes (unless you change it with os.setcwd() or whatever that command is). So if you use a Game Actuator to launch ./levels/level1.blend, the working directory will still be /home/user/whatever, not /home/user/whatever/levels (as it would be on Windows).

On Mac:
I don’t believe that I have run os.getcwd() on a Mac since Blender 2.44, but I imagine the behavior is still the same, since I haven’t heard of a bug fix for the issue. When I did run the function, I was very disappointed with what I found. On Macs it doesn’t matter how you open Blender, os.getcwd() will always return the root level directory (that is, / ). You need to either use absolute paths in your game, or you need to put a configuration file in the root level directory to point to your game directory.

On Windows:
If you open Blender directly, then use File >> Open to open your file, os.getcwd() will return the Blender directory (usually C:\Program Files\Blender Foundation\Blender). However, if you double-click the .blend file in Windows Explorer or My Computer, os.getcwd() will return the directory that the .blend is residing in. The same holds true with runtimes.

On Windows, os.getcwd() changes as you navigate through directories. Imagine your .blend is in C:\Documents and Settings\User\whatever and you use the Game Actuator to launch \levels\level1.blend. From inside level1.blend, os.getcwd() will return C:\Documents and Settings\User\whatever\levels.

My thoughts:
I am of the opinion that the file path behavior needs to be standardized between all operating systems so that we do not have to write different .blends and scripts for each different scenario (as I am having to do for my current game project).

It seems to me that of the three behaviors, the Linux behavior is the most correct. From a structural perspective, the current working directory should always be the directory of the main game file, not the directory of the current .blend. This standardizes relative paths across all .blends in the game, so sound effects will always be in the ./sfx folder of the main game folder, regardless of what directory the working .blend is in.

Hope that helps.


To all: If I was wrong about any of the info above, please let me know so that I can correct it.

ok, so, i will do a shell script to run blender from the game directory, problem solved(?) :slight_smile: (at the game directory)

blender game.blend