genBSDf cannot find


I am working on using genBSDF to create a custom BSDF based on a geometry that I have created in Rhino. Using Honeybee modules in Grasshopper, I have created a .rad file of the geometry which then is translated into a BSDF file.

When I run the genBSDF script it returns the following error:

Although from what I can see I have this file located in C:\Radiance\bin. I am updated to the latest version of Radiance. Are there any thoughts here? Working on this a few months back (before updating Radiance) I was able to generate BSDF files.

Thank you in advance for your help!


Hi John,

The file “” should be located in C:\Radiance\lib. If it’s in that folder but isn’t being found by rcontrib, then your system’s RAYPATH variable may not be set up. Edit your environment variables and make sure that C:\Radiance\lib is part of your RAYPATH.


Hi Nathaniel,

Thanks for your help! It looks like it was added to the RAYPATH for the system, not the user.

After solving this error, I am looking at this now:

Not sure if you have seen this error before “Could not wrap BSDF data”?



Yes, the user RAYPATH supersedes the system RAYPATH on Windows. I usually suggest to delete the user RAYPATH variable so that the computer is forced to use the system RAYPATH.

The “Couldn't wrap BSDF data” error looks like a separate issue, so I suggest looking at that thread to start.


Thanks for your help, Nathaniel!

Hey Greg,

Thanks for your reply. I took a look at the tb.dat file located in the temp folder. It is a completely empty file.


Did genBSDF fail right away, or did it take some time before reporting this error?

Either there’s something wrong with rfluxmtx tool, or the inputs genBSDF is sending to it. It’s difficult to know. What happens if you run “rfluxmtx” by itself on the command line? What about running “rcontrib -version”?

My apologies on the delay, got caught up with some other work. genBSDF does not fail right away. It spends about 15 sec. in the initial line of code and an addition 2 mins in the “Recover using:” line before returning the error.

Here is what I get when running rfluxmt an rcontrib:

The .mtx file that is created in the folder is empty after running this.

Well, this seems normal except for the genBSDF error you are getting. Unfortunately, it’s impossible for me to debug without your input file. If you want to post that, I can try running your genBSDF command, myself. It might not uncover the problem if it’s specific to your system, but it’s all I can think to try.

Ok thanks, Greg. Here is the RAD File that I am trying to create a BSDF from. I appreciate your help!!

Well, it seems to work fine with the Unix build, so I’m not sure what’s going on with the Windows version. I have no way to debug that, unfortunately. Maybe someone else can give it a try.

Some advice on your model – your actual geometry (according to getbbox) goes from a Z-value of -0.25 to -0.1. You really should make the maximum Z closer to 0 if you can. I suggest using:

xform -t 0 0 0.0999 70-open.rad > 70-open-moved.rad

I would also adjust your bounds so you don’t go all the way to each edge, which causes leakage (a lot of leakage with your original positioning). I used the following options in my test:

genBSDF +geom inch -r “-ab 1 -ad 200 -lw 1e-4 -st .01 -ss 32” -dim 2 24 -24 -2 -0.16 0 70-open-moved.rad > 70-open-moved.xml

This seemed to give more reasonable results.

Hi, John,
I ran into the same problem as you do. I am wondering if you have solved this in Windows version.


Hi Green,

Having another look at this, and I don’t know if @JohnSloane ever resolved his issue, the most likely culprit is a misbehaving fscanf() function. If you get the same failure as John, can you package together the contents of the temporary directory pointed to by genBSDF as a zip file and post it somewhere for me to look at?


Hi Greg,
sorry for the late response. It is a great honor to receive your reply. The link is attached below. I have tried to put the .rad file in Linux, and it worked out fine. I really hope you can help find the solution to the Windows version.


It seems as though genBSDF is failing in the “rmtxop” call, as the output of rfluxmtx is OK. Try running the following commands on your system:

rmtxop -fa -t -c 0.2651 0.6701 0.0648 behind.dat > test1.mtx
getinfo - < test1.mtx > test2.dat

If the contents of test1.mtx are empty, then the trouble is rmtxop. If test1.mtx has data but test2.dat does not, then the trouble is the getinfo command. If neither one is empty, then there must be a problem somewhere else in the script.


Hi Greg,
The test file is attached below. test1.mtx has data but test2.dat does not. How can I fix the trouble of the getinfo command?


Is it possible that you are accessing an older version of getinfo on your system? Can you find out which executable you are actually calling, and check the date on it?

Sometimes, old versions of Radiance commands come with installations of some other package, such as DAYSIM or OpenStudio. Occasionally, these bring along commands that run but do not produce correct output, either because the newer commands have new features, or there is a bug or problem with the old command.

If you explicitly run the getinfo command that is in the same executable directory as the other new Radiance commands (i.e., “rtrace -version” gives you 5.4a) and it still has this problem, then we need to fix a bug in the latest Windows version.


Hi Greg,
After I run “rtrace-version”, it turns out that I am using an older version. :sweat_smile: I tried to replace the bin and lib folders in Daysim with the latest radiance version, and now the genbsdf command worked out fine! Will the simple replacement operation influence the future use of daysim?


I am relieved to hear that it was just a command version issue, and that you were able to solve it. I can’t speak to the behavior of DAYSIM if you change your executable directory search order to find newer commands, first. It will probably be OK, because most changes made to Radiance are backwards-compatible, but I cannot offer you any guarantees. Best to ask folks on the DAYSIM sub-discussion list on that one. DAYSIM is not really supported anymore.

The getinfo command was updated to handle Windows cr-lf end-of-line sequences some years after the last DAYSIM distro, and this is the issue you ran into with genBSDF.

Thanks a lot, Greg :smiley:. Really Sorry for the late reply. too busy with work for the last two months.