BSDF orientation and implementation

Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the -dim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.

In my BSDF material definition, I would alter the up vector according to the surface being applied - the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry's orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU's with varying properties? It seems so from David Geisler-Moroder's presentation at the 2012 Workshop (http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf). Certainly skylights and windows will have different VLT and it would again be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

Chris Coulter
Senior Lighting Designer
Buro Happold Consulting Engineers
100 Broadway, 23rd Floor
New York, NY 10005
Tel: 212.334.2025
Direct: 212.616.0254
Email: [email protected]
Website: www.burohappold.com

Chris,
Everything you write seems correct. One whatch-it I can offer is to make
sure you're system is situated properly for the genBSDF run. +Z is into the
space, +Y is up. All of the geometry should be in the -Z space. If you
don't follow these guidelines you're BSDF will be strange.
Andy

···

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter < [email protected]> wrote:

Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able
to apply a BSDF to one of my projects. This project will be using
micro-louver cellular structures imbedded within an IGU, in both skylights
and vertical windows. I think I understand the general process, but wanted
to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in
multiple orientations (of course). My understanding of the BSDF and
seemingly from this mail (
http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html),
I should be able to calculate the BSDF once for my system. I was planning
model the louvers as 1m by 1m, but run genBSDF with the -dim arguments
smaller than this. Is this the correct approach? Ideally I would not
calculate the BSDF for each orientation, assuming that micro-louver
geometry does not change.

In my BSDF material definition, I would alter the up vector according to
the surface being applied - the up vector matches the BSDF orientation
(calculated in xy space) to the specific geometry's orientation (0 0 1 for
a window). If the louver are rotated within the IGU assembly (rz -45) for a
skylight, I can account for this with the up vector of 1 1 0 (surface
normal is 0 0 1). This would hold true for rotation within the vertical
apertures as well. Each different up vector would be a different BSDF
material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import
the BSDF file into Window and create multiple options for IGU's with
varying properties? It seems so from David Geisler-Moroder's presentation
at the 2012 Workshop (
http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf).
Certainly skylights and windows will have different VLT and it would again
be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to
ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

*Chris Coulter*

*Senior Lighting Designer*
Buro Happold Consulting Engineers

100 Broadway, 23rd Floor

New York, NY 10005

Tel: 212.334.2025

Direct: 212.616.0254

Email: [email protected]

Website: www.burohappold.com

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

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs
including the glass panes of your IGU. Therefore my approach is usually to
simulate only the system without any glazing and put the overall system
together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single
system you should decide if the kind of system you are simulating is
representative for your application. I tend to simulate typical periods of
a systems (e.g. for a lamella system you can use the -dim settings to get
that right) and model any frame in the geometric model. However, in cases
where e.g. the ratio of system thickness to system size dimension is quite
high and thus the frame will significantly influence the BSDF, it is better
to include the real geometry in the BSDF simulation model. However, you
then probably end up generating more than a single BSDF for the same system
depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

···

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]>:

Chris,
Everything you write seems correct. One whatch-it I can offer is to make
sure you're system is situated properly for the genBSDF run. +Z is into the
space, +Y is up. All of the geometry should be in the -Z space. If you
don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter < > [email protected]> wrote:

Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able
to apply a BSDF to one of my projects. This project will be using
micro-louver cellular structures imbedded within an IGU, in both skylights
and vertical windows. I think I understand the general process, but wanted
to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in
multiple orientations (of course). My understanding of the BSDF and
seemingly from this mail (
http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html),
I should be able to calculate the BSDF once for my system. I was planning
model the louvers as 1m by 1m, but run genBSDF with the -dim arguments
smaller than this. Is this the correct approach? Ideally I would not
calculate the BSDF for each orientation, assuming that micro-louver
geometry does not change.

In my BSDF material definition, I would alter the up vector according to
the surface being applied - the up vector matches the BSDF orientation
(calculated in xy space) to the specific geometry's orientation (0 0 1 for
a window). If the louver are rotated within the IGU assembly (rz -45) for a
skylight, I can account for this with the up vector of 1 1 0 (surface
normal is 0 0 1). This would hold true for rotation within the vertical
apertures as well. Each different up vector would be a different BSDF
material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import
the BSDF file into Window and create multiple options for IGU's with
varying properties? It seems so from David Geisler-Moroder's presentation
at the 2012 Workshop (
http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf).
Certainly skylights and windows will have different VLT and it would again
be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to
ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

*Chris Coulter*

*Senior Lighting Designer*
Buro Happold Consulting Engineers

100 Broadway, 23rd Floor

New York, NY 10005

Tel: 212.334.2025

Direct: 212.616.0254

Email: [email protected]

Website: www.burohappold.com

_______________________________________________
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

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

1 Like

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF distribution) are very useful for getting comfortable with your generated BSDFs. I am working on a little ‚Äútest room‚ÄĚ model, a la the ltview script but for CFS instead of luminaries. When it‚Äôs sensible I‚Äôll post some results. It‚Äôs very helpful to visualize these things; Andy‚Äôs BSDFviewer is awesome, but I also like to mock these things up in Radiance proper so I am certain the functions and the models are are being implemented and oriented correctly, you know what I mean?

- Rob

···

From: David Geisler-Moroder <[email protected]<mailto:[email protected]>>
Reply-To: Radiance discussion <[email protected]<mailto:[email protected]>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:[email protected]>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs including the glass panes of your IGU. Therefore my approach is usually to simulate only the system without any glazing and put the overall system together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single system you should decide if the kind of system you are simulating is representative for your application. I tend to simulate typical periods of a systems (e.g. for a lamella system you can use the -dim settings to get that right) and model any frame in the geometric model. However, in cases where e.g. the ratio of system thickness to system size dimension is quite high and thus the frame will significantly influence the BSDF, it is better to include the real geometry in the BSDF simulation model. However, you then probably end up generating more than a single BSDF for the same system depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:[email protected]>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make sure you're system is situated properly for the genBSDF run. +Z is into the space, +Y is up. All of the geometry should be in the -Z space. If you don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:
Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road…

The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the ‚Äďdim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.

In my BSDF material definition, I would alter the up vector according to the surface being applied ‚Äď the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry‚Äôs orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU’s with varying properties? It seems so from David Geisler-Moroder’s presentation at the 2012 Workshop (http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf). Certainly skylights and windows will have different VLT and it would again be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to ask these questions while I’m waiting on genBSDF.

Any help is much appreciated, as always.

Chris Coulter
Senior Lighting Designer
Buro Happold Consulting Engineers
100 Broadway, 23rd Floor
New York, NY 10005
Tel: 212.334.2025<tel:212.334.2025>
Direct: 212.616.0254<tel:212.616.0254>
Email: [email protected]<mailto:[email protected]>
Website: www.burohappold.com<http://www.burohappold.com>

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

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

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

Andy/David/Rob - Thanks for the encouragement and suggestions.

I've been working through trying to troubleshoot as I go along. Studying it in a 10m cube so I can easily understand how the light is being redistributed rather than in my full model. I also found that running the CFS through genBSDF with an all black material helpful to digest that specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf seems backwards using the same geometry - which is unnerving. I'm reworking the process and will post updates, and inevitably more questions. I was finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much easier once I realized the network had been disabled and then resolved my proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will look into it.

David, your note was clear. Thanks. My system is grid a 10mm cubes fit into skylights that are 4m x 8m or larger. I think the edge condition can be ignored in the BSDF calculation.

Thanks again all for help here and in the tutorials, presentations, code, etc. Once I can confirm my results are wrong and its not as much of a user error as it likely is, I'll post more info/questions.

Chris

