[Radiance-general] Re: physically-based landscapes

Wed, 18 Jun 2003 22:39:13 -0700

Hi Santiago,

Thanks for sending me your files.  It really does help to see the 
actual problem being worked on.

The answer to your different values turns out to be quite simple, and 
it is related to the problem I mentioned with the sun being too small 
to capture with the default indirect parameters.  See my inline 
comments, below.

-Greg

> From: "Santiago Torres" <[email protected]>
> Date: Tue Jun 17, 2003  7:26:52  PM US/Pacific
> To: "Greg Ward" <[email protected]>
> Subject: RE: physically-based landscapes
>
> Hello Greg,
>
> I am attaching a gziped tar of the files I used. I included the two sky
> deffinitions (original and mapped) and the sky_orig.pic that maps into 
> the
> second sky (I reduced its size to half to make it lighter)
>
> I`m also including a simple room scene where I tried the direct sun
> renderings with the three options (normal, mapped sky and the 
> fisheye.cal
> method as you described) in case you are interested in seeing these 
> too.
> Afterwards I thought that, if I take images of the real sky, the sun 
> will be
> added separately anyway, as I would be taking it with a different 
> camera and
> ND filters, so I hope it would work as a gensky sky.
>
> The readme file has an account of the files and commands I used. I 
> hope it
> is clearly explained.
>
> Thank you for your help.
>
> Santiago.
----------------------------------
Santiago's attached README:

> Note on the files and commands used
>
> mapsky.cal is a variation of the fisheye.cal file.
> The only differences are a rotation in the x axis and an extra "if" to 
> render ground at constant illuminance.

The following won't affect this particular test, but you need to change 
the if calls in this file, as returning coordinates of (x,y)=(0.5,0.5) 
as you do for the ground will actually return the zenith luminance.  
You should return (x,y)=(0.05,0.05) instead to be sure to get the bit 
of ground in the corner of the image.

> sky_orig.rad and sky_orig.pic are as in normal procedure, i.e. with 
> !gensky.
>
> sky_alter.rad is the mapped sky.
>
> room.rad is a simple scene where I tried the window sun patch, etc.
> And room_greg.rad is an application of the method you described to map 
> the window_view image into the window.
> windview.pic and windview_lores.pic are the corresponding images.
> I include this ones in case you are interested, the problem with the 
> sun patch I will try to solve it as you suggested.
>
> Commands I used:
>
> oconv sky_orig.rad > sky_orig.oct
> rpict -vta -vd 0 0 1 -vu 0 1 0 -vv 180 -vh 180 -ab 1 -x 2048 -y 2048 
> sky_orig.oct > sky_orig.pic
> oconv sky_alter.rad > sky_alter.oct
> echo "0 0 0 0 0 1" | rtrace -h -I+ -w -ab 1 sky_orig.oct
>
> 3.719349e+02    3.719349e+02    3.864030e+02
>
> echo "0 0 0 0 0 1" | rtrace -h -I+ -w -ab 1 sky_alter.oct
>
> 5.205561e+01    5.205561e+01    6.651048e+01
>
> which is approximately 7 times lower for the alter sky (when I was 
> expecting both to be the same)

The discrepancy is due to the fact that the gensky command you used 
includes a description of the sun, which is included as part of the 
direct  calculation in rtrace to get the result of 372.  However, when 
you use the picture of the sky in place of the gensky output, you are 
leaving rtrace to find the itty bitty sun disk in the great big sky 
with only 512 samples (the default value of -ad).  If you change the 
rtrace parameters to -ad 16000 -as 800, you get the following result, 
instead:

echo "0 0 0 0 0 1" | rtrace -h -I+ -w -ab 1 -ad 16000 -as 800 
sky_alter.oct

3.682684e+02    3.682684e+02    3.827203e+02

Which is obviously a lot closer.  Alternately, you can change your 
gensky command by adding a -s option to exclude the direct solar, and 
again your values will agree, this time closer to the 52 watts/m^2 you 
get from integrating the sky without including the sun.

>
> For the room scene:
>
> oconv sky_orig.rad room.rad > scene_orig.oct
> rpict -vp 1.5 2.9 1.5 -vd 0 -1 0 -vv 100 -vh 100 -ab 2 scene_orig.rad 
> > scene_orig.pic
>
> oconv sky_alter.rad room.rad > scene_orig.oct
> idem rpict...
>
> oconv room_greg.rad > scene_greg.oct
> idem rpict...

I realize now why the room_greg.rad gets roughly the same answer as the 
original room where the sky is modeled correctly -- it's because of the 
trick I suggested of reducing the resolution of the illum's modifier 
with pfilt.  Since pfilt works in floating point, it correctly computes 
the average over each area, including the sun's disk (no matter how 
small), and thus your window illum source has a distribution 
corresponding to sun streaming in.  There will likely be some artifacts 
due to source sampling, which can be reduced by decreasing the value of 
the -ds option, but it might be OK as it is.

If it were my model, I'd still want to model the sun separately 
somehow, which would probably mean using a glass material for the 
window illum's alternate type (as in room.rad) and modeling the sky 
more as you have done in sky_alter.rad.

>
> I hope I`m not forgetting anything, and that it`s clear. Thank you for 
> your interest.
>
> Santiago.
>
>> -----Original Message-----
>> From: Greg Ward [mailto:[email protected]]
>> Sent: Wednesday, June 18, 2003 1:49 AM
>> To: [email protected]
>> Cc: [email protected]
>> Subject: Re: physically-based landscapes
>>
>>
>> Hi Santiago,
>>
>> I could make some guesses as to what's going on with your model, but
>> unless I see the actual files involved, I'm not going to be able to
>> figure it out.  Can you put together a gzip'ped tar file and mail it 
>> to
>> my account directly <[email protected]>.  I'll have a look.  Be sure to
>> include the list of commands you've been using, what you expected, and
>> what you got.
>>
>> Thanks,
>> -Greg