Mkillum bsdf + sample density

Hi Everyone / Greg,

Is there a way to specify both the sample density and a bsdf for mkillum?
For example in the file I feed to mkillum I have:
#@mkillum d=128 d=bsdf.xml

The second Œd¹ seemingly reverts the sample density the default (32). If I
do it the other way I think it omits the bsdf data. Am I missing a trick?

Best,
Andy

···

____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

Hi Andy,

The mkillum sample density is set by the resolution of the BSDF, since there's not much point in using more (or fewer) samples than the transmission data allows.

-Greg

···

From: Andrew McNeil <[email protected]>
Date: December 10, 2009 12:42:43 PM PST

Hi Everyone / Greg,

Is there a way to specify both the sample density and a bsdf for mkillum?
For example in the file I feed to mkillum I have:
#@mkillum d=128 d=bsdf.xml

The second ‘d’ seemingly reverts the sample density the default (32). If I do it the other way I think it omits the bsdf data. Am I missing a trick?

Best,
Andy

Hi Greg,

Thanks for your response, that d= option behavior makes sense now, but leads
to a question about the number of output directions in illum.dat...

My BSDF has 18 "latitudes" and 24 "azimuths" (432 divisions)
The resulting illum.dat is 13x39 = 507 angles

After considering your response, I guess the difference between 432 and 507
is a result of a BSDF pattern that doesn't match the typical radiance
hemisphere division scheme used by mkillum?

I'm guessing that mkillum gets from 432 to 507 by:
sqrt(432/pi) = 12
12*pi = 38
12+1 x 38+1 = 13 x 39 = 507
Am I close? I don't have an explanation for adding one to each dimension.

Finally, the sampling pattern of my BSDF (18x24) and the hemisphere division
used by mkillum (13x39) results in double-sampling of some BSDF angles and
non-sampling of others. In conclusion I would be best served by using the
typical radiance hemisphere division ( m x pi*m ) to generate a BSDF that
"agrees" with mkillum. (or should I stop speculating...)

Andy

···

On 12/10/09 2:55 PM, "Greg Ward" <[email protected]> wrote:

Hi Andy,

The mkillum sample density is set by the resolution of the BSDF, since
there's not much point in using more (or fewer) samples than the
transmission data allows.

-Greg

From: Andrew McNeil <[email protected]>
Date: December 10, 2009 12:42:43 PM PST

Hi Everyone / Greg,

Is there a way to specify both the sample density and a bsdf for
mkillum?
For example in the file I feed to mkillum I have:
#@mkillum d=128 d=bsdf.xml

The second Œd¹ seemingly reverts the sample density the default
(32). If I do it the other way I think it omits the bsdf data. Am
I missing a trick?

Best,
Andy

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

Hi Andy,

That's some good guessing! Yes, the difference is due to the very different sampling strata. I had to check my code (line 444 of src/gen/mkillum2.c) to verify. I don't add 1, but round-off to the nearest integer, rather than the lesser one.

With regards to the mismatch of samples, this does cause some issues, particularly near the zenith, where the altitude/azimuth strata used by mkillum are a very poor match to the Klems/Tregenza strata used for the BSDF. Mkillum does a reasonable job with normalization and sample distribution to make sure some rays go through each little window (and the s= setting can still affect this). So long as the light and distribution are not simultaneously "peaky," it all works out.

Cheers,
-Greg

···

From: Andrew McNeil <[email protected]>
Date: December 10, 2009 4:17:04 PM PST

Hi Greg,

Thanks for your response, that d= option behavior makes sense now, but leads
to a question about the number of output directions in illum.dat...

My BSDF has 18 "latitudes" and 24 "azimuths" (432 divisions)
The resulting illum.dat is 13x39 = 507 angles

After considering your response, I guess the difference between 432 and 507
is a result of a BSDF pattern that doesn't match the typical radiance
hemisphere division scheme used by mkillum?

I'm guessing that mkillum gets from 432 to 507 by:
sqrt(432/pi) = 12
12*pi = 38
12+1 x 38+1 = 13 x 39 = 507
Am I close? I don't have an explanation for adding one to each dimension.

Finally, the sampling pattern of my BSDF (18x24) and the hemisphere division
used by mkillum (13x39) results in double-sampling of some BSDF angles and
non-sampling of others. In conclusion I would be best served by using the
typical radiance hemisphere division ( m x pi*m ) to generate a BSDF that
"agrees" with mkillum. (or should I stop speculating...)

Andy

Hi Everyone,

Earlier this week Greg inspired me to look deeper into mkillum code to
understand exactly how mkillum gets arrives at the illum.dat output
resolution. It resulted in a double a-ha moment that I wanted to share to
close out this thread.

First A-ha: the reason for the apparent +1 in the illum.dat resolution:

Following the calculation for hemisphere divisions in the mkillum code I
still got a sampling resolution of 12x38 instead of 13x39 that is written to
the illum.dat file. It turns out that the hemisphere sampling resolution
*is* 12 x 38, but mkillum purposely writes writes an illum.dat array that is
one greater in both dimensions. It makes perfect sense when I consider
interpolation.

The 0 degree phi value is repeated as a 360 degree value (line 363 of
mkillum3.c). This simplifies interpolation between the last phi value and
the first phi value in a theta row.

The extra theata row is less than 0 degrees (or greater than 90 degrees
altitude). This is added so to allow interpolation towards a consistent
zenith value. The extra values in the illum array are twice the average of
the values in the upper theta row minus the value in the current phi
division (line 267 of mkillum3.c). The values are place on the other side
of the zenith (over the top). The result is that as theta approaches zenith
the interpolated result approaches the same zenith value for all phi
divisions.

In most cases this avoids anomalies at the zenith.

Second A-Ha: The cause of an artifact I was witnessing when testing my bsdf
with mkillum:
http://www.mcneilorama.com/radiance/BSDF/mkillum.html
(See sun position 2 & 3)

The over the top interpolation explains an artifact that occurs when one of
the illum values in the near zenith row is much greater the the others in
the row ( in this case due to direct sunlight). The high value increases
the computed average for the zenith. Then the over the top interpolations
create a bright circle between the upper theta row and the zenith.

Now that I know what causes the artifact I can safely ignore it. These sun
positions used in the renderings are simply for testing the behavior. The
sun will never be close to the zenith of the mkillum. In fact the panelite
dimensions were specifically determined to preclude sunlight from passing
directly into the gallery.

···

On 12/10/09 8:30 PM, "Greg Ward" <[email protected]> wrote:

Hi Andy,

That's some good guessing! Yes, the difference is due to the very
different sampling strata. I had to check my code (line 444 of src/
gen/mkillum2.c) to verify. I don't add 1, but round-off to the
nearest integer, rather than the lesser one.

With regards to the mismatch of samples, this does cause some issues,
particularly near the zenith, where the altitude/azimuth strata used
by mkillum are a very poor match to the Klems/Tregenza strata used for
the BSDF. Mkillum does a reasonable job with normalization and sample
distribution to make sure some rays go through each little window (and
the s= setting can still affect this). So long as the light and
distribution are not simultaneously "peaky," it all works out.

Cheers,
-Greg

From: Andrew McNeil <[email protected]>
Date: December 10, 2009 4:17:04 PM PST

Hi Greg,

Thanks for your response, that d= option behavior makes sense now,
but leads
to a question about the number of output directions in illum.dat...

My BSDF has 18 "latitudes" and 24 "azimuths" (432 divisions)
The resulting illum.dat is 13x39 = 507 angles

After considering your response, I guess the difference between 432
and 507
is a result of a BSDF pattern that doesn't match the typical radiance
hemisphere division scheme used by mkillum?

I'm guessing that mkillum gets from 432 to 507 by:
sqrt(432/pi) = 12
12*pi = 38
12+1 x 38+1 = 13 x 39 = 507
Am I close? I don't have an explanation for adding one to each
dimension.

Finally, the sampling pattern of my BSDF (18x24) and the hemisphere
division
used by mkillum (13x39) results in double-sampling of some BSDF
angles and
non-sampling of others. In conclusion I would be best served by
using the
typical radiance hemisphere division ( m x pi*m ) to generate a BSDF
that
"agrees" with mkillum. (or should I stop speculating...)

Andy

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

Hi Andy,

Nice analysis. I had forgotten about this bit of trickery near the zenith. The general assumption with mkillum is that it won't be relied upon for the direct component, which is why an illum is produced rather than a light by default. Once you have a non-diffusing system that is relying entirely on mkillum, you're in a bit of trouble. This is a key caveat that needs to be worked out somehow in the BSDF case....

Cheers,
-Greg

···

From: Andrew McNeil <[email protected]>
Date: December 18, 2009 9:49:25 AM PST

Hi Everyone,

Earlier this week Greg inspired me to look deeper into mkillum code to
understand exactly how mkillum gets arrives at the illum.dat output
resolution. It resulted in a double a-ha moment that I wanted to share to
close out this thread.

First A-ha: the reason for the apparent +1 in the illum.dat resolution:

Following the calculation for hemisphere divisions in the mkillum code I
still got a sampling resolution of 12x38 instead of 13x39 that is written to
the illum.dat file. It turns out that the hemisphere sampling resolution
*is* 12 x 38, but mkillum purposely writes writes an illum.dat array that is
one greater in both dimensions. It makes perfect sense when I consider
interpolation.

The 0 degree phi value is repeated as a 360 degree value (line 363 of
mkillum3.c). This simplifies interpolation between the last phi value and
the first phi value in a theta row.

The extra theata row is less than 0 degrees (or greater than 90 degrees
altitude). This is added so to allow interpolation towards a consistent
zenith value. The extra values in the illum array are twice the average of
the values in the upper theta row minus the value in the current phi
division (line 267 of mkillum3.c). The values are place on the other side
of the zenith (over the top). The result is that as theta approaches zenith
the interpolated result approaches the same zenith value for all phi
divisions.

In most cases this avoids anomalies at the zenith.

Second A-Ha: The cause of an artifact I was witnessing when testing my bsdf
with mkillum:
http://www.mcneilorama.com/radiance/BSDF/mkillum.html
(See sun position 2 & 3)

The over the top interpolation explains an artifact that occurs when one of
the illum values in the near zenith row is much greater the the others in
the row ( in this case due to direct sunlight). The high value increases
the computed average for the zenith. Then the over the top interpolations
create a bright circle between the upper theta row and the zenith.

Now that I know what causes the artifact I can safely ignore it. These sun
positions used in the renderings are simply for testing the behavior. The
sun will never be close to the zenith of the mkillum. In fact the panelite
dimensions were specifically determined to preclude sunlight from passing
directly into the gallery.