···

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF distribution) are very useful for getting comfortable with your generated BSDFs. I am working on a little "test room" model, a la the ltview script but for CFS instead of luminaries. When it's sensible I'll post some results. It's very helpful to visualize these things; Andy's BSDFviewer is awesome, but I also like to mock these things up in Radiance proper so I am certain the functions and the models are are being implemented and oriented correctly, you know what I mean?

- Rob

From: David Geisler-Moroder <[email protected]<mailto:[email protected]>>
Reply-To: Radiance discussion <[email protected]<mailto:[email protected]>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:[email protected]>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs including the glass panes of your IGU. Therefore my approach is usually to simulate only the system without any glazing and put the overall system together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single system you should decide if the kind of system you are simulating is representative for your application. I tend to simulate typical periods of a systems (e.g. for a lamella system you can use the -dim settings to get that right) and model any frame in the geometric model. However, in cases where e.g. the ratio of system thickness to system size dimension is quite high and thus the frame will significantly influence the BSDF, it is better to include the real geometry in the BSDF simulation model. However, you then probably end up generating more than a single BSDF for the same system depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:[email protected]>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make sure you're system is situated properly for the genBSDF run. +Z is into the space, +Y is up. All of the geometry should be in the -Z space. If you don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:
Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the -dim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.

In my BSDF material definition, I would alter the up vector according to the surface being applied - the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry's orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU's with varying properties? It seems so from David Geisler-Moroder's presentation at the 2012 Workshop (http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf). Certainly skylights and windows will have different VLT and it would again be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

Chris Coulter
Senior Lighting Designer
Buro Happold Consulting Engineers
100 Broadway, 23rd Floor
New York, NY 10005
Tel: 212.334.2025<tel:212.334.2025>
Direct: 212.616.0254<tel:212.616.0254>
Email: [email protected]<mailto:[email protected]>
Website: www.burohappold.com<http://www.burohappold.com>

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

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

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

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

Chris,
A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree
BSDFs that flips the transmission front and back. So your tensor tree BSDF
is probably fine. My stupid utility has a bug. I'll let you know when I've
fixed it and posted a new version.
Andy

···

On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter < [email protected]> wrote:

Andy/David/Rob - Thanks for the encouragement and suggestions.

I've been working through trying to troubleshoot as I go along. Studying
it in a 10m cube so I can easily understand how the light is being
redistributed rather than in my full model. I also found that running the
CFS through genBSDF with an all black material helpful to digest that
specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me
understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf
seems backwards using the same geometry - which is unnerving. I'm reworking
the process and will post updates, and inevitably more questions. I was
finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much
easier once I realized the network had been disabled and then resolved my
proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will
look into it.

David, your note was clear. Thanks. My system is grid a 10mm cubes fit
into skylights that are 4m x 8m or larger. I think the edge condition can
be ignored in the BSDF calculation.

Thanks again all for help here and in the tutorials, presentations, code,
etc. Once I can confirm my results are wrong and its not as much of a user
error as it likely is, I'll post more info/questions.

Chris

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for
visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF
distribution) are very useful for getting comfortable with your generated
BSDFs. I am working on a little "test room" model, a la the ltview script
but for CFS instead of luminaries. When it's sensible I'll post some
results. It's very helpful to visualize these things; Andy's BSDFviewer is
awesome, but I also like to mock these things up in Radiance proper so I am
certain the functions and the models are are being implemented and oriented
correctly, you know what I mean?

- Rob

From: David Geisler-Moroder <[email protected]<mailto:
[email protected]>>
Reply-To: Radiance discussion <[email protected]
<mailto:[email protected]>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:
[email protected]>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs
including the glass panes of your IGU. Therefore my approach is usually to
simulate only the system without any glazing and put the overall system
together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single
system you should decide if the kind of system you are simulating is
representative for your application. I tend to simulate typical periods of
a systems (e.g. for a lamella system you can use the -dim settings to get
that right) and model any frame in the geometric model. However, in cases
where e.g. the ratio of system thickness to system size dimension is quite
high and thus the frame will significantly influence the BSDF, it is better
to include the real geometry in the BSDF simulation model. However, you
then probably end up generating more than a single BSDF for the same system
depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:
[email protected]>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make
sure you're system is situated properly for the genBSDF run. +Z is into the
space, +Y is up. All of the geometry should be in the -Z space. If you
don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter < > [email protected]<mailto:[email protected]>> > wrote:
Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able
to apply a BSDF to one of my projects. This project will be using
micro-louver cellular structures imbedded within an IGU, in both skylights
and vertical windows. I think I understand the general process, but wanted
to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in
multiple orientations (of course). My understanding of the BSDF and
seemingly from this mail (
http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html),
I should be able to calculate the BSDF once for my system. I was planning
model the louvers as 1m by 1m, but run genBSDF with the -dim arguments
smaller than this. Is this the correct approach? Ideally I would not
calculate the BSDF for each orientation, assuming that micro-louver
geometry does not change.

In my BSDF material definition, I would alter the up vector according to
the surface being applied - the up vector matches the BSDF orientation
(calculated in xy space) to the specific geometry's orientation (0 0 1 for
a window). If the louver are rotated within the IGU assembly (rz -45) for a
skylight, I can account for this with the up vector of 1 1 0 (surface
normal is 0 0 1). This would hold true for rotation within the vertical
apertures as well. Each different up vector would be a different BSDF
material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import
the BSDF file into Window and create multiple options for IGU's with
varying properties? It seems so from David Geisler-Moroder's presentation
at the 2012 Workshop (
http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf).
Certainly skylights and windows will have different VLT and it would again
be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to
ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

Chris Coulter
Senior Lighting Designer
Buro Happold Consulting Engineers
100 Broadway, 23rd Floor
New York, NY 10005
Tel: 212.334.2025<tel:212.334.2025>
Direct: 212.616.0254<tel:212.616.0254>
Email: [email protected]<mailto:[email protected]>
Website: www.burohappold.com<http://www.burohappold.com>

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

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

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

_______________________________________________
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

That's good to hear...I was just about to upload some images asking for clarification.

Follow-up to the 5-phase process:
I'm using a small CFS model to generate my BSDF, do I need to create an array with the actual geometry covering the full aperture for the Direct Sun Contribution (Cds)?

For rendering - It seems so, otherwise I don't see how the shadow rays are traced that get piped to rcontrib. model_nosuns.oct doesn't have the proxy surface, only physical geometry.
For calc points - Maybe? The model_suns.oct has both physical geometry and proxied geometry.

Although, when I try the as the tutorial states, I get a "rtrace: Broken Pipe" error. My tensor tree BSDF has an error for 110.9% rear reflection.
Just to verify that wasn't an issue, I doubled back to the files used in Andy's tutorial, I also get the error. Code run there was:
vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn -faa -ab 0 octs/model_nosuns.oct | \
            rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac -fo -o viewpics_ds/back_%04d.hdr \
            -e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I -ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct
My standard build is the HEAD from 26SEP13, but also tried one from last week (2/21) with no success.

General question if 5-phase is unable to work without full geometry for the CFS, are we then limited to only systems that can be modeled (ie, no lenses, laser cut panels, etc)?

Sorry if I'm all over the place, I started writing this mail at 3p.

Chris

···

From: Andrew McNeil [mailto:[email protected]]
Sent: Thursday, February 27, 2014 1:54 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Chris,
A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree BSDFs that flips the transmission front and back. So your tensor tree BSDF is probably fine. My stupid utility has a bug. I'll let you know when I've fixed it and posted a new version.
Andy

On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:
Andy/David/Rob - Thanks for the encouragement and suggestions.

