Reflexion and transmission in Radiance

Hi I’m trying to understand the dielectric material in Radiance. Therefore I’ve tried to detect the reflection and transmission with rtrace -I. I’ve placed one detector in front of my material block (direction: to the block) to detect the relfection and one detector behind the block (direction: to the block) to detect the transmission. But I’ve never measured any reflection and I dont quite understand the values I get for the transmission. For example if I defined my dielectric material with a transmission coefficient equals to 0.6 then I measure a transmission greater then 0.6.

If somebody has any idea how I can meassure the reflection and how I can get a better understanding of the transmission I would be very grateful.

Greetings Philip

Hi Phillip, this leads to some question that may help to find the problem:

  1. Did you make sure that the surface normals of the “dielectric block”
    point outwards? You can temporarily set the material to glow. If your
    “block” is emissive to all directions, surface orientation is fine. If
    any surface is black, this would be oriented inwards.

  2. What -ab setting did you choose?

  3. How did you define your light source? I would recommend to set up a
    distance “source” with a narrow angular diameter.

Best, Lars.

16.11.20 09:59 Philip wrote via discourse.radiance-online.org:

Hi Lars, thanks for your fast reply.

  1. I’ve checked that every surface normal is pointing outwards with your suggested method.

  2. I’ve used $ rtrace -I scene.oct < input.dat > output.dat
    I thought that -ab describes the diffuse bounces. Does it influences the direct bounces too?

3.My light source is defined in the following way:

void light bright
0
0
3 1000 0 0

bright source light_q
0
0
4 0 -1 0 180

Greetings Philip

Hi Philip!

I’ve checked that every surface normal is pointing outwards with your
suggested method.

Good to see that the surface geometry is not the culprit.

I’ve used $ rtrace -I scene.oct < input.dat > output.dat
I thought that -ab describes the diffuse bounces. Does it influences
the direct bounces too?
No, but if you would have defined your source by glow, not light, it
would have made a difference.

My light source is defined in the following way:

void light bright
0
0
3 1000 0 0

bright source light_q
0
0
4 0 -1 0 180

There are two probems with this:

First, “light” defines a source that is tested by deterministic
ray-tracing. E.g. to find its contribution to the local illuminance on a
surface, one ray would be sent to its centre, or (if enabled) each of
its automatically generated partitions. This works fine for point-like
sources, and even for e.g. a typical luminaire at a distance of several
meters. If, however, the subtended solid angle get large, sending one
ray to the centre becomes little meaningful. And partitioning it to the
degree that thousands of samples are distributed over the source area
renders the idea of deterministic ray-tracing superfluous. Therefore,
whenever defining sourfaces that are not “small” when seen from the
illuminated surfaces, it is better to switch to “stochastic sampling”.
Here, random samples are sent out and, whenever hitting other (luminous
or reflective) surfaces, return a contribution to the illuminance (as
part of the ambient calculation, requiring -ab >0). This is more or less
what has been first published as “distributed ray-tracing”, and
triggered if you switch from “light” to “glow”. This is also the reason
why you would usually model the sun as “light”, and the sky hemisphere
as “glow”. So to get a reasonable result, switch from “light” to “glow”,
and run rtrace with -ab 1. The next important parameters will be -ad and
-lw, since they control how many random samples are sent out. With a
large, uniform source this is no problem, but a narrow or non-uniform
“glow”-source, or one seen e.g. through a small aperture, this quickly
leads to -ad settings >10000 and beyond. With rtrace point-sensors, this
may be acceptable, but if you would generate an image the computing cost
would at some point become a serios limitation.

Second, since you may not only want to calculate transmission and
reflection by a diffusely illuminated sample (this is what your 180 deg.
source gives you), you may want to shrink the source diameter. The
problem with this is that the narrower the source gets, the more random
sample rays you will need to hit it. Switching back to “light” with the
narrow source would address this problem. Unfortunately, in the case of
reflection on a dielectric, Radiance would not find the path to the
source any more. This is very similar to the problem of caustics, e.g.
the calculation of the illuminance on a diffuse surface contributed by
perfectly mirror-like reflection from a “light” source. I did not test
it, but you would probably get a correct result for tranmission, but not
reflection with a e.g. 2 deg. source of type “light”.

