Why can't I catch the reflected light of curtainwall with point based simulation

Hi, everyone

I am modeling the reflected light’s impaction of curtainwall on sourrounding buidings using radiance.I want to get the area of affected by refelected light,so I decided to use point based simulation.And I also assgined mrrior type material to the curtain wall,however, I cannot see the refelected light,while I got the reflected light by image based simulation. below is the simulation result:

My command line:
rtrace -I -h -dp 64 -ds 0.5 -dt 0.5 -dc 0.25 -dr 0 -st 0.85 -lr 4 -lw 0.05 -ab 2 -ad 1000 -as 128 -ar 300 -aa 0.1 -af GlareStudy.amb -e error.log GlareStudy_RAD.oct < GlareStudy_1.pts > GlareStudy_1.res

I guessed that it was because the point based simulation send rays only in normal direction of surfaces.

And I have another question,that is ,if I use photon map (forward trace method) to perform point based simulation,can I get the reflected light?


as far as I know, the mirror material doesn’t work with curved surfaces. To answer your second question, the photon mapping extension should do the job here, as it was developed specifically for complex specular materials (BSDFs) and geometries.

Beyond the rather dry manpage for mkpmap, your RADIANCE distribution should also include a PDF photon map manual in ray/doc/pdf to get you started. You will need to specify the -apc option to mkpmap for caustic photons, in addition to -apg for global photons.

Hope this helps. Let me know if your run into any issues. The parametrisation isn’t particularly intuitive and requires some experimentation. Good luck!


1 Like

Thank you,Roland,I have got the reflected light using photon mapping.

But I ecounted another problem that is how to performance annual iluminance simulation for photon mapping method.Is matrix based daylight simualtion(2 phase method) also suitable for it?

Hi Yongqing,

Nice going! Photon mapping does infact support daylight coefficients. You can generate a contribution photon map with mkpmap’s -apC option, pass it to rcontrib to generate the coefficients, and then scale these with genskyvec and dctimestep:

mkpmap -apC <contribPmap> ... <octree>
rcontrib -ap <contribPmap> -o -V- coeffFileSpec> -m <mod> ... <octree>
genskyvec ... | genskyvec | dctimestep <coeffFileSpec>

I’ve included an example in Appendix 3 of my out-of-core photon mapping paper with daylight coefficients. Of course there’s probably other ways.

There a few caveats to note here: Contribution photon mapping requires lots of photons; the number scales with the number of sun positions or sky conditions. Beyond 200M photons, the default kd-tree data structure gets pretty slow; in that case you’ll need to use the out-of-core photon mapping data structure. Currently this has to be enabled during compilation. Let me know if you run into these limitations.

I’m currently working on a next evolution of contribution photon mapping, which will be precomputed and compressed. This is gonna take a while tho.

Hope this helps. Good luck,


1 Like

When I executed below command, warning “light source is not found” was given,and many warings reported that zero ray direction in local hit.

onconv skyVmtx.sky material_GlareImage.rad GlareImage.rad > glareImage.oct
mkpmap -apC contrib.pm 200m glareImage.oct



void glow sky_mat
1 1 1 0
sky_mat source sky
0 0 1 180

void glow ground_glow
1 .8 .5 0
ground_glow source ground
0 0 -1 180

Hi Yongqing,

The warning about missing light sources is normal if you’re only using glow; mkpmap actually treats these as regular light sources (i.e. they always contribute to ambient illumination).

The warning about zero ray direction is more subtle and is an unfortunate (in retrospect) consequence of the fact that the incident directions of the primary photon hitpoints aren’t stored by default to save memory. The default build is primarily intended for simulating sun positions with different modifiers. Hence the direction passed to the binning function (which you appear to be using here) defaults to zero.

To enable directional binning, you’ll have to recompile in ray/src/rt with:

rmake clean
rmake OPT+=-DPMAP_PRIMARYDIR install

I realise this is inconvenient, and I will revise the defaults on the next release (hopefully) with the precomputed contribution photon map. I’m also considering making the out-of-core photon map the default – once I get it to work under Windows. :roll_eyes:

Sorry for the inconvenience. Let me know if you have any means to recompile, otherwise I’ll have to see about issuing a build with new defaults in short order. (@Rob_Guglielmetti Would this be automatically included in your builds?)

Best regards,


If you push updates to CVS, it will be included and released next weekend.


