POV-Ray : Newsgroups : povray.general : Render frames backwards Server Time
5 Aug 2024 10:25:05 EDT (-0400)
  Render frames backwards (Message 11 to 20 of 40)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Jaime Vives Piqueres
Subject: Re: Render frames backwards
Date: 14 Nov 2002 07:07:58
Message: <3dd3921d@news.povray.org>
Thorsten Froehlich wrote:
> So you suggest one renders the even and another the odd indexed frames? 
> Or do you suggest that the beginning and the end of a sequence take long
> and you divide them such that one renders from beginning to the middle of
> the
> sequence and the other from the end to the middle of the sequence?  Why
> would it have to work backwards in either case?  The speed would be the
> same regardless of sequence direction!

  IMHO, in the case you proposed, one of the computers can finish before 
the other, because the first half renders fast or viceversa, so one of the 
computers becomes iddle while the other is still rendering, and there are 
still pending frames. With the other solution (starting at both ends), no 
computer is iddle: both finish at the same time, so they finish the task 
before undoubtely (except in perfectly balanced animations where all the 
frames take the same amount of time to render).
 
> No, this would not distribute perfectly regardless of the image except
> trivial cases.  In fact it would be very far away from perfect
> distribution as each and every pixel can take a "random" amount of time.

  Again wrong, IMHO. Warp means perfect distribution of rendering power not 
perfect distribution of pixels rendered. Again, starting at both ends 
eliminates the posibility of on CPU finish before the other and becoming 
iddle.

  Of course, I always do this techniques "manually", and never would have 
requested a new feature myself... ;)


-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Render frames backwards
Date: 14 Nov 2002 08:39:55
Message: <3dd3a7ab@news.povray.org>
In article <3dd38dbe$1@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk>
wrote:

> Huh? I think you're missing the point.

No:

> 34, 43,11, 76, 32, 2, 23, 73, 83, 23, 76, 63, 31,63,68,65
>
> Numbers 1 to 8 add to 294, 8 to 16 add to 472. Without knowing the render time
> of each frame prior to rendering, the only way I can ensure that both renders
> finish at the same time is to start one render at one end of the sequence, and
> the other render at the other end of the sequence.

You may have noticed that I gave _two_ ways to do it.  Either even and odd
frames or splitting in the middle.

BTW, your method will not make sure both renders end at the same time.  To
the contrary, starting from both ends has exactly the same properties as
starting anywhere else because you can never know that the last frame
rendered in one instance of POV-Ray will not take longer than the last frame
of the other instance's "last" frame being rendered.

In essence, if you seek perfect (or close to that) distribution of load on
two systems with different speed, you would have to use really long
sequences which have no "exotic" frames that take much longer or much less
time than the average.  Otherwise such a simple attempt of load distribution
will simply not give you any advantage at all.

However, a simple way to achieve some distribution is to use POV-Ray's
"continue" feature.  While probably (I would have to try) rendering the
animation directly won't work, creating a simple batch file that sets the
external "clock" directly will perform exactly as it should as long as the
result images are kept in the same directory on one system and that systems
prevents files to be opened by multiple processes for writing simultaneously
(which should be the default behavior, so there should be no problem).  If
you now start POV-Ray with the continue option on both systems and share the
result image directory, POV-Ray will skip rendered images and fail on
partially rendered images (the other instance is rendering it already).
While not optimal, this scales much better than just starting a render from
the end and one from the beginning -- you can use more than just two
systems.  In fact this is so trivial, it should be possible to do it
comfortably with a DOS-style shell scripting - you would not even have to
calculate the clock values yourself but could leave it to the shell script.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Render frames backwards
Date: 14 Nov 2002 08:42:42
Message: <3dd3a852@news.povray.org>
In article <3dd3921d@news.povray.org> , Jaime Vives Piqueres 
<jai### [at] ignoranciaorg>  wrote:

>> So you suggest one renders the even and another the odd indexed frames?
>> Or do you suggest that the beginning and the end of a sequence take long
>> and you divide them such that one renders from beginning to the middle of
>> the
>> sequence and the other from the end to the middle of the sequence?  Why
>> would it have to work backwards in either case?  The speed would be the
>> same regardless of sequence direction!
>
>   IMHO, in the case you proposed, one of the computers can finish before
> the other, because the first half renders fast or viceversa, so one of the
> computers becomes iddle while the other is still rendering, and there are
> still pending frames. With the other solution (starting at both ends), no
> computer is iddle: both finish at the same time, so they finish the task
> before undoubtely (except in perfectly balanced animations where all the
> frames take the same amount of time to render).

Hmm, why did you as well as Tom manage to completely miss that I queried
_two_ possible solutions?  I mean, the very first sentence is crystal clear.
And note that I did not proposed them as solution but _asked_ which one Warp
is talking about.  There are questionmarks at the end...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Render frames backwards
Date: 14 Nov 2002 08:43:32
Message: <3dd3a884@news.povray.org>
In article <3dd38a52@news.povray.org> , "Andrew Cocker" 
<mai### [at] andrewcockercouk> wrote:

> You are assuming that both my computers are as fast as each other. They're
> not. One is much slower, but I don't want to have to calculate/guestimate how
> many frames to give each PC.

Well, if one is much slower, is it really worth separating the work at all?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Andrew Cocker
Subject: Re: Render frames backwards
Date: 14 Nov 2002 08:52:04
Message: <3dd3aa84$1@news.povray.org>
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dd3a884@news.povray.org...

> Well, if one is much slower, is it really worth separating the work at all?

