mirror material ignoring modifier in virtual source calculations

Dear all,

I am currently having problems using mirror materials with brightfunc
modifiers for virtual source calculations. The mirror material seems to
ignore the modifier. I've seen in recent post that there seems to be a bug
with in the m_mirror routine and I wonder if that is the problem or if it
could be something else.

Thanks,

rioboo

Hi Rioboo,

It helps when you give a specific example. What is your material definition, and what is it doing that disagrees with your expectations?

The mirror material will ignore its modifiers in the case when you have given an alternate material type. This will be called instead when viewed directly. The modifiers to the mirror itself will only be used for calculating the virtual source contributions.

Best,
-Greg

···

From: goodriver laurus <[email protected]>
Date: June 12, 2016 4:16:03 PM PDT

Dear all,

I am currently having problems using mirror materials with brightfunc modifiers for virtual source calculations. The mirror material seems to ignore the modifier. I've seen in recent post that there seems to be a bug with in the m_mirror routine and I wonder if that is the problem or if it could be something else.

Thanks,

rioboo

···

Dear Greg, Many thanks for for quick response. I am trying to use a modified mirror like the one posted on 17 March 2008 in order to emulate the angular-dependent reflections from a glass: void glass glass_alt_mat 0 0 3 0.96 0.96 0.96 void brightfunc glass_angular_effect 2 A1+(1-A1)*(exp(-5.85*Rdot)-0.00287989916) . 0 1 0.08 glass_angular_effect mirror glass_mat 1 glass_alt_mat 0 3 1 1 1 I use this material to quantify in a top view the illuminance on the ground due to reflected light from vertical windows (therefore not looking at the glass, but just at the reflections). The calculation is been done with rpict -i -ab 0 -dr 1. I have also tried other values for the parameters but the results are the same.

I would expect the reflections to vary in value depending on the angle of incidence on the glass. However, all reflections seem to be of the same intensity, actually 100% reflective like in an ideal mirror. I wonder if the issues I am having may have to do with the way I am using rpict or if there is a more fundamental error. I have tried testing this issue in Radiance 4.2 for Windows to see if could have to do with the platform or with recent issues with the m_mirror routine, as posted a few days ago, but the results are again the same. Thanks and best regards, Rioboo


Hi Rioboo, It helps when you give a specific example. What is your material definition, and what is it doing that disagrees with your expectations? The mirror material will ignore its modifiers in the case when you have given an alternate material type. This will be called instead when viewed directly. The modifiers to the mirror itself will only be used for calculating the virtual source contributions. Best, -Greg > *From: goodriver laurus <[rioboo at gmail.com](http://www.radiance-online.org/mailman/listinfo/radiance-general)>* > *Date: June 12, 2016 4:16:03 PM PDT* > > *Dear all,* > > *I am currently having problems using mirror materials with brightfunc modifiers for virtual source calculations. The mirror material seems to ignore the modifier. I've seen in recent post that there seems to be a bug with in the m_mirror routine and I wonder if that is the problem or if it could be something else.* > > *Thanks,* > > *rioboo*

Hi Rioboo,

Your definition looks correct to me. What different conditions are you using to make this determination?

1) Do you change the angle of the sun? This is the only way to test different angles on the mirror, since the sun is a collimated source of light.

2) When you change the solar angle, do you move your point or at least ensure that it remains in the reflected beam? If it sees sunlight directly as well, you will need to look for variation in the 8-80% that is reflected (depending on angle).

3) Are you sure your mirror surface normal faces outwards? If it faces inwards, like most windows in Radiance, then the mirrored sources will only happen on the interior.

Cheers,
-Greg

···

From: goodriver laurus <[email protected]>
Date: June 13, 2016 2:29:16 AM PDT

Dear Greg,

Many thanks for for quick response. I am trying to use a modified mirror like the one posted on 17 March 2008 in order to emulate the angular-dependent reflections from a glass:

void glass glass_alt_mat
0
0
3 0.96 0.96 0.96

void brightfunc glass_angular_effect
2 A1+(1-A1)*(exp(-5.85*Rdot)-0.00287989916) .
0
1 0.08

glass_angular_effect mirror glass_mat
1 glass_alt_mat
0
3 1 1 1

I use this material to quantify in a top view the illuminance on the ground due to reflected light from vertical windows (therefore not looking at the glass, but just at the reflections). The calculation is been done with rpict -i -ab 0 -dr 1. I have also tried other values for the parameters but the results are the same.

I would expect the reflections to vary in value depending on the angle of incidence on the glass. However, all reflections seem to be of the same intensity, actually 100% reflective like in an ideal mirror.
I wonder if the issues I am having may have to do with the way I am using rpict or if there is a more fundamental error. I have tried testing this issue in Radiance 4.2 for Windows to see if could have to do with the platform or with recent issues with the m_mirror routine, as posted a few days ago, but the results are again the same.

