[Radiance-general] Re: proposed feature: interpreting view names in rad

[Greg Ward]

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...