Dear list,
I know this keeps coming up every now and then, but I just wanted to
check the latest state-of-the-art when it comes to simulating light
pipes. Here is what I gathered from various pieces of documentation,
posts, and the back of my head:
a) a forward raytracer such pmap seems to be the optimal solution, but
pmap has not been merged into Radiance Classic yet and only works with
Radiance 3.7
b) Radzilla, which also supported (some of the) pmap functionality
seems to be unmaintained.
c) the mirror material can only be used on planar objects, hence it's
no good inside a tube (inverted cylinder). How good would a metal tube
in combination with ridiculously high number of bounces be?
d) Guilio made some suggestions in this thread:
http://luminance.londonmet.ac.uk/radiance_mailinglists/general/2005-May/002708.html
about using some approximations in combination with a glow material
e) then there's the new rtcontrib program
(http://luminance.londonmet.ac.uk/radiance_mailinglists/general/2005-May/002710.html):
"Rtcontrib can also be used by the more adventurous among you to
compute input/output relations for devices such as light pipes and
shading systems, although I have yet to test such an approach,
myself." --Greg
There is a directory ray/src/rtcontutor, but the example explains
rtcontrib's use for daylight coefficients, not light pipes. I
personally can't quite work out how it would possibly replace a
forward raytracer, so has anybody been adventurous yet used it for
this?
f) How about gathering the external environment with a mkillum across
the pipe's entrance, then spreading the light in the interior using a
second mkillum at the pipe's exit?
Many thanks for sharing your thoughts
Axel
f) How about gathering the external environment with a mkillum across the pipe's entrance, then spreading the light in the interior using a second mkillum at the pipe's exit?
Axel - I had a go at this years ago when time for experimentation seemed easier to come by. Can't recall the details, but I think it worked passably well for the diffuse component of illumination. For direct however, as expected, it didn't do too well.
-John
···
-----------------------------------------------
Dr. John Mardaljevic
Senior Research Fellow
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)
[email protected]
http://www.iesd.dmu.ac.uk/~jm
Hi Axel,
Responses inline...
c) the mirror material can only be used on planar objects, hence it's
no good inside a tube (inverted cylinder). How good would a metal tube
in combination with ridiculously high number of bounces be?
Would work for the sky, but not the sun.
e) then there's the new rtcontrib program
(http://luminance.londonmet.ac.uk/radiance_mailinglists/general/2005-May/002710.html):
"Rtcontrib can also be used by the more adventurous among you to
compute input/output relations for devices such as light pipes and
shading systems, although I have yet to test such an approach,
myself." --Greg
There is a directory ray/src/rtcontutor, but the example explains
rtcontrib's use for daylight coefficients, not light pipes. I
personally can't quite work out how it would possibly replace a
forward raytracer, so has anybody been adventurous yet used it for
this?
I gave it a go for illustration purposes at the 2006 Radiance workshop. You can download a QuickTime movie of the presentation from:
http://www.radiance-online.org/radiance-workshop5/2006_Radiance_Workshop/
It's the talk entitled, "Applying the Radiance rtcontrib program," but heed the warning and download the QT movie rather than hitting the link on your browser, because most browsers (including Safari) barf on it. The key part you want to check out is "Step 2" in the mirrored light pipe example. I'm using flat surfaces, but only for comparison purposes. The rtcontrib approach should work for any geometry.
f) How about gathering the external environment with a mkillum across
the pipe's entrance, then spreading the light in the interior using a
second mkillum at the pipe's exit?
Again, this wouldn't work for the solar component.
-Greg
Greg,
thanks for your reply.
e) then there's the new rtcontrib program
(http://luminance.londonmet.ac.uk/radiance_mailinglists/general/
2005-May/002710.html):
"Rtcontrib can also be used by the more adventurous among you to
compute input/output relations for devices such as light pipes and
shading systems, although I have yet to test such an approach,
myself." --Greg
There is a directory ray/src/rtcontutor, but the example explains
rtcontrib's use for daylight coefficients, not light pipes. I
personally can't quite work out how it would possibly replace a
forward raytracer, so has anybody been adventurous yet used it for
this?
It's the talk entitled, "Applying the Radiance rtcontrib program,"
but heed the warning and download the QT movie rather than hitting
the link on your browser, because most browsers (including Safari)
barf on it. The key part you want to check out is "Step 2" in the
mirrored light pipe example. I'm using flat surfaces, but only for
comparison purposes. The rtcontrib approach should work for any
geometry.
Found your talk. I also looked at the examples in the rtcontutor
directory (which seems to have disappeared in the 3R9 tar ball). The
geometry you used for the light ducts is relatively simple. I am
particularly interested in round light pipes, not square light ducts.
I noticed that in model.mat, you define the material for the duct as
metal, only to immediately re-define it as mirror:
----------------8<-----------------
void metal mirror_mat
0
0
5 .9 .9 .9 1 0
void mirror mirror_mat
0
0
3 .9 .9 .9
----------------8<-----------------
I understand why you would prefer mirror instead of metal: it creates
virtual sources of the sun, dealing with the direct component. So
would the only option with a round pipe be to break it up into
polygons?
It strikes me that this particular example of rtcontrib is useful for
demonstrating its use with sky components, so a large number of sky
distributions and sun positions may be computed rather quickly once
the coefficients (individual images) are generated. Guess you used the
light ducts simply to add some interest to the scene. The same scene
complexity could as well have been simulated without rtcontrib if an
animation ("input/output relations", as you called it) was not sought.
Many thanks
Axel
Hi Axel,
Found your talk. I also looked at the examples in the rtcontutor
directory (which seems to have disappeared in the 3R9 tar ball). The
geometry you used for the light ducts is relatively simple. I am
particularly interested in round light pipes, not square light ducts.
As I said, I used planar geometry so I could compare to the virtual source result. Rtcontrib will work with any geometry.
I noticed that in model.mat, you define the material for the duct as
metal, only to immediately re-define it as mirror:
----------------8<-----------------
void metal mirror_mat
0
5 .9 .9 .9 1 0
void mirror mirror_mat
0
3 .9 .9 .9
----------------8<-----------------
I understand why you would prefer mirror instead of metal: it creates
virtual sources of the sun, dealing with the direct component. So
would the only option with a round pipe be to break it up into
polygons?
I don't recall why I left the original definition in there, but the later one is all that matters. There's not a lot of sense in breaking your cylinder into long polygons, as it would end up creating an insane number of virtual sources. Better to leave it as a cylinder and use the metal type, since mirror doesn't do anything for curved geometries.
It strikes me that this particular example of rtcontrib is useful for
demonstrating its use with sky components, so a large number of sky
distributions and sun positions may be computed rather quickly once
the coefficients (individual images) are generated. Guess you used the
light ducts simply to add some interest to the scene. The same scene
complexity could as well have been simulated without rtcontrib if an
animation ("input/output relations", as you called it) was not sought.
Actually, I was trying to come up with a scene that would be very difficult to simulate w/o rtcontrib -- if the light pipe had curved surfaces, for example. In such case, you wouldn't have been able to render even a single time point if it included the sun without rtcontrib.
-Greg