Thanks and best regards,

Rioboo
Hi Rioboo,

It helps when you give a specific example. What is your material definition, and what is it doing that disagrees with your expectations?

The mirror material will ignore its modifiers in the case when you have given an alternate material type. This will be called instead when viewed directly. The modifiers to the mirror itself will only be used for calculating the virtual source contributions.

Best,
-Greg

> From: goodriver laurus <rioboo at gmail.com>
> Date: June 12, 2016 4:16:03 PM PDT
>
> Dear all,
>
> I am currently having problems using mirror materials with brightfunc modifiers for virtual source calculations. The mirror material seems to ignore the modifier. I've seen in recent post that there seems to be a bug with in the m_mirror routine and I wonder if that is the problem or if it could be something else.
>
> Thanks,
>
> rioboo

Hi Greg,

I am sending you a simple test with my results, so you can have a look
if you have the time. I have included a small batch file to run the
calculation under MS-DOS (I had to change the extension to bat2 in
order to avoid the attachment to be blocked).

In answer to your questions:

1- I was testing different sun positions, but the test attached
includes only one. This should suffice to try different angles of
incidence, since every reflector has a different orientation.

2- I am not sure if I understand this point. I do see different values
where direct and reflected components converge, is that the question?

3- I checked the normals and they point outwards, but I guess that was
expected since I can see the reflections and the camera is located
outside the buildings.

I greatly appreciate your help, this issue is really puzzling me.

Many thanks,

Rioboo

Hi Rioboo,

Your definition looks correct to me. What different conditions are
you using to make this determination?

1) Do you change the angle of the sun? This is the only way to test
different angles on the mirror, since the sun is a collimated source
of light.

2) When you change the solar angle, do you move your point or at least
ensure that it remains in the reflected beam? If it sees sunlight
directly as well, you will need to look for variation in the 8-80%
that is reflected (depending on angle).

3) Are you sure your mirror surface normal faces outwards? If it
faces inwards, like most windows in Radiance, then the mirrored
sources will only happen on the interior.

Cheers,
-Greg

test_Greg.rar (42.2 KB)

Hi Rioboo,

Your bat file only creates a single rendering with a single solar position. In fact, I don't understand the output, which looks much darker than it should be for direct solar illumination. Are you rendering different solar angles? Can you do it with a simpler test case, like a single piece of glass with your mirror parallel to a diffuse surface that does not face the sun? If you ran that at different solar incident angles, the value divided by the cosine of the incident angle (to account for grazing sunlight) should follow the Fresnel approximation you are using.

Cheers,
-Greg

···

From: goodriver laurus <[email protected]>
Date: June 13, 2016 11:56:25 AM PDT

Hi Greg,
I am sending you a simple test with my results, so you can have a look if you have the time. I have included a small batch file to run the calculation under MS-DOS (I had to change the extension to bat2 in order to avoid the attachment to be blocked).
In answer to your questions:
1- I was testing different sun positions, but the test attached includes only one. This should suffice to try different angles of incidence, since every reflector has a different orientation.
2- I am not sure if I understand this point. I do see different values where direct and reflected components converge, is that the question?
3- I checked the normals and they point outwards, but I guess that was expected since I can see the reflections and the camera is located outside the buildings.
I greatly appreciate your help, this issue is really puzzling me.
Many thanks,
Rioboo

Hi Rioboo,

Your definition looks correct to me. What different conditions are you using to make this determination?

1) Do you change the angle of the sun? This is the only way to test different angles on the mirror, since the sun is a collimated source of light.

2) When you change the solar angle, do you move your point or at least ensure that it remains in the reflected beam? If it sees sunlight directly as well, you will need to look for variation in the 8-80% that is reflected (depending on angle).

3) Are you sure your mirror surface normal faces outwards? If it faces inwards, like most windows in Radiance, then the mirrored sources will only happen on the interior.

Cheers,
-Greg

Greg,

I think I may have found the issue. I was creating a simpler scene to send
over when I realized that the angular dependence was actually working. I
almost missed it because the differences were small, but it was working.
So, I went back to the original test and I discovered that the difference
was that I had been using aliases in the original test, but had had not
used them in the simplified scene I sent you, sorry about that. Could that
be it?

When I use aliases the mirror material seems to ignore the modifier:

void glass glass_alt_mat
0
0
3 0.96 0.96 0.96

void brightfunc glass_angular_effect
2 A1+(1-A1)*(exp(-5.85*Rdot)-0.00287989916) .
0
1 0.08

glass_angular_effect mirror glass_mat
1 glass_alt_mat
0
3 1 1 1
void alias window glass_mat