So this case of measuring illuminance by reflection from a dielectric,
appearing trivial at first sight, can actually be challenging for a
backward ray-tracing algorithm. Please keep this problem in mind for the
future - if you ever need to model such mirror-like reflection toward a
diffuse surface (or virtual sensor plane with rtrace -I), you would
rather use secondary sources by “mirror” or e.g. photon mapping.

Best, Lars.

1 Like

Hi Lars and thanks for your reply.

I understand now what my problem was. First of all I made a mistake in defining my light source. My light source should be defined in the following way:

void light bright
0
0
3 1e7 0 0 

bright source light_q
0 
0
4 0 -1 0 0.5

My final goal is to know how I can create a material in Radiance with a specific specular reflectance and transmittance and absorption. After reseachring a bit I found out that I can potentially use the materials “Dielectric” or “BRTDfunc” to achieve my goal. I wanted to test if the defined materials would work like I think they would and therefore I did the reflection and transmission experiment. Additionally in my simulations I need to use “light” (because I want to represent the sun with my light source). Did I understand it right that there is no way to check the reflection of my “block”, if I use “light” ? Furthermore I just tried to measure the transmission with my new light source and I didnt get the results I expected. My “block” is 0.2 x 0.2 x 0.2 (in meters) and for the material “Dielectric” I used the following definition:

void dielectric material_
0
0
5 0.6 0.6 0.6 1.5 0

and got a transmission of 0.75. And for the “BRTDfunc” material I used:

void BRTDfunc material_
10  0.3  0.3  0.3
    0.6  0.6  0.6
    0  0  0
0
9   0 0 0
    0 0 0
    0 0 0

and got a transmission of 0.36. In both cases I expected a value around 0.6. It would be awesome if somebody could tell me if my understanding of the materials is wrong or if I have a diffrent error.

Greetings Philip

Hi Philip,

You can render a 180° image with rpict instead of the rtrace -I, then
integrate over the hemisphere and calculate the illuminance. Rpict sends
out view rays, where the specular path is traced to “light”, so you can
check if your model is doing what you think (as a plus you also have a
visualization). However, later in the simulation the restrictions
mentioned by Lars occur when an ambient ray would hit the material (then
the specular path to “light” is not traced (e.g. for dielectric, glass,
BRTDfunc).

Jan

Hi all,

First of all thank you for your anser Jan. I will try it out. But has someone an understanding what I can expect when using BRTDfunc in the way of:

void BRTDfunc material_
10  0.3  0.3  0.3
    0.6  0.6  0.6
    0  0  0
0
9   0 0 0
    0 0 0
    0 0 0

Can I expect an transmission of 0.6 and reflexion of 0.3 independet of the length of the objekt which has the material_ property. And furthermore is the angle of reflection the same as the angle of incidence.

Greetings Philip

Yes, the transmission will be 0.6 for any incident direction, and mirror-like reflection will be 0.3 in the above description.

Hi again, I haven’t found a solution for measuring direct reflection of a material with rtrace -I. Is there a solution? My latest try was the mirror material. I’ve generated a cube (l = 1m) and placed him so that the center ist at (0, 0.5, 0). Then I’ve defined the following mirror material and assigned it to the cube.

void mirror mirror_mat
0 
0 
3 0.7 0.7 0.7 

This cube gets irradiated with the follow light source (direct light):

void light bright 
0
0
3 1000 0 0

bright source lightq 
0
0
4 0 -1 0 0.5

Then I used the following command:

rtrace -I scene.oct < input.dat > output.dat

The input file contains one detector to measure the irradiance of the incoming light and one for the reflected light:

0 -1 0 0 -1 0 
0 -1 0 0 1 0

And still I only measure the incoming light and 0 reflected light. I’m a bit confused is there really no way to detect the irradiance of a reflection from this kind of light source with the programm rtrace or did I do a mistake or misunderstood something.

Greeting Philip

Odd, because it works when I try it. What did you use to generate your cube? This is my complete input:

void mirror mirror_mat
0
0
3 0.7 0.7 0.7

!genbox mirror_mat cube 1 1 1 | xform -t -.5 0 -.5

void light bright
0
0
3 1000 0 0

bright source lightq
0
0
4 0 -1 0 .5

When I feed it your sample positions, I get non-zero values for the red channel (only), since your light source has zero green and blue components.

If you hand-built your cube, you should make sure that the surface normals face outward, because that matters for the mirror material type.

Hi Greg and thanks for the fast replay. Your example works for me just fine as well. So I know where my problem is thank you a lot.

Greetings Philip

Hi again, so to test wheter my surface normals face outward or not I changed the material to glow like @Lars_Grobe told me in the begining of this post.

void glow mirror_mat
0 
0 
4 100 0 0 0

Then I’ve placed detectors above every surface of the cube. Therefore the Input-File looks like this:

0 -0.5 0 0 1 0 
0 0.5 1 0 0 -1 
0 1.5 0 0 -1 0 
0 0.5 -1 0 0 1
-1 0.5 0 1 0 0
1 0.5 0 -1 0 0

and then I used rtrace again to measure if my cube is emissive to all directions. The result is that for every detector I detect a non zero irradiance. So if I understood Lars correctly this should mean that the surface normals are pointing outwards. So now I’am confused again. Can there be another problem with the cube @Greg_Ward ?

Greetings Philip

You should learn to use rpict and rvu and the other visualization tools. What about the objview script, which allows you to visualize a Radiance object with little fuss? I cannot emphasize enough how important it is to look at your models rather than relying on numerical results. Too often, people place test points outside of their spaces, or have walls where windows should be, etc. The sooner you learn to use the rich visualization environment of Radiance, the better off you will be.

Thanks for the advice and sharing your experiance. So I’ve used rvu and the objview to check whether the surfaces of the cube emit light or not. Every surface that I saw was red, so every surface was emitting light. Do you have another advice to find out where the problem is @Greg_Ward?

Thanks for the fast reply and greetings Philip

I’m glad you know how to use the rendering tools. This will be helpful in future.

If you put the sample points exactly on the surfaces of each cube, then they won’t measure those surfaces. You need to put them a little in front of them and send the sample rays at the surfaces with -I- (radiance rather than irradiance) calculation. Then you will read something.

I dont quite understand the last part your post. My situation is the following. I tested that the surface normals of my cube are pointing outwards with rvu and objview but still if I assign the mirror material to the block and try to measure the reflection (the sensor point has enough distance to the mirror-block) I measure nothing with my block. But I measure something if I do it with the cube from your example. Could there be any other problem then the surface normals? Furthermore what do you mean with -I-.

Greetings Philip

With the rtrace -I+ option (same as -I, opposite of -I-), the given sample origin and orientation are used to compute irradiance, which if you give it points on each surface, look AWAY from that surface. If you want to know what the value of a surface is, you need to compute RADIANCE (-I-) rather than irradiance, and start from a point slightly away from said surface(s), giving a normal direction towards the surface(s). So, you need to use “rtrace -I-” with the set of points you have given. Then your values will be non-zero.

While it is true that even the irradiance values should be non-zero, specifying “glow” surfaces means that they will not be computed as illuminating anything unless you also set -ab 1 or greater. The other option is to use “light” surfaces rather than “glow”.

Oh ok now I understand what you mean with -I-. So now I’ve used:

rtrace -I- -ab 1 -ad 6000 scene.oct < input.dat > output.dat

The input files contain sensor points which are slightly away from the surface(s), with a direction towards the surface(s). Then I measure the 100 W/m^2/sr which I defined for my glow material. But what do I gain from this information. Does it show me in combination which the rvu & objpict test that the surface normals are pointing outwards? I’m sorry if I’m a bit slow in understanding.

Greetings Philip

If you want to short-cut this discussion to what went wrong in your initial test, then share the cube surfaces you are using, which must be different from the one I generated with the genbox command. Otherwise, why was your result different from mine?

Ok you can download the files that I used from the following link:

The mirror_block.mtl and mirror_block.obj are generated with blender. Then I used:

obj2mesh -a materials.rad mirror_block.obj model.rtm

to generate the rtm-file which the rad-file scene.rad uses. After this I generated the octree file scene.oct with:

oconv scene.rad light.rad > scene.oct

After this I used:

rtrace -I -ab 1 -ad 6000 scene.oct < input.dat > output.dat

to generate the output-file. Thanks a lot for the help and the quick replies.

Greetings Philip