[Radiance-general] Re: animation

[Greg Ward]

> From: atelier iebele abel <atelier@iebele.nl>:

> Back to the animation-issue. It takes too much time to render 
> animations for
> our application, because we use very large geometry, we use a lot of 
> light
> sources,  we have to render several minutes, we only (?) have 4 cpu's
> available on Linux and we have to produce very good looking images for 
> our
> customers (they expect images like they have seen on tv/dvd : sharp 
> sharper
> sharpest).
> To survive the competition using Radiance (we are using Radiance daily, 
> so we
> really don't want to work with something else) we need another 
> approach, and
> we are willing to spent our time to get it work.

I don't know about your country, but in the U.S., computers are a whole 
lot cheaper
than people, and it might be worthwhile to invest in a stack of Linux 
boxes to run
your animations -- Charles Ehrlich while he was still at LBNL put a 
tower together
last year with 9 CPUs and a disk array for less than $15K US.

> Taken the above into account, I and my partner are thinking about an 
> image
> format like the radiance .pic, that is rendered without ambient bounces 
> (-ab
> 0). In this (or additional) image format we also like to have the 
> following
> data per pixel (ok, these images take lots of diskspace...):
>
>    * name of the modifier for the object this pixel represent (as a 
> string)
>    * normal orientation of this object (float float float)
>    * position of the pixel in XYZ space (float float float)
>
> With this information per pixel (maybe I need more info in te future) 
> we think
> we can produce an automated proces in enhancing radiance pictures that 
> are
> rendered without radiosity. This process is 2D image processing, using 
> some 3d
> data that is 'stored' with the pixel.
> Also this kind of image data allows us to separate objects in one 
> image, to
> process them individually in 2D.
>
> We think we can speed up animation times using a combination of 3d and 
> 2d (
> rendering my scene with -ab 0 takes about 9 minutes on 4 times PAL res.
> against 3 hours with a nice radiosity as you suggested.
> Probably far more to achieve the results we really want. 2d/3d image
> processing will take about 5 minutes or less per frame ).

This reminds me a lot of Ken Perlin's classic 1985 Siggraph paper, where
he uses his noise function with similar pixel information to sythesize 
images.

> I already looked at rtrace, which seems to produce the kind of 
> information I
> need. Two problems arose when I looked at rtrace:
>
> 1. I don't know where to start
> 2. I think I prefer changing code in rpict (to use the -S option and -vf
> option )
> 3. I think I prefer changing code in rpict.c (to have a all in one 
> executable,
> instead of using scripts)

I strongly suggest you use rtrace, as it is already designed and 
optimized
for this type of output.  When you use the -fff and -omNp options, you 
will
avoid all recursive ray calls and get a very fast calculation.  The rays
for any desired view can be generated with the vwrays command (new
with 3.4).  To generate the 10th view in the file "anim.vf", you could 
use:

% sed -n 10p anim.vf > frame10.vf
% vwrays -ff -vf frame10.vf -pa 0 -x 3072 -y 2304 \
	| rtrace -x 3072 -y 2304 -fff -omNp anim.oct > frame10.data

See the vwrays man page for more details and examples.

-Greg