experiences with the photon map

Hi list!

While I am trying this on Radzilla now (as there is no photon-mapping
available in Radiance-3.9 at the time of this writing), I am pretty sure
that the effects I get are not related to Radzilla but on the way I use
the pmap-System.

I am trying to model a simple, highly specular horizontal light duct,
with a rectangular cross-section (yes I know that in THIS case I could
use the mirror material and Radiance, but I will go for non-planar
surfaces later).

Now either I get very splotchy luminance images in the inside, or,
increasing the `bandwith` to rather high values, have a blurry result
with - and this is the problem - light leaving the geometry even though
it is closed (the duct has a 45 degree mirror at its end that should
actually close it, but the sides extend besides the mirror and appear
illuminated even behind it).

I am working with an initial photon count for both global and caustic
photons of 2.000.000 and a bandwith value of 2000 at the moment.

Is it possible to get such systems rendered in a way that I have both a
smooth luminance and no light escaping the geometry?

Is there any source for a starting point in what way rtcontrib could be
used for modeling such systems? I know the qt-movie from the workshop,
but I did not get it - and it seams that I know noone except Greg who
got it so far :wink:

Thank You & CU, Lars.

Hi Lars,

I'm pretty sure its a question how you modeled the end of your "light-pipe".
Photon mapping is doing an density estimate to calculate the radiance
and is searching for photons in the nearby.
Unfortunately the algorithm is doing this also for surfaces , which are
"leaving" a closed space. For example, if you have a closed box and you
add a surface to the scene, which is half inside and half outside the
box, you will get light into the box.
You can avoid this phenomena, if you really "close" your pipe (I assume
so :wink: ).

The question of photons and how many of them should be collected within
the density estimate cannot be answered without knowing more about the
scene. Its similar to "pure Radiance", the parameter setting is depending
on the scene and materials..... :wink: . Anyhow, 2000 for the "collecting"= bandwidth seems to be high for me.
Have you also tested the bias compensation (-apcb) in order to reduce the splotches?

By the way, we will probably update photon-mapping for the 3.9 version
(or the 4.0) version within the next half year, fixing also some bugs.
This depends on a new project probably launched in January.

Cheers,

Jan

Lars O. Grobe wrote:

···

> Hi list!
>
> While I am trying this on Radzilla now (as there is no photon-mapping
> available in Radiance-3.9 at the time of this writing), I am pretty sure
> that the effects I get are not related to Radzilla but on the way I use
> the pmap-System.
>
> I am trying to model a simple, highly specular horizontal light duct,
> with a rectangular cross-section (yes I know that in THIS case I could
> use the mirror material and Radiance, but I will go for non-planar
> surfaces later).
>
> Now either I get very splotchy luminance images in the inside, or,
> increasing the `bandwith` to rather high values, have a blurry result
> with - and this is the problem - light leaving the geometry even though
> it is closed (the duct has a 45 degree mirror at its end that should
> actually close it, but the sides extend besides the mirror and appear
> illuminated even behind it).
>
> I am working with an initial photon count for both global and caustic
> photons of 2.000.000 and a bandwith value of 2000 at the moment.
>
> Is it possible to get such systems rendered in a way that I have both a
> smooth luminance and no light escaping the geometry?
>
> Is there any source for a starting point in what way rtcontrib could be
> used for modeling such systems? I know the qt-movie from the workshop,
> but I did not get it - and it seams that I know noone except Greg who
> got it so far :wink:
>
> Thank You & CU, Lars.
>
>
> _______________________________________________
> Radiance-general mailing list
> [email protected]
> http://www.radiance-online.org/mailman/listinfo/radiance-general
  
--
Dipl.-Ing. Jan Wienold
Project Manager
Fraunhofer-Institut für Solare Energiesysteme
Thermal Systems and Buildings, Lighting and Daylighting
Heidenhofstr. 2, 79110 Freiburg, Germany
Phone: +49(0)761 4588 5133 Fax:+49(0)761 4588 9133
[email protected]
http://www.ise.fraunhofer.de

