Dear all,
I've been reading some of the very interesting presentations from the last Radiance workshop and am now keen on finally getting to the bottom of this rtcontrib thing.
My aim is to do Dynamic Daylight Simulations, DDS, using rtcontrib rather than DaySim.
As I am going along, I am preparing more material for the Advanced Tutorial. A usual, the notes advance at a leisurely pace, trying to make one little mistake or discovery a time, rather than doing them all at once.
I have put up some very early notes (really only just scribble with some images) here:
http://luminance.londonmet.ac.uk/pickup/rtcontrib_lesson.html
and would be grateful for any feedback.
This is what's there at the moment:
- show that rpict is simply a convenient way of calling rtrace to produce an image
- show that rtcontrib is a souped-up version of rtrace (bear with me before banging your head against the wall over this one)
- show how rtcontrib produces individual images based on light source modifiers
- show how this can be extended to different 'zones' using binning, e.g. for daylight coefficients
I have not looked at the mkillum-like functionality of rtcontrib yet (pseudo-forward-raytracer?), and the model you see in the images doesn't even have a window pane.
All images under a glow sky (not the ones with circular 11deg light sources) have an overcast distribution. Eventually, this should probably be a simple glow without any distribution assigned to it, but I've used a gensky material for now to be able to compare the absolute values of the combined results which should match the rpict ones.
The big show stopper so far is that I don't get the absolute values right for a glow sky with Tregenza subdivisions. You will also see just how weird the sky hemisphere looks in this simulation after the 145 patches have been combined.
Any hints are very welcome.
Cheers
Axel
Hi Axel,
I like your step by step documentation of your process. I picked up a few
tricks along the way.
I do have one tip for you which you may have already figured out give the
time elapsed between your email and my reply.
When combining your tregenza patch renderings you should use pcomb's -o
option to use original pixel values instead of exposure adjusted values.
The -o option needs to precede every image, so I'm not sure if it'll work
with the wild card character. Alternatively you could use pfilt -1 -e 1
when resizing the tregenza patch renderings to explicitly set exposure at 1.
I think this might solve the brightness issue you are having with rtcontrib
rendered images.
Best,
Andy
···
On 1/17/10 6:04 AM, "Axel Jacobs" <[email protected]> wrote:
Dear all,
I've been reading some of the very interesting presentations from the
last Radiance workshop and am now keen on finally getting to the bottom
of this rtcontrib thing.
My aim is to do Dynamic Daylight Simulations, DDS, using rtcontrib
rather than DaySim.
As I am going along, I am preparing more material for the Advanced
Tutorial. A usual, the notes advance at a leisurely pace, trying to make
one little mistake or discovery a time, rather than doing them all at once.
I have put up some very early notes (really only just scribble with some
images) here:
http://luminance.londonmet.ac.uk/pickup/rtcontrib_lesson.html
and would be grateful for any feedback.
This is what's there at the moment:
- show that rpict is simply a convenient way of calling rtrace to
produce an image
- show that rtcontrib is a souped-up version of rtrace (bear with me
before banging your head against the wall over this one)
- show how rtcontrib produces individual images based on light source
modifiers
- show how this can be extended to different 'zones' using binning, e.g.
for daylight coefficients
I have not looked at the mkillum-like functionality of rtcontrib yet
(pseudo-forward-raytracer?), and the model you see in the images doesn't
even have a window pane.
All images under a glow sky (not the ones with circular 11deg light
sources) have an overcast distribution. Eventually, this should probably
be a simple glow without any distribution assigned to it, but I've used
a gensky material for now to be able to compare the absolute values of
the combined results which should match the rpict ones.
The big show stopper so far is that I don't get the absolute values
right for a glow sky with Tregenza subdivisions. You will also see just
how weird the sky hemisphere looks in this simulation after the 145
patches have been combined.
Any hints are very welcome.
Cheers
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses
Dear all,
an update to the rtcontrib lesson is available:
http://luminance.londonmet.ac.uk/pickup/rtcontrib_lesson.html
I've had lots of feedback from Greg, and also wish to thank Andy who spotted the flaw in my pcomb command line. I clearly out-smarted myself with the image compression.
Although there is some new material, I mostly re-wrote what was already there. The document should be much more readable (it has real sentences in it now) and consistent.
I am rather pleased with the result so far, but also have to admit that I am somewhat shocked about the sheer size of the document. And I am less than half-way through the exercises.
Anyhow, I hope that you all enjoy the read, and that it proves to be as informative to you as it has been for myself. Stay tuned.
Cheers
Axel
Axel,
your link to the lesson archive is broken...
you have http://luminance.londonmet.ac.uk/rtcontrib_lesson.tgz
I think you mean http://luminance.londonmet.ac.uk/pickup/rtcontrib_lesson.tgz
thanks for the tutorial!
Rob Fitzsimmons
Dear all,
the rtcontrib lesson has found a new home here:
http://luminance.londonmet.ac.uk/learnix/docs/rtcontrib_lesson.html
There are likely to be many typos, mistakes and inconsistencies left in it, but it's mostly done: Dynamic daylight simulations with Radiance's rtcontrib can be done. Well, sort of-ish.
As to the software--All scripts that are provided with the tutorial are available as a download. The link is on the page. Everything was written to get a particular task done. There is absolutely no flexibility built into any of the code. If you do decide to try some of the things that I have covered and come up with some better/more elegant/more configurable software or command lines, I'd be happy to hear from you. Please consider sharing your experience.
Thank you all for the feedback, especially Greg! You've been extremely helpful.
Cheers
Axel
Hello all,
I've been working through Axel Jacobs' excellent 'rtcontrib' tutorial (thank you Axel!!) and have hit a wall when it comes to using the 'reinhart.cal' file in lieu of the 'tregenza.cal file. Using the latter 'cal' file I get a complete bin of images for each patch:
$ vwrays -ff -vf fish_up.vf | rtcontrib @rtc.opt -ffc $(vwrays -d -vf fish_up.vf) -f tregenza.cal -b tbin -o ./images/patches/p%03d.hdr -m sky_glow -w test.oct
However when using the reinhart.cal file the images in the bin are only partially completed and listed as 'unfinished' when viewed with ximage (I'm pretty sure that I'm using the most recent reinhart.cal file; v 1.4 2009/12/09 21:34:23):
$ vwrays -ff -vf fish_up.vf | rtcontrib @rtc.opt -ffc $(vwrays -d -vf fish_up.vf) -e MF:2 -f reinhart.cal -b rbin -o ./images/patches/p%03d.hdr -m sky_glow -w test.oct
Has anyone come across similar results?
Thanks and Happy New Years to all.
Chris
Christian Humann ~ Associate
LOISOS + UBBELOHDE
- - - - - - - - - - - - - - - - - - - - - - - - - - -
1917 Clement Avenue Building 10A
Alameda, CA 94501 USA
- - - - - - - - - - - - - - - - - - - - - - - - - - -
510 521 3800 VOICE
510 521 3820 FAX
- - - - - - - - - - - - - - - - - - - - - - - - - - -
www.coolshadow.com
Hi Chris,
I normally recommend using the -bn option with rtcontrib. Not sure if this will fix your problem or not:
$ vwrays -ff -vf fish_up.vf | rtcontrib @rtc.opt -ffc $(vwrays -d -vf fish_up.vf) -e MF:2 -f reinhart.cal -bn Nrbins -b rbin -o ./images/patches/p%03d.hdr -m sky_glow -w test.oct
Best,
-Greg
···
From: Chris Humann <[email protected]>
Date: February 6, 2010 10:37:32 AM JST
Hello all,
I've been working through Axel Jacobs' excellent 'rtcontrib' tutorial (thank you Axel!!) and have hit a wall when it comes to using the 'reinhart.cal' file in lieu of the 'tregenza.cal file. Using the latter 'cal' file I get a complete bin of images for each patch:
$ vwrays -ff -vf fish_up.vf | rtcontrib @rtc.opt -ffc $(vwrays -d -vf fish_up.vf) -f tregenza.cal -b tbin -o ./images/patches/p%03d.hdr -m sky_glow -w test.oct
However when using the reinhart.cal file the images in the bin are only partially completed and listed as 'unfinished' when viewed with ximage (I'm pretty sure that I'm using the most recent reinhart.cal file; v 1.4 2009/12/09 21:34:23):
$ vwrays -ff -vf fish_up.vf | rtcontrib @rtc.opt -ffc $(vwrays -d -vf fish_up.vf) -e MF:2 -f reinhart.cal -b rbin -o ./images/patches/p%03d.hdr -m sky_glow -w test.oct
Has anyone come across similar results?
Thanks and Happy New Years to all.
Chris
Christian Humann ~ Associate
LOISOS + UBBELOHDE
As always, thanks for the response Greg.
As suggested I tried adding the -bn option, however ;rtcontrib' still only generates 248 unfinished files with the '-e MF:2' option. All works fine with 'e MF:1'. I tried sending the files to a ramdisk, but still no joy.
I'm wondering if I did something funny when compiling the most recent head under OS X? Has anyone had similar results using Linux or Cygwin?
Thanks,
Chris H
···
On Feb 5, 2010, at 11:00 PM, Greg Ward wrote:
Hi Chris,
I normally recommend using the -bn option with rtcontrib. Not sure if this will fix your problem or not:
$ vwrays -ff -vf fish_up.vf | rtcontrib @rtc.opt -ffc $(vwrays -d -vf fish_up.vf) -e MF:2 -f reinhart.cal -bn Nrbins -b rbin -o ./images/patches/p%03d.hdr -m sky_glow -w test.oct
Best,
-Greg
From: Chris Humann <[email protected]>
Date: February 6, 2010 10:37:32 AM JST
Hello all,
I've been working through Axel Jacobs' excellent 'rtcontrib' tutorial (thank you Axel!!) and have hit a wall when it comes to using the 'reinhart.cal' file in lieu of the 'tregenza.cal file. Using the latter 'cal' file I get a complete bin of images for each patch:
$ vwrays -ff -vf fish_up.vf | rtcontrib @rtc.opt -ffc $(vwrays -d -vf fish_up.vf) -f tregenza.cal -b tbin -o ./images/patches/p%03d.hdr -m sky_glow -w test.oct
However when using the reinhart.cal file the images in the bin are only partially completed and listed as 'unfinished' when viewed with ximage (I'm pretty sure that I'm using the most recent reinhart.cal file; v 1.4 2009/12/09 21:34:23):
$ vwrays -ff -vf fish_up.vf | rtcontrib @rtc.opt -ffc $(vwrays -d -vf fish_up.vf) -e MF:2 -f reinhart.cal -b rbin -o ./images/patches/p%03d.hdr -m sky_glow -w test.oct
Has anyone come across similar results?
Thanks and Happy New Years to all.
Chris
Christian Humann ~ Associate
LOISOS + UBBELOHDE
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Ah. Sounds like you're running up against a system limit on the number of open file descriptors, which is typically set to 256. I don't know how to overcome this. The ulimit command should provide help, but I can't get it to behave for me.
When I use reinhart.cal, I don't usually produce separate component files for this reason.
Best,
-Greg
···
From: Christian Humann <[email protected]>
Date: February 6, 2010 12:42:28 PM PST
As always, thanks for the response Greg.
As suggested I tried adding the -bn option, however ;rtcontrib' still only generates 248 unfinished files with the '-e MF:2' option. All works fine with 'e MF:1'. I tried sending the files to a ramdisk, but still no joy.
I'm wondering if I did something funny when compiling the most recent head under OS X? Has anyone had similar results using Linux or Cygwin?
Thanks,
Chris H
I was following Axel's tutorial myself yesterday and had the same
problem that Chris describes. At least I managed to change my
file limit ...
Ah. Sounds like you're running up against a system limit on the number of
open file descriptors, which is typically set to 256. I don't know how to
overcome this. The ulimit command should provide help, but I can't get it
to behave for me.
On Mac OS X the max number of open files is limited to 256 per
user process. That's pretty low and not sufficient for any subdivision
of the Tregenza sky pattern.
To change the open files limit (on OS X!) I created a file
"/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
and I set the kernel limit with "sysctl -w kern.maxfiles=1024".
After a reboot I could set the shell's limit with "ulimit -n 1024".
This can go into your ".profile" if you're going to use it a lot.
I had a few odd observations regarding the missing or incomplete
patch files but that seems to be solved now (just tried it with MF:2
and it worked fine). I am still puzzled by the fact that creating all
these image doesn't seem to take much time at all (a few minutes
at max). When I tried the "vwrays | rtrace" example yesterday it
took half an hour to produce the image ...
Further down the tutorial you will have to replace the "seq"
command in Axel's scripts (not available on OS X). A simple
loop with a counter will do.
When I use reinhart.cal, I don't usually produce separate
component files for this reason.
Before Axel's tutorial I didn't know about reinhart.cal and the
use of genskyvec. It feels very elegant this way; better than
doing a separate calculation for defined sun positions like
daysim.
At the moment I just have a major problem with the quantities
in my simulation. At the end I achieve roughly 10% of Axel's
example values and the TFS values look just wrong ...
Anyway, a big thanks to Axel for this introduction.
Regards,
Thomas
···
On Sat, Feb 6, 2010 at 9:38 PM, Greg Ward <[email protected]> wrote:
Forget about that. It turned out that I had a mix of MF:2
and MF:1 files on my system. After rerunning all of the
steps with MF:2 I manage to get a similar result as Axel
did.
PS:
I rewrote the gen_yearvect script to allow the input of a
MF value on the command line and replace the failed
gendaylit calls with gensky. If anyone is interested I can
send it via PM. If you're following the tutorial you can't
use it, though, because other scripts still rely on the
preset names for directories etc.
Cheers,
Thomas
···
On Sun, Feb 7, 2010 at 9:54 AM, Thomas Bleicher <[email protected]> wrote:
At the moment I just have a major problem with the quantities
in my simulation. At the end I achieve roughly 10% of Axel's
example values and the TFS values look just wrong ...