# 5Phase & proxy geometry

Hi all, I’m coming again with more questions now regarding the 5Phase
Method. I hope someone finds the time to answer.

As following:

1.- I’m not sure of the use of the ‘BSDFproxy polygon inside’ included in

If the latter was generated by genBSDF and includes already the dimensions
of the venetian blind, the model, the glazing, and the thickness is also
specified…why do we need to specify the coordinates of the polygon (same of
the glow material) in this file?

I also wonder if we need to use proxy when only if we have a system such as
venetian blinds. Is possible to use it also if we have a daylight system as
thick as a glass pane such as lasercut panel 6mm?

I guess that I can shorten this question by: what would be exactly the
function of the proxy geometry?

2.- Regarding this, in the tutorial you have to rotate the geometry in
order to generate the two xml files (section 6.2) my
silly-silly-super-silly question is: what would be the orientation of the
resulting xml file? Are we re-orientating it by the last three values of
the orientation vector in the glazing_bsdf.rad ?

3.- I have a final question that just came now when trying the 5Phase: What
would be the number to use in rcontrib –bn when creating the
direct-sun-coefficient-matrix?

As I understand, it represents the number of sky patches, and it will
generate the values of the RGB in the output file. But, if I use –e MF:6 –f
reinhart.cal –b 5186, I obtain a matrix result with 31116 columns, which is
the number of sky patches six times? Please tell me where am I wrong.

Chantal.

Hi Chantal,

1.- I’m not sure of the use of the ‘BSDFproxy polygon inside’ included in

The BSDF material is applied to this surface. It allows Radiance to use the
BSDF data in lieu of sampling the geometry during the direct sun simulation.

If the latter was generated by genBSDF and includes already the dimensions
of the venetian blind, the model, the glazing, and the thickness is also
specified…why do we need to specify the coordinates of the polygon (same of
the glow material) in this file?

The BSDF is not always produced by genBSDF, it can come from WINDOW or from
measurement as well. But regardless, the intention is that optical data in
a BSDF file is not specific to a size of window, and so you could use it in
various sized windows. For example if lightlouver produces a BSDF for
their product using genBSDF for one project you might want to use it in a
2m window for one project but a 3m window for another. Addtionally there
may be times when you want to use a different thinckness for the
simulation. I can think of probably half a dozen reasons why you might not
want to use dimensions baked into a BSDF file, an as is typical with

I also wonder if we need to use proxy when only if we have a system such
as venetian blinds. Is possible to use it also if we have a daylight system
as thick as a glass pane such as lasercut panel 6mm?

Yes, but it isn't worth it unless you have a good Radiance material model
for the lasercut panel. Otherwise you're better off using the BSDF
(assuming it was measured).

I guess that I can shorten this question by: what would be exactly the
function of the proxy geometry?

The BSDF, even high resolution tensortree BSDFs, are spatially averaged. A
venetian blind that is angled to admit stripes of light modeled with only a
BSDF will result in a rectangular patch of intermediate brightness. Using
proxy geometry results in bright sun alternating with dark shadows.

2.- Regarding this, in the tutorial you have to rotate the geometry in
order to generate the two xml files (section 6.2) my
silly-silly-super-silly question is: what would be the orientation of
the resulting xml file? Are we re-orientating it by the last three values
of the orientation vector in the glazing_bsdf.rad ?

The WINDOW XML file standard says inside is +Z outside is -Z, up is +Y.
In Radiance we use up as +Z and inside and outside, well it depends on the

3.- I have a final question that just came now when trying the 5Phase:
What would be the number to use in rcontrib –bn when creating the
direct-sun-coefficient-matrix?

As I understand, it represents the number of sky patches, and it will
generate the values of the RGB in the output file. But, if I use –e MF:6 –f
reinhart.cal –b 5186, I obtain a matrix result with 31116 columns, which is
the number of sky patches six times? Please tell me where am I wrong.

There should be three values per skypatch (R G and B) I don't know why you
are getting twice as many. Can you send the full command you are using?

Andy

Hi Andy

Thanks a lot for your help with all my questions. I found the solution to
the last one... (Not really worth mentioning!!)

:))

Regarding my previous 1st. Question:

I tried to create a *glazing_bsdf.rad* file using one of the cfs.xml files
that we have in the lab. I’ve got the message:

“Unsupported IncidentDataStructure for BSDF”, I assume this means that this
is not a ‘tensor tree high resolution BSDF”.

This might be a silly question but: if there is a way to resample the
tensor tree BSDF into a Klems basis BSDF, is there any way

to do the other way around? Or...perhaps this 'error message' means
something else..?

Chantal.

···

2013/11/1 Andrew McNeil <[email protected]>

Hi Chantal,

1.- I’m not sure of the use of the ‘BSDFproxy polygon inside’ included in

The BSDF material is applied to this surface. It allows Radiance to use
the BSDF data in lieu of sampling the geometry during the direct sun
simulation.

If the latter was generated by genBSDF and includes already the
dimensions of the venetian blind, the model, the glazing, and the thickness
is also specified…why do we need to specify the coordinates of the polygon
(same of the glow material) in this file?

