I am rendering a medium piece (8k x 8k) using rpiece on a
cluster of Opteron processors, and I have used "rpiece -F"
to create the sync file and start 4 processes. I even used
"rpiece -R" to restart the job once. (Thanks to Giulio
Antonutto for helping me get started.)
Anyways, there are two parts of the 64 subdivisions of the
image that are giving me trouble. I invoke them piece-at-a-
time:
% more argsN
-X 8 -Y 8 -t 600 @vp11 @opts -x 8000 -y 8000 -o img13.pic scene.oct
% echo 2 0 | rpiece @argsN
rpict: warning - no light sources found
FRAME 1: -vta -vp 1.3 -1.8 1.1 -vd -0.524211 0.708567 -0.472373
-vu 0 0 1 -vh 5.45455 -vv 5.45455 -vo 0 -va 0 -vs -1.5 -vl -3.5
rpict: 0 rays, 0.00% after 0.000u 0.000s 0.000r hours on str2
rpict: consistency - bad ray direction in inithemi
rpiece: read error from rpict
Command exited with non-zero status 1
I understand the "no light sources" error: I illuminate with
the sky dome only. It's the "bad ray direction" that is causing
me problems.
Now, I had previously seen this error when I rendered a smaller
version with rpict. I simply re-ran rpict with the "-ro" recover-
overwrite option. But it seems that the "rpiece -R" recover
option restarts any incomplete subsections instead of continuing
where rpict left off. So, every time I try to patch the missing
pieces, I get the same error at (presumably) the same place.
So, can rpiece recover in a pixel-wise sense like rpict, or,
how can I find out what command sequence (including rpict and
not rpiece) can render those bad patches and put them in the
final image.
Or, is there any rpiece option that will ignore the "bad ray
direction" error, or mitigate its effects?
Thank you.
Mark
Hi Mark,
The "bad ray direction" is a serious error, caused either by a miscompiled binary or a corrupted ambient file. Assuming it's the latter, you should try deleting (or renaming) your ambient file before attempting recovery. A corrupted ambient file is usually the result of a faulty NFS lock manager. See previous posts on this topic.
-Greg
···
From: Mark Stock <[email protected]>
Date: May 27, 2004 8:25:40 AM PDT
I am rendering a medium piece (8k x 8k) using rpiece on a
cluster of Opteron processors, and I have used "rpiece -F"
to create the sync file and start 4 processes. I even used
"rpiece -R" to restart the job once. (Thanks to Giulio
Antonutto for helping me get started.)
Anyways, there are two parts of the 64 subdivisions of the
image that are giving me trouble. I invoke them piece-at-a-
time:
% more argsN
-X 8 -Y 8 -t 600 @vp11 @opts -x 8000 -y 8000 -o img13.pic scene.oct
% echo 2 0 | rpiece @argsN
rpict: warning - no light sources found
FRAME 1: -vta -vp 1.3 -1.8 1.1 -vd -0.524211 0.708567 -0.472373
-vu 0 0 1 -vh 5.45455 -vv 5.45455 -vo 0 -va 0 -vs -1.5 -vl -3.5
rpict: 0 rays, 0.00% after 0.000u 0.000s 0.000r hours on str2
rpict: consistency - bad ray direction in inithemi
rpiece: read error from rpict
Command exited with non-zero status 1
I understand the "no light sources" error: I illuminate with
the sky dome only. It's the "bad ray direction" that is causing
me problems.
Now, I had previously seen this error when I rendered a smaller
version with rpict. I simply re-ran rpict with the "-ro" recover-
overwrite option. But it seems that the "rpiece -R" recover
option restarts any incomplete subsections instead of continuing
where rpict left off. So, every time I try to patch the missing
pieces, I get the same error at (presumably) the same place.
So, can rpiece recover in a pixel-wise sense like rpict, or,
how can I find out what command sequence (including rpict and
not rpiece) can render those bad patches and put them in the
final image.
Or, is there any rpiece option that will ignore the "bad ray
direction" error, or mitigate its effects?
Thank you.
Mark
Thanks for your quick reply, Greg. I have more information
that may help our understanding.
The other options that the rendering used are
-ps 1 -ab 2 -aa 0 -ad 8 -as 0 -dj 0.7 -st 0.05
so I'm guessing it's not the ambient file. It is possible that
with all of the compiler optimizations that I used, I cut one
too many corners.
But how does this explain the fact that I could always
"rpict -ro" and it would continue where it left off, creating
a fine image in the end?
Is there some way to find out what compile-time options
I used? Is there a file in ray/src that contains that
information?
Also, I seem to be unable to search the radiance-online
archives for a whole phrase. How is this done?
Mark
···
On Thu, 27 May 2004, Greg Ward wrote:
The "bad ray direction" is a serious error, caused either by a
miscompiled binary or a corrupted ambient file. Assuming it's the
latter, you should try deleting (or renaming) your ambient file before
attempting recovery. A corrupted ambient file is usually the result of
a faulty NFS lock manager. See previous posts on this topic.
-Greg
> From: Mark Stock <[email protected]>
> Date: May 27, 2004 8:25:40 AM PDT
>
> I am rendering a medium piece (8k x 8k) using rpiece on a
> cluster of Opteron processors, and I have used "rpiece -F"
> to create the sync file and start 4 processes. I even used
> "rpiece -R" to restart the job once. (Thanks to Giulio
> Antonutto for helping me get started.)
>
> Anyways, there are two parts of the 64 subdivisions of the
> image that are giving me trouble. I invoke them piece-at-a-
> time:
>
> % more argsN
> -X 8 -Y 8 -t 600 @vp11 @opts -x 8000 -y 8000 -o img13.pic scene.oct
>
> % echo 2 0 | rpiece @argsN
> rpict: warning - no light sources found
> FRAME 1: -vta -vp 1.3 -1.8 1.1 -vd -0.524211 0.708567 -0.472373
> -vu 0 0 1 -vh 5.45455 -vv 5.45455 -vo 0 -va 0 -vs -1.5 -vl -3.5
> rpict: 0 rays, 0.00% after 0.000u 0.000s 0.000r hours on str2
> rpict: consistency - bad ray direction in inithemi
> rpiece: read error from rpict
> Command exited with non-zero status 1
>
> I understand the "no light sources" error: I illuminate with
> the sky dome only. It's the "bad ray direction" that is causing
> me problems.
>
> Now, I had previously seen this error when I rendered a smaller
> version with rpict. I simply re-ran rpict with the "-ro" recover-
> overwrite option. But it seems that the "rpiece -R" recover
> option restarts any incomplete subsections instead of continuing
> where rpict left off. So, every time I try to patch the missing
> pieces, I get the same error at (presumably) the same place.
>
> So, can rpiece recover in a pixel-wise sense like rpict, or,
> how can I find out what command sequence (including rpict and
> not rpiece) can render those bad patches and put them in the
> final image.
>
> Or, is there any rpiece option that will ignore the "bad ray
> direction" error, or mitigate its effects?
>
> Thank you.
>
> Mark
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Mark,
Yeah, I had similar problems with the gcc optimizer when I tried it. If you used makeall to set the options rather than doing it by hand on the command line, you should be able to find your settings in the "rmake" script that gets put in your Radiance executables directory. benchmark speeds without simultaneously introducing some nefarious bug in the renderer. I spent some time on it, but gave up trying to figure out where the calculations had gone south. From what I've seen with gcc problems in the past, they can be incredibly subtle. (At one point, the optimizer was giving incorrect arithmetic results inside a simple loop -- 2+2 = 5 and that sort of nonsense.)
I can't explain why rpict would be able to recover using the -ro option where rpiece cannot. When code doesn't compile right, it's anybody's guess as to what's going on.
I also don't know how to search the archives for phrases -- maybe Peter A-B or someone familiar with our system could help with that one?
-Greg
···
From my experiments under OS X at least, I couldn't approach your
From: Mark Stock <[email protected]>
Date: May 27, 2004 9:57:16 AM PDT
Thanks for your quick reply, Greg. I have more information
that may help our understanding.
The other options that the rendering used are
-ps 1 -ab 2 -aa 0 -ad 8 -as 0 -dj 0.7 -st 0.05
so I'm guessing it's not the ambient file. It is possible that
with all of the compiler optimizations that I used, I cut one
too many corners.
But how does this explain the fact that I could always
"rpict -ro" and it would continue where it left off, creating
a fine image in the end?
Is there some way to find out what compile-time options
I used? Is there a file in ray/src that contains that
information?
Also, I seem to be unable to search the radiance-online
archives for a whole phrase. How is this done?
Mark