[Radiance-general] Re: animation

[atelier iebele abel]

As I wrote in my previous message : "I would be really _happy_  to
experiment with this". Now I am _HAPPY_!

Thanks Greg and Carsten for your replies.
This morning the first thing I did was trying Greg's command line suggestions,
I changed the output to ASCII to explore the results, and: this is exactly
what I meant!
I will work on this as much as time permits me to do, and I will share the
results. This might take a while, therefore I will thank you both at this
moment very, very much.
Carsten, also your suggestions where to look in rpict (ray.h) are very
helpfull. For this moment I will start with Greg's suggestion. The syntax of
the command line is far less complicated as I expected, so this will work for
now.
I changed Greg's line a little, so the output per pixel now is:
modifier-name value normal position
( vwrays -ff -vf view01.vf -pa 0 -x 1000 -y 1000  | rtrace -x 1000 -y 1000
-fff -omvNp model.oct > test.data ).

This is where I can start from, I let you know when I have some results (or
questions), but for now there is a lot to experiment with.

Thanks a lot!

Iebele


Greg Ward wrote:

> > 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
>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general@radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-general