The BSDF is not always produced by genBSDF, it can come from WINDOW or
from measurement as well. But regardless, the intention is that optical
data in a BSDF file is not specific to a size of window, and so you could
use it in various sized windows. For example if lightlouver produces a
BSDF for their product using genBSDF for one project you might want to use
it in a 2m window for one project but a 3m window for another. Addtionally
there may be times when you want to use a different thinckness for the
simulation. I can think of probably half a dozen reasons why you might not
want to use dimensions baked into a BSDF file, an as is typical with

I also wonder if we need to use proxy when only if we have a system such
as venetian blinds. Is possible to use it also if we have a daylight system
as thick as a glass pane such as lasercut panel 6mm?

Yes, but it isn't worth it unless you have a good Radiance material model
for the lasercut panel. Otherwise you're better off using the BSDF
(assuming it was measured).

I guess that I can shorten this question by: what would be exactly the
function of the proxy geometry?

The BSDF, even high resolution tensortree BSDFs, are spatially averaged.
A venetian blind that is angled to admit stripes of light modeled with
only a BSDF will result in a rectangular patch of intermediate brightness.
Using proxy geometry results in bright sun alternating with dark shadows.

2.- Regarding this, in the tutorial you have to rotate the geometry in
order to generate the two xml files (section 6.2) my
silly-silly-super-silly question is: what would be the orientation of
the resulting xml file? Are we re-orientating it by the last three values
of the orientation vector in the glazing_bsdf.rad ?

The WINDOW XML file standard says inside is +Z outside is -Z, up is +Y.
In Radiance we use up as +Z and inside and outside, well it depends on the

3.- I have a final question that just came now when trying the 5Phase:
What would be the number to use in rcontrib –bn when creating the
direct-sun-coefficient-matrix?

As I understand, it represents the number of sky patches, and it will
generate the values of the RGB in the output file. But, if I use –e MF:6 –f
reinhart.cal –b 5186, I obtain a matrix result with 31116 columns, which is
the number of sky patches six times? Please tell me where am I wrong.

There should be three values per skypatch (R G and B) I don't know why you
are getting twice as many. Can you send the full command you are using?

Andy

_______________________________________________
[email protected]

Hi Chantal,
You should be able to use a non-klems and non-tensor tree BSDF as long as
the angle basis can be described using the format described in the XML
schema (not all can - I've maintain hacked version of Radiance to use a
BSDF angle basis that I've developed). If you send me the XML file I can
look to see what could be causing the problem.

Yes, there are tools for resampling BSDF files.
bsdf2klems :

bsdf2ttree :

Andy

···

On Sun, Nov 3, 2013 at 8:53 AM, minchaca <[email protected]> wrote:

Hi Andy

Thanks a lot for your help with all my questions. I found the solution to
the last one... (Not really worth mentioning!!)

:))

Regarding my previous 1st. Question:

I tried to create a *glazing_bsdf.rad* file using one of the cfs.xml
files that we have in the lab. I’ve got the message:

“Unsupported IncidentDataStructure for BSDF”, I assume this means that
this is not a ‘tensor tree high resolution BSDF”.

This might be a silly question but: if there is a way to resample the
tensor tree BSDF into a Klems basis BSDF, is there any way

to do the other way around? Or...perhaps this 'error message' means
something else..?

Chantal.

2013/11/1 Andrew McNeil <[email protected]>

Hi Chantal,

1.- I’m not sure of the use of the ‘BSDFproxy polygon inside’ included in

The BSDF material is applied to this surface. It allows Radiance to use
the BSDF data in lieu of sampling the geometry during the direct sun
simulation.

If the latter was generated by genBSDF and includes already the
dimensions of the venetian blind, the model, the glazing, and the thickness
is also specified…why do we need to specify the coordinates of the polygon
(same of the glow material) in this file?

The BSDF is not always produced by genBSDF, it can come from WINDOW or
from measurement as well. But regardless, the intention is that optical
data in a BSDF file is not specific to a size of window, and so you could
use it in various sized windows. For example if lightlouver produces a
BSDF for their product using genBSDF for one project you might want to use
it in a 2m window for one project but a 3m window for another. Addtionally
there may be times when you want to use a different thinckness for the
simulation. I can think of probably half a dozen reasons why you might not
want to use dimensions baked into a BSDF file, an as is typical with

I also wonder if we need to use proxy when only if we have a system such
as venetian blinds. Is possible to use it also if we have a daylight system
as thick as a glass pane such as lasercut panel 6mm?

Yes, but it isn't worth it unless you have a good Radiance material model
for the lasercut panel. Otherwise you're better off using the BSDF
(assuming it was measured).

I guess that I can shorten this question by: what would be exactly the
function of the proxy geometry?

The BSDF, even high resolution tensortree BSDFs, are spatially averaged.
A venetian blind that is angled to admit stripes of light modeled with
only a BSDF will result in a rectangular patch of intermediate brightness.
Using proxy geometry results in bright sun alternating with dark shadows.

2.- Regarding this, in the tutorial you have to rotate the geometry in
order to generate the two xml files (section 6.2) my
silly-silly-super-silly question is: what would be the orientation of
the resulting xml file? Are we re-orientating it by the last three values
of the orientation vector in the glazing_bsdf.rad ?

The WINDOW XML file standard says inside is +Z outside is -Z, up is +Y.
In Radiance we use up as +Z and inside and outside, well it depends on the

3.- I have a final question that just came now when trying the 5Phase:
What would be the number to use in rcontrib –bn when creating the
direct-sun-coefficient-matrix?

As I understand, it represents the number of sky patches, and it will
generate the values of the RGB in the output file. But, if I use –e MF:6 –f
reinhart.cal –b 5186, I obtain a matrix result with 31116 columns, which is
the number of sky patches six times? Please tell me where am I wrong.

There should be three values per skypatch (R G and B) I don't know why
you are getting twice as many. Can you send the full command you are using?

Andy

_______________________________________________
[email protected]

_______________________________________________
[email protected]

Hi Andy

I thank you for the pdf files and I'll send you then the xml file so you
can have a look to it. Thanks also for that!

Chantal

···

2013/11/4 Andrew McNeil <[email protected]>

Hi Chantal,
You should be able to use a non-klems and non-tensor tree BSDF as long as
the angle basis can be described using the format described in the XML
schema (not all can - I've maintain hacked version of Radiance to use a
BSDF angle basis that I've developed). If you send me the XML file I can
look to see what could be causing the problem.

Yes, there are tools for resampling BSDF files.
bsdf2klems :
bsdf2ttree :

Andy

On Sun, Nov 3, 2013 at 8:53 AM, minchaca <[email protected]> wrote:

Hi Andy

Thanks a lot for your help with all my questions. I found the solution to
the last one... (Not really worth mentioning!!)

:))

Regarding my previous 1st. Question:

I tried to create a *glazing_bsdf.rad* file using one of the cfs.xml
files that we have in the lab. I’ve got the message:

“Unsupported IncidentDataStructure for BSDF”, I assume this means that
this is not a ‘tensor tree high resolution BSDF”.

This might be a silly question but: if there is a way to resample the
tensor tree BSDF into a Klems basis BSDF, is there any way

to do the other way around? Or...perhaps this 'error message' means
something else..?

Chantal.

2013/11/1 Andrew McNeil <[email protected]>

Hi Chantal,

1.- I’m not sure of the use of the ‘BSDFproxy polygon inside’ included

The BSDF material is applied to this surface. It allows Radiance to use
the BSDF data in lieu of sampling the geometry during the direct sun
simulation.

If the latter was generated by genBSDF and includes already the
dimensions of the venetian blind, the model, the glazing, and the thickness
is also specified…why do we need to specify the coordinates of the polygon
(same of the glow material) in this file?

The BSDF is not always produced by genBSDF, it can come from WINDOW or
from measurement as well. But regardless, the intention is that optical
data in a BSDF file is not specific to a size of window, and so you could
use it in various sized windows. For example if lightlouver produces a
BSDF for their product using genBSDF for one project you might want to use
it in a 2m window for one project but a 3m window for another. Addtionally
there may be times when you want to use a different thinckness for the
simulation. I can think of probably half a dozen reasons why you might not
want to use dimensions baked into a BSDF file, an as is typical with

I also wonder if we need to use proxy when only if we have a system
such as venetian blinds. Is possible to use it also if we have a daylight
system as thick as a glass pane such as lasercut panel 6mm?

Yes, but it isn't worth it unless you have a good Radiance material
model for the lasercut panel. Otherwise you're better off using the BSDF
(assuming it was measured).

I guess that I can shorten this question by: what would be exactly the
function of the proxy geometry?

The BSDF, even high resolution tensortree BSDFs, are spatially averaged.
A venetian blind that is angled to admit stripes of light modeled with
only a BSDF will result in a rectangular patch of intermediate brightness.
Using proxy geometry results in bright sun alternating with dark shadows.

2.- Regarding this, in the tutorial you have to rotate the geometry in
order to generate the two xml files (section 6.2) my
silly-silly-super-silly question is: what would be the orientation of
the resulting xml file? Are we re-orientating it by the last three values
of the orientation vector in the glazing_bsdf.rad ?

The WINDOW XML file standard says inside is +Z outside is -Z, up is +Y.
In Radiance we use up as +Z and inside and outside, well it depends on

3.- I have a final question that just came now when trying the 5Phase:
What would be the number to use in rcontrib –bn when creating the
direct-sun-coefficient-matrix?

As I understand, it represents the number of sky patches, and it will
generate the values of the RGB in the output file. But, if I use –e MF:6 –f
reinhart.cal –b 5186, I obtain a matrix result with 31116 columns, which is
the number of sky patches six times? Please tell me where am I wrong.

There should be three values per skypatch (R G and B) I don't know why
you are getting twice as many. Can you send the full command you are using?

Andy

_______________________________________________