Hi!

I'm actually not an experienced PovRay user neither a modeler/animator 
in general.

My question is, however, that if I have an animated scene, then invoking 
PovRay separately for each and every frame results (or is it possible to 
result) in anything different from when I invoke PR for the whole 
animation once. I understand that when I invoke PR to render a single 
frame split up into multiple parts, then there may be artifacts at the 
edges of the parts due to anti-aliasing and similar effects. That's why 
I'm asking about splitting up animations - wondering whether there are 
algorithms in PR that imply that the whole animation is computed in one 
pass.

Are there any serious performance implications of such plit computing?

thx
mortee

Post a reply to this message

"Marton Fabo" <mor### [at] eikbmehu> wrote in message
news:404b97b5$1@news.povray.org...
>
> My question is, however, that if I have an animated scene, then invoking
> PovRay separately for each and every frame results (or is it possible to
> result) in anything different from when I invoke PR for the whole
> animation once. I understand that when I invoke PR to render a single
> frame split up into multiple parts, then there may be artifacts at the
> edges of the parts due to anti-aliasing and similar effects. That's why
> I'm asking about splitting up animations - wondering whether there are
> algorithms in PR that imply that the whole animation is computed in one
> pass.

There are a few ways this occurs... antialiasing and area_light cause a
random 'jitter' of the pixels unless you opt not to use the jittering. Also
'radiosity', 'media', and 'photons' could cause a flickering frame to frame.
In fact, normals, pigment patterns, objects, will do so too if the scale is
very small while they (or the camera) move. Saving rendering data (e.g.
radiosity, photons) isn't really useful for animations which should change
frame to frame.

So basically, to answer your question about animations/stills differing
algorithm, there is not any. POV-Ray doesn't do anything special to the
rendered output image for animations that it doesn't for non-animations or
vice versa. Each frame is just like a rendered still image. The randomness
of how pixels appear isn't completely controllable via any overall switch
either. Pixel randomness is somewhat beyond control aside from the
aforementioned 'jitter' keyword and using very high quality settings.

Hopefully I've answered completely and correctly enough. If not, someone
might come along with a more in-depth explanation.

-- 
Bob H.
http://www.3digitaleyes.com

Post a reply to this message

Hughes, B. wrote:

> So basically, to answer your question about animations/stills differing
> algorithm, there is not any. POV-Ray doesn't do anything special to the
> rendered output image for animations that it doesn't for non-animations or
> vice versa. Each frame is just like a rendered still image.

[...]

> Hopefully I've answered completely and correctly enough. If not, someone
> might come along with a more in-depth explanation.

So, if I break up an animation into frames and submit each one 
separately to a rendering farm basically results in the same as if it 
were submitted in one job. If that's the case, the answer is satisfying (:

byez
mortee

Post a reply to this message

Marton Fabo <mor### [at] eikbmehu> wrote in news:404cad88@news.povray.org:


> So, if I break up an animation into frames and submit each one 
> separately to a rendering farm basically results in the same as if it 
> were submitted in one job. If that's the case, the answer is
> satisfying (: 
> 
> 

That is the case and how we do it on our renderfarm.

-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

On Mon, 08 Mar 2004 18:30:01 +0100, Marton Fabo <mor### [at] eikbmehu>
wrote:

>So, if I break up an animation into frames and submit each one 
>separately to a rendering farm basically results in the same as if it 
>were submitted in one job. If that's the case, the answer is satisfying (:

Well, *almost*. You have to make sure that no frames depend on
anything from previous frames.

The most common case is with things that require a lot of parsing;
there the usual practice is to save the intermediate result (as valid
for the current frame) to a file, then in the next frame read that
file and avoid calculating everything again. Examples where this
approach is used are mostly physics simulations - particle systems,
kinematic or dynamic simulations (billiards, cloth...), planetary
systems, flocking algorithms etc.

It is also not uncommon to have some frame parse heavily and generate
for example a height field, some numerical data, a texture, or even a
whole .inc file, which are then reused as-is in further frames. An
example of this would be an animation where the camera flies over a
forest or grass field or such.

The last thing I can think of is more of a speculation than a real
application and concerns radiosity. POV-Ray uses a pretty intelligent
Monte-Carlo sampling algorithm for gathering radiosity samples which
means that only those parts of the image visible from the camera will
be sampled, thus saving a lot of unnecessary calculations. In
addition, POV-Ray allows to save and load radiosity data so that most
of the preliminary calculations are avoided. In effect this means that
if you want to render a fly-by or fly-through animation with
radiosity, you can save the radiosity data after each frame and load
it in the next frame. POV-Ray will then only perform the heavy
radiosity calculations where needed, i.e. in parts which were
previously outside the camera field of vision. Since in most such
animations the camera field of vision changes insignificantly from
frame to frame, this could lead to a significant speed-up of radiosity
calculations. Mind you, I haven't tried this but it sounds like a good
idea :)

Anyway, to get back to your original question, if you want to spread
an animation across multiple CPUs, then you will have to make sure
that you don't use the above techniques.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message