If I use 'window' as the material for the geometry, then 'glass_mat' alias
is used instead, but the 'glass_angular_effect' modifier seems to be
ignored. However, if I apply 'glass_mat' as the material for the geometry
then it does work. So, I wonder if this is a reasonable explanation and if
it can be explained by the work aliases work. If that is the case it would
be great to know if there is a way around it so I can keep using aliases
whilst making sure modifiers are not ignored.

Many thanks,

Rioboo

Hi Rioboo,

Your bat file only creates a single rendering with a single solar
position. In fact, I don't understand the output, which looks much
darker than it should be for direct solar illumination. Are you
rendering different solar angles? Can you do it with a simpler test
case, like a single piece of glass with your mirror parallel to a
diffuse surface that does not face the sun? If you ran that at
different solar incident angles, the value divided by the cosine of
the incident angle (to account for grazing sunlight) should follow the
Fresnel approximation you are using.

Cheers,
-Greg

Randolph,

That was my suspicion, and I was also guessing that applying the modifier
to the alias could perhaps work, but I had not tested it. It is great that
you can confirm it! It now makes sense, but I wonder if it would just be
easier if aliases could inherit modifiers, unless Greg thinks it is not
appropriate. I would personally think it would be more intuitive.

Many thanks,

Rioboo

I believe you need to apply the "inherit" modifier to the alias, otherwise,
indeed, the alias will not inherit the original material's modifier.

Randolph

You are both correct. Applying the original modifier to the alias works, as does using the "inherit" tag. One of the purposes of alias'es is to "pull out" a material (or modifier) definition to use with (or within) a different modifier chain. The "inherit" tag was added later on to simplify alias management when all you wanted to do was essentially reassign materials. If that's what you want alias'es for, then just get in the habit of using "inherit" in your work.

Cheers,
-Greg

···

From: goodriver laurus <[email protected]>
Date: June 14, 2016 6:45:46 AM PDT

Randolph,

That was my suspicion, and I was also guessing that applying the modifier to the alias could perhaps work, but I had not tested it. It is great that you can confirm it! It now makes sense, but I wonder if it would just be easier if aliases could inherit modifiers, unless Greg thinks it is not appropriate. I would personally think it would be more intuitive.

Many thanks,

Rioboo

I believe you need to apply the "inherit" modifier to the alias, otherwise,
indeed, the alias will not inherit the original material's modifier.

Randolph

I believe you need to apply the "inherit" modifier to the alias, otherwise,
indeed, the alias will not inherit the original material's modifier.

Randolph

···

On Jun 14, 2016 2:37 AM, "goodriver laurus" <[email protected]> wrote:

Greg,

I think I may have found the issue. I was creating a simpler scene to send
over when I realized that the angular dependence was actually working. I
almost missed it because the differences were small, but it was working.
So, I went back to the original test and I discovered that the difference
was that I had been using aliases in the original test, but had had not
used them in the simplified scene I sent you, sorry about that. Could that
be it?

When I use aliases the mirror material seems to ignore the modifier:

void glass glass_alt_mat
0
0
3 0.96 0.96 0.96

void brightfunc glass_angular_effect
2 A1+(1-A1)*(exp(-5.85*Rdot)-0.00287989916) .
0
1 0.08

glass_angular_effect mirror glass_mat
1 glass_alt_mat
0
3 1 1 1
void alias window glass_mat

If I use 'window' as the material for the geometry, then 'glass_mat' alias
is used instead, but the 'glass_angular_effect' modifier seems to be
ignored. However, if I apply 'glass_mat' as the material for the geometry
then it does work. So, I wonder if this is a reasonable explanation and if
it can be explained by the work aliases work. If that is the case it would
be great to know if there is a way around it so I can keep using aliases
whilst making sure modifiers are not ignored.

Many thanks,

Rioboo

Hi Rioboo,

Your bat file only creates a single rendering with a single solar position. In fact, I don't understand the output, which looks much darker than it should be for direct solar illumination. Are you rendering different solar angles? Can you do it with a simpler test case, like a single piece of glass with your mirror parallel to a diffuse surface that does not face the sun? If you ran that at different solar incident angles, the value divided by the cosine of the incident angle (to account for grazing sunlight) should follow the Fresnel approximation you are using.

Cheers,
-Greg

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

The "inherit" tag was added later on to simplify alias management when all you wanted to do was essentially reassign materials. If that's what you want alias'es for, then just get in the habit of using "inherit" in your work.

I didn't even know about 'inherit' 'till just now; I've always used aliases for reassignment. Awesome, thanks Greg!

#MindBlown

- Rob

···

On 6/14/16, 9:34 AM, "Greg Ward" <[email protected]<mailto:[email protected]>> wrote: