[Radiance-general] irradiance calc that ignores incident angle

[Stephen Wasilewski]

Thaks Greg,  I ended up trying something like this (correct syntax for
anyone who is curious, the -u 10 allows for a standard input read within
the loop):

while read -u 10 p;
do
rsensor -vp $p -h -rd 100000 -vd 0 0 1 -vu 0 1 0 -n 8 -w -ab 0 uniform.dat
test.oct
done 10<vpts.txt

but it is very slow (since it is making lots of successive calls to rsensor
and has to load the octree into memory each time).  Ultimately, I realized
that for my purposes I could just correct the source with 1/cos and then
use rtrace normally.

Stephen Wasilewski
*LOISOS *+* UBBELOHDE*
- - - - - - - - - - - - - - - - - - - - - - - - - - -
1917 Clement Avenue  Building 10A
Alameda, CA  94501 USA
- - - - - - - - - - - - - - - - - - - - - - - - - - -
510 521 3800 VOICE
510 521 3820 FAX
- - - - - - - - - - - - - - - - - - - - - - - - - - -
www.coolshadow.com

On Fri, Jun 30, 2017 at 5:29 PM, Greg Ward <gregoryjward at gmail.com> wrote:

> It sounds like you want to be able to specify a list of points and
> orientations at which to compute this uniform (non-cosine) average.  In
> other words, replacing the -I option in rtrace with something that computes
> a uniform hemispherical integral.
>
> You could take the first part of your command to generate the points and
> normals.  Then, call  rsensor in a loop like so:
>
> vwrays -fa refs/L2.hdr refs/L2.zbf | rcalc -of -e
> '$1=$1;$2=$2;$3=$3+2.5;$4=0;$5=0;$6=if($3-1,1,0)' > orig_dir.txt
>
> foreach orig_dir ( " `cat orig_dir.txt` " )
> rsensor -n 8 [rtrace options] [-rd $N1] [-dn $N2] -vp $orig_dir[1-3] -vd
> $orig_dir[4-6] uniform.dat test.oct >> results.txt
> end
>
> (I apologize that I don't know the bash syntax for the loop.  I never
> really understood bash.)
>
> If you really, really want to use rtrace, you can instead use the above
> loop with "." in place of the octree to create a really long list of ray
> samples, which you can give to rtrace and send it's output again to total
> using an option to average every N values.  The result would be about the
> same, though rsensor is more accurate/efficient because of the separate
> source sampling, which you can control with the -dn option.
>
> Cheers,
> -Greg
>
> *From: *Stephen Wasilewski <stephen at coolshadow.com>
>
> *Date: *July 1, 2017 12:25:51 AM GMT+06:30
>
>
> Greg,
>
> the reason I want to call rtrace is because I want to run the uniform
> distribution for a large number of points/pixels
> is there a way to feed a points file into either of your example commands
> to run the sensor for all points (and accumulate result for each point).
> I'm looking to be able to do something like this:
>
> rtrace -n 8 -ffc -w -I -ov -x 3000 -y 1163 -ld- [options] test.oct  <
> test.pts  > test.hdr
>
> or
>
> vwrays -fa refs/L2.hdr refs/L2.zbf | rcalc -of -e
> '$1=$1;$2=$2;$3=$3+2.5;$4=0;$5=0;$6=if($3-1,1,0)' | rtrace -n 8 -ffc -w
> -I -ov -x 3000 -y 1163 -ld- [options] test.oct > test.hdr
>
> and have it run fairly quickly, but with a uniform distribution.
>
> thanks,
>
> Stephen Wasilewski
> - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> On Thu, Jun 29, 2017 at 7:20 PM, Greg Ward <gregoryjward at gmail.com> wrote:
>
>> Hi Stephen,
>>
>> The simplest method is to use rsensor to generate a set of uniformly
>> distributed rays over the hemisphere, which you can re-use as often as you
>> like.  The sensor file below specifies a uniform distribution out to 90°,
>> and even samples a few rays below the horizon  Let's call it "uniform.dat":
>>
>> degrees 0 90 180 270
>> 0 1 1 1 1
>> 5 1 1 1 1
>> 85 1 1 1 1
>> 90 1 1 1 1
>> 95 0 0 0 0
>>
>> You can run rsensor on the above file and either use it to call rtrace,
>> or since you seem to want to call rtrace yourself, create instead a set of
>> sample rays:
>>
>> rsensor -h -rd 100000 -vp 0 0 0 -vd 0 0 1 -vu 0 1 0 uniform.dat >
>> uniform_znorm_samp.txt
>>
>> You can then give this as input to rtrace with whatever model you like:
>>
>> rtrace -h [options] octree < uniform_znorm_samp.txt | total -m
>>
>> I've passed the output to total with the -m option, assuming you just
>> want the average result.  If you're willing to call rsensor in place of
>> rtrace, you can shorten the calculation time with:
>>
>> rsensor -rd 100000 -vp 0 0 0 -vd 0 0 1 -vu 0 1 0 uniform.dat [rtrace
>> options] octree
>>
>> This has the added advantage of sampling light sources directly (unless
>> you set -dn 0), and it even supports the -n multiprocessing option on
>> Unix.  You will need to divide the result by the hemispherical solid angle
>> (2π), or else change all your sensor file values by 1/(2π) to get a uniform
>> average.
>>
>> I did spent quite a bit of time writing and debugging rsensor for just
>> this sort of thing, so you may as well use it.  (Thanks to Zack Rogers for
>> specifying the problem and funding the initial work, and to David
>> Geisler-Moroder for doggedly testing the code & helping me sort out its
>> many issues.)
>>
>> Cheers,
>> -Greg
>>
>> *From: *Stephen Wasilewski <stephen at coolshadow.com>
>>
>> *Date: *June 30, 2017 4:18:34 AM GMT+06:30
>>
>>
>> I'm curious if anyone knows of a way to simulate a sensor point that has
>> a constant response (not cosine corrected) for all incident angles (at
>> least over a hemisphere).  I know I can do this with an angular fisheye
>> image and I assume I could use rsensor, but i would like a way to do this
>> with a single rtrace or rpict calculation.  Applications include:
>>
>> 1. measuring direct normal irradiance (when I know the source is small
>> (cos(x) ~ 1), but not the incident angle.
>> 2. calculating percent of a sky/source description that is visible from a
>> point.
>>
>> The one though I have is to place an analysis plane with a BRTDfunc
>> material assigned and then do a radiance calc looking at the plane, but
>> this only works for the 1st case, where it is part of the direct
>> calculation.  For the second case I tried making a bsdf with bsdf2ttree (or
>> bsdf2klems) but it seems to introduce a lot of sampling error and doesn't
>> appear to be working quite right.
>>
>> BRTDfunc approach:
>>
>> #cal file:
>> r(x,y,z) = 1/(x*NxP+y*NyP+z*NzP)/PI;
>>
>> #material:
>> void BRTDfunc test
>> 10 0 0 0 0 0 0 r r r test.cal
>> 0
>> 9 0 0 0 0 0 0 0 0 0
>>
>> BSDF approach:
>> #cal file:
>> rdif(ix,iy,iz,ox,oy,oz) = if(oz*iz,1/(ix*ox+iy*oy+iz*oz)/PI,0);
>>
>> #bsdf2ttree:
>> bsdf2ttree -t3 -g 7 -forward -f test.cal rdif > test.xml
>>
>> #material:
>> void BSDF test
>> 6 0 test.xml 0 1 0 .
>> 0
>> 0
>>
>> Either way, this feels like an inelegant approach, so anyone have a
>> better idea or a way to get this working for a diffuse calculation?
>>
>> Stephen Wasilewski
>>
>>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general at radiance-online.org
> https://www.radiance-online.org/mailman/listinfo/radiance-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20170703/5686a06f/attachment.html>