In office:
Mo,Tue: 8:30-18:00
We,Thu: 8:30-16:00
Fr: 8:30-15:30

Hi Jan!

I'm pretty sure its a question how you modeled the end of your "light-pipe".
Photon mapping is doing an density estimate to calculate the radiance
and is searching for photons in the nearby.
Unfortunately the algorithm is doing this also for surfaces , which are
"leaving" a closed space. For example, if you have a closed box and you
add a surface to the scene, which is half inside and half outside the
box, you will get light into the box.
You can avoid this phenomena, if you really "close" your pipe (I assume
so :wink: ).
  
Well the pipe is closed by the 45 degree mirror, but I guess that I must not have geometry extend from the end (so that a part of it is inside the system and a part is outside). This is really important for modelling and was not clear to me so far! So the viewer in the sketch below will see the surfaces A and B lid even though light is not able to reach those, because the photons hitting the surface are counted even though not visible from the viewer position, right?

Surface A

···

___________________________
                          >
light source | viewer
________________|___________

Surface B

By the way, we will probably update photon-mapping for the 3.9 version
(or the 4.0) version within the next half year, fixing also some bugs.
This depends on a new project probably launched in January.
  

This is good news for all Radiance users! Will it be possible to use BRTDfunc modifiers with the photon map than? At the moment we have a strange situation - most Radiance users most probably use the software for advanced daylighting simulation. But they cannot model the advanced systems with the core distribution (pmap is not integrated), and even if they patch Radiance to support photon mapping, they cannot use the galzing definitions as given e.g. by the glaze script because of a lack of support for BRTDfunc in the pmap extension. I wonder how one can model a daylight set-up with light redirection systems in Radiance at all at the moment.

How are experiences with the pmap for Radiance 3.8? I could use that one for now (I cannot really wait for half a year, so I must use what is available) if it is found to have been relieable. Or should I stay with 3.7?

Again thanks to you and the other Fraunhofer folks making this important extension available to us - is there any hope that pmap could become part of the Radiance distribution itself one day?

CU, Lars.

Hi Lars,

Lars O. Grobe wrote:

Hi Jan!

I'm pretty sure its a question how you modeled the end of your
"light-pipe".
Photon mapping is doing an density estimate to calculate the radiance
and is searching for photons in the nearby.
Unfortunately the algorithm is doing this also for surfaces , which are
"leaving" a closed space. For example, if you have a closed box and you
add a surface to the scene, which is half inside and half outside the
box, you will get light into the box.
You can avoid this phenomena, if you really "close" your pipe (I assume
so :wink: ).
  
Well the pipe is closed by the 45 degree mirror, but I guess that I
must not have geometry extend from the end (so that a part of it is
inside the system and a part is outside). This is really important for
modelling and was not clear to me so far! So the viewer in the sketch
below will see the surfaces A and B lid even though light is not able
to reach those, because the photons hitting the surface are counted
even though not visible from the viewer position, right?

Surface A
___________________________
                         >
light source | viewer
________________|___________

Surface B

Yes! And the higher the bandwidth is the more will be transferred in the
the "dark" space. But its only a problem, if the "outside" is very dark
and no photons are stored there. Then, the density estimate searches for
nearby photons and collects the "wrong" ones.

By the way, we will probably update photon-mapping for the 3.9 version
(or the 4.0) version within the next half year, fixing also some bugs.
This depends on a new project probably launched in January.
  

This is good news for all Radiance users! Will it be possible to use
BRTDfunc modifiers with the photon map than? At the moment we have a
strange situation - most Radiance users most probably use the software
for advanced daylighting simulation. But they cannot model the
advanced systems with the core distribution (pmap is not integrated),
and even if they patch Radiance to support photon mapping, they cannot
use the galzing definitions as given e.g. by the glaze script because
of a lack of support for BRTDfunc in the pmap extension. I wonder how
one can model a daylight set-up with light redirection systems in
Radiance at all at the moment.