I've been working through trying to troubleshoot as I go along. Studying it in a 10m cube so I can easily understand how the light is being redistributed rather than in my full model. I also found that running the CFS through genBSDF with an all black material helpful to digest that specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf seems backwards using the same geometry - which is unnerving. I'm reworking the process and will post updates, and inevitably more questions. I was finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much easier once I realized the network had been disabled and then resolved my proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will look into it.

David, your note was clear. Thanks. My system is grid a 10mm cubes fit into skylights that are 4m x 8m or larger. I think the edge condition can be ignored in the BSDF calculation.

Thanks again all for help here and in the tutorials, presentations, code, etc. Once I can confirm my results are wrong and its not as much of a user error as it likely is, I'll post more info/questions.

Chris

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF distribution) are very useful for getting comfortable with your generated BSDFs. I am working on a little "test room" model, a la the ltview script but for CFS instead of luminaries. When it's sensible I'll post some results. It's very helpful to visualize these things; Andy's BSDFviewer is awesome, but I also like to mock these things up in Radiance proper so I am certain the functions and the models are are being implemented and oriented correctly, you know what I mean?

- Rob

From: David Geisler-Moroder <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Reply-To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs including the glass panes of your IGU. Therefore my approach is usually to simulate only the system without any glazing and put the overall system together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single system you should decide if the kind of system you are simulating is representative for your application. I tend to simulate typical periods of a systems (e.g. for a lamella system you can use the -dim settings to get that right) and model any frame in the geometric model. However, in cases where e.g. the ratio of system thickness to system size dimension is quite high and thus the frame will significantly influence the BSDF, it is better to include the real geometry in the BSDF simulation model. However, you then probably end up generating more than a single BSDF for the same system depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make sure you're system is situated properly for the genBSDF run. +Z is into the space, +Y is up. All of the geometry should be in the -Z space. If you don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:
Good morning Gurus!
I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the -dim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.

In my BSDF material definition, I would alter the up vector according to the surface being applied - the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry's orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU's with varying properties? It seems so from David Geisler-Moroder's presentation at the 2012 Workshop (http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf). Certainly skylights and windows will have different VLT and it would again be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

Chris Coulter
Senior Lighting Designer
Buro Happold Consulting Engineers
100 Broadway, 23rd Floor
New York, NY 10005
Tel: 212.334.2025<tel:212.334.2025><tel:212.334.2025<tel:212.334.2025>>
Direct: 212.616.0254<tel:212.616.0254><tel:212.616.0254<tel:212.616.0254>>
Email: [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
Website: www.burohappold.com<http://www.burohappold.com><http://www.burohappold.com>

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

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

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

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

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

Hi Chris,

Looking at the command you quoted, the "-opn" option to rtrace should be "-opN" for better efficiency, but this isn't what's causing the "broken pipe" error. That indicates that rcontrib is refusing input before rtrace is done supplying it.

The only think I can think of is that you are running out of file descriptors. If using "-e MF:2" instead of "-e MF:6" solves the problem, then this is the most likely cause. The MF:6 setting requires 5186 descriptors. Quoting Thomas Bleicher from a Feb. 2007 post:

On Mac OS X the max number of open files is limited to 256 per
user process. That's pretty low and not sufficient for any subdivision
of the Tregenza sky pattern.

To change the open files limit (on OS X!) I created a file
"/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
and I set the kernel limit with "sysctl -w kern.maxfiles=1024".

After a reboot I could set the shell's limit with "ulimit -n 1024".
This can go into your ".profile" if you're going to use it a lot.

Unfortunately, the method for changing the number of allowed descriptors varies from one system to the next. Good luck!

Best,
-Greg

···

From: Chris Coulter <[email protected]>
Date: February 27, 2014 3:47:22 PM PST

That’s good to hear…I was just about to upload some images asking for clarification.

Follow-up to the 5-phase process:
I’m using a small CFS model to generate my BSDF, do I need to create an array with the actual geometry covering the full aperture for the Direct Sun Contribution (Cds)?

For rendering - It seems so, otherwise I don’t see how the shadow rays are traced that get piped to rcontrib. model_nosuns.oct doesn’t have the proxy surface, only physical geometry.
For calc points ‚Äď Maybe? The model_suns.oct has both physical geometry and proxied geometry.

Although, when I try the as the tutorial states, I get a ‚Äúrtrace: Broken Pipe‚ÄĚ error. My tensor tree BSDF has an error for 110.9% rear reflection.
Just to verify that wasn’t an issue, I doubled back to the files used in Andy’s tutorial, I also get the error. Code run there was:
vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn -faa -ab 0 octs/model_nosuns.oct | \
            rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac -fo -o viewpics_ds/back_%04d.hdr \
            -e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I -ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct
My standard build is the HEAD from 26SEP13, but also tried one from last week (2/21) with no success.

General question if 5-phase is unable to work without full geometry for the CFS, are we then limited to only systems that can be modeled (ie, no lenses, laser cut panels, etc)?

Sorry if I’m all over the place, I started writing this mail at 3p.

Chris

From: Andrew McNeil [mailto:[email protected]]
Sent: Thursday, February 27, 2014 1:54 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Chris,
A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree BSDFs that flips the transmission front and back. So your tensor tree BSDF is probably fine. My stupid utility has a bug. I'll let you know when I've fixed it and posted a new version.
Andy

On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter <[email protected]> wrote:
Andy/David/Rob - Thanks for the encouragement and suggestions.

I've been working through trying to troubleshoot as I go along. Studying it in a 10m cube so I can easily understand how the light is being redistributed rather than in my full model. I also found that running the CFS through genBSDF with an all black material helpful to digest that specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf seems backwards using the same geometry - which is unnerving. I'm reworking the process and will post updates, and inevitably more questions. I was finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much easier once I realized the network had been disabled and then resolved my proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will look into it.

David, your note was clear. Thanks. My system is grid a 10mm cubes fit into skylights that are 4m x 8m or larger. I think the edge condition can be ignored in the BSDF calculation.

Thanks again all for help here and in the tutorials, presentations, code, etc. Once I can confirm my results are wrong and its not as much of a user error as it likely is, I'll post more info/questions.

Chris

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF distribution) are very useful for getting comfortable with your generated BSDFs. I am working on a little "test room" model, a la the ltview script but for CFS instead of luminaries. When it's sensible I'll post some results. It's very helpful to visualize these things; Andy's BSDFviewer is awesome, but I also like to mock these things up in Radiance proper so I am certain the functions and the models are are being implemented and oriented correctly, you know what I mean?

- Rob

From: David Geisler-Moroder <[email protected]<mailto:[email protected]>>
Reply-To: Radiance discussion <[email protected]<mailto:[email protected]>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:[email protected]>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs including the glass panes of your IGU. Therefore my approach is usually to simulate only the system without any glazing and put the overall system together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single system you should decide if the kind of system you are simulating is representative for your application. I tend to simulate typical periods of a systems (e.g. for a lamella system you can use the -dim settings to get that right) and model any frame in the geometric model. However, in cases where e.g. the ratio of system thickness to system size dimension is quite high and thus the frame will significantly influence the BSDF, it is better to include the real geometry in the BSDF simulation model. However, you then probably end up generating more than a single BSDF for the same system depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:[email protected]>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make sure you're system is situated properly for the genBSDF run. +Z is into the space, +Y is up. All of the geometry should be in the -Z space. If you don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:
Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the -dim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.

In my BSDF material definition, I would alter the up vector according to the surface being applied - the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry's orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU's with varying properties? It seems so from David Geisler-Moroder's presentation at the 2012 Workshop (http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf). Certainly skylights and windows will have different VLT and it would again be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

Chris Coulter

Chris,