When I use rmake to recompile in ray/src/rt, I got an error:

/usr/bin/ld: cannot find -lrtrad

Thanks for the info, Mingbo!

Hi Yongqing,

sorry, I forgot you’re building from scratch. In that case you’ll have to run

makeall install OPT+=-DPMAP_PRIMARYDIR

in the ray directory. This rebuilds the entire RADIANCE suite. You may want to precede this with a

makeall clean

to remove old binaries.

Good luck,



I use your command to recompile in the ray directory.And most of the source code were compiled successfully,only one error appeared:
cp ./meta2tga ./pexpand ./psort ./cv ./psmeta ./plotin ./x11meta ./bgraph ./igraph ./dgraph ./gcomp ./plot4 ./meta2bmp /usr/local/bin
cp symbols.met vchars.met boxw.plt curve.plt line.plt scatter.plt cartesian.plt function.plt polar.plt standard.plt /usr/local/lib/ray/meta
cp: target '/usr/local/lib/ray/meta' is not a directory
make: *** [Rmakefile:35: install] Error 1

However,I didn’t think this error would affect the run of mkpmap.
And I use the mkpmap after being compiled to run as following command:
mkpmap -n 7 -apC contrib1.pm 20m GlareImage.oct

But the waring “warning - zero ray direction in localhit” still appeared.

And I was sure that the version of mkpmap I runned was the recompiled one.

Hi Yongqing,

that’s strange. i suspect it’s still the old version too, likely because makeall bailed out. I have the meta directory, so not sure why it’s missing on your end. (@Anyone Any ideas?)

Check the output of getinfo on the generated photon map; the new build should have a VERSION field suffixed with “D”. These are feature flags indicating what’s embedded in the photon map file format.


Try removing whatever /usr/local/lib/ray/meta is and running

mkdir /usr/local/lib/ray/meta

I don’t know what happened on your system. This should as you surmise have nothing to do with the errors from mkpmap, however.

Thanks, Greg.

And indeed it shouldn’t affect the rest of the build – unless of course makeall bails out before installing the binaries.



Below is the head information of generated photon map.

It exactly included a VERSION field suffixed with “D”.

Hi Yongqing,

can you please post your rcontrib command line? I’m gonna have to reproduce this first.

Thx & best regards,



Below is my rcontrib command line:
rcontrib -I+ -ap contribnew.pm 80 -y 264060 -n 8 -dp 64 -ds 0.5 -ar 300 -aa 0.1 -ad 1000 -lw 1.0e-3 -dc 0.25 -faf -e MF:1 -f reinhart.cal -b rbin -bn Nrbins -m sky_mat GlareImage.oct < GlareStudy_0.pts > cds.mtx

And I also included my project files:

Thank you!



I have created a meta folder in /usr/local/lib/ray/ and recompile in ray directory,there were no errors during compiling.But the waring from mkpmap still existed.

Hi Yongqing,

thanks for your input. I’ve debugged mkpmap with your scene, and it looks like you’ve triggered a residual (and probably ancient!) bug in the BRDF photon scattering routine – congrats! :wink:
The ray direction wasn’t initialised under certain conditions, which triggered the (legitimate) warning in localhit(). Apparently few folks use BRDF these days.

Note this actually has nothing to do with the missing ray directions in the default contrib photon map; looking at the code again, I can confirm rcontrib actually issues a more explicit warning in this case:

warning - no photon primary directions for bin evaluation; using dummy (0,0,0)! 
Recompile with -DPMAP_CBDM.

(PMAP_CBDM is just a combination of PMAP_PRIMARYDIR and PMAP_PRIMARYPOS to enable full-blown climate based daylight modelling, at the expense of a large memory footprint).

You shouldn’t be getting this warning anymore, although you may still be getting one about missing primary hitpoints, which you can ignore since reinhart.cal ignores the ray’s intersection point.

I have just committed a bugfix into the CVS, which should become available in the nightly build. Alternatively, you can grab the revised source file here, replacing ray/src/pmapmat.c, and recompile with the abovementioned options.

Note I chose not to enable PMAP_PRIMARYDIR per default on this occasion, as this option will be obsoleted with the upcoming precomputed contribution photon map; the photons will then contain pre-binned contributions/coefficients, making the directions implicit.

Thanks again for pointing this bug out, and please keep me posted. Best regards,


Thank you,Roland!

Follow your guidance,the waring from mkpmap exactly disappeared!