Reading rtrace binary file

Hello I am new to radiance and appreciate your help.
I am trying to rtrace with many points (I need the power and distance of almost all possible paths). Because output files get very large I opted for the binary output.
When I read the binary file I first read it as uint8, and at the beginning of each row I am counting the numbers of reflections by counting how many bytes have a value of 9 (ascii for tab).
After the tab I typecast the rest of the row to single precision values.
my problem: This logic seem to work fine on small files but on large files the chance of a single precision number to to start with a byte with value = 9 is not negligible, and my code fails.
is there an option to change the ‘Tab’ separator with a “nan” float value or any value which can not be misinterpreted. Any other idea is of course more than welcome.

Example rtrace command:
’ /Users/dannussinson/MPI-SIM/OptiCore/+radMat/rtrace -n 1 -lw 1.000000e-02 -x 1000 -y 1000 -ad 100 -av 0.0 0.0 0.0 -o~tVp -h -faf -ab 1 -dj 0 -aa 0.000000 -as 0 radfiles/testWithWall_tmp.oct <radfiles/testWithWall_tmp.pts >/tmp/DATMPI_test.bin ’

Hi Dan,

Seems like you are “diving into the deep end” on this. I would recommend using an output option like -o~~t~Vp, so you get two tildes followed by tabs as a ray tree terminator, and however many tabs followed by a tilde and a tab before your floating-point ray branches. Whether a tilde-tab sequence will ever be found in a 32-bit float is an open question. I remember I used three tildes in rtcontrib before it was rewritten, just to make sure confusion would be very unlikely, but they start to add up…


Hi Greg,
Thank you so much for the prompt reply.
I didn’t realize I can concatenate ‘~’.
I believe this can solve my problem or at-least make it very improbable.
Still, wouldn’t a cleaner solution be using NaN with the same precision as the output?
Wouldn’t it eliminate the chances of confusion and as an added benefit I could read the entire file as float. (I am using Matlab to call Radiance and looping through the file is slow).

Sending SNANF would work in your particular circumstance, but not with other options to rtrace, such as -faa or -fad or when you mix material names with IEEE values. Just try with the double-tilde approach and see if you have any issues. I was using it for years with rtcontrib and it seemed to work reliably.

Thanks again Greg, this has been very helpful and the code now works great.
I could still shave about ~4 seconds of runtime if I was able to make sure all “place holders” are multiples of 4 bytes so I can directly read the binary as float.
can I do it using the output option string?


No, I’m afraid there’s no option for that. You’re stuck with getc() unless you feel like modifying rtrace.c yourself.

I did actually modify rtrace to deal with this situation. Instead of tabs, I just print out the number of tabs. It’s a very easy change to do (once you’re over the issues of setting up a development environment, which took most of the time…)

Cool – that’s why there’s source code! If you record your change as a contextual patch (read the man pages for “patch” and “diff” – I think it’s possible), then you can reapply to new versions of the code more easily.