possible inconsistency of bin numbers between BSDF and kelms_int.cal

radiance-general
1

Jia,
This diagram: https://dl.dropbox.com/u/15562376/bin.jpg is wrong.
You should look at klems_int.cal to determine what the patch numbers are.
My bad.
Andy

···

On Sat, Oct 20, 2012 at 5:11 AM, Jia Hu <[email protected]> wrote:

Hi all:

I have a question about the bin number.

To calculate view matrix: (south-facing window)
$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b kbinS -bn Nkbins -m
window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

kbinS uses the (0, 1, 0) as normal (pointing to inside room).

For a ray direction (-1, -1, 0), using klems_int.cal to calculate the bin
number, the bin number is about #57 (I did it manually).

Klems_int.cal (download Klems_init.cal<https://dl.dropbox.com/u/15562376/klems_int.cal>)
seems use "z" hemisphere (see this figure:
https://dl.dropbox.com/u/15562376/coordinate.jpg). From the figure, we
can see "z" hemisphere points to the room (that is, the hemisphere is
located in the room) "zr" (z reverse) hemisphere is towards outside (the
hemisphere is outside the room).

The possible inconsistency is:

(1) Klems_int.cal uses "z" hemisphere to calculate the bin number, for
example, for ray direction (-1, -1, 0), the bin number is #57 for "z"
hemisphere coordinate. (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg)

(2) The "Transmission Back" data in the BSDF .XML is used in the three
phase DC method (see Greg's explanation<http://permalink.gmane.org/gmane.comp.graphics.radiance.general/2729>),
and thus the calculation is based on "zr" (z reverse) hemisphere , for ray
direction (-1, -1, 0), the bin number is about #69 according to the "z
reverse" hemisphere coordinate (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg).

So my questions are:

(a) Given the ray direction, which hemisphere ( "z" or "zr" ) does
"Klems_init.cal" use?

(b) whether the bin numbers (for the same ray direction) between
"Klems_int.cal" and BSDF .xml are inconsistent or not?

(c) if they are using different bin numbers, how to handle ViewMatrix *
BSDF in the calculation?

Thank you in advance,

Jia

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

2

dctimestep originally used just the front transmission data, and if front
transmission data were missing the result was zero. I think Greg has
recently made changes so that it can us back transmission too. Try with
the HEAD.

Andy

···

On Sat, Oct 20, 2012 at 5:38 PM, Jia Hu <[email protected]> wrote:

Sorry to keep bothering you... Just add some additional information. I
search "transmission back" and "transmission front" in the code and find
"Transmission Front" is more likely used according to the code. The
following two code snippets from bsdf_m.c and bsdf.c shows "Transmission
Front" data will be loaded or preferred ?

Another issue, I remember Greg mention that even if only "Transmission
Front" is present, the BSDF library in Radiance can still computer
Transmission matrix. But my simple test case (download here<https://dl.dropbox.com/u/15562376/test_10_21.zip>)
did not show that. If you change "Transmission Back" in the .xml file to
"Transmission Front". The results will be zero.

*// ray/src/common/bsdf_m.c*
/*
* Remember that front and back are reversed from WINDOW 6 orientations
* *Favor their "Front" (incoming light) since that's more often valid*
*/
tfront = !strcasecmp(sdata, "Transmission Back");
if (!strcasecmp(sdata, "Transmission Front") ||
tfront & (sd->tf == NULL)) {
if (sd->tf != NULL)
SDfreeSpectralDF(sd->tf);
if ((sd->tf = SDnewSpectralDF(1)) == NULL)
return RC_MEMERR;
df = sd->tf;

*// ray/src/common/bsdf.c*

for (wld = ezxml_child(wtl, "WavelengthData");
wld != NULL; wld = wld->next) {
if (strcasecmp(ezxml_txt(ezxml_child(wld,"Wavelength")),
"Visible"))
continue;
for (wdb = ezxml_child(wld, "WavelengthDataBlock");
wdb != NULL; wdb = wdb->next)
if (!strcasecmp(ezxml_txt(ezxml_child(wdb,
"WavelengthDataDirection")),
*"Transmission Front"))*
break;
if (wdb != NULL) { */* load front BTDF */*
load_bsdf_data(dp, wdb);
break; /* ignore the rest */
}
}

Thanks,

Jia

On Sat, Oct 20, 2012 at 4:01 PM, Jia Hu <[email protected]> wrote:

Hi all:

In the Klems_init.cal file, for south window (using kbinS), the Klems
coordinate is defined as:

z+: pointing to inside (that is, (0,1, 0) )
x+: pointing to West ( that is (-1, 0, 0) )
y+: pointing to Up (0,0,1)

This coordinate is consistent with the Klems coordinate system used in
WINDOW 6 (see this: https://dl.dropbox.com/u/15562376/coordinate.jpg).
In the figure, Klems coordinate system defines: x or xr points to (-1, 0,
0) and y or yr points to (0, 0, 1).

However, if using this command to calculate view matrix:

$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b *kbinS* -bn Nkbins
-m window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

where, kbinS defines z axis in the Klems coordinate system as (0 1 0),
that is, pointing to room interior.

Thus, the bin number calculated by Klems_init.cal is actually based on z
hemisphere <https://dl.dropbox.com/u/15562376/coordinate.jpg> (the
hemisphere protrudes towards room). the bin number corresponds with
"Transmittance Front" in BSDF xml file. For example, ray direction (-1, -1,
0) (backward, ray travels from inside to outside room) hits the bin 58<https://dl.dropbox.com/u/15562376/bin.jpg>
defined in z hemisphere because the hemisphere protrudes towards (0 1 0).
But ray direction (-1 -1 0) hits bin 46<https://dl.dropbox.com/u/15562376/bin.jpg> defined in
z reverse (i.e., zr) coordinate because the hemisphere protrudes towards (0
-1 0) (towards outside).

When calculating Daylighting Matrix, it still uses Klems_init.cal and
kbinS, that is, z hemisphere coordinate system, therefore, Radiance seems
needing to use "Transmission Front", which is defined in z hemisphere. But
currently Radiance uses "Transmission Back" (from inside to outside), which
defined in zr hemisphere,

So, should we need to

(a) use "*kbinN*" (defining z axis of Klems coordinate towards (0 -1 0)
) and "Transmission Back" for south window, or
  (b) use "Transmission Front" and *kbinS*?

I am very confused about this. Does anyone know the possible reasons?

Thank you !

Jia

On Sat, Oct 20, 2012 at 8:11 AM, Jia Hu <[email protected]> wrote:

Hi all:

I have a question about the bin number.

To calculate view matrix: (south-facing window)
$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b kbinS -bn Nkbins
-m window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

kbinS uses the (0, 1, 0) as normal (pointing to inside room).

For a ray direction (-1, -1, 0), using klems_int.cal to calculate the
bin number, the bin number is about #57 (I did it manually).

Klems_int.cal (download Klems_init.cal<https://dl.dropbox.com/u/15562376/klems_int.cal>)
seems use "z" hemisphere (see this figure:
https://dl.dropbox.com/u/15562376/coordinate.jpg). From the figure, we
can see "z" hemisphere points to the room (that is, the hemisphere is
located in the room) "zr" (z reverse) hemisphere is towards outside (the
hemisphere is outside the room).

The possible inconsistency is:

(1) Klems_int.cal uses "z" hemisphere to calculate the bin number, for
example, for ray direction (-1, -1, 0), the bin number is #57 for "z"
hemisphere coordinate. (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg)

(2) The "Transmission Back" data in the BSDF .XML is used in the three
phase DC method (see Greg's explanation<http://permalink.gmane.org/gmane.comp.graphics.radiance.general/2729>),
and thus the calculation is based on "zr" (z reverse) hemisphere , for ray
direction (-1, -1, 0), the bin number is about #69 according to the "z
reverse" hemisphere coordinate (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg).

So my questions are:

(a) Given the ray direction, which hemisphere ( "z" or "zr" ) does
"Klems_init.cal" use?

(b) whether the bin numbers (for the same ray direction) between
"Klems_int.cal" and BSDF .xml are inconsistent or not?

(c) if they are using different bin numbers, how to handle ViewMatrix *
BSDF in the calculation?

Thank you in advance,

Jia

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

3

One more thing, the patch numbers will be different for incident and
exiting hemispheres. one side uses left handed numbering the other uses
right handed numbering. Energy that is transmitted specularly will have
the same incident and exiting patch number.

Andy

···

On Mon, Oct 22, 2012 at 9:45 AM, Andrew McNeil <[email protected]> wrote:

Jia,
This diagram: https://dl.dropbox.com/u/15562376/bin.jpg is wrong.
You should look at klems_int.cal to determine what the patch numbers are.
My bad.
Andy

On Sat, Oct 20, 2012 at 5:11 AM, Jia Hu <[email protected]> wrote:

Hi all:

I have a question about the bin number.

To calculate view matrix: (south-facing window)
$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b kbinS -bn Nkbins -m
window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

kbinS uses the (0, 1, 0) as normal (pointing to inside room).

For a ray direction (-1, -1, 0), using klems_int.cal to calculate the bin
number, the bin number is about #57 (I did it manually).

Klems_int.cal (download Klems_init.cal<https://dl.dropbox.com/u/15562376/klems_int.cal>)
seems use "z" hemisphere (see this figure:
https://dl.dropbox.com/u/15562376/coordinate.jpg). From the figure, we
can see "z" hemisphere points to the room (that is, the hemisphere is
located in the room) "zr" (z reverse) hemisphere is towards outside (the
hemisphere is outside the room).

The possible inconsistency is:

(1) Klems_int.cal uses "z" hemisphere to calculate the bin number, for
example, for ray direction (-1, -1, 0), the bin number is #57 for "z"
hemisphere coordinate. (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg)

(2) The "Transmission Back" data in the BSDF .XML is used in the three
phase DC method (see Greg's explanation<http://permalink.gmane.org/gmane.comp.graphics.radiance.general/2729>),
and thus the calculation is based on "zr" (z reverse) hemisphere , for ray
direction (-1, -1, 0), the bin number is about #69 according to the "z
reverse" hemisphere coordinate (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg).

So my questions are:

(a) Given the ray direction, which hemisphere ( "z" or "zr" ) does
"Klems_init.cal" use?

(b) whether the bin numbers (for the same ray direction) between
"Klems_int.cal" and BSDF .xml are inconsistent or not?

(c) if they are using different bin numbers, how to handle ViewMatrix *
BSDF in the calculation?

Thank you in advance,

Jia

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

4

Hi Andy:

"the patch numbers will be different for incident and exiting hemispheres.
one side uses left handed numbering the other uses right handed numbering."

···

------
Yes, from this figure https://dl.dropbox.com/u/15562376/coordinate.jpg, Z
hemisphere coordinate uses right handed and Zr uses left handed, but for
forward rays (both incoming and outgoing rays whose direction is from
inside room to outside), these rays will only use Z hemisphere, Zr
hemisphere does not exist for those forward rays, and thus no left handed
coordinate in this sense. Thus outgoing rays still uses Z hemisphere patch
number.

To make it clear, you may read this report
http://windows.lbl.gov/software/window/6/Venetian%20Technical%20Document.pdf ,
*Page 6, 7, 10 and 47 -50*, the report shows that both incoming and exiting
rays' patch numbers are based on only one Hemisphere, either Z or Zr
hemisphere but not both, that is why, *if you see the page 49 in the report
*( or https://dl.dropbox.com/u/15562376/PDF_page_49.jpg*)*, the incoming
patch number is 31 and the outgoing patch is still 31 because they are
using the same hemisphere. In the outgoing side, there is no hemisphere and
outgoing ray still uses the hemisphere in the incoming ray side to
determine the patch number. That is why they have the same patch numbers if
their directions are the same.

I think you figure is correct if you stand inside the room and look at the
window. Klems_int.cal uses Z hemisphere to determine the patch number.

My concern is that Radiance loads "Transmission Back" data which uses Zr
hemisphere but VewMatrix and DaylightMatrix uses Z hemisphere. In other
words, when Radiance loads "Transmission Back" data, it assumes all the
patch number is determined based on Zr hemisphere (both incoming and
outgoing rays patch number is based on this Zr hemisphere). But V and D,
the patch numbers of both incoming and outgoing rays determine patch
numbers based on Z hemisphere (right hemisphere in the figure).

Thanks,

Jia

On Mon, Oct 22, 2012 at 12:45 PM, Andrew McNeil <[email protected]> wrote:

Jia,
This diagram: https://dl.dropbox.com/u/15562376/bin.jpg is wrong.
You should look at klems_int.cal to determine what the patch numbers are.
My bad.
Andy

On Sat, Oct 20, 2012 at 5:11 AM, Jia Hu <[email protected]> wrote:

Hi all:

I have a question about the bin number.

To calculate view matrix: (south-facing window)
$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b kbinS -bn Nkbins -m
window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

kbinS uses the (0, 1, 0) as normal (pointing to inside room).

For a ray direction (-1, -1, 0), using klems_int.cal to calculate the bin
number, the bin number is about #57 (I did it manually).

Klems_int.cal (download Klems_init.cal<https://dl.dropbox.com/u/15562376/klems_int.cal>)
seems use "z" hemisphere (see this figure:
https://dl.dropbox.com/u/15562376/coordinate.jpg). From the figure, we
can see "z" hemisphere points to the room (that is, the hemisphere is
located in the room) "zr" (z reverse) hemisphere is towards outside (the
hemisphere is outside the room).

The possible inconsistency is:

(1) Klems_int.cal uses "z" hemisphere to calculate the bin number, for
example, for ray direction (-1, -1, 0), the bin number is #57 for "z"
hemisphere coordinate. (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg)

(2) The "Transmission Back" data in the BSDF .XML is used in the three
phase DC method (see Greg's explanation<http://permalink.gmane.org/gmane.comp.graphics.radiance.general/2729>),
and thus the calculation is based on "zr" (z reverse) hemisphere , for ray
direction (-1, -1, 0), the bin number is about #69 according to the "z
reverse" hemisphere coordinate (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg).

So my questions are:

(a) Given the ray direction, which hemisphere ( "z" or "zr" ) does
"Klems_init.cal" use?

(b) whether the bin numbers (for the same ray direction) between
"Klems_int.cal" and BSDF .xml are inconsistent or not?

(c) if they are using different bin numbers, how to handle ViewMatrix *
BSDF in the calculation?

Thank you in advance,

Jia

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

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

5

Hi Andy:

Yes. But currently the fact is that if the back transmission data is
missing, the results are zero even if there are front transmission data.
That is why I am confused.

Thanks,

Jia

···

On Mon, Oct 22, 2012 at 12:50 PM, Andrew McNeil <[email protected]> wrote:

dctimestep originally used just the front transmission data, and if front
transmission data were missing the result was zero. I think Greg has
recently made changes so that it can us back transmission too. Try with
the HEAD.

Andy

On Sat, Oct 20, 2012 at 5:38 PM, Jia Hu <[email protected]> wrote:

Sorry to keep bothering you... Just add some additional information. I
search "transmission back" and "transmission front" in the code and find
"Transmission Front" is more likely used according to the code. The
following two code snippets from bsdf_m.c and bsdf.c shows "Transmission
Front" data will be loaded or preferred ?

Another issue, I remember Greg mention that even if only "Transmission
Front" is present, the BSDF library in Radiance can still computer
Transmission matrix. But my simple test case (download here<https://dl.dropbox.com/u/15562376/test_10_21.zip>)
did not show that. If you change "Transmission Back" in the .xml file to
"Transmission Front". The results will be zero.

*// ray/src/common/bsdf_m.c*
/*
* Remember that front and back are reversed from WINDOW 6 orientations
* *Favor their "Front" (incoming light) since that's more often valid*
*/
tfront = !strcasecmp(sdata, "Transmission Back");
if (!strcasecmp(sdata, "Transmission Front") ||
tfront & (sd->tf == NULL)) {
if (sd->tf != NULL)
SDfreeSpectralDF(sd->tf);
if ((sd->tf = SDnewSpectralDF(1)) == NULL)
return RC_MEMERR;
df = sd->tf;

*// ray/src/common/bsdf.c*

for (wld = ezxml_child(wtl, "WavelengthData");
wld != NULL; wld = wld->next) {
if (strcasecmp(ezxml_txt(ezxml_child(wld,"Wavelength")),
"Visible"))
continue;
for (wdb = ezxml_child(wld, "WavelengthDataBlock");
wdb != NULL; wdb = wdb->next)
if (!strcasecmp(ezxml_txt(ezxml_child(wdb,
"WavelengthDataDirection")),
*"Transmission Front"))*
break;
if (wdb != NULL) { */* load front BTDF */*
load_bsdf_data(dp, wdb);
break; /* ignore the rest */
}
}

Thanks,

Jia

On Sat, Oct 20, 2012 at 4:01 PM, Jia Hu <[email protected]> wrote:

Hi all:

In the Klems_init.cal file, for south window (using kbinS), the Klems
coordinate is defined as:

z+: pointing to inside (that is, (0,1, 0) )
x+: pointing to West ( that is (-1, 0, 0) )
y+: pointing to Up (0,0,1)

This coordinate is consistent with the Klems coordinate system used in
WINDOW 6 (see this: https://dl.dropbox.com/u/15562376/coordinate.jpg).
In the figure, Klems coordinate system defines: x or xr points to (-1, 0,
0) and y or yr points to (0, 0, 1).

However, if using this command to calculate view matrix:

$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b *kbinS* -bn
Nkbins -m window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

where, kbinS defines z axis in the Klems coordinate system as (0 1 0),
that is, pointing to room interior.

Thus, the bin number calculated by Klems_init.cal is actually based on z
hemisphere <https://dl.dropbox.com/u/15562376/coordinate.jpg> (the
hemisphere protrudes towards room). the bin number corresponds with
"Transmittance Front" in BSDF xml file. For example, ray direction (-1, -1,
0) (backward, ray travels from inside to outside room) hits the bin 58<https://dl.dropbox.com/u/15562376/bin.jpg>
defined in z hemisphere because the hemisphere protrudes towards (0 1 0).
But ray direction (-1 -1 0) hits bin 46<https://dl.dropbox.com/u/15562376/bin.jpg> defined in
z reverse (i.e., zr) coordinate because the hemisphere protrudes towards (0
-1 0) (towards outside).

When calculating Daylighting Matrix, it still uses Klems_init.cal and
kbinS, that is, z hemisphere coordinate system, therefore, Radiance seems
needing to use "Transmission Front", which is defined in z hemisphere. But
currently Radiance uses "Transmission Back" (from inside to outside), which
defined in zr hemisphere,

So, should we need to

(a) use "*kbinN*" (defining z axis of Klems coordinate towards (0 -1
0) ) and "Transmission Back" for south window, or
  (b) use "Transmission Front" and *kbinS*?

I am very confused about this. Does anyone know the possible reasons?

Thank you !

Jia

On Sat, Oct 20, 2012 at 8:11 AM, Jia Hu <[email protected]> wrote:

Hi all:

I have a question about the bin number.

To calculate view matrix: (south-facing window)
$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b kbinS -bn Nkbins
-m window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

kbinS uses the (0, 1, 0) as normal (pointing to inside room).

For a ray direction (-1, -1, 0), using klems_int.cal to calculate the
bin number, the bin number is about #57 (I did it manually).

Klems_int.cal (download Klems_init.cal<https://dl.dropbox.com/u/15562376/klems_int.cal>)
seems use "z" hemisphere (see this figure:
https://dl.dropbox.com/u/15562376/coordinate.jpg). From the figure, we
can see "z" hemisphere points to the room (that is, the hemisphere is
located in the room) "zr" (z reverse) hemisphere is towards outside (the
hemisphere is outside the room).

The possible inconsistency is:

(1) Klems_int.cal uses "z" hemisphere to calculate the bin number, for
example, for ray direction (-1, -1, 0), the bin number is #57 for "z"
hemisphere coordinate. (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg)

(2) The "Transmission Back" data in the BSDF .XML is used in the three
phase DC method (see Greg's explanation<http://permalink.gmane.org/gmane.comp.graphics.radiance.general/2729>),
and thus the calculation is based on "zr" (z reverse) hemisphere , for ray
direction (-1, -1, 0), the bin number is about #69 according to the "z
reverse" hemisphere coordinate (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg).

So my questions are:

(a) Given the ray direction, which hemisphere ( "z" or "zr" ) does
"Klems_init.cal" use?

(b) whether the bin numbers (for the same ray direction) between
"Klems_int.cal" and BSDF .xml are inconsistent or not?

(c) if they are using different bin numbers, how to handle ViewMatrix *
BSDF in the calculation?

Thank you in advance,

Jia

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

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

6

Hi Greg,

Thanks for your updating! I looked at the code, which seems to prefer
"Front Transmission" (WINDOW 6 convention) data and if it is NULL, then the
back transmission data will be used?

Thank you !

Jia

···

On Tue, Oct 23, 2012 at 6:28 PM, Greg Ward <[email protected]> wrote:

Hi Jia,

There was a bug in the recently-added reciprocity calculation in
dctimestep, which I hope I have now corrected. Please try this again with
the copy of dctimestep.c from the current HEAD.

Thanks for pointing out the problem.

Best,
-Greg

*From: *Jia Hu <[email protected]>

*Date: *October 22, 2012 10:28:52 AM PDT

*
*

Hi Andy:

Yes. But currently the fact is that if the back transmission data is
missing, the results are zero even if there are front transmission data.
That is why I am confused.

Thanks,

Jia

On Mon, Oct 22, 2012 at 12:50 PM, Andrew McNeil <[email protected]> wrote:

dctimestep originally used just the front transmission data, and if front
transmission data were missing the result was zero. I think Greg has
recently made changes so that it can us back transmission too. Try with
the HEAD.

Andy

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