We will probably include BRTDfunc into pmap, but this is not clear now.

A remark from me: I never use BRTF in RADIANCE now, since all the
angular information you put into your model is lost for the glow
material. That means, if you model a specific sky luminance distribution
and you are using BTDF-func, no angular information of your BTDF-model
is used! It is treated lambertian ! And this is especially hard, if you
want to model a system, which is intended to redirect the bright zenith sky.
If I model advanced glazings, I use either standard glass and modify it
by brightfunc or for high reflective materials I use a mixfunc of glass
(+brightfunc) and metal. I always check the angular transmission and
reflection of the model by a virtual measuement - and I also test, if it
still works for the sky.

But Greg presented at the workshop the BTDF implementation into mkillum
- this seems to me a very good approach to calculate the advanced window
systems! So this can probably solve your problem now. But I don't know,
how it treats the sky and if the angular information is also "lost".
This is also new to me - I haven't tested it yet.

How are experiences with the pmap for Radiance 3.8? I could use that
one for now (I cannot really wait for half a year, so I must use what
is available) if it is found to have been relieable. Or should I stay
with 3.7?

I have to admit, that we work here still with the 3.7 version (RADIANCE
and pmap). No experience with 3.8.
If you are using pmap, don't use the -I option for rtrace - it is giving
you wrong values. This is one of the bugs we will solve in the near
future. If you want to calculate the illuminance, you should calculate a
180 degree fish-eye-picture at your calculation points and integrate
the picture (you can use findglare or evalglare to calc an illuminance
from a picture)

Again thanks to you and the other Fraunhofer folks making this
important extension available to us - is there any hope that pmap
could become part of the Radiance distribution itself one day?

Well, this is not so easy to answer. It is also a problem of maintenance
- we can maintain only, if we have funding. And we are still looking for
a volunteer for that.....

Cheers,

Jan

···

CU, Lars.

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

--
Dipl.-Ing. Jan Wienold
Project Manager
Fraunhofer-Institut für Solare Energiesysteme
Thermal Systems and Buildings, Lighting and Daylighting
Heidenhofstr. 2, 79110 Freiburg, Germany
Phone: +49(0)761 4588 5133 Fax:+49(0)761 4588 9133
[email protected]

In office:
Mo,Tue: 8:30-18:00
We,Thu: 8:30-16:00
Fr: 8:30-15:30

Again thanks to you and the other Fraunhofer folks making this important extension available to us - is there any hope that pmap could become part of the Radiance distribution itself one day?

I have looked at this in the past, but not recently, I admit. The chief problem as I see it is that the photon map is implemented as an either/or strategy that's decided at compile time. If it were implemented as a separate module, there would be no question of including it in the distribution. However, since the implementation is intimately entangled in the main rendering code, there are maintenance issues that I cannot resolve. When I go to change or add something, I don't understand the pmap add-on well enough to know what I'm doing won't break it. In other words, including the pmap module as written means I would have to be done developing Radiance, essentially.

In my opinion, the best solution would be to create a separate tool using the photon map to replace mkillum in certain circumstances. I am starting to head this direction with my rtcontrib developments, though I also need to add support for BRTDfunc and other material types for this to be complete. Such a solution would do well for daylighting systems, but wouldn't achieve the caustics that many consider the most valuable contribution of the photon mapping method.

-Greg

Jan's comment:

But Greg presented at the workshop the BTDF implementation into mkillum
- this seems to me a very good approach to calculate the advanced window
systems! So this can probably solve your problem now. But I don't know,
how it treats the sky and if the angular information is also "lost".
This is also new to me - I haven't tested it yet.

This should be working for the angular distribution of the sky, though mkillum with the BTDF input hasn't been fully validated at this point. Any help in that direction will be greatly appreciated.

