[Radiance-general] possible inconsistency of bin numbers between BSDF and kelms_int.cal

Mon Oct 22 10:28:52 PDT 2012

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 <amcneil at lbl.gov> 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 <hujia06 at gmail.com> 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 <hujia06 at gmail.com> 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 <hujia06 at gmail.com> 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
>> Radiance-general at radiance-online.org
>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>
>>
>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general at radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20121022/542f5019/attachment-0001.html>