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:
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!
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?
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:
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.
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.
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?)
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.
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.
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.
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!
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,