The BSDF types in Radiance only work for "highlights" currently -- indirect components default to diffuse, as you point out. I am looking at ways to correct this in future releases, now that BSDF data is becoming more available, thanks in large part to Peter A-B and his continuing efforts to improve the measurement side of things.

Best,
-Greg

Jan Wienold wrote:

I have to admit, that we work here still with the 3.7 version (RADIANCE
and pmap). No experience with 3.8.
If you are using pmap, don't use the -I option for rtrace - it is giving
you wrong values. This is one of the bugs we will solve in the near
future. If you want to calculate the illuminance, you should calculate a
180 degree fish-eye-picture at your calculation points and integrate
the picture (you can use findglare or evalglare to calc an illuminance
from a picture)
  
Hello again...

I have been thinking about what you wrote here, and I took a look at what findglare would give me from a picture (as I understood that findglare on an octree would also just call rtace -I thus give a wrong result). The manpage of findglare says:

"By default, findglare only computes glare sources and indirect vertical illuminance for the given view [...]"

So I would get only the indirect irradiance, while, to calculate the illuminance, I would need the total irradiance including direct irradiance e.g. from light sources visible from the point of view - right? So I cannot automate this using an existing tool but must write a script to integrate fish-eye projected pictures over the whole hemisphere, right?

Thank you for your support on all that pmap-related stuff!!!

Lars.

Hi Lars,

I think you are right. Anyhow, I'm not sure, if Roland implemented the
correct pmap conform rpict-call within findglare - I'm pretty sure he
never worked on that. Therefore there is no other way as rendering the
whole hemisphere and than evaluating the picture.
If you also plan to use evalglare (last week Stephen visited us and he
mentioned that), you have to do that anyhow.

Merry Christmas and best wishes for the 2009!

Jan

Lars O. Grobe wrote:

···

Jan Wienold wrote:

I have to admit, that we work here still with the 3.7 version (RADIANCE
and pmap). No experience with 3.8.
If you are using pmap, don't use the -I option for rtrace - it is giving
you wrong values. This is one of the bugs we will solve in the near
future. If you want to calculate the illuminance, you should calculate a
180 degree fish-eye-picture at your calculation points and integrate
the picture (you can use findglare or evalglare to calc an illuminance
from a picture)
  
Hello again...

I have been thinking about what you wrote here, and I took a look at
what findglare would give me from a picture (as I understood that
findglare on an octree would also just call rtace -I thus give a wrong
result). The manpage of findglare says:

"By default, findglare only computes glare sources and indirect
vertical illuminance for the given view [...]"

So I would get only the indirect irradiance, while, to calculate the
illuminance, I would need the total irradiance including direct
irradiance e.g. from light sources visible from the point of view -
right? So I cannot automate this using an existing tool but must write
a script to integrate fish-eye projected pictures over the whole
hemisphere, right?

Thank you for your support on all that pmap-related stuff!!!

Lars.

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

--
Dipl.-Ing. Jan Wienold
Project Manager
Fraunhofer-Institut für Solare Energiesysteme
Thermal Systems and Buildings, Lighting and Daylighting
Heidenhofstr. 2, 79110 Freiburg, Germany
Phone: +49(0)761 4588 5133 Fax:+49(0)761 4588 9133
[email protected]

In office:
Mo,Tue: 8:30-18:00
We,Thu: 8:30-16:00
Fr: 8:30-15:30

I think you are right. Anyhow, I'm not sure, if Roland implemented the
correct pmap conform rpict-call within findglare - I'm pretty sure he
never worked on that. Therefore there is no other way as rendering the
whole hemisphere and than evaluating the picture.

Help!!! I do not get it... to get the illuminance from a 180 degree fisheye picture (no matter if taken by a camera or rendered by rpict), I have to integrate the luminance values over the circular surface of the projected hemisphere. This means that I somehow have to sum-up the pixel values. Still I do not really know the maths to do it, can anyone give me a hint, please? Is it the average of the pixel values multiplied by the surface area, the pixel values being weighted according to the solid angles they cover?

CU Lars.