Yes. POV runs on lower priority on my main PC, and if I have other tasks to perform,
such as
mpeg encoding, I have to let them run on a higher priority. When they are completed,
POV will
use all the processing power again. However, during the video encode, POV has done
hardly any
rendering. My spare PC has made useful progress.

Every little helps.

Andy Cocker


Post a reply to this message

From: Jaime Vives Piqueres
Subject: Re: Render frames backwards
Date: 14 Nov 2002 09:23:01
Message: <3dd3b1c5@news.povray.org>
Thorsten Froehlich wrote:

> In article <3dd3921d@news.povray.org> , Jaime Vives Piqueres
> <jai### [at] ignoranciaorg>  wrote:
> 
>>> So you suggest one renders the even and another the odd indexed frames?
>>> Or do you suggest that the beginning and the end of a sequence take long
>>> and you divide them such that one renders from beginning to the middle
>>> of the
>>> sequence and the other from the end to the middle of the sequence?  Why
>>> would it have to work backwards in either case?  The speed would be the
>>> same regardless of sequence direction!
>>
>>   IMHO, in the case you proposed, one of the computers can finish before
>> the other, because the first half renders fast or viceversa, so one of
>> the computers becomes iddle while the other is still rendering, and there
>> are still pending frames. With the other solution (starting at both
>> ends), no computer is iddle: both finish at the same time, so they finish
>> the task before undoubtely (except in perfectly balanced animations where
>> all the frames take the same amount of time to render).
> 
> Hmm, why did you as well as Tom manage to completely miss that I queried
> _two_ possible solutions?  I mean, the very first sentence is crystal
> clear. And note that I did not proposed them as solution but _asked_ which
> one Warp
> is talking about.  There are questionmarks at the end...

  Sorry, my fault for quoting the wrong message. I was talking about this 
proposal (which reading what I wrote seems clear):

>>How about taking the much simpler approach of just starting the second one
>>in the middle?  Kind of more logical...


-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org


Post a reply to this message

From: Ken
Subject: Re: Render frames backwards
Date: 14 Nov 2002 09:38:02
Message: <3DD3B553.C37419D9@pacbell.net>
Jaime Vives Piqueres wrote:
> 
> Thorsten Froehlich wrote:
> > So you suggest one renders the even and another the odd indexed frames?
> > Or do you suggest that the beginning and the end of a sequence take long
> > and you divide them such that one renders from beginning to the middle of
> > the
> > sequence and the other from the end to the middle of the sequence?  Why
> > would it have to work backwards in either case?  The speed would be the
> > same regardless of sequence direction!
> 
>   IMHO, in the case you proposed, one of the computers can finish before
> the other, because the first half renders fast or viceversa, so one of the
> computers becomes iddle while the other is still rendering, and there are
> still pending frames. With the other solution (starting at both ends), no
> computer is iddle: both finish at the same time, so they finish the task
> before undoubtely (except in perfectly balanced animations where all the
> frames take the same amount of time to render).

How can a second instance of POV-Ray possibly know exactly which frames had
been rendered by the first instance. Backward frame rendering on the second
instance would make no difference as neither instance knows what the other is
doing and couldn't possibly know when to stop in the theoretical middle.
So, as Thorsten already mentioned, it won't matter if you start the second
instance from the middle or the end becasue the two instances have no way
to track and communicate what the other instance has completed. The program
would have to be modified to allow this idea to work and no matter what
you do you will never acheive a perfect load balance with each machine
stopping at exactly the same time.


-- 
Ken Tyler


Post a reply to this message

From: ABX
Subject: Re: Render frames backwards
Date: 14 Nov 2002 09:53:52
Message: <csd7tucrttb1ofvjdrkpo1c6sqhfa9kt0t@4ax.com>
On Thu, 14 Nov 2002 06:38:11 -0800, Ken <tyl### [at] pacbellnet> wrote:
> How can a second instance of POV-Ray possibly know exactly which frames had
> been rendered by the first instance.

Not perfect solution but perhaps something like
  #if(file_exist(...))
    #error "seems this frame was already rendered so no more frames"
  #end
at the end of script. Of course finding name of frames is not trivial thing.

ABX


Post a reply to this message

From: Rafal 'Raf256' Maj
Subject: Re: Render frames backwards
Date: 14 Nov 2002 10:02:30
Message: <Xns92C6A284D1B7Araf256com@204.213.191.226>
"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3dd36e60$1@news.povray.org 

> How about taking the much simpler approach of just starting the second
> one in the middle?  Kind of more logical...

What if computers don't have equal speed, or some frames took longer to 
render then others ? It's a good example where my [not-yet-written] overlay  
for remote rendering would be usefull ;)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M


Post a reply to this message

From: Andrew Cocker
Subject: Re: Render frames backwards
Date: 14 Nov 2002 10:28:34
Message: <3dd3c122@news.povray.org>
"Ken" <tyl### [at] pacbellnet> wrote in message news:3DD3B553.C37419D9@pacbell.net...
> How can a second instance of POV-Ray possibly know exactly which frames had
> been rendered by the first instance. Backward frame rendering on the second
> instance would make no difference as neither instance knows what the other is
> doing and couldn't possibly know when to stop in the theoretical middle.
> So, as Thorsten already mentioned, it won't matter if you start the second
> instance from the middle or the end becasue the two instances have no way
> to track and communicate what the other instance has completed. The program
> would have to be modified to allow this idea to work and no matter what
> you do you will never acheive a perfect load balance with each machine
> stopping at exactly the same time.

The user would cancel one or both instances when he/she sees that the 'middle' point
has
passed, and there are no more frames to be rendered. If the 'middle' point is passed
and the
user is not at the pc, then some frames are duplicated on each computer. These can
easily be
deleted.

Andy Cocker


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.