[Radiance-general] Re: query about accurately modelling glazing
Jack de Valpine
[email protected]
Thu, 15 Jan 2004 14:08:25 -0500
--------------010901070502040602010803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi All,
Well here are some further things to confuse/clarify the possibilities.
The BRTDfunc is very powerful and has multiple uses. Several things that
I actually find quite nice about it are:
* values represent transmittance and reflectance, as one might
determine from manufacturers data or from Optics 5 (a side note, I
believe that Optics 5 is actually used to calculate the values
that manufacturers then report for the measurements, this
information is incorporated into tools like the Window 4 and 5
software, some one from the LBL optics group could probably give a
better summary of the capabilities).
* allocation of values is clear, that is values are allocated to
specular and diffuse components of the material definition (the
problem here if you are trying to simulate a glazing material that
has diffuse transmittance/reflectance performance is that
manufacturers are only reporting total reflectance and
transmittance and not diffuse and specular measures, so then you
have to measure by hand. I think that Rob G. could give everyone a
really superb summary on how to setup a measuring environment for
glazing materials).
* enables simulation of more complex glazing materials such as those
that have higher or differing front/back side reflectances than
accounted for in the typical "glass" material type ( I believe
that the reflectance for the glass material type is around 7%).
Note that it is possible to use one BRTDfunc definition to define front
and backside reflectances. Note also that transmittance as I understand
it must be the same front and back (this is supported by the fact that
there is only one transmittance that is supplied in manufacturers data
and software such as Optics 5).
Here is a simple definition for a "simple" glazing material (I am pretty
confident that I am going to get some corrective feedback on this ;->):
void BRTDfunc gl.test
10
if(Rdot, .12, .11) if(Rdot, .12, .11) if(Rdot, .12, .11)
0.70 0.70 0.70
0 0 0
.
0
9
0 0 0 0 0 0 0 0 0
This would define a simple glazing material with a total front side
reflectance of 12%, a total backside reflectance of 11% and a total
transmittance of 70%. This material could be applied to a single surface
and does not need separate front and backside polygons. However what
this definition does not account for is the impact of the incident angle
of the incoming ray on the resulting transmittance and reflectance. It
is not clear to me what kind of error this might actually introduce,
however, I believe that a definition such as this could easily take the
place of the two (front and back) BRTDfunc definitions that get exported
from Optics 5.
I believe that there is some trickiness with normals and BRTDfunc, so I
hope that I am using Rdot to calculate orientation correctly?
Note that the section in the definition with the 10 arguments relates to
the specular behavior of the material and the section with 9(+)
arguments relates to the diffuse behavior of the material. Summing
between these gives us total reflectance and transmittance. In this case
the there is no diffuse behavior to the material.
Depending on the application is might be worth checking out glaze.csh in
the latest release. This calculates models for both single and double
surface glazing materials. I am not sure how it compares to glazing.cal
in terms of the accuracy of the underlying model. Note however that
glaze.csh is built around a handful (5 or 6) sets of reflectance and
transmittance values as it "database". Some of these were actually
measure by me and looking back on it, I would prefer to measure the
"pvb" materials under a more precise protocol than I did originally
(again Rob G. would be the real resource here). I would think that the
tool could be extended to account for many things that can be exported
from Optics 5. Perhaps the Optics 5 group might be interested in having
Greg develop a more robust solution for what gets exported from Optics 5
to account for a more sophisticated model of angular dependance and
other properties?
Well, all in all probably more confusion that clarity.
Best,
-Jack
Zack Rogers wrote:
> Hello,
>
>> secondly, what does this do to the transmittance? physically, the
>> transmittance going one way should be the same as the transmittance
>> going the other way. should the (rtrns, gtrns, btrns) variables then
>> be the same for both front and back panes? or does it not matter, as
>> long as the product of their transmittances is equal to that of the
>> combination.
>>
> This is true for a symetric glass composition (ie. single pane no
> low-e, double pane, clear, no low-e) but not true for non-symetric
> glass which is often the case for glass with low-e and glass with one
> of the panes tinted. I believe the front and back transmittance is
> always really close, (ie. it can't be 10% in one direction and 90% in
> the other) but they can vary slightly. This is what desktop radiance
> and optics 5 definition method allows you to do.
>
>> finally, there are no functions built in. that means that there is
>> no dependence on angle of incidence for either transmittance or
>> reflectance. this is unrealistic, as transmittance generally reduces
>> and reflectance generally increases with increasing angle of incidence.
>>
> I do think Desktop Radiance and Optics 5 both make use of the angular
> transmittance function. This is part of the glass primitive. And in
> my example, the BRTDFunc calls glazing.cal which provides the angular
> transmittance function. Also, from my comparisions a while ago now,
> the two methods gave me identical results. That is:
>
> void glass clear3_glass
> 0
> 0
> 3 0.92189 0.98612 0.972
> void BRTDfunc clear3_front
> 10 0.84636 0.90553 0.89251 0.07428 0.08322
> 0.08556 0 0 0
> . 0
> 9 0 0 0 0 0 0 0 0 0
> void BRTDfunc clear3_back 10
> 0.84636 0.90553 0.89251
> 0.07567 0.08418 0.08538
> 0 0 0
> . 0
> 9 0 0 0 0 0 0 0 0 0
>
> is equivalent to:
>
> void BRTDfunc clear3_glass
> 10 rrho grho brho
> rtau gtau btau
> 0 0 0
> glazing.cal
> 0
> 18 0 0 0
> 0 0 0
> 0 0 0
> 0.07428 0.08322 0.08556
> 0.07567 0.08418 0.08538
> 0.84636 0.90553 0.89251
>
> Also, you might want to check out glass1.cal and glass2.cal which is
> part of the newest HEAD radiance release. It just distinguishes
> between single pane and double pane which have different angular
> dependance functions. Also, check out glaze.csh in the latest
> release, I was just informed of this and have not checked it out
> personally, but I understand it helps create these definitions.
>
> So, I think the BRTDFunc methods can provide greater accuracy than the
> glass primitive.
>
> I hope I have not mistated any of this, anyone please correct me if so.
>
> Regards,
> Zack
>
>
>
> _______________________________________________
> Radiance-general mailing list
> [email protected]
> http://www.radiance-online.org/mailman/listinfo/radiance-general
>
>
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
--------------010901070502040602010803
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Hi All,<br>
<br>
Well here are some further things to confuse/clarify the possibilities.<br>
<br>
The BRTDfunc is very powerful and has multiple uses. Several things that
I actually find quite nice about it are:<br>
<ul>
<li>values represent transmittance and reflectance, as one might determine
from manufacturers data or from Optics 5 (a side note, I believe that Optics
5 is actually used to calculate the values that manufacturers then report
for the measurements, this information is incorporated into tools like the
Window 4 and 5 software, some one from the LBL optics group could probably
give a better summary of the capabilities).</li>
<li>allocation of values is clear, that is values are allocated to specular
and diffuse components of the material definition (the problem here if you
are trying to simulate a glazing material that has diffuse transmittance/reflectance
performance is that manufacturers are only reporting total reflectance and
transmittance and not diffuse and specular measures, so then you have to
measure by hand. I think that Rob G. could give everyone a really superb
summary on how to setup a measuring environment for glazing materials).</li>
<li>enables simulation of more complex glazing materials such as those
that have higher or differing front/back side reflectances than accounted
for in the typical "glass" material type ( I believe that the reflectance
for the glass material type is around 7%).</li>
</ul>
Note that it is possible to use one BRTDfunc definition to define front and
backside reflectances. Note also that transmittance as I understand it must
be the same front and back (this is supported by the fact that there is only
one transmittance that is supplied in manufacturers data and software such
as Optics 5). <br>
<br>
Here is a simple definition for a "simple" glazing material (I am pretty
confident that I am going to get some corrective feedback on this ;->):<br>
<br>
void BRTDfunc gl.test<br>
10<br>
if(Rdot, .12, .11) if(Rdot, .12, .11) if(Rdot, .12, .11)<br>
0.70 0.70 0.70<br>
0 0 0<br>
.<br>
0<br>
9<br>
0 0 0 0 0 0 0 0 0<br>
<br>
This would define a simple glazing material with a total front side reflectance
of 12%, a total backside reflectance of 11% and a total transmittance of
70%. This material could be applied to a single surface and does not need
separate front and backside polygons. However what this definition does not
account for is the impact of the incident angle of the incoming ray on the
resulting transmittance and reflectance. It is not clear to me what kind
of error this might actually introduce, however, I believe that a definition
such as this could easily take the place of the two (front and back) BRTDfunc
definitions that get exported from Optics 5. <br>
<br>
I believe that there is some trickiness with normals and BRTDfunc, so I hope
that I am using Rdot to calculate orientation correctly?<br>
<br>
Note that the section in the definition with the 10 arguments relates to
the specular behavior of the material and the section with 9(+) arguments
relates to the diffuse behavior of the material. Summing between these gives
us total reflectance and transmittance. In this case the there is no diffuse
behavior to the material.<br>
<br>
Depending on the application is might be worth checking out glaze.csh in
the latest release. This calculates models for both single and double surface
glazing materials. I am not sure how it compares to glazing.cal in terms
of the accuracy of the underlying model. Note however that glaze.csh is built
around a handful (5 or 6) sets of reflectance and transmittance values as
it "database". Some of these were actually measure by me and looking back
on it, I would prefer to measure the "pvb" materials under a more precise
protocol than I did originally (again Rob G. would be the real resource here).
I would think that the tool could be extended to account for many things
that can be exported from Optics 5. Perhaps the Optics 5 group might be interested
in having Greg develop a more robust solution for what gets exported from
Optics 5 to account for a more sophisticated model of angular dependance
and other properties?<br>
<br>
Well, all in all probably more confusion that clarity.<br>
<br>
Best,<br>
<br>
-Jack<br>
<br>
<br>
Zack Rogers wrote:<br>
<blockquote type="cite" cite="[email protected]">Hello, <br>
<br>
<blockquote type="cite">secondly, what does this do to the transmittance?
physically, the transmittance going one way should be the same as the transmittance
going the other way. should the (rtrns, gtrns, btrns) variables then be
the same for both front and back panes? or does it not matter, as long as
the product of their transmittances is equal to that of the combination. <br>
<br>
</blockquote>
This is true for a symetric glass composition (ie. single pane no low-e,
double pane, clear, no low-e) but not true for non-symetric glass which
is often the case for glass with low-e and glass with one of the panes tinted.
I believe the front and back transmittance is always really close, (ie.
it can't be 10% in one direction and 90% in the other) but they can vary
slightly. This is what desktop radiance and optics 5 definition method
allows you to do. <br>
<br>
<blockquote type="cite">finally, there are no functions built in. that
means that there is no dependence on angle of incidence for either transmittance
or reflectance. this is unrealistic, as transmittance generally reduces
and reflectance generally increases with increasing angle of incidence. <br>
<br>
</blockquote>
I do think Desktop Radiance and Optics 5 both make use of the angular transmittance
function. This is part of the glass primitive. And in my example, the
BRTDFunc calls glazing.cal which provides the angular transmittance function.
Also, from my comparisions a while ago now, the two methods gave me identical
results. That is: <br>
<br>
void glass clear3_glass <br>
0 <br>
0 <br>
3 0.92189 0.98612 0.972 <br>
void BRTDfunc clear3_front <br>
10 0.84636 0.90553 0.89251 0.07428 0.08322 0.08556
0 0 0 <br>
. 0 <br>
9 0 0 0 0 0 0 0 0 0 <br>
void BRTDfunc clear3_back 10 <br>
0.84636 0.90553 0.89251 <br>
0.07567 0.08418 0.08538 <br>
0 0 0 <br>
. 0 <br>
9 0 0 0 0 0 0 0 0 0 <br>
<br>
is equivalent to: <br>
<br>
void BRTDfunc clear3_glass <br>
10 rrho grho brho <br>
rtau gtau btau <br>
0 0 0 <br>
glazing.cal <br>
0 <br>
18 0 0 0 <br>
0 0 0 <br>
0 0 0 <br>
0.07428 0.08322 0.08556 <br>
0.07567 0.08418 0.08538 <br>
0.84636 0.90553 0.89251 <br>
<br>
Also, you might want to check out glass1.cal and glass2.cal which is part
of the newest HEAD radiance release. It just distinguishes between single
pane and double pane which have different angular dependance functions.
Also, check out glaze.csh in the latest release, I was just informed of
this and have not checked it out personally, but I understand it helps create
these definitions. <br>
<br>
So, I think the BRTDFunc methods can provide greater accuracy than the glass
primitive. <br>
<br>
I hope I have not mistated any of this, anyone please correct me if so. <br>
<br>
Regards, <br>
Zack <br>
<br>
<br>
<br>
_______________________________________________ <br>
Radiance-general mailing list <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <br>
<a class="moz-txt-link-freetext" href="http://www.radiance-online.org/mailman/listinfo/radiance-general">http://www.radiance-online.org/mailman/listinfo/radiance-general</a> <br>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
# John E. de Valpine
# president
#
# visarc incorporated
# <a class="moz-txt-link-freetext" href="http://www.visarc.com">http://www.visarc.com</a>
#
# channeling technology for superior design and construction</pre>
<br>
</body>
</html>
--------------010901070502040602010803--