|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Is the radiosity data independent of the camera location?
>
> If yes, does it mean that you can get the same effect as in the
> "regular" radiosity used in scanline renderers, that is: Calculate radiosity
> once, render same scene from different camera locations many times?
>
AFAIK, no. It would only work only if the new image doesn't include areas of the
scene invisible in the original image.
First level radiosity samples are only taken at points hit by the camera (or
reflected/transmitted) rays, so for the rest of the scene radiosity information
would be isufficient. Of course there should usually be a fair amount of samples
generated during secondary bounces, which can be reused to speed up the process.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst wrote:
>
> Warp wrote:
> >
> > Is the radiosity data independent of the camera location?
> >
> > If yes, does it mean that you can get the same effect as in the
> > "regular" radiosity used in scanline renderers, that is: Calculate radiosity
> > once, render same scene from different camera locations many times?
> >
>
> AFAIK, no. It would only work only if the new image doesn't include areas of the
> scene invisible in the original image.
> First level radiosity samples are only taken at points hit by the camera (or
> reflected/transmitted) rays, so for the rest of the scene radiosity information
> would be isufficient. Of course there should usually be a fair amount of samples
> generated during secondary bounces, which can be reused to speed up the process.
But wouldn't secondary and tertiary bounces return lower values
than a primary bounce value ? If so then what value would it
add for speeding up the process ?
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39C### [at] peakeduee>, Margus Ramst
<mar### [at] peakeduee> wrote:
> AFAIK, no. It would only work only if the new image doesn't include
> areas of the scene invisible in the original image.
I think it will compute extra samples for areas that weren't sampled
before, so that isn't the problem. However, if the scene is dynamic, for
instance, if there is a ball rolling through it, things probably won't
work right. In other words, the only kind of animation you can do with
this method is one where only the camera moves.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
>
> But wouldn't secondary and tertiary bounces return lower values
> than a primary bounce value ? If so then what value would it
> add for speeding up the process ?
>
Frankly, I might have been wrong here. AFAICS they _could_ be reused if their
current recursion level is stored, but I don't know if it is.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> I think it will compute extra samples for areas that weren't sampled
> before, so that isn't the problem.
Yes, but you _will_ have to take extra samples if the viewpoint changes, unlike
in "real" radiosity where the entire scene is energy-balanced before rendering.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst <mar### [at] peakeduee> wrote:
: Yes, but you _will_ have to take extra samples if the viewpoint changes, unlike
: in "real" radiosity where the entire scene is energy-balanced before rendering.
On the other hand, calculating radiosity only where it's needed and not
everywhere saves rendering time and memory.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On the other hand, calculating radiosity only where it's needed and not
> everywhere saves rendering time and memory.
What if one were willing to invest the time and memory for calculating the
radiosity of the whole scene? Wouldn't that be cool? I mean, you process
once, and then you can do a flythrough throught any point of the scene as
many times as you want to, without having to reprocess. I would do it. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tony[B] <ben### [at] panamac-comnet> wrote:
: What if one were willing to invest the time and memory for calculating the
: radiosity of the whole scene? Wouldn't that be cool?
The whole scene? Even if it has things like infinite surfaces (eg. planes)?
Even in finite scenes it may spend days and consume gigabytes of disk
space for the entire scene.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The whole scene? Even if it has things like infinite surfaces (eg.
planes)?
> Even in finite scenes it may spend days and consume gigabytes of disk
> space for the entire scene.
Really? Wow. I didn't know it was such a tall order... Could it perhaps be
completely calculated for a bounded space?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" <ben### [at] panamac-comnet> wrote...
> > On the other hand, calculating radiosity only where it's needed and
not
> > everywhere saves rendering time and memory.
>
> What if one were willing to invest the time and memory for calculating the
> radiosity of the whole scene? Wouldn't that be cool? I mean, you process
> once, and then you can do a flythrough throught any point of the scene as
> many times as you want to, without having to reprocess. I would do it. :)
How would this save any calculation time? Let's say we go with the current
implementation, and set some options to make sure it doesn't take extra
samples if it doesn't need them. We do one fly-through of the scene,
keeping the data along the way. After that, we know that we've got all the
info we need for another fly-through, and not any extra. We can then do
another fly-through very quickly.
Also, if we wanted to do a fly-through backwards at that point, we could do
that, too. We might end up having to do more calculations to get the
back-sides of objects. But think about the situation where you never do the
backwards fly-through. If you had pre-calculated everything, you would have
done work that didn't need to be done. You would have "wasted" computation
time, and the whole process would have taken _longer_ (assuming you're using
the same algorithm in both cases).
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |