[Radiance-general] Re: query about accurately modelling glazing

Greg Ward [email protected]
Fri, 16 Jan 2004 23:23:09 -0800


Hi Alex,

> From: alex Summerfield <[email protected]>
> Date: January 16, 2004 4:49:37 AM PST
>
> Hi All,
>
> Thanks everyone for this interesting thread. Since there is a fair bit 
> of discussion on precise measurement of transmission and reflection 
> properties, this might be a good opportunity to check about Radiance 
> handling of glazing with the greater wisdom out there.
>
> Ok so as my limited understanding has it:
>
> refractive index: in Radiance this is only used for tracing 'view 
> rays' - (so that we see a view refracted through the glazing) but that 
> the light is transmitted through and cast into the space is 
> unaffected. When tracing a ray back towards a direct source, such as 
> the sun - if it were refracted it would be deflected and might miss a 
> small target source.
>
> (hmmm, might create some surreal situations - suppose we are standing 
> in a space and could just see a refracted sun through the edge of the 
> window but the line on the floor indicates we are standing in shadow.)
> Probably the most common example where refraction of direct sources 
> might be visually important would be glass bricks.

Actually, refraction is never ignored in Radiance, even when tracing to 
light sources.  The sources will be missed or not depending on how big 
they are and how much refraction goes on.  If a pane of glass is 
modeled using dielectric, so that rays are refracted going through it, 
they get bent back straight so they still head in the same direction, 
albeit shifted, slightly.  Spheres and lenses are a different matter of 
course, and caustics are not modeled correctly for that reason.  You 
need to use the photon map for that!

> I think refractive index also does not apply when tracing rays as part 
> of the indirect calculation - even though missing a large area source 
> (sky) is not likely to be a problem.

I don't know where you heard this, but it's not true.

> Reflectance - in atria there are likely to be complex and multiple 
> glazing surfaces - eg the roof and then in large areas along the 
> offices lining the edge. The intricate reflections may be visible in 
> the scene, but specular reflections from the glazing (or anything 
> else) will not contribute to illuminance levels in the atrium - unless 
> specified as secondary sources (ie generate 'virtual' sources). This 
> is not going to handle anything other than smooth flat surfaces (eg 
> not water).

That's partially true.  Interreflections of the sky and other parts of 
the ambient calculation will consider the multiple reflections going 
on, specular as well as diffuse.  However, you would have to use 
virtual sources to get the pure specular reflections from light 
sources, which can be expensive.  You're better off doing that only 
when it really matters -- like when you have a mirrored building facade 
or something.

> (Daniel - this may have relevance for your work) it does not include 
> the contribution of indirect sources eg bright overcast skies are not 
> going to be specularly reflected around the atrium. The Radiance 
> indirect calculation essentially deals with diffuse-diffuse pathways 
> only.

Again, these are accounted for correctly.

> Ok so does that mean specs and functions for reflectance changing with 
> angle of incidence are going to effect the appearance of the scene 
> visible in the glazing, the light transmitted, but not the light 
> reflected?

They affect both.

> And what about direct sunlight and diffusing glass? Is the light 
> transmitted - or does the random scattering cause the same problem as 
> refraction about missing the target when tracing the ray backwards?

The diffuse or rough specular part of transmission (and reflection) 
gets included in the indirect (ambient) calculation.  If modeled using 
the directional diffuse part of one of the *func or *data material 
types, this gets lumped into the Lambertian component, which admittedly 
is a very crude approximation.  Perhaps this is what you are thinking 
of above -- however, it doesn't apply to the Gaussian materials 
(plastic, metal, trans, plastic2, metal2, trans2).  These all work 
properly, which is why you should use them whenever possible.  Problems 
remain when you get strong caustics from a low roughness surface, 
however.

> Anyway synthetic images of what we see in these types of scenes - with 
> all those glossy hard surfaces and intricate multiple reflection of 
> sky sources etc. - may be substantially different to what the walls, 
> floor etc 'see'.
>
> well hope this is right - i await heavy editing/ comments.
> cheers
> alex
>
> *******************************************************
> A. J. Summerfield                 [email protected]
> Faculty of Architecture, University of Sydney
>
> Outside of a dog, a book is man's best friend.
> Inside a dog, it's too dark to read.       Groucho Marx
> *******************************************************
>
>
> On 15 Jan 2004, at 7:08 pm, Jack de Valpine wrote:
>
>> 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
>>
>>