Rtcontrib inside of script

Greetings from inside the octree.

I'm trying to make a script that will as one of its steps call rtcontrib and
compute a set of daylight coefficient images, based on Axel Jacobs'
tutorial.

From a BASH prompt, if I set up some view options (in $vw) and render

options (in a file called rtc.opt), the following command...

vwrays -ff $vw | rtcontrib @rtc.opt -fo -ffc $(vwrays -d $vw) -f
tregenza.cal -b tbin -o images/patches/treg%03d.hdr -m sky_glow model_dc.oct

...works. I get treg[000-145].hdr in my images/patches directory. This is
good.

But if I try to put the same construct into a Ruby script (note slightly
different variable names), the following command...

vwrays -ff #{vw} | rtcontrib #{rtc} -n 15 -ffc $(vwrays -d #{vw}) -fo -f
tregenza.cal -b tbin -o #{Dir.pwd}/output/dc/test/treg%03d.hdr -m sky_glow
model_dc.oct"

...does not work. Fail. Boo. What I end up with is just a single
treg000.hdr. Any ideas why? I have a feeling the system doesn't like the
vwrays call inside of the rtcontrib call. Anyone know how to pass this
through from Ruby without a problem?

Hi Rob!

...does not work. Fail. Boo. What I end up with is just a single
treg000.hdr. Any ideas why? I have a feeling the system doesn't like the
vwrays call inside of the rtcontrib call. Anyone know how to pass this
through from Ruby without a problem?

I am calling rtcontrib from inside bash-scripts, and it works fine. Probably this is some Ruby-specific problem. I tend to insert a print-command right in front of the command call to see whether all variable names and such get resolved as expected. In my experience, quoting and typos are the worst origins of errors in interpreted scripts (and the reason people like compiled languages doing much more checks).

Cheers, Lars.

Hi Lars,

Yeah, I have a similar check in my script right now to debug this, and the
variables are all being expanded correctly. I think the error lies further
up the chain now. I'll let ya know what I find out!

- Rob

···

On 8/19/10 4:24 AM, "Lars O. Grobe" <[email protected]> wrote:

Hi Rob!

...does not work. Fail. Boo. What I end up with is just a single
treg000.hdr. Any ideas why? I have a feeling the system doesn't like the
vwrays call inside of the rtcontrib call. Anyone know how to pass this
through from Ruby without a problem?

I am calling rtcontrib from inside bash-scripts, and it works fine.
Probably this is some Ruby-specific problem. I tend to insert a
print-command right in front of the command call to see whether all
variable names and such get resolved as expected. In my experience,
quoting and typos are the worst origins of errors in interpreted scripts
(and the reason people like compiled languages doing much more checks).

Cheers, Lars.

It's probably a quoting problem. Does Ruby perhaps process "%03d" itself? You may need to quote the '%'.

Randolph

···

On 2010-08-18 14:45:39 -0700, Guglielmetti, Robert said:

Greetings from inside the octree.

I'm trying to make a script that will as one of its steps call rtcontrib and
compute a set of daylight coefficient images, based on Axel Jacobs'
tutorial.

From a BASH prompt, if I set up some view options (in $vw) and render

options (in a file called rtc.opt), the following command...

vwrays -ff $vw | rtcontrib @rtc.opt -fo -ffc $(vwrays -d $vw) -f
tregenza.cal -b tbin -o images/patches/treg%03d.hdr -m sky_glow model_dc.oct

...works. I get treg[000-145].hdr in my images/patches directory. This is
good.

But if I try to put the same construct into a Ruby script (note slightly
different variable names), the following command...

vwrays -ff #{vw} | rtcontrib #{rtc} -n 15 -ffc $(vwrays -d #{vw}) -fo -f
tregenza.cal -b tbin -o #{Dir.pwd}/output/dc/test/treg%03d.hdr -m sky_glow
model_dc.oct"

...does not work. Fail. Boo. What I end up with is just a single
treg000.hdr. Any ideas why? I have a feeling the system doesn't like the
vwrays call inside of the rtcontrib call. Anyone know how to pass this
through from Ruby without a problem?

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs