Rtrace -ot with mirrors

radiance-general
1

I’ve encountered an apparent bug where using the rtrace -ot flag when there are mirror sources in the scene results in a segmentation fault. I am using an intel mac (10.14.6), and tried a number of compilations (including my own and precompiled from LBL git, including the latest, oldest and 5.3 official). I found one old version that works, but everything newer seems to segfault. I also tried it in a linux/docker container with the same result, that version is compiled from source downloaded in the past week. If I remove the mirror source(s) or the t/T from the output, the trace works fine.

Version that works:

RADIANCE 5.3a lastmod Sat Jul  6 13:23:48 CEST 2019 by stephenwasilewski on Stephens-MacBook-Pro.local

Oldest version that segfaults (which predates everything available precompiled on the LNL git):

RADIANCE 5.3a lastmod Mon May 11 13:19:27 CEST 2020 by stephenwasilewski on Stephens-MacBook-Pro.local

here are the steps to (hopefully) reproduce:

test.rad:

void light solar 0 0 3 100 100 100
solar source sun 0 0 4 0 -1 1 0.533000
void mirror refl 0 0 3 .5 .5 .5
void plastic test 0 0 5 .5 .5 .5 0 0
refl polygon test.1540 0 0 12 0 10 10 0 10 0 10 10 0 10 10 10
test polygon test.6457 0 0 12 10 0 0 10 10 0 0 10 0 0 0 0

commands:

oconv test.rad > test.oct
echo 5 5 5 0 0 -1 | rtrace -i -h -w -ovTMpv box.oct

expected result:

	solar	0.000000e+00	0.000000e+00	0.000000e+00	1.000000e+02	1.000000e+02	1.000000e+02	
		solar	0.000000e+00	0.000000e+00	0.000000e+00	1.000000e+02	1.000000e+02	1.000000e+02	
	refl	5.000000e+00	1.000000e+01	5.000000e+00	5.000000e+01	5.000000e+01	5.000000e+01	
test	5.000000e+00	5.000000e+00	0.000000e+00	7.208992e-03	7.208992e-03	7.208992e-03	
7.208992e-03	7.208992e-03	7.208992e-03
2

Hi Stephen,

Thanks for identifying and reporting this bug, and giving a simple way to reproduce it. I realized this issue was introduced just over 2 years ago, and no one found it until now.

I had changed the start-up order in rtrace to make it so sources aren’t initialized when they aren’t needed, and neglected to assign the “putreal” function pointer before it was needed for virtual sources. This is why it’s so difficult to create unit tests that explore all the corner cases…

I just checked a fix into the CVS head, and it will get put into new packages next weekend, but you can grab it whenever.

Cheers,
-Greg

3

Hi Greg,

Thanks, That fixed it.

1 Like
4

Hi Greg,

So it turns out there might be a new problem. The output now includes a large number of initial rays not related to the actual trace.

this:

echo 0 0 0 0 0 0 | rtrace -i -h -w -ovTMpv box.oct

should yield 1 line of a null result, but instead yields 8193 lines if there are mirrors in the scene. It seems this is related to the direct pretest, as it seems to always equal 1 + 16 * dp in this simple scene. In my actual scene iit seems to hover around 4500, but varies call to call.

I went back and checked and the old version does not have this problem.

5

Ah. Interesting. I didn’t remember what it did before as far as pretests went, whether those were traced or not. I suppose they shouldn’t be. I’ll look into correcting this back to the old behavior. Hopefully, it’s not too difficult.

ADD: Just checked in a fix - rt/rtrace.c v 2.104

1 Like