Hello radiance users,
I am performing calculations on illumiance values inside a 22 x 13 x 6 m
geometry that is exclusively lit by a sort of rectangular light pipes.
There's no direct contribution on the spot where I want to know the
irradiance values so I've put some emphasis on the ambient parameters. I've
done measurements on a scale model so I already have a clue on what the
outcome should look like. I use rtrace and it goes like this:
rtrace -I+ -h -ab 7 -aa 0.05 -as 512 -ad 1024 -ar 10000 -av 0.1 0.1 0.1 -aw
1 -af ambfiles/trace.amb -dp 512 -ds .2 -dt .05 -dc .75 -dr 3 -dj .7 -sj
1 -st .01 -lr 8 -lw .001 -e errorfile octrees/room.oct < input > result
(Transformation from irradiance to illuminance happens elsewhere.) The
problem I'm faced with is that the process runs out of memory (on a 2 Gb
memory system). Depending on the platform the process is either terminated
(mingw) or starts swapping to HD (osx). The error message goes: rtrace:
system - out of memory in avstore. I've tried several alternative settings,
e.g. leaving out the -av and -aw parameters (that is setting them to -av 0 0
0 -aw 0) but it won't help. Thuogh reducing the ab setting to 3 solves the
problem, I need more bounces to get anywhere near the final result. I also
wonder if the continuously expanding ambfile behaves normally (it reaches up
to 1.5 Gb when the process terminates). It seems as if new values are added
rather that substituted in the ambfile. Or do I have to use some sort of
cut-off criteria?
I am not at all new to radiance, but obviously not familiar enough with the
code to sort out this problem. Can anyone help?
Kind regards,
Casper Esmeijer
P.S. The model is pretty straightforward. For the light pipes I created a
separate (frozen) octree and I used the instance surface type and xform to
put them in place.
rtrace -I+ -h -ab 7 -aa 0.05 -as 512 -ad 1024 -ar 10000 -av 0.1 0.1 0.1
-aw 1 -af ambfiles/trace.amb -dp 512 -ds .2 -dt .05 -dc .75 -dr 3 -dj .7
-sj 1 -st .01 -lr 8 -lw .001 -e errorfile octrees/room.oct < input >
result
I don't know if it will help your memory issue, but it seems your -ar
value of 10000 is much higher than should be required. I find that
extreme values for 'ar' are only required when the total scene size is
much larger than the zone you're interested in. An example would be a
daylighting model for a single small room in a building that also
includes large external geometry many times larger than the room itself.
Try -ar 200 and -ar 600. You may be surprised that high values don't
impact your results that much, but would have a strong impact on the
quality of rendered images.
-Chris
···
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses
Hi Casper,
I think that light pipes are a bit tricky with Radiance. There are probably others who can chime in on this, but I will give you a few thoughts to start with.
Currently you are setting really high ambient parameters in order to try to trace rays back out the light pipe to fine the solar source. This is tricky with a backwards raytracer such as Radiance. One method that might help short circuit this a bit would be to use mkillum to calculate secondary sources that can be used to simplify things. These secondary sources would make it easier for light to "reach" the space from a calculation standpoint therefore allowing more manageable rendering parameters. One possible way to do this would be to place polygons at the top of your light pipe elements effectively "closing" them to the outside, then you could run mkillum with the polygons to generate secondary sources. Perhaps to optimize things further you could then place polygons to close the bottom end of the pipes and again run mkillum on these resulting in light distribution that is effectively at the bottom of the pipe. I am not sure how valid this is so perhaps others can chime in.
Regards,
-Jack de Valpine
Casper Esmeijer wrote:
···
Hello radiance users,
I am performing calculations on illumiance values inside a 22 x 13 x 6 m geometry that is exclusively lit by a sort of rectangular light pipes. There's no direct contribution on the spot where I want to know the irradiance values so I've put some emphasis on the ambient parameters. I've done measurements on a scale model so I already have a clue on what the outcome should look like. I use rtrace and it goes like this:
rtrace -I+ -h -ab 7 -aa 0.05 -as 512 -ad 1024 -ar 10000 -av 0.1 0.1 0.1 -aw 1 -af ambfiles/trace.amb -dp 512 -ds .2 -dt .05 -dc .75 -dr 3 -dj .7 -sj 1 -st .01 -lr 8 -lw .001 -e errorfile octrees/room.oct < input > result
(Transformation from irradiance to illuminance happens elsewhere.) The problem I'm faced with is that the process runs out of memory (on a 2 Gb memory system). Depending on the platform the process is either terminated (mingw) or starts swapping to HD (osx). The error message goes: rtrace: system - out of memory in avstore. I've tried several alternative settings, e.g. leaving out the -av and -aw parameters (that is setting them to -av 0 0 0 -aw 0) but it won't help. Thuogh reducing the ab setting to 3 solves the problem, I need more bounces to get anywhere near the final result. I also wonder if the continuously expanding ambfile behaves normally (it reaches up to 1.5 Gb when the process terminates). It seems as if new values are added rather that substituted in the ambfile. Or do I have to use some sort of cut-off criteria?
I am not at all new to radiance, but obviously not familiar enough with the code to sort out this problem. Can anyone help?
Kind regards,
Casper Esmeijer
P.S. The model is pretty straightforward. For the light pipes I created a separate (frozen) octree and I used the instance surface type and xform to put them in place.
------------------------------------------------------------------------
_______________________________________________
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:
.... Perhaps to optimize things further you could then place polygons to close the bottom end of the pipes and again run mkillum on these resulting in light distribution that is effectively at the bottom of the pipe. I am not sure how valid this is so perhaps others can chime in.
Oooh, I hadn't thought of that before, but of course you're right. A very complex skylight/laylight system with multiple "nasty" layers could be sorted out, via mkillum, one at a time with progressive mkillum runs starting from the outside and working your way in. Then for the final calcs/renders, you would simply use the last set of illums. Why wouldn't this be valid? As long as you only use the last set of illums so there isn't any double- or triple counting of contributions, this seems totally valid to me. Greg?
- Rob
Hi Casper et al.,
I need a little more information about the material on the inside of the light pipes. Is it diffuse? If not, then you probably don't need all the ambient bounces. Even if it is, Jack's idea for using mkillum is a good one. I'd try putting the illum surface on the interior portal first, and set mkillum -aa 0 so there's no ambient storage, decreasing other parameters to mkillum accordingly, e.g.:
mkillum -ab 0 -ad 256 -as 0 -ab 4
This will perform a pure Monte Carlo calculation in mkillum, which will avoid the storage problem and still give you reasonable results.
As Jack points out, light pipes are not really Radiance's forte, and down the line there will be better options, like using rtcontrib in a more general ray-tracing precalculation. Right now, you're sort of stuck with mkillum. If your interior surfaces are mirror-like, then you may also avail yourself of the "mirror" type to handle redirected sunlight, but only if you expect that.
Best,
-Greg
···
From: Rob Guglielmetti <[email protected]>
Date: May 13, 2008 8:52:38 AM PDT
Jack de Valpine wrote:
.... Perhaps to optimize things further you could then place polygons to close the bottom end of the pipes and again run mkillum on these resulting in light distribution that is effectively at the bottom of the pipe. I am not sure how valid this is so perhaps others can chime in.
Oooh, I hadn't thought of that before, but of course you're right. A very complex skylight/laylight system with multiple "nasty" layers could be sorted out, via mkillum, one at a time with progressive mkillum runs starting from the outside and working your way in. Then for the final calcs/renders, you would simply use the last set of illums. Why wouldn't this be valid? As long as you only use the last set of illums so there isn't any double- or triple counting of contributions, this seems totally valid to me. Greg?
- Rob
Greg, Rob, Jack, Christopher,
Thanks for your response. The light pipes are lined with a diffuse material. So are all other
surfaces. I hadn't thought of using mkillum. Probably the result of how a design process works.
You start out with a plan, then it is slightly changed, some modifications are made and before
you know it you are stuck with something completely different than you started with.
Even though I realise a backward raytracer is not at it's best in these circumstances I'll give the
illums a go and keep you posted.
Casper
···
-----Original Message-----
From: Greg Ward <[email protected]>
To: Radiance general discussion <[email protected]>
Date: Tue, 13 May 2008 11:21:55 -0700
Subject: Re: [Radiance-general] out of memory in avstore
Hi Casper et al.,
I need a little more information about the material on the inside of
the light pipes. Is it diffuse? If not, then you probably don't
need all the ambient bounces. Even if it is, Jack's idea for using
mkillum is a good one. I'd try putting the illum surface on the
interior portal first, and set mkillum -aa 0 so there's no ambient
storage, decreasing other parameters to mkillum accordingly, e.g.:
mkillum -ab 0 -ad 256 -as 0 -ab 4
This will perform a pure Monte Carlo calculation in mkillum, which
will avoid the storage problem and still give you reasonable results.
As Jack points out, light pipes are not really Radiance's forte, and
down the line there will be better options, like using rtcontrib in a
more general ray-tracing precalculation. Right now, you're sort of
stuck with mkillum. If your interior surfaces are mirror-like, then
you may also avail yourself of the "mirror" type to handle redirected
sunlight, but only if you expect that.
Best,
-Greg