Hi,
I just got some surprising results from mkillum.
I have a very basic set-up, that consists of a test-room facing a wall with a small window. I put a koffer around the open side of the room, and define these surfaces as illums using mkillum. In the next step, I display only the scene illuminated by the mkillum-generated illum - the sky dome that was used to generate the illum has been removed here, to have only the contribution by the illum visible.
Now the illum replaces the indirekt contribution into the room, and this looks ok. But - the illum also illuminates the outside geometry in my case. So I have a bright area on the wall opposite of my test room. This is also clearly visible from inside (the sky dome has been switched on again in that case).
I never came to think about it, but this would mean that in all those cases, where we place an illum inside a fenestration, the fenestrations inner surfaces will appear brigther then they should be, right?
CU Lars.
Images are available at:
http://www.larsgrobe.de/mkillum_inside.jpg
http://www.larsgrobe.de/mkillum_outside.jpg
the yellow wireframe is supposed to explain the illum surfaces...
Sorry, this was a stupid mistake of mine. When I replaced the polygon surface that I had been using before by a !gensurf-line, I ended up with a wrong surface normal. This made my illum become oriented to the outside world. As the other surfaces where still facing inwards, the culprit surface still got enough light from the sides to illuminate the opposite wall. I only found this when I switched to the light modifier type using mkillums l+, because than the surface appeared completely black when seen from inside (the illum being not visible itself makes this kind of debugging more difficult, and I was 100% sure that the orientation was ok because I had tested it before - but than there had been the polygon).
So, this is my second non-problem reported to the list, sorry for messing up your mail boxes...
CU Lars.
Hi Lars,
Nice that I slept through this one, too... Your debugging tips are helpful. Another way to determine whether you are looking at the back or front of a surface is in rvu, which reports the first surface hit (even if it's invisible) and tells you back or front. This is only for materials that care which side you hit, like lights, illums, dielectric, etc. Plastic and metal won't let you know. The only way to tell for these surfaces is to turn backface visibility off with -bv0. This can cause your scene to look a bit confused, so I only recommend it as a last resort.
Best,
-Greg
···
From: "Lars O. Grobe" <[email protected]>
Date: February 11, 2009 3:30:18 AM PST
Sorry, this was a stupid mistake of mine. When I replaced the polygon surface that I had been using before by a !gensurf-line, I ended up with a wrong surface normal. This made my illum become oriented to the outside world. As the other surfaces where still facing inwards, the culprit surface still got enough light from the sides to illuminate the opposite wall. I only found this when I switched to the light modifier type using mkillums l+, because than the surface appeared completely black when seen from inside (the illum being not visible itself makes this kind of debugging more difficult, and I was 100% sure that the orientation was ok because I had tested it before - but than there had been the polygon).
So, this is my second non-problem reported to the list, sorry for messing up your mail boxes...
CU Lars.
Hi Lars,
One thing that we do to confirm orientation is to test the relevant geometry by assigning a glow material. Front will "glow" back will be black.
-Jack
Greg Ward wrote:
···
Hi Lars,
Nice that I slept through this one, too... Your debugging tips are helpful. Another way to determine whether you are looking at the back or front of a surface is in rvu, which reports the first surface hit (even if it's invisible) and tells you back or front. This is only for materials that care which side you hit, like lights, illums, dielectric, etc. Plastic and metal won't let you know. The only way to tell for these surfaces is to turn backface visibility off with -bv0. This can cause your scene to look a bit confused, so I only recommend it as a last resort.
Best,
-Greg
From: "Lars O. Grobe" <[email protected]>
Date: February 11, 2009 3:30:18 AM PST
Sorry, this was a stupid mistake of mine. When I replaced the polygon surface that I had been using before by a !gensurf-line, I ended up with a wrong surface normal. This made my illum become oriented to the outside world. As the other surfaces where still facing inwards, the culprit surface still got enough light from the sides to illuminate the opposite wall. I only found this when I switched to the light modifier type using mkillums l+, because than the surface appeared completely black when seen from inside (the illum being not visible itself makes this kind of debugging more difficult, and I was 100% sure that the orientation was ok because I had tested it before - but than there had been the polygon).
So, this is my second non-problem reported to the list, sorry for messing up your mail boxes...
CU Lars.
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Jack de Valpine wrote:
Hi Lars,
One thing that we do to confirm orientation is to test the relevant geometry by assigning a glow material. Front will "glow" back will be black.
If you're using AutoCAD, you can select the element and then step through the vertex order in the properties dialog box. There is also an autoLISP routine floating out there on the intertubes that draws an arrow indicating the normal, and has a flip function too. I realize this is modeling tool-specific, and is one step removed from the actual Radiance scene description, but I mention it anyway, just because. =8-)
- Rob