possible inconsistency of bin numbers between BSDF and kelms_int.cal

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

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

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

Yes, that's correct. Reciprocity means that you can reverse the direction for a BTDF if you manage all of the angles correctly, which I wasn't doing before.

Cheers,
-Greg

···

From: Jia Hu <[email protected]>
Date: October 23, 2012 8:45:32 PM PDT

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

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