Hi all,
Struggling with ies lights & ambient parameters, and blotchy renderings. For those interested, have a look at this:
http://www.rumblestrip.org/rad/rad_01.html
...and then report back on this frequency, if you have any suggestions. TIA
Rob,
With -ar set that high, those splotches should be much smaller.
Are you positive that there are no objects in your scene that
are placed far away from the room that we're looking at?
You also may want to try rendering with -aa 0 -ad 16 just to
see what the image should look like.
Mark
···
On Tue, 9 Sep 2003, Rob Guglielmetti wrote:
Hi all,
Struggling with ies lights & ambient parameters, and blotchy renderings.
For those interested, have a look at this:http://www.rumblestrip.org/rad/rad_01.html
...and then report back on this frequency, if you have any suggestions. TIA
----
Rob Guglielmetti
e. [email protected]
w. www.rumblestrip.org_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
I would apply mkillum surfaces to the coffered ceiling. If you need to circumvent this technique and are ready for 80 hours, try:
rpict -x ... -y ... -ps 1 -w -ab 3 -ad 2048 -as 2048 -ar 5000 -av .05 .05 .05 -ds .2 (actually, this looks more like -ad 4096).
This (almost) always works -
unless you are impatient
Rad is nice, but I found it always helpful to understand what each rpict parameter means. You need them for rtrace anyway.
With mkillum, you might be done in 24 hours. The neat side effect is that you only have to produce mkillum surfaces for one coffer, then you can array them with xform below each coffer. You could even turn off the indirect calculation (which increases values by around 20% for this space, depending on reflectance values)
In principle, you could approximate the coffer distribution with a lambertian light source. I estimate that this coffer has an efficiency between 10 and 25%, so multiply lamp lumens by .15 and assign this flux to an illum surface for initial qick and dirty light levels.
Martin
···
-----Original Message-----
From: Rob Guglielmetti [mailto:[email protected]]
Sent: Tue 9/9/2003 11:20 AM
To: radiance-general
Cc:
Subject: [Radiance-general] -ar, -ad, -as, ahh $#*@!
Hi all,
Struggling with ies lights & ambient parameters, and blotchy renderings.
For those interested, have a look at this:
http://www.rumblestrip.org/rad/rad_01.html
...and then report back on this frequency, if you have any suggestions. TIA
----
Rob Guglielmetti
e. [email protected]
w. www.rumblestrip.org
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Rob,
This seems to be a classic example of where you just can't rely on the interreflection calculation in Radiance to solve your problem for you. The basic assumption in this approximation is that the indirect illumination varies slowly over surfaces, which clearly isn't the case in this scene.
Solution: you need to apply mkillum to create pseudo light sources (imposters) for your indirect luminaires. To do so, put a shallow box with an open top around a single ceiling-mounted light source (5 rectangles) and use the "void" modifer for these, making sure they face out into your room. Let's say you called this file "light_in.rad". Using either the octree for your room or a reduced one that just has that one light source switched on (better), you would run mkillum thus:
% mkillum -ab 1 -ad 512 -as 256 -ar 16 < light_in.rad > light_out.rad
In addition to creating the light_out.rad file, mkillum will generate 5 data files containing the computed output distribution for your luminaire. You may then take the light_out.rad and use an array transform to place it over all the light sources in your scene. For the sake of calculational efficiency, I recommend that you also change the light primitives in your original luminaire files to the "glow" type with an effective distance equal to the diagonal of your luminaire dimension, so as to avoid sending shadow rays to these sources unnecessarily.
The net result should be a fast and accurate rendering of your space.
-Greg
···
From: Rob Guglielmetti <[email protected]>
Date: Tue Sep 9, 2003 8:20:52 AM US/PacificHi all,
Struggling with ies lights & ambient parameters, and blotchy renderings. For those interested, have a look at this:
http://www.rumblestrip.org/rad/rad_01.html
...and then report back on this frequency, if you have any suggestions. TIA
----
Rob Guglielmetti
thanks everyone!
Mark, just for fun, I'm trying your -aa 0 -ad 16 trick right now (it'll be a while before I can post a result, methinks).
Martin, yours was a good heads up as to the essence of the problem -- once again I'm expecting brute force CPU cycles to make up for a lack of understanding about the guts of Radiance.
This is good, though. I finally realize that mkillum can be thought of as a way of rolling your own ies files, sorta.
Greg Ward wrote:
Hi Rob,
This seems to be a classic example of where you just can't rely on the interreflection calculation in Radiance to solve your problem for you. The basic assumption in this approximation is that the indirect illumination varies slowly over surfaces, which clearly isn't the case in this scene.
er, right. =8-/
Solution: you need to apply mkillum to create pseudo light sources (imposters) for your indirect luminaires. To do so, put a shallow box with an open top around a single ceiling-mounted light source (5 rectangles) and use the "void" modifer for these, making sure they face out into your room. Let's say you called this file "light_in.rad". Using either the octree for your room or a reduced one that just has that one light source switched on (better), you would run mkillum thus:
lemme make sure I understand; these 5 rectangles would define the inside recess of the coffer, yes? And I would call it out like so:
void polygon coffer.top
0
12
0 0 -5
0 10 -5
10 10 -5
10 0 -5
... and so on?
For the
sake of calculational efficiency, I recommend that you also change the light primitives in your original luminaire files to the "glow" type with an effective distance equal to the diagonal of your luminaire dimension, so as to avoid sending shadow rays to these sources unnecessarily.
I *think* I understand...
The net result should be a fast and accurate rendering of your space.
That's all I ever wanted. =8-)
I'll try these suggestions. Thanks guys.
Hi Rob,
lemme make sure I understand; these 5 rectangles would define the inside recess of the coffer, yes? And I would call it out like so:
void polygon coffer.top
0
12
0 0 -5
0 10 -5
10 10 -5
10 0 -5... and so on?
Actually, you want your rectangles to be the four sides plus another one _below_ the coffer, sealing it off from the world, so to speak. The idea is that the mkillum replaces these surfaces with illum light sources (imposters), whose output distributions mimics the coffer/ceiling combination. You need to make sure that source rays can't sneak past this geometry, which is why you want it to make a tight seal around your luminaire system.
-G
Hi Rob,
Just to weigh in below.....
Rob Guglielmetti wrote:
thanks everyone!
Mark, just for fun, I'm trying your -aa 0 -ad 16 trick right now (it'll be a while before I can post a result, methinks).
Martin, yours was a good heads up as to the essence of the problem -- once again I'm expecting brute force CPU cycles to make up for a lack of understanding about the guts of Radiance.
This is good, though. I finally realize that mkillum can be thought of as a way of rolling your own ies files, sorta.
Greg Ward wrote:
Hi Rob,
This seems to be a classic example of where you just can't rely on the interreflection calculation in Radiance to solve your problem for you. The basic assumption in this approximation is that the indirect illumination varies slowly over surfaces, which clearly isn't the case in this scene.
er, right. =8-/
Solution: you need to apply mkillum to create pseudo light sources (imposters) for your indirect luminaires. To do so, put a shallow box with an open top around a single ceiling-mounted light source (5 rectangles) and use the "void" modifer for these, making sure they face out into your room. Let's say you called this file "light_in.rad". Using either the octree for your room or a reduced one that just has that one light source switched on (better), you would run mkillum thus:
lemme make sure I understand; these 5 rectangles would define the inside recess of the coffer, yes? And I would call it out like so:
Actually, what I think Greg means here is that you place an open top box to enclose a selected coffer in this case. For example 4 polygons that form the perimeter around the coffer and are "extruded" (for lack of a better term) down from the ceiling/coffer surface, these polygons should be capped with a 5th that in essence encloses the coffer. Note that the normals for these polygons must all point out into the the room. The function of this box is to "catch" the light from the true sources in the coffer in the mkillum calculation and then subsequently serve as the light emitting surfaces (hidden because they are illums) for the coffer based on the data that is generated by the mkillum calc. The appearance of the light in the coffer itself can be controlled by using glow surfaces in place of the light sources in the coffer with a radius applied for each glow to enable the glow some minimal calculation ability within the coffer and behind the illum.
···
void polygon coffer.top
0
12
0 0 -5
0 10 -5
10 10 -5
10 0 -5... and so on?
For the
sake of calculational efficiency, I recommend that you also change the light primitives in your original luminaire files to the "glow" type with an effective distance equal to the diagonal of your luminaire dimension, so as to avoid sending shadow rays to these sources unnecessarily.
I *think* I understand...
The net result should be a fast and accurate rendering of your space.
That's all I ever wanted. =8-)
I'll try these suggestions. Thanks guys.
----
Rob Guglielmetti
e. [email protected]
w. www.rumblestrip.org_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Folks,
I tried the mkillum suggestions, moderate success.
Results appended to previous web page (http://www.rumblestrip.org/rad/rad_01.html).
Comments appreciated. Thanks for your help.
I gotta go.
Hi Rob,
You should do version 2 or 3 (of the three scenarios indicated) for constucting the so-called impostr geometry for mkillum processing. In version 1 which I am guessing is what you used, you will have a number of potential problem areas (althought the image certainly looks a lot better): 1) overlapping geometry and materials, 2) 4 illums with normals pointing the wrong way. Now I am just going to hazard a guess that either one of these issues could cause the motting that you have noted on the floor (another possibility may be your glow material settings).
Of the two scenarios for illum geometry, I am going to say that 3 would actually be preferable, since you then remove 4 illum polygons from processing and aviod some other possible pitfalls from the long skiny polygons and likely requiring an increas in the -ds parameter depending on how the distribution works. But to makethis work your one polygon should seal the coffer as you have indicated and not overlap the fixture/coffer geometry that hangs down. Thus if you have to cheat your coffer depth by a small amount in order to do this, this would probably be a good idea.
Finally you can exercise some control over the mkillum process based on how you set the paremeters giving you fairly low or high resolution data for simulating the fixture.
-Jack
···
---- [email protected] wrote:
Folks,
I tried the mkillum suggestions, moderate success.
Results appended to previous web page
(http://www.rumblestrip.org/rad/rad_01.html).Comments appreciated. Thanks for your help.
I gotta go.
----
Rob Guglielmetti
e. [email protected]
w. www.rumblestrip.org_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Jack,
Hi Rob,
You should do version 2 or 3 (of the three scenarios indicated) for constucting the so-called impostr geometry for mkillum processing. In version 1 which I am guessing is what you used, you will have a number of potential problem areas (althought the image certainly looks a lot better): 1) overlapping geometry and materials, 2) 4 illums with normals pointing the wrong way. Now I am just going to hazard a guess that either one of these issues could cause the motting that you have noted on the floor (another possibility may be your glow material settings).
Yep, I used version 1. And I had the same concerns you cite. This is why I made those diagrams (1Pic = 1Kword)! I guess I thought the goal was to tell mkillum about the major contributing surfaces to the luminous flux at the aperture, which is why I thought the inside of the coffer needed to be defined as illums. The normals of those polys were facing toward the aperture, which in my mind was "into the room".
Now, it's crystal clear. Mkillum wants geometry near the aperture, but not interfering with the aperture. It will look backwards from this geometry into the light fixture, to find sources, and convert that geometry into a photometrically accurate distribution. It truly is a way to generate an ".ies file" for a custom fixture!
Of the two scenarios for illum geometry, I am going to say that 3 would actually be preferable, since you then remove 4 illum polygons from processing and aviod some other possible pitfalls from the long skiny polygons and likely requiring an increas in the -ds parameter depending on how the distribution works. But to makethis work your one polygon should seal the coffer as you have indicated and not overlap the fixture/coffer geometry that hangs down. Thus if you have to cheat your coffer depth by a small amount in order to do this, this would probably be a good idea.
THanks for clarifying this; you have answered all my questions by simply picking one image. This is what I suspected, but wasn't sure. Yes, this particular coffer detail has all the geometry above the ceiling plane, so of course the single polygon (option 3) will work. I see now that you & Greg were asking me to drop the illum polys down below the ceiling to clear any geometry of the luminaire/coffer itself. Which also answers my own question about how close the illum polygons should be; it appears that the closer the better, as long as they don't touch the luminaire.
Finally you can exercise some control over the mkillum process based on how you set the paremeters giving you fairly low or high resolution data for simulating the fixture.
Yes, that's where I still have work to do. Greg spoon fed me the mkillum parameters for this model, but I still have no idea how he came up with them. But yes, I see now that the parameters used in the mkillum process control the resolution of the resultant data files. It makes a lot of sense now, this wonderful tool called mkillum. Thanks Jack, I hope to try out your suggestions tomorrow.
Rob Guglielmetti
[email protected]
www.rumblestrip.org
···
On Tuesday, September 9, 2003, at 08:06 PM, John de Valpine wrote:
Another update, complete with more questions, is available at:
Hi Rob,
Wow, big improvement!
I may not have communicated well about which option to use. The option I meant was the last one with the one polygon that closes the coffer. I was counting 1, 2, 3 after the base case diagram, sorry.
As far as the light "artifacts" around the coffers, I have to guess that those are geometry. You may want to make sure everything is an illum type. And also triple check the orientation of polygons (maybe make them lights or glows and objview just the light polygons to check orientation.
-Jack
Rob Guglielmetti wrote:
···
Another update, complete with more questions, is available at:
http://www.rumblestrip.org/rad/rad_01.html
----
Rob Guglielmetti
e. [email protected]
w. www.rumblestrip.org_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general.
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Jack de Valpine wrote:
Hi Rob,
Wow, big improvement!
I may not have communicated well about which option to use. The option I meant was the last one with the one polygon that closes the coffer. I was counting 1, 2, 3 after the base case diagram, sorry.
OK, thanks for the clarification. But I need to use the last option anyway, because a closer inspection of my coffers (it's not my model) shows that the baffles do project below the ceiling plane. So I have a depressed box around it.
As far as the light "artifacts" around the coffers, I have to guess that those are geometry. You may want to make sure everything is an illum type. And also triple check the orientation of polygons (maybe make them lights or glows and objview just the light polygons to check orientation.
OK, I'll dissect the scene files, thanks.
Rob Guglielmetti wrote:
Hi folks, 'nother update, if interested:
http://www.rumblestrip.org/rad/rad_01.html#break2
What the heck are those bright artifacts near the coffers?
I think that's a rather old bug in Radiance.
Illums sometimes behave strange (they forget that they should
show the repacement material) when viewed under a very flat
angle, which is what you seem to be doing here.
Of course, it's been years that I submitted the last bug report
about this (can't find my test case anymore) and I haven't
checked it since, so I might just as well be wrong. But your
pictures really remind me of that old weirdness, so it could be
worth to do some research about what really happens there.
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Hi Schorsch,
yeah, there is definitely something strange about the illums when viewed under flat angle, I also experienced this. I used my usually well -working brute force type of approach and simply disabled the extra 'drawsources' routine (I think in render() in rpict.c, I'm not quite shure anymore), to make this problem go away .. :-).
But concerning Rob's pictures, I think that there still might be some geometry errors in the coffer modell, e.g. gaps between polygons or intersections or whatever.
-Carsten
I've never heard of this bug, before. I looked at th code, and can't figure out how it might come about. Does anyone have a test scene for reproducing it?
-Greg
···
From: [email protected] (Carsten Bauer)
Date: Sat Sep 13, 2003 7:15:36 AM US/PacificHi Schorsch,
yeah, there is definitely something strange about the illums when viewed under flat angle, I also experienced this. I used my usually well -working brute force type of approach and simply disabled the extra 'drawsources' routine (I think in render() in rpict.c, I'm not quite shure anymore), to make this problem go away .. :-).
But concerning Rob's pictures, I think that there still might be some geometry errors in the coffer modell, e.g. gaps between polygons or intersections or whatever.
-Carsten
Greg Ward wrote:
I've never heard of this bug, before. I looked at th code, and can't
figure out how it might come about. Does anyone have a test scene for
reproducing it?
Unfortunately, my original test case appears to be lost.
I was unable to quickly reconstruct it, but some minimal
information still survived:
The problem only seems to appear (have appeared) when the
illum has a distribution curve (eg. an IES file) applied to
it. And I recall that a specific parameter combination was
required to trigger it. I think that this usually prevents
it from appearing in rview, which makes it tricky to catch.
Probably the vaguest bug description I've ever submitted, eh? 
But I wouldn't be surprised if we were able to finally
chase it down with a little experimentation. Maybe Rob can
strip down his scene until only the offending polygons
(and maybe a surrounding box) are left. By relaxing the
simulation parameters one by one we should then be able
to narrow it down to the real culprits.
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Ha, I am sitting here in front of my pea sea, playing with this model
right now. What a welcome diversion. I was in the midst of doing
just that, as I am re-creating my radiance scene description after a
very abrupt lesson in the whims of gzip (don't ask).
I am building a separate model of one coffer, for the mkillum
process. It would be trivial to place it in a small box room for
further study. I would be happy to give you the files when they are
ready, which is likely to be sometime tomorrow because a show
about the Reno Air Races is airing on TV soon. =8-)
As for the bug's relation to my current woes, well, I don't know.
The renderings that exhibited this problem are old. The latest
renderings (the ones at the end of my web page on all this) do not
have any of these artifacts. The problems I'm currently having with
the rendering of the coffers is more of an uneven illumination inside
the coffers; there are no strange artifacts. But if my model can help
you guys analyze this elusive bug, I'd be happy to send it to you.
Let me know.
···
On 13 Sep 2003, at 19:15, Georg Mischler wrote:
But I wouldn't be surprised if we were able to finally
chase it down with a little experimentation. Maybe Rob can
strip down his scene until only the offending polygons
(and maybe a surrounding box) are left. By relaxing the
simulation parameters one by one we should then be able
to narrow it down to the real culprits.
================
Rob Guglielmetti
[email protected]
www.rumblestrip.org
Ok, so after mentioning the discrepancy between rpict and rview I
actually ran my new test scene through rpict, and bingo!
Maybe it's possible, but within the last hour I couldn't manage
to get the effect in rview. I also found that the appearance
together with mapping data was a coincidence, the bug triggers
with plane jane illums as well.
I'm appending a very simple test case using the rpict defaults
(plus -ab 1 for visuals). Something interesting I also just
detected is that the size of the source appears to make a
difference.
Since this now turns into a development issue, I'm crossposting
to the dev-list. I suggest that everybody involved also reply
there.
-schorsch
illumbug.tgz (450 Bytes)
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/