Like so many other aspects of Radiance, the notion of view files has evolved to where it is, and changing things at this point would probably mean breaking a lot of scripts.
As Jack pointed out, rpict takes the LAST (not the first) view in a view file as the valid one. Technically, it takes the accumulation of view settings, so if for some reason a person had in their file:
VIEW= -vta -vh 180 -vv 150 -vp 10 5 3 -vd .1 .9 -.1
VIEW= -vtv -vh 50 -vv 35
The actual view used would be "-vtv -vh 50 -vv 35 -vp 10 5 3 -vd .1 .9 -.1"
Since rvu appends to a view file a complete specification, the earlier views are generally irrelevant. The reason rvu appends rather than overwrites this file is two-fold:
1) It is often handy to edit the view file to get back to a previous view that you realize you liked better than the final view you wrote there.
2) You can use the append feature and the fact that anything following the view file in the rvu "view" command is added at the end of the line makes for a convenient way to store key frames and time from the previous keyframe, which the spline.cal function can then use to interpolate animated paths -- see footnote at the end of this message.
Having rpict ignore all but the last view in a file was the most convenient way to get the behavior I wanted. If your wish is to have rpict render all views in the file instead, you can simply run it as:
rpict [options] -S 1 -o frame%02d.hdr octree < vlist.vf
Another nice thing about doing it this way is that you can start as many rpict processes as you have processors and you get to run your sequence in parallel. This is what rad does in fact, using also the -PP option to share memory as well.
Getting back to your suggested modification to rad's behavior, I expect it would cause some confusion and consternation for users who create their view files with rvu and overwrite previous views if they got multiple renderings they weren't expecting of views they didn't want. Also, I'd have to think up yet another naming scheme for the multiple output pictures, which I'm very reluctant to do.
-Greg
-Greg
Footnote:
···
=======
Using rvu to create key frame positions and interpolating these for a walk-through animation path:
(in rvu): view key.vf -t 1.5
(in rvu): [some view changes to get to the next key frame position]
(in rvu): view key.vf -t 2.5
etc.
The view file can then be converted to something usable with:
rcalc -i key.fmt -e '$1=px;$2=py;$3=pz;$4=dx;$5=dy;$6=dz;$7=vh;$8=vv;$9=t' \
> tabfunc Px Py Pz Dx Dy Dz Ah Av T > key.cal
Where "key.fmt" contains:
rvu -vtv -vp ${px} ${py} ${pz} -vd ${dx} ${dy} ${dz} -vu 0 0 1 -vh ${vh} -vv ${vv} -vo 0 -va 0 -vs 0 -vl 0 -t ${t}
Interpolating a path of 1000 frames can be done with something like:
cnt 1000 | rcalc -f key.cal -f spline.cal -o view.fmt -e 't=Ttot/999*$1' \
-s vt=v -e 'vux=0;vuy=0;vuz=1;vo=0;va=0;vs=0;vl=0' \
-e 'vpx=s(Px);vpy=s(Py);vpz=s(Pz);vh=s(Ah);vv=s(Av)' \
> animpath.vf
Both "spline.cal" and "view.fmt" are provided in ray/src/cal/cal/. This path can then be handed to ranimate for a nice walk-through sequence.
This is mostly from memory, so I may have messed up on a detail or two...