Hi Lars,

If you use the hemispherical fisheye type (-vth), you just need the straight average of the circular area times pi to get the irradiance (times 179 for illuminance). For angular fisheye perspectives, as you might get from a camera or the -vta option, you need a solid angle correction equal to the cosine of the angle times the sine of the angle divided by the angle itself (in radians) and additional normalization . It's a strange correction term, but here it is in a pcomb command for a 190-degree fisheye lens:

  pcomb -e 'sq(x):x*x' \
   -e 'ar=190/2*PI/180*sqrt(sq(2/xmax*x-1)+sq(2/ymax*y-1))' \
  -e 'cf=WE*sq(190*PI/180*2/(xmax+ymax))*if(ar-PI/2,0,if(ar-.01,cos(ar)*sin(ar)/ar,1))' \
  -e 'lo=cf*li(1)' input.hdr > corrected.hdr

I believe this is correct.
-Greg

···

From: "Lars O. Grobe" <[email protected]>
Date: January 2, 2009 2:16:32 AM PST

I think you are right. Anyhow, I'm not sure, if Roland implemented the
correct pmap conform rpict-call within findglare - I'm pretty sure he
never worked on that. Therefore there is no other way as rendering the
whole hemisphere and than evaluating the picture.

Help!!! I do not get it... to get the illuminance from a 180 degree fisheye picture (no matter if taken by a camera or rendered by rpict), I have to integrate the luminance values over the circular surface of the projected hemisphere. This means that I somehow have to sum-up the pixel values. Still I do not really know the maths to do it, can anyone give me a hint, please? Is it the average of the pixel values multiplied by the surface area, the pixel values being weighted according to the solid angles they cover?

CU Lars.

Hi Greg,

thank you, great, I think that means I got it right, even if I would not have figured out that pcomb-line in a life-time :wink:

Lars.

Shortly after PMAP was released I messed about with it to try and
understand what the numbers all meant and to see what you had to do to
get accurate results. I have cut down a presentation I created to
provide 4 slides of the process I went through to get appropriate images
and numbers. Not very scientific to be honest but perhaps a starting
point for further study.

I will go and have another look at the same model with alternative
suggestions for the three variables if you have any. Although I may
already have the results as only some of them are included here.

Regards

Andrew

20071204_apb_LightpipeStudy_Part_rev04.pdf (330 KB)

···

__________________________
Andrew Bissell
B.Eng(Hons) C.Eng MSLL MCIBSE MIET
Associate Lighting Designer
Cundall Light4
Direct: 0161 200 1235
Mobile: 07899 907 978
Office: 0161 244 5660
P Please consider the environment before printing this e-mail
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Lars
O. Grobe
Sent: 04 December 2008 08:01
To: [email protected]
Subject: [Radiance-general] experiences with the photon map

Hi list!

While I am trying this on Radzilla now (as there is no photon-mapping
available in Radiance-3.9 at the time of this writing), I am pretty sure
that the effects I get are not related to Radzilla but on the way I use
the pmap-System.

I am trying to model a simple, highly specular horizontal light duct,
with a rectangular cross-section (yes I know that in THIS case I could
use the mirror material and Radiance, but I will go for non-planar
surfaces later).

Now either I get very splotchy luminance images in the inside, or,
increasing the `bandwith` to rather high values, have a blurry result
with - and this is the problem - light leaving the geometry even though
it is closed (the duct has a 45 degree mirror at its end that should
actually close it, but the sides extend besides the mirror and appear
illuminated even behind it).

I am working with an initial photon count for both global and caustic
photons of 2.000.000 and a bandwith value of 2000 at the moment.

Is it possible to get such systems rendered in a way that I have both a
smooth luminance and no light escaping the geometry?

Is there any source for a starting point in what way rtcontrib could be
used for modeling such systems? I know the qt-movie from the workshop,
but I did not get it - and it seams that I know noone except Greg who
got it so far :wink:

Thank You & CU, Lars.

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