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.