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
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 landscapesHello 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.oct3.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.picoconv 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 landscapesHi 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
Thank you very much for your reply. It is perfectly clear now. I was not
thinking that rtrace does a sampling calculation as well. As I mentioned, I
plan to take measurings of the sun separately anyway, so I will include it
in a different source (and not in the same picture as I had first thought) I
hope to get some results I can share with the group.
Thanks again and best regards,
Santiago.
----- Original Message -----
From: "Greg Ward" <[email protected]>
To: "Santiago Torres" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, June 19, 2003 2:39 PM
Subject: Re: physically-based landscapes
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