You can use the 5-phase method without CFS geometry. just use a BSDF
material with zero thickness in model_suns.oct. This approach makes sense
for a case where you have a tensor tree BSDF but can't model the actual
system geometry.

Andy

···

On Thu, Feb 27, 2014 at 3:47 PM, Chris Coulter < [email protected]> wrote:

General question if 5-phase is unable to work without full geometry for
the CFS, are we then limited to only systems that can be modeled (ie, no
lenses, laser cut panels, etc)?

Thanks, Greg. I knew I had previously changed the ulimit, and verified it was higher than default. I was at 4096 - close but radiance isn't horseshoes or hand grenades.

Chris

···

From: Greg Ward [mailto:[email protected]]
Sent: Monday, March 03, 2014 12:47 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

Looking at the command you quoted, the "-opn" option to rtrace should be "-opN" for better efficiency, but this isn't what's causing the "broken pipe" error. That indicates that rcontrib is refusing input before rtrace is done supplying it.

The only think I can think of is that you are running out of file descriptors. If using "-e MF:2" instead of "-e MF:6" solves the problem, then this is the most likely cause. The MF:6 setting requires 5186 descriptors. Quoting Thomas Bleicher from a Feb. 2007 post:

On Mac OS X the max number of open files is limited to 256 per
user process. That's pretty low and not sufficient for any subdivision
of the Tregenza sky pattern.

To change the open files limit (on OS X!) I created a file
"/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
and I set the kernel limit with "sysctl -w kern.maxfiles=1024".

After a reboot I could set the shell's limit with "ulimit -n 1024".
This can go into your ".profile" if you're going to use it a lot.

Unfortunately, the method for changing the number of allowed descriptors varies from one system to the next. Good luck!

Best,
-Greg

From: Chris Coulter <[email protected]<mailto:[email protected]>>

Date: February 27, 2014 3:47:22 PM PST

That's good to hear...I was just about to upload some images asking for clarification.

Follow-up to the 5-phase process:
I'm using a small CFS model to generate my BSDF, do I need to create an array with the actual geometry covering the full aperture for the Direct Sun Contribution (Cds)?

For rendering - It seems so, otherwise I don't see how the shadow rays are traced that get piped to rcontrib. model_nosuns.oct doesn't have the proxy surface, only physical geometry.
For calc points - Maybe? The model_suns.oct has both physical geometry and proxied geometry.

Although, when I try the as the tutorial states, I get a "rtrace: Broken Pipe" error. My tensor tree BSDF has an error for 110.9% rear reflection.
Just to verify that wasn't an issue, I doubled back to the files used in Andy's tutorial, I also get the error. Code run there was:
vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn -faa -ab 0 octs/model_nosuns.oct | \
            rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac -fo -o viewpics_ds/back_%04d.hdr \
            -e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I -ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct
My standard build is the HEAD from 26SEP13, but also tried one from last week (2/21) with no success.

General question if 5-phase is unable to work without full geometry for the CFS, are we then limited to only systems that can be modeled (ie, no lenses, laser cut panels, etc)?

Sorry if I'm all over the place, I started writing this mail at 3p.

Chris

From: Andrew McNeil [mailto:[email protected]]
Sent: Thursday, February 27, 2014 1:54 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Chris,
A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree BSDFs that flips the transmission front and back. So your tensor tree BSDF is probably fine. My stupid utility has a bug. I'll let you know when I've fixed it and posted a new version.
Andy

On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:
Andy/David/Rob - Thanks for the encouragement and suggestions.

I've been working through trying to troubleshoot as I go along. Studying it in a 10m cube so I can easily understand how the light is being redistributed rather than in my full model. I also found that running the CFS through genBSDF with an all black material helpful to digest that specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf seems backwards using the same geometry - which is unnerving. I'm reworking the process and will post updates, and inevitably more questions. I was finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much easier once I realized the network had been disabled and then resolved my proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will look into it.

David, your note was clear. Thanks. My system is grid a 10mm cubes fit into skylights that are 4m x 8m or larger. I think the edge condition can be ignored in the BSDF calculation.

Thanks again all for help here and in the tutorials, presentations, code, etc. Once I can confirm my results are wrong and its not as much of a user error as it likely is, I'll post more info/questions.

Chris

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF distribution) are very useful for getting comfortable with your generated BSDFs. I am working on a little "test room" model, a la the ltview script but for CFS instead of luminaries. When it's sensible I'll post some results. It's very helpful to visualize these things; Andy's BSDFviewer is awesome, but I also like to mock these things up in Radiance proper so I am certain the functions and the models are are being implemented and oriented correctly, you know what I mean?

- Rob

From: David Geisler-Moroder <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Reply-To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs including the glass panes of your IGU. Therefore my approach is usually to simulate only the system without any glazing and put the overall system together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single system you should decide if the kind of system you are simulating is representative for your application. I tend to simulate typical periods of a systems (e.g. for a lamella system you can use the -dim settings to get that right) and model any frame in the geometric model. However, in cases where e.g. the ratio of system thickness to system size dimension is quite high and thus the frame will significantly influence the BSDF, it is better to include the real geometry in the BSDF simulation model. However, you then probably end up generating more than a single BSDF for the same system depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make sure you're system is situated properly for the genBSDF run. +Z is into the space, +Y is up. All of the geometry should be in the -Z space. If you don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:
Good morning Gurus!
I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the -dim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.

In my BSDF material definition, I would alter the up vector according to the surface being applied - the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry's orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU's with varying properties? It seems so from David Geisler-Moroder's presentation at the 2012 Workshop (http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf). Certainly skylights and windows will have different VLT and it would again be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

Chris Coulter

This didn't get through when I originally set it so I'm trying again...

Chris,

You can use the 5-phase method without CFS geometry. just use a BSDF
material with zero thickness in model_suns.oct. This approach makes sense
for a case where you have a tensor tree BSDF but can't model the actual
system geometry.

Andy

···

On Tue, Mar 4, 2014 at 8:40 AM, Chris Coulter <[email protected] > wrote:

Thanks, Greg. I knew I had previously changed the ulimit, and verified
it was higher than default. I was at 4096 - close but radiance isn't
horseshoes or hand grenades.

Chris

*From:* Greg Ward [mailto:[email protected]]
*Sent:* Monday, March 03, 2014 12:47 PM

*To:* Radiance general discussion
*Subject:* Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

Looking at the command you quoted, the "-opn" option to rtrace should be
"-opN" for better efficiency, but this isn't what's causing the "broken
pipe" error. That indicates that rcontrib is refusing input before rtrace
is done supplying it.

The only think I can think of is that you are running out of file
descriptors. If using "-e MF:2" instead of "-e MF:6" solves the problem,
then this is the most likely cause. The MF:6 setting requires 5186
descriptors. Quoting Thomas Bleicher from a Feb. 2007 post:

On Mac OS X the max number of open files is limited to 256 per
user process. That's pretty low and not sufficient for any subdivision
of the Tregenza sky pattern.

To change the open files limit (on OS X!) I created a file
"/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
and I set the kernel limit with "sysctl -w kern.maxfiles=1024".

After a reboot I could set the shell's limit with "ulimit -n 1024".
This can go into your ".profile" if you're going to use it a lot.

Unfortunately, the method for changing the number of allowed descriptors
varies from one system to the next. Good luck!

Best,

-Greg

*From: *Chris Coulter <[email protected]>

*Date: *February 27, 2014 3:47:22 PM PST

That's good to hear...I was just about to upload some images asking for
clarification.

Follow-up to the 5-phase process:

I'm using a small CFS model to generate my BSDF, do I need to create an
array with the actual geometry covering the full aperture for the Direct
Sun Contribution (Cds)?

For rendering - It seems so, otherwise I don't see how the shadow rays are
traced that get piped to rcontrib. model_nosuns.oct doesn't have the proxy
surface, only physical geometry.

For calc points - Maybe? The model_suns.oct has both physical geometry and
proxied geometry.

Although, when I try the as the tutorial states, I get a "rtrace: Broken
Pipe" error. My tensor tree BSDF has an error for 110.9% rear reflection.

Just to verify that wasn't an issue, I doubled back to the files used in
Andy's tutorial, I also get the error. Code run there was:

vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn
-faa -ab 0 octs/model_nosuns.oct | \

            rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac
-fo -o viewpics_ds/back_%04d.hdr \

            -e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I
-ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct

My standard build is the HEAD from 26SEP13, but also tried one from last
week (2/21) with no success.

General question if 5-phase is unable to work without full geometry for
the CFS, are we then limited to only systems that can be modeled (ie, no
lenses, laser cut panels, etc)?

Sorry if I'm all over the place, I started writing this mail at 3p.

*Chris*

*From:* Andrew McNeil [mailto:[email protected] <[email protected]>]
*Sent:* Thursday, February 27, 2014 1:54 PM
*To:* Radiance general discussion
*Subject:* Re: [Radiance-general] BSDF orientation and implementation

Chris,

A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree
BSDFs that flips the transmission front and back. So your tensor tree BSDF
is probably fine. My stupid utility has a bug. I'll let you know when I've
fixed it and posted a new version.

Andy

On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter < > [email protected]> wrote:

Andy/David/Rob - Thanks for the encouragement and suggestions.

I've been working through trying to troubleshoot as I go along. Studying
it in a 10m cube so I can easily understand how the light is being
redistributed rather than in my full model. I also found that running the
CFS through genBSDF with an all black material helpful to digest that
specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me
understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf
seems backwards using the same geometry - which is unnerving. I'm reworking
the process and will post updates, and inevitably more questions. I was
finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much
easier once I realized the network had been disabled and then resolved my
proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will
look into it.

David, your note was clear. Thanks. My system is grid a 10mm cubes fit
into skylights that are 4m x 8m or larger. I think the edge condition can
be ignored in the BSDF calculation.

Thanks again all for help here and in the tutorials, presentations, code,
etc. Once I can confirm my results are wrong and its not as much of a user
error as it likely is, I'll post more info/questions.

Chris

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for
visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF
distribution) are very useful for getting comfortable with your generated
BSDFs. I am working on a little "test room" model, a la the ltview script
but for CFS instead of luminaries. When it's sensible I'll post some
results. It's very helpful to visualize these things; Andy's BSDFviewer is
awesome, but I also like to mock these things up in Radiance proper so I am
certain the functions and the models are are being implemented and oriented
correctly, you know what I mean?

- Rob

From: David Geisler-Moroder <[email protected]<mailto:
[email protected]>>
Reply-To: Radiance discussion <[email protected]
<mailto:[email protected]>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:
[email protected]>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs
including the glass panes of your IGU. Therefore my approach is usually to
simulate only the system without any glazing and put the overall system
together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single
system you should decide if the kind of system you are simulating is
representative for your application. I tend to simulate typical periods of
a systems (e.g. for a lamella system you can use the -dim settings to get
that right) and model any frame in the geometric model. However, in cases
where e.g. the ratio of system thickness to system size dimension is quite
high and thus the frame will significantly influence the BSDF, it is better
to include the real geometry in the BSDF simulation model. However, you
then probably end up generating more than a single BSDF for the same system
depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:
[email protected]>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make
sure you're system is situated properly for the genBSDF run. +Z is into the
space, +Y is up. All of the geometry should be in the -Z space. If you
don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter < > [email protected]<mailto:[email protected]>> > wrote:
Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able
to apply a BSDF to one of my projects. This project will be using
micro-louver cellular structures imbedded within an IGU, in both skylights
and vertical windows. I think I understand the general process, but wanted
to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in
multiple orientations (of course). My understanding of the BSDF and
seemingly from this mail (
http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html),
I should be able to calculate the BSDF once for my system. I was planning
model the louvers as 1m by 1m, but run genBSDF with the -dim arguments
smaller than this. Is this the correct approach? Ideally I would not
calculate the BSDF for each orientation, assuming that micro-louver
geometry does not change.

In my BSDF material definition, I would alter the up vector according to
the surface being applied - the up vector matches the BSDF orientation
(calculated in xy space) to the specific geometry's orientation (0 0 1 for
a window). If the louver are rotated within the IGU assembly (rz -45) for a
skylight, I can account for this with the up vector of 1 1 0 (surface
normal is 0 0 1). This would hold true for rotation within the vertical
apertures as well. Each different up vector would be a different BSDF
material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import
the BSDF file into Window and create multiple options for IGU's with
varying properties? It seems so from David Geisler-Moroder's presentation
at the 2012 Workshop (
http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf).
Certainly skylights and windows will have different VLT and it would again
be nice to not be required to run genBSDF multiple times.

I am in the process of working through the steps on my own, but wanted to
ask these questions while I'm waiting on genBSDF.

Any help is much appreciated, as always.

Chris Coulter

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

To confirm BSDF orientation in the 3-phase steps:

If I have a skylight where the CFS is rotated -45 in the plane of the glass to align w/ site rotation, the daylightmatrix command should look something like this:
        genklemsamp -vd 0 0 1 -vu 1 1 0 dmx_surf.rad | rcontrib -c 1000 -ab 2 -ad 1024 -e MF:1 -f reinhart.cal -b rbin -bn Nrbins -m sky_glow model_3ph.oct > daylightmatrix.dmx

I previously had the -vu as 0 1 0, but realized that setting the vu as noted above is probably used to correctly orient the bsdf within the skylight - right? The standard application of a vertical aperture would typically be -vu 0 0 1 (or not expressed, as this would be the default) unless this has a similar orientation adjustment. I know the Direct Sun Coeff Matrix uses physical geomtry w/ the BSDF primative that is oriented in the material description. I realized that my first pass at the daylight matrices didn't account for any rotation and this seems to be the most logical case of how to apply.

Also, is it ok to change the number of sky divisions to MF:2 or higher? I know the klems patches are 145, but didn't know if there was something that would be incorrect in the matrix multiplication stages? I guess maybe it isn't as critical as generally you're trying to make the sun patches smaller, which is what the 5-phase method introduces. Maybe an increase in the accuracy of the diffuse calcs...? If it is acceptable, this would be both in the gendaymtx sky matrix and the daylight matrix pieces (view matrix uses klems)?

Confirmation, or corrections, are greatly appreciated. I'm trying to troubleshoot data and looking into all aspects...

Thanks
Chris

···

_____________________________________________
From: Chris Coulter [mailto:[email protected]]
Sent: Tuesday, March 04, 2014 11:40 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Thanks, Greg. I knew I had previously changed the ulimit, and verified it was higher than default. I was at 4096 - close but radiance isn't horseshoes or hand grenades.

Chris

From: Greg Ward [mailto:[email protected]]
Sent: Monday, March 03, 2014 12:47 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

Looking at the command you quoted, the "-opn" option to rtrace should be "-opN" for better efficiency, but this isn't what's causing the "broken pipe" error. That indicates that rcontrib is refusing input before rtrace is done supplying it.

The only think I can think of is that you are running out of file descriptors. If using "-e MF:2" instead of "-e MF:6" solves the problem, then this is the most likely cause. The MF:6 setting requires 5186 descriptors. Quoting Thomas Bleicher from a Feb. 2007 post:

   On Mac OS X the max number of open files is limited to 256 per
   user process. That's pretty low and not sufficient for any subdivision
   of the Tregenza sky pattern.

   To change the open files limit (on OS X!) I created a file
   "/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
   and I set the kernel limit with "sysctl -w kern.maxfiles=1024".

   After a reboot I could set the shell's limit with "ulimit -n 1024".
   This can go into your ".profile" if you're going to use it a lot.

Unfortunately, the method for changing the number of allowed descriptors varies from one system to the next. Good luck!

Best,

-Greg

¬†¬†¬†From: Chris Coulter <[email protected]<mailto:[email protected]>>

   Date: February 27, 2014 3:47:22 PM PST

   That's good to hear...I was just about to upload some images asking for clarification.

   Follow-up to the 5-phase process:

   I'm using a small CFS model to generate my BSDF, do I need to create an array with the actual geometry covering the full aperture for the Direct Sun Contribution (Cds)?

   For rendering - It seems so, otherwise I don't see how the shadow rays are traced that get piped to rcontrib. model_nosuns.oct doesn't have the proxy surface, only physical geometry.

   For calc points - Maybe? The model_suns.oct has both physical geometry and proxied geometry.

   Although, when I try the as the tutorial states, I get a "rtrace: Broken Pipe" error. My tensor tree BSDF has an error for 110.9% rear reflection.

   Just to verify that wasn't an issue, I doubled back to the files used in Andy's tutorial, I also get the error. Code run there was:

   vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn -faa -ab 0 octs/model_nosuns.oct | \

               rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac -fo -o viewpics_ds/back_%04d.hdr \

               -e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I -ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct

   My standard build is the HEAD from 26SEP13, but also tried one from last week (2/21) with no success.

   General question if 5-phase is unable to work without full geometry for the CFS, are we then limited to only systems that can be modeled (ie, no lenses, laser cut panels, etc)?

   Sorry if I'm all over the place, I started writing this mail at 3p.

   Chris

¬†¬†¬†From: Andrew McNeil [mailto:[email protected]]
   Sent: Thursday, February 27, 2014 1:54 PM
   To: Radiance general discussion
   Subject: Re: [Radiance-general] BSDF orientation and implementation

   Chris,

   A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree BSDFs that flips the transmission front and back. So your tensor tree BSDF is probably fine. My stupid utility has a bug. I'll let you know when I've fixed it and posted a new version.

   Andy

¬†¬†¬†On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:

   Andy/David/Rob - Thanks for the encouragement and suggestions.

   I've been working through trying to troubleshoot as I go along. Studying it in a 10m cube so I can easily understand how the light is being redistributed rather than in my full model. I also found that running the CFS through genBSDF with an all black material helpful to digest that specular transmission is occurring as expected.
   Andy's reminder that +Z is "in" the space was helpful in making me understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf seems backwards using the same geometry - which is unnerving. I'm reworking the process and will post updates, and inevitably more questions. I was finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much easier once I realized the network had been disabled and then resolved my proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will look into it.

   David, your note was clear. Thanks. My system is grid a 10mm cubes fit into skylights that are 4m x 8m or larger. I think the edge condition can be ignored in the BSDF calculation.

   Thanks again all for help here and in the tutorials, presentations, code, etc. Once I can confirm my results are wrong and its not as much of a user error as it likely is, I'll post more info/questions.

   Chris

   -----Original Message-----
¬†¬†¬†From: Guglielmetti, Robert [mailto:[email protected]<mailto:[email protected]>]
   Sent: Wednesday, February 26, 2014 11:40 PM
   To: Radiance general discussion
   Subject: Re: [Radiance-general] BSDF orientation and implementation

   Hi Chris,

   What Andy said! To that end, I would add that tools like objview (for visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF distribution) are very useful for getting comfortable with your generated BSDFs. I am working on a little "test room" model, a la the ltview script but for CFS instead of luminaries. When it's sensible I'll post some results. It's very helpful to visualize these things; Andy's BSDFviewer is awesome, but I also like to mock these things up in Radiance proper so I am certain the functions and the models are are being implemented and oriented correctly, you know what I mean?

   - Rob

¬†¬†¬†From: David Geisler-Moroder <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
¬†¬†¬†Reply-To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
   Date: Wednesday, February 26, 2014 at 10:34 AM
¬†¬†¬†To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
   Subject: Re: [Radiance-general] BSDF orientation and implementation

   Hi Chris,

   a short note from my side:
   Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs including the glass panes of your IGU. Therefore my approach is usually to simulate only the system without any glazing and put the overall system together in WINDOW with the right glass.
   Concerning the generation of BSDFs for various applications of a single system you should decide if the kind of system you are simulating is representative for your application. I tend to simulate typical periods of a systems (e.g. for a lamella system you can use the -dim settings to get that right) and model any frame in the geometric model. However, in cases where e.g. the ratio of system thickness to system size dimension is quite high and thus the frame will significantly influence the BSDF, it is better to include the real geometry in the BSDF simulation model. However, you then probably end up generating more than a single BSDF for the same system depending on the applications.

   I hope it's somehow clear... if not, let me know and I'll try again :wink:

   Cheers,
   David

¬†¬†¬†2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>:
   Chris,
   Everything you write seems correct. One whatch-it I can offer is to make sure you're system is situated properly for the genBSDF run. +Z is into the space, +Y is up. All of the geometry should be in the -Z space. If you don't follow these guidelines you're BSDF will be strange.
   Andy

¬†¬†¬†On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:
   Good morning Gurus!

   I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the -dim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.

In my BSDF material definition, I would alter the up vector according to the surface being applied - the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry's orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU's with varying properties? It seems so from David Geisler-Moroder's presentation at the 2012 Workshop (

Attachments:
        ATT00001.txt (248 Bytes)

Chris,

Your view settings for genklemsamp look appropriate. You also need to
rotate the angular bins in your view matrix simulation. You can do this
with the -b argument:

-b 'kbin(0,0,1,1,1,0)'

first three values are from the -vd in genklemsamp and the last three
values are from the -vu option.

You can use any number of sky divisions, but the number of sky divisions
must be the same when generating the sky matrix and daylight matrix. If
they are not the same then matrix multiplication won't work.

Andy

···

On Fri, Apr 18, 2014 at 11:15 AM, Chris Coulter < [email protected]> wrote:

To confirm BSDF orientation in the 3-phase steps:

If I have a skylight where the CFS is rotated -45 in the plane of the
glass to align w/ site rotation, the daylightmatrix command should look
something like this:
        genklemsamp -vd 0 0 1 -vu 1 1 0 dmx_surf.rad | rcontrib -c 1000
-ab 2 -ad 1024 -e MF:1 -f reinhart.cal -b rbin -bn Nrbins -m sky_glow
model_3ph.oct > daylightmatrix.dmx

I previously had the -vu as 0 1 0, but realized that setting the vu as
noted above is probably used to correctly orient the bsdf within the
skylight - right? The standard application of a vertical aperture would
typically be -vu 0 0 1 (or not expressed, as this would be the default)
unless this has a similar orientation adjustment. I know the Direct Sun
Coeff Matrix uses physical geomtry w/ the BSDF primative that is oriented
in the material description. I realized that my first pass at the daylight
matrices didn't account for any rotation and this seems to be the most
logical case of how to apply.

Also, is it ok to change the number of sky divisions to MF:2 or higher? I
know the klems patches are 145, but didn't know if there was something that
would be incorrect in the matrix multiplication stages? I guess maybe it
isn't as critical as generally you're trying to make the sun patches
smaller, which is what the 5-phase method introduces. Maybe an increase in
the accuracy of the diffuse calcs...? If it is acceptable, this would be both
in the gendaymtx sky matrix and the daylight matrix pieces (view matrix
uses klems)?

Confirmation, or corrections, are greatly appreciated. I'm trying to
troubleshoot data and looking into all aspects...

Thanks
Chris

_____________________________________________
*From:* Chris Coulter [mailto:[email protected]<[email protected]>]

*Sent:* Tuesday, March 04, 2014 11:40 AM

*To:* Radiance general discussion
*Subject:* Re: [Radiance-general] BSDF orientation and implementation

Thanks, Greg. I knew I had previously changed the ulimit, and verified it
was higher than default. I was at 4096 - close but radiance isn't
horseshoes or hand grenades.

Chris

*From:* Greg Ward [mailto:[email protected] <[email protected]>]

*Sent:* Monday, March 03, 2014 12:47 PM
*To:* Radiance general discussion
*Subject:* Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

Looking at the command you quoted, the "-opn" option to rtrace should be
"-opN" for better efficiency, but this isn't what's causing the "broken
pipe" error. That indicates that rcontrib is refusing input before rtrace
is done supplying it.

The only think I can think of is that you are running out of file
descriptors. If using "-e MF:2" instead of "-e MF:6" solves the problem,
then this is the most likely cause. The MF:6 setting requires 5186
descriptors. Quoting Thomas Bleicher from a Feb. 2007 post:

On Mac OS X the max number of open files is limited to 256 per
user process. That's pretty low and not sufficient for any subdivision
of the Tregenza sky pattern.

To change the open files limit (on OS X!) I created a file
"/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
and I set the kernel limit with "sysctl -w kern.maxfiles=1024".

After a reboot I could set the shell's limit with "ulimit -n 1024".
This can go into your ".profile" if you're going to use it a lot.

Unfortunately, the method for changing the number of allowed descriptors
varies from one system to the next. Good luck!

Best,

-Greg

*From: *Chris Coulter <*[email protected]*<[email protected]>
>

*Date: *February 27, 2014 3:47:22 PM PST

That's good to hear...I was just about to upload some images asking for
clarification.

Follow-up to the 5-phase process:

I'm using a small CFS model to generate my BSDF, do I need to create an
array with the actual geometry covering the full aperture for the Direct
Sun Contribution (Cds)?

For rendering - It seems so, otherwise I don't see how the shadow rays are
traced that get piped to rcontrib. model_nosuns.oct doesn't have the proxy
surface, only physical geometry.

For calc points - Maybe? The model_suns.oct has both physical geometry and
proxied geometry.

Although, when I try the as the tutorial states, I get a "rtrace: Broken
Pipe" error. My tensor tree BSDF has an error for 110.9% rear reflection.

Just to verify that wasn't an issue, I doubled back to the files used in
Andy's tutorial, I also get the error. Code run there was:

vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn
-faa -ab 0 octs/model_nosuns.oct | \

            rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac
-fo -o viewpics_ds/back_%04d.hdr \

            -e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I
-ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct

My standard build is the HEAD from 26SEP13, but also tried one from last
week (2/21) with no success.

General question if 5-phase is unable to work without full geometry for
the CFS, are we then limited to only systems that can be modeled (ie, no
lenses, laser cut panels, etc)?

Sorry if I'm all over the place, I started writing this mail at 3p.

*Chris*

*From:* Andrew McNeil [mailto:[email protected] <[email protected]>]
*Sent:* Thursday, February 27, 2014 1:54 PM
*To:* Radiance general discussion
*Subject:* Re: [Radiance-general] BSDF orientation and implementation

Chris,

A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree
BSDFs that flips the transmission front and back. So your tensor tree BSDF
is probably fine. My stupid utility has a bug. I'll let you know when I've
fixed it and posted a new version.

Andy

On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter < > *[email protected]* <[email protected]>> wrote:

Andy/David/Rob - Thanks for the encouragement and suggestions.

I've been working through trying to troubleshoot as I go along. Studying
it in a 10m cube so I can easily understand how the light is being
redistributed rather than in my full model. I also found that running the
CFS through genBSDF with an all black material helpful to digest that
specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me
understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf
seems backwards using the same geometry - which is unnerving. I'm reworking
the process and will post updates, and inevitably more questions. I was
finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much
easier once I realized the network had been disabled and then resolved my
proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will
look into it.

David, your note was clear. Thanks. My system is grid a 10mm cubes fit
into skylights that are 4m x 8m or larger. I think the edge condition can
be ignored in the BSDF calculation.

Thanks again all for help here and in the tutorials, presentations, code,
etc. Once I can confirm my results are wrong and its not as much of a user
error as it likely is, I'll post more info/questions.

Chris

-----Original Message-----
From: Guglielmetti, Robert [mailto:*[email protected]*<[email protected]>
]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for
visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF
distribution) are very useful for getting comfortable with your generated
BSDFs. I am working on a little "test room" model, a la the ltview script
but for CFS instead of luminaries. When it's sensible I'll post some
results. It's very helpful to visualize these things; Andy's BSDFviewer is
awesome, but I also like to mock these things up in Radiance proper so I am
certain the functions and the models are are being implemented and oriented
correctly, you know what I mean?

- Rob

From: David Geisler-Moroder <*[email protected]*<[email protected]>
<mailto:*[email protected]* <[email protected]>>>
Reply-To: Radiance discussion <*[email protected]*<[email protected]>
<mailto:*[email protected]*<[email protected]>
>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <*[email protected]*<[email protected]>
<mailto:*[email protected]*<[email protected]>
>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs
including the glass panes of your IGU. Therefore my approach is usually to
simulate only the system without any glazing and put the overall system
together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single
system you should decide if the kind of system you are simulating is
representative for your application. I tend to simulate typical periods of
a systems (e.g. for a lamella system you can use the -dim settings to get
that right) and model any frame in the geometric model. However, in cases
where e.g. the ratio of system thickness to system size dimension is quite
high and thus the frame will significantly influence the BSDF, it is better
to include the real geometry in the BSDF simulation model. However, you
then probably end up generating more than a single BSDF for the same system
depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <*[email protected]*<[email protected]>
<mailto:*[email protected]* <[email protected]>>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make
sure you're system is situated properly for the genBSDF run. +Z is into the
space, +Y is up. All of the geometry should be in the -Z space. If you
don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter < > *[email protected]* <[email protected]><mailto: > *[email protected]* <[email protected]>>> wrote:
Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able
to apply a BSDF to one of my projects. This project will be using
micro-louver cellular structures imbedded within an IGU, in both skylights
and vertical windows. I think I understand the general process, but wanted
to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in
multiple orientations (of course). My understanding of the BSDF and
seemingly from this mail (
http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html),
I should be able to calculate the BSDF once for my system. I was planning
model the louvers as 1m by 1m, but run genBSDF with the -dim arguments
smaller than this. Is this the correct approach? Ideally I would not
calculate the BSDF for each orientation, assuming that micro-louver
geometry does not change.

In my BSDF material definition, I would alter the up vector according to
the surface being applied - the up vector matches the BSDF orientation
(calculated in xy space) to the specific geometry's orientation (0 0 1 for
a window). If the louver are rotated within the IGU assembly (rz -45) for a
skylight, I can account for this with the up vector of 1 1 0 (surface
normal is 0 0 1). This would hold true for rotation within the vertical
apertures as well. Each different up vector would be a different BSDF
material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import
the BSDF file into Window and create multiple options for IGU's with
varying properties? It seems so from David Geisler-Moroder's presentation
at the 2012 Workshop (

Attachments:
        ATT00001.txt (248 Bytes)

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

Thanks Andy! Makes sense, have to align the interior piece as well so the right energy is transferred through.
This solved the issues I was having.

C

···

From: Andrew McNeil [mailto:[email protected]]
Sent: Friday, April 18, 2014 4:06 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Chris,

Your view settings for genklemsamp look appropriate. You also need to rotate the angular bins in your view matrix simulation. You can do this with the -b argument:

-b 'kbin(0,0,1,1,1,0)'

first three values are from the -vd in genklemsamp and the last three values are from the -vu option.

You can use any number of sky divisions, but the number of sky divisions must be the same when generating the sky matrix and daylight matrix. If they are not the same then matrix multiplication won't work.

Andy

On Fri, Apr 18, 2014 at 11:15 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:
To confirm BSDF orientation in the 3-phase steps:

If I have a skylight where the CFS is rotated -45 in the plane of the glass to align w/ site rotation, the daylightmatrix command should look something like this:
        genklemsamp -vd 0 0 1 -vu 1 1 0 dmx_surf.rad | rcontrib -c 1000 -ab 2 -ad 1024 -e MF:1 -f reinhart.cal -b rbin -bn Nrbins -m sky_glow model_3ph.oct > daylightmatrix.dmx

I previously had the -vu as 0 1 0, but realized that setting the vu as noted above is probably used to correctly orient the bsdf within the skylight - right? The standard application of a vertical aperture would typically be -vu 0 0 1 (or not expressed, as this would be the default) unless this has a similar orientation adjustment. I know the Direct Sun Coeff Matrix uses physical geomtry w/ the BSDF primative that is oriented in the material description. I realized that my first pass at the daylight matrices didn't account for any rotation and this seems to be the most logical case of how to apply.

Also, is it ok to change the number of sky divisions to MF:2 or higher? I know the klems patches are 145, but didn't know if there was something that would be incorrect in the matrix multiplication stages? I guess maybe it isn't as critical as generally you're trying to make the sun patches smaller, which is what the 5-phase method introduces. Maybe an increase in the accuracy of the diffuse calcs...? If it is acceptable, this would be both in the gendaymtx sky matrix and the daylight matrix pieces (view matrix uses klems)?

Confirmation, or corrections, are greatly appreciated. I'm trying to troubleshoot data and looking into all aspects...

Thanks
Chris

_____________________________________________
From: Chris Coulter [mailto:[email protected]]
Sent: Tuesday, March 04, 2014 11:40 AM

To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Thanks, Greg. I knew I had previously changed the ulimit, and verified it was higher than default. I was at 4096 - close but radiance isn't horseshoes or hand grenades.

Chris

From: Greg Ward [mailto:[email protected]]
Sent: Monday, March 03, 2014 12:47 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

Looking at the command you quoted, the "-opn" option to rtrace should be "-opN" for better efficiency, but this isn't what's causing the "broken pipe" error. That indicates that rcontrib is refusing input before rtrace is done supplying it.

The only think I can think of is that you are running out of file descriptors. If using "-e MF:2" instead of "-e MF:6" solves the problem, then this is the most likely cause. The MF:6 setting requires 5186 descriptors. Quoting Thomas Bleicher from a Feb. 2007 post:

On Mac OS X the max number of open files is limited to 256 per
user process. That's pretty low and not sufficient for any subdivision
of the Tregenza sky pattern.

To change the open files limit (on OS X!) I created a file
"/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
and I set the kernel limit with "sysctl -w kern.maxfiles=1024".

After a reboot I could set the shell's limit with "ulimit -n 1024".
This can go into your ".profile" if you're going to use it a lot.

Unfortunately, the method for changing the number of allowed descriptors varies from one system to the next. Good luck!

Best,

-Greg

From: Chris Coulter <[email protected]<mailto:[email protected]>>

Date: February 27, 2014 3:47:22 PM PST

That's good to hear...I was just about to upload some images asking for clarification.

Follow-up to the 5-phase process:

I'm using a small CFS model to generate my BSDF, do I need to create an array with the actual geometry covering the full aperture for the Direct Sun Contribution (Cds)?

For rendering - It seems so, otherwise I don't see how the shadow rays are traced that get piped to rcontrib. model_nosuns.oct doesn't have the proxy surface, only physical geometry.

For calc points - Maybe? The model_suns.oct has both physical geometry and proxied geometry.

Although, when I try the as the tutorial states, I get a "rtrace: Broken Pipe" error. My tensor tree BSDF has an error for 110.9% rear reflection.

Just to verify that wasn't an issue, I doubled back to the files used in Andy's tutorial, I also get the error. Code run there was:

vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn -faa -ab 0 octs/model_nosuns.oct | \

            rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac -fo -o viewpics_ds/back_%04d.hdr \

            -e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I -ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct

My standard build is the HEAD from 26SEP13, but also tried one from last week (2/21) with no success.

General question if 5-phase is unable to work without full geometry for the CFS, are we then limited to only systems that can be modeled (ie, no lenses, laser cut panels, etc)?

Sorry if I'm all over the place, I started writing this mail at 3p.

Chris

From: Andrew McNeil [mailto:[email protected]]
Sent: Thursday, February 27, 2014 1:54 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Chris,

A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree BSDFs that flips the transmission front and back. So your tensor tree BSDF is probably fine. My stupid utility has a bug. I'll let you know when I've fixed it and posted a new version.

Andy

On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:

Andy/David/Rob - Thanks for the encouragement and suggestions.

I've been working through trying to troubleshoot as I go along. Studying it in a 10m cube so I can easily understand how the light is being redistributed rather than in my full model. I also found that running the CFS through genBSDF with an all black material helpful to digest that specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf seems backwards using the same geometry - which is unnerving. I'm reworking the process and will post updates, and inevitably more questions. I was finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much easier once I realized the network had been disabled and then resolved my proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will look into it.

David, your note was clear. Thanks. My system is grid a 10mm cubes fit into skylights that are 4m x 8m or larger. I think the edge condition can be ignored in the BSDF calculation.

Thanks again all for help here and in the tutorials, presentations, code, etc. Once I can confirm my results are wrong and its not as much of a user error as it likely is, I'll post more info/questions.

Chris

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

What Andy said! To that end, I would add that tools like objview (for visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF distribution) are very useful for getting comfortable with your generated BSDFs. I am working on a little "test room" model, a la the ltview script but for CFS instead of luminaries. When it's sensible I'll post some results. It's very helpful to visualize these things; Andy's BSDFviewer is awesome, but I also like to mock these things up in Radiance proper so I am certain the functions and the models are are being implemented and oriented correctly, you know what I mean?

- Rob

From: David Geisler-Moroder <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Reply-To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Subject: Re: [Radiance-general] BSDF orientation and implementation

Hi Chris,

a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs including the glass panes of your IGU. Therefore my approach is usually to simulate only the system without any glazing and put the overall system together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single system you should decide if the kind of system you are simulating is representative for your application. I tend to simulate typical periods of a systems (e.g. for a lamella system you can use the -dim settings to get that right) and model any frame in the geometric model. However, in cases where e.g. the ratio of system thickness to system size dimension is quite high and thus the frame will significantly influence the BSDF, it is better to include the real geometry in the BSDF simulation model. However, you then probably end up generating more than a single BSDF for the same system depending on the applications.

I hope it's somehow clear... if not, let me know and I'll try again :wink:

Cheers,
David

2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make sure you're system is situated properly for the genBSDF run. +Z is into the space, +Y is up. All of the geometry should be in the -Z space. If you don't follow these guidelines you're BSDF will be strange.
Andy

On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:
Good morning Gurus!

I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road...

The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the -dim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.

In my BSDF material definition, I would alter the up vector according to the surface being applied - the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry's orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.

Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU's with varying properties? It seems so from David Geisler-Moroder's presentation at the 2012 Workshop (

Attachments:
        ATT00001.txt (248 Bytes)

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