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

1112 · January 13, 2021, 2:58am

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?

Dr_Roland_Schregle · January 13, 2021, 5:29am

Hi,

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!

–Roland

1112 · January 14, 2021, 1:29am

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?

Dr_Roland_Schregle · January 14, 2021, 10:42pm

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,

–Roland

1112 · January 16, 2021, 3:40am

Hi,Roland
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

skyVmtx.sky

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

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

Dr_Roland_Schregle · January 16, 2021, 4:38pm

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.

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,

–Roland

Mingbo · January 18, 2021, 1:30am

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

1112 · January 18, 2021, 1:34am

Hi,Roland

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

/usr/bin/ld: cannot find -lrtrad

Dr_Roland_Schregle · January 18, 2021, 2:37am

Thanks for the info, Mingbo!

Dr_Roland_Schregle · January 18, 2021, 2:45am

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,

–Roland

1112 · January 18, 2021, 9:52am

Hi,Roland

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.

Dr_Roland_Schregle · January 18, 2021, 4:10pm

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.

–Roland

Greg_Ward · January 18, 2021, 4:39pm

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.

Dr_Roland_Schregle · January 18, 2021, 4:56pm

Thanks, Greg.

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

–Roland

1112 · January 19, 2021, 1:39am

Hi,Roland

Below is the head information of generated photon map.

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

Dr_Roland_Schregle · January 19, 2021, 2:08am

Hi Yongqing,

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

Thx & best regards,

–Roland

1112 · January 19, 2021, 2:42am

Hi,Roland

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!

Yongqing

1112 · January 20, 2021, 12:36am

Hi,@Greg_ward,@Dr_Roland_Schregle

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.

Dr_Roland_Schregle · January 20, 2021, 10:52pm

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!
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,

–Roland

1112 · January 21, 2021, 9:05am

Thank you,Roland!

Follow your guidance,the waring from mkpmap exactly disappeared!