[Radiance-general] animation
atelier iebele abel
[email protected]
Tue, 07 May 2002 11:54:03 +0200
--------------74D1507D3B1A95F2484367A5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thanks Greg and Peter for your replies,
I tried your suggestions, while some already were taken into account. The
results are better, but not that good that my problem is solved (put it in
other words: it does not fit my application yet). Also rendering times are
very long now.
That is why I like to ask you something that is in my mind for over a year.
The general purpose I use Radiance for is presentation and design of
architecture and public exterior lighting. There is no other rendering tool
that offers me the flexibility and kind of images that Radiance produces. What
I also need from Radiance is the photometric correctness of the images, but I
always use the images in a sequence, comparing one image with the other, to
disccuss design issues. That means that the numerical representation of
lighting is less important for me as the 'look'. This allows me to work on
images with image processing tools, this actually destroys some of the
Radiance data, but makes the design better to communicate (for my purposes).
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.
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 ).
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)
As you understand, some hints are very much appreciated.
I think about these kind of hints:
-where in rpict.c are pixels stored into a file (or stdout)?
-Is it possible at that point to write the mentioned data to stdout also?
-What are the variables/pointers that hold these data?
The 2D processing of the resulting files will be my work (although I don't
know what kind of project I start here) and I like to share the results with
the 'community', when it finally works as we want.
I hope my questions are not to difficult or time consuming to answer. I would
be really _happy_ to experiment with this. I think it will result in a really
nice tool for video production environments (again, we will work on these
tools, I only need a good starting point for them).
Ok, this starts to get a long email, I hope you believe with me that the above
is worth trying, although it might have a very expiremental character in the
beginning.
Iebele
--------------74D1507D3B1A95F2484367A5
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Thanks Greg and Peter for your replies,
<p>I tried your suggestions, while some already were taken into account.
The results are better, but not that good that my problem is solved (put
it in other words: it does not fit my application yet). Also rendering
times are very long now.
<br>That is why I like to ask you something that is in my mind for over
a year.
<p>The general purpose I use Radiance for is presentation and design of
architecture and public exterior lighting. There is no other rendering
tool that offers me the flexibility and kind of images that Radiance produces.
What I also need from Radiance is the photometric correctness of the images,
but I always use the images in a sequence, comparing one image with the
other, to disccuss design issues. That means that the numerical representation
of lighting is less important for me as the 'look'. This allows me to work
on images with image processing tools, this actually destroys some of the
Radiance data, but makes the design better to communicate (for my purposes).
<p>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).
<br>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.
<p>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...):
<br>
<ul>
<li>
name of the modifier for the object this pixel represent (as a string)</li>
<li>
normal orientation of this object (float float float)</li>
<li>
position of the pixel in XYZ space (float float float)</li>
</ul>
<p><br>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.
<br>Also this kind of image data allows us to separate objects in one image,
to process them individually in 2D.
<p>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.
<br>Probably far more to achieve the results we really want. 2d/3d image
processing will take about 5 minutes or less per frame ).
<p>I already looked at rtrace, which seems to produce the kind of information
I need. Two problems arose when I looked at rtrace:
<p>1. I don't know where to start
<br>2. I think I prefer changing code in rpict (to use the -S option and
-vf option )
<br>3. I think I prefer changing code in rpict.c (to have a all in one
executable, instead of using scripts)
<p>As you understand, some hints are very much appreciated.
<br>I think about these kind of hints:
<br>-where in rpict.c are pixels stored into a file (or stdout)?
<br>-Is it possible at that point to write the mentioned data to stdout
also?
<br>-What are the variables/pointers that hold these data?
<p>The 2D processing of the resulting files will be my work (although I
don't know what kind of project I start here) and I like to share the results
with the 'community', when it finally works as we want.
<p>I hope my questions are not to difficult or time consuming to answer.
I would be really _happy_ to experiment with this. I think it will
result in a really nice tool for video production environments (again,
we will work on these tools, I only need a good starting point for them).
<p>Ok, this starts to get a long email, I hope you believe with me that
the above is worth trying, although it might have a very expiremental character
in the beginning.
<br>
<p>Iebele
<br>
<br>
<br>
<br> </html>
--------------74D1507D3B1A95F2484367A5--