 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Forgive me if this has been asked before, but is it possible, when rendering on 2
machines, to
have the second machine start at the last frame, and work towards frame 1, so both
machines
meet each other at some point? Using something like +kff400 +sf400 +ef1 (which doesn't
work)
Obviously, there are some scenes that will break with this method (some particle
systems etc),
but I'd like the option to do it.
If not, can this be implemented in the next MegaPOV please?
All the best,
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 14 Nov 2002 01:46:24 -0000, "Andrew Cocker" <mai### [at] andrewcocker couk>
wrote:
> If not, can this be implemented in the next MegaPOV please?
Hmm, yes, I think it could be usefull from time to time.
Would be Frame_Step=Integer option sufficient?
Something like
Frame_Step=1 (default-forward)
Frame_Step=-1 (backward)
Frame_Step=0 (wrong value)
I will try. But I think you can use some workaround already. Just add
Declare=Direction=1 or Declare=Direction=0 in settings and then use
#if(Direction=1)
#declare Current_Frame=frame_number;
#else
#declare Current_Frame=calculated_reversed_frame_number;
#end
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How about setting an "Internal_Clock" running along with
the clock in one animation, and Internal_Clock=1-clock;
in the second?
And, just as a little sidenote, Rune's System would be
able to calculate frames backward like that if set
correctly, although it will have to reparse the entire
batch again and again for each frame of the backwards
animation, and, once its released, my system is capable
of that, which doesn't use I/O for data-tracking and
uses an algorithmic approach to particle generation, much
like Chris' Colefax SprayGen, but more advanced.
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
> Forgive me if this has been asked before, but is it possible, when
rendering on 2 machines, to
> have the second machine start at the last frame, and work towards frame 1,
so both machines
> meet each other at some point? Using something like +kff400 +sf400 +ef1
(which doesn't work)
>
> Obviously, there are some scenes that will break with this method (some
particle systems etc),
> but I'd like the option to do it.
>
> If not, can this be implemented in the next MegaPOV please?
>
> All the best,
>
> Andy Cocker
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 14 Nov 2002 09:07:50 +0100, "Tim Nikias" <tim### [at] gmxde> wrote:
> Internal_Clock=1-clock;
Internal_Clock = final_clock - (clock - initial_clock);
And what about cyclic animations ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dd30061@news.povray.org> , "Andrew Cocker"
<mai### [at] andrewcockercouk> wrote:
> Forgive me if this has been asked before, but is it possible, when
> rendering on 2 machines, to
> have the second machine start at the last frame, and work towards frame 1,
> so both machines
> meet each other at some point? Using something like +kff400 +sf400 +ef1
> (which doesn't work)
>
> Obviously, there are some scenes that will break with this method (some
> particle systems etc),
> but I'd like the option to do it.
>
> If not, can this be implemented in the next MegaPOV please?
How about taking the much simpler approach of just starting the second one
in the middle? Kind of more logical...
Apart from that, right now nothing keeps you from writing a batch file and
simply set "clock".
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <bfl6tusuk70dfht3spv6p2aodskvvsid08@4ax.com> , ABX
<abx### [at] abxartpl> wrote:
> I will try. But I think you can use some workaround already. Just add
> Declare=Direction=1 or Declare=Direction=0 in settings and then use
Yes, see my other message. Simple solutions are usually much better...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> How about taking the much simpler approach of just starting the second one
> in the middle? Kind of more logical...
I think that the idea is that if one computer starts from the beginning
and the other from the end, the rendering time is distributed optimally
if not all frames take the same amount of time to render. For example, if
the frames at the first half take longer to render than the ones in the
second half, then no time will be wasted when the second computer gets its
job done while the first one still has a long way to go.
Btw, the same idea can be applied when rendering a single image in
a computer with two processors: One processor renders normally, the other
in reverse order. When they reach the same pixel, they stop. This distributes
the rendering effort perfectly, regardless of the image.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dd37767@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> I think that the idea is that if one computer starts from the beginning
> and the other from the end, the rendering time is distributed optimally
> if not all frames take the same amount of time to render. For example, if
> the frames at the first half take longer to render than the ones in the
> second half, then no time will be wasted when the second computer gets its
> job done while the first one still has a long way to go.
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!
> Btw, the same idea can be applied when rendering a single image in
> a computer with two processors: One processor renders normally, the other
> in reverse order. When they reach the same pixel, they stop. This distributes
> the rendering effort perfectly, regardless of the image.
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.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dd37fa3@news.povray.org...
> 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!
>
> > Btw, the same idea can be applied when rendering a single image in
> > a computer with two processors: One processor renders normally, the other
> > in reverse order. When they reach the same pixel, they stop. This distributes
> > the rendering effort perfectly, regardless of the image.
>
> 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.
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.
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dd37fa3@news.povray.org...
>
> 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!
>
Huh? I think you're missing the point. As far as I can see, starting one render
from the last frame and another from the first frame is the only way to ensure
the best distribution of work. Take 16 random numbers between 1 and 100 and
place them in sequence:
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.
> > Btw, the same idea can be applied when rendering a single image in
> > a computer with two processors: One processor renders normally, the other
> > in reverse order. When they reach the same pixel, they stop. This
distributes
> > the rendering effort perfectly, regardless of the image.
>
> 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.
Distribute perfectly in terms of time, not in terms of percentage of image
rendered.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dd3a7ab@news.povray.org...
> In article <3dd38dbe$1@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk>
> wrote:
>
>
> You may have noticed that I gave _two_ ways to do it. Either even and odd
> frames or splitting in the middle.
>
But neither of these work if, in the case of even and odd, alternate images take
significantly different amount of times to render (odd frames use media, even
don't), and in the case of splitting in the middle, if the second half of the
sequence is significantly slower or faster than the first half (or, needless to
say, if one PC is slower than the other).
The point with starting at opposite ends is that if the final frame takes as
long as all the other frames put together (either because it's running on a
slower machine, or just becuase of the nature of the image), then one
render-instance renders only one image, and the other render-instance renders
the rest.
I think the misunderstanding here is that a) I don't propose that each
render-instance should render the same number of frames and b) I don't propose
that either render-instance "knows" when to stop - it would be up to the user to
note that instance-a had rendered images 1-20 and that instance-b had rendered
images 30-21 and that therefore the render could now be stopped.
Nor, btw, do I propose that this would lead to an "exact" distribution - one
instance would invariably finish its final frame before the other, whatever
frame that might be.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
The two processes must communicate in order for them to know where to stop.
That is, when one process has rendered a frame and is ready to start the
next frame, it asks the other process if that frame is free. If the other
process answers "yes", then it proceeds, else it stops.
And yes, communication between two processes suffer from all the
mutual exclusion problems typical to parallel processing, and if not
well done, the two processes might start rendering the same frame. This
shouldn't be a big problem in this case, though. And besides, there are
algorithms which handle the mutual exclusion problem.
For those who don't know, the mutual exclusion problem means that
if the access to a common variable is not locked between the "ask if
the frame is free" and "set the frame as non-free" commands, then the
other process might ask for the variable after the first process asked,
but before it could set it as non-free. Then both will get a "it's free"
value which is of course not desired.
How to lock other processes from accessing the variable while one process
is reading and setting it is an interesting problem with interesting
algorithmical solutions.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> 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!
No, I mean that one process starts from the beginning and the other from
the end, and when they meet at the same frame, they stop.
(Yes, this needs communication between the two processes.)
> 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.
As someone else said, I was talking about distributing the rendering
effort among both processors. The idea is exactly the same as above
(ie. when the two processes meet at the same pixel, they stop).
(In the case of rendering a single image with two processors mutual
exclusion problems don't really matter, as it's not too dangerous if
the two processes happen to render the same pixel before stopping.)
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dd3c432@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk>
wrote:
>> You may have noticed that I gave _two_ ways to do it. Either even and odd
>> frames or splitting in the middle.
>>
>
> But neither of these work if, in the case of even and odd, alternate images
> take significantly different amount of times to render (odd frames use media,
> even don't), and in the case of splitting in the middle, if the second half of
> the sequence is significantly slower or faster than the first half (or,
> needless to say, if one PC is slower than the other).
I never said they would work, I asked what Warp was talking about. Notice
the questionmarks and the wording.
> I think the misunderstanding here is that a) I don't propose that each
> render-instance should render the same number of frames and b) I don't propose
> that either render-instance "knows" when to stop - it would be up to the user
> to note that instance-a had rendered images 1-20 and that instance-b had
> rendered images 30-21 and that therefore the render could now be stopped.
But that is not what Andrew has been looking for. If one would know in
advance how many frame each instance will render the need to start at both
ends does simply not exist.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dd3cc49@news.povray.org...
<snip>
Now you've got me confused. Warp proposed (or rather, he elaborated on) a
theoretical method to evenly distribute a render. You made a wrong assumption
(that the idea was for the two renders to meet at the middle frame/pixel), and
then continued to assert that the approach was "wrong", even when every effort
had been made to clear up the assumption.
I've re-read the entire thread, and, yes, I got somewhat confused about whether
you were proposing or criticising at one moment, but the point is that no one
ever proposed what you criticised - you just misunderstood what was being
proposed.
Also, the confusion on my part arose quite reasonably from this:
"You may have noticed that I gave _two_ ways to do it. Either even and odd
frames or splitting in the middle."
Now, you don't in any way imply that you agree with me (i.e. that the two
methods won't work), you just carry on criticising Warp's proposal, and picking
up on unimportant details, such as that there may be some overlap on the final
frame.
What I'm getting at is that at no point have you said "ah, I misunderstood",
even though you evidently did.
That said, I like the proposal of checking for whether a file exists, but that
will only work where the two instances share a file-system.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dd3d95c@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk>
wrote:
> Now you've got me confused. Warp proposed (or rather, he elaborated on) a
> theoretical method to evenly distribute a render. You made a wrong assumption
> (that the idea was for the two renders to meet at the middle frame/pixel), and
> then continued to assert that the approach was "wrong", even when every effort
> had been made to clear up the assumption.
No, I asked which of the two methods he suggested as no communication of the
two instances could exist. The only way it could work without communication
is that disjoint sets of frames are rendered by each instance. So I asked
which of the two simple methods possible creating disjoint sets of frames he
is talking about. This is really perfectly clear, at least to me (see
below), and I fail to see why you then you assume I would probably be too
inexperienced or for some other reason not know that different frames can
take a different amount of time to render (remind me, how much time do I
spend optimizing POV-Ray per day?) and go on explaining it to me. I just
don't get it.
> I've re-read the entire thread, and, yes, I got somewhat confused about
> whether you were proposing or criticizing at one moment, but the point is that
> no one ever proposed what you criticized - you just misunderstood what was
> being proposed.
OK, so the term "So you suggest" does not make clear that it is not me
suggesting something. Would you be so kind to reword what I said such that
these misunderstandings can be avoided in the future? I simply do not know
a better way to express that I am talking about an assumption I make about
what someone else is saying:
"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!"
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dd3d95c@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk>
wrote:
> What I'm getting at is that at no point have you said "ah, I misunderstood",
> even though you evidently did.
No, I misunderstood absolutely nothing. I simply asked for more details,
and then mentioned that the two ways I could possibly understand what Warp
says will both not work.
After all, you lectured me on the most simple fact possible, so obviously
you just jumped on something I said, ignored that it was a question
(questionmarks are valid in English, aren't they?), and then go on and
accuse me of misunderstanding when I ask a question?
I think I will just killfile you. Sorry!
Thorsten
To quote your initial reply:
> Huh? I think you're missing the point. As far as I can see, starting one
> render from the last frame and another from the first frame is the only way to
> ensure the best distribution of work. Take 16 random numbers between 1 and 100
> and place them in sequence:
>
> 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.
____________________________________________________
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dd3e683@news.povray.org...
<snip>
Well, at the risk of being killfiled, this is getting silly.
Andrew asked if it was possible to start an anim render on two machines,
starting at opposite ends. You proposed that a solution would be:
>"How about taking the much simpler approach of just starting the second one
>in the middle? Kind of more logical..." (that's your first reply to Andrew's
post)
Then Warp points out that this doesn't achieve what Andrew wants - and then,
despite the fact that both Warp and Andrew have been very specific, you come up
with two non-working interpretations of what they have said ("non-working" in
the sense that they don't achieve an optimisation of render time).
On top of this, you also state that starting a render from opposite ends does
not achieve an optimal render time:
>"Otherwise such a simple attempt of load distribution
>will simply not give you any advantage at all."
Which is plainly false. So tell me, how am I to interpret this as anything else
but that you've misunderstood what is being proposed?
Aditionally, you state that:
>"But that is not what Andrew has been looking for. If one would know in
>advance how many frame each instance will render the need to start at both
>ends does simply not exist."
Well, imho, Andrew knew exactly what he was looking for (from his original
post):
>"Forgive me if this has been asked before, but is it possible, when rendering
on 2 machines, to
>have the second machine start at the last frame, and work towards frame 1, so
both machines
>meet each other at some point?"
Where does he state that he needs to know how many frames each instance will
render?
Now, I'm sorry if I've offended by my daring to try and clarify, but you
seem/seemed confused about what was being proposed - I am well aware of your
contribution to pov, but I am also aware that developers don't tend to do much
complex scene creation (which is not a criticism - those that can, program,
those that can't write scenes;), so what might seem an obstacle to you (lack of
co-ordination between the two instances), might not seem an obstace to someone
rendering a complex scene.
Andrews suggestion, for example, would be a boon for me - if you apply Warp's
varient that you could apply it to a still image, and have two renders render
the scene - one from top left to bottom right, the other from bottom right to
top left.
I could render the image in two unequal halves on my home and work machine. It
might seem a problem that there is no co-ordination between the two processes,
but if the render takes, say 7 days, this is not really an issue, since I will
have a chance to check the progress of each render and choose an appropriate
time to stop them.
Now, apart from my terrible crime of trying to clear up what seemed to be a
misinterpretation on your part, my only other sin was that I became confused
between what you were proposing as a solution and what you were criticising as a
solution (a criticism based on your misinterpretation of what was being said).
Given that your proposal:
>"How about taking the much simpler approach of just starting the second one
>in the middle? Kind of more logical..." (that's your first reply to Andrew's
post)
and your criticism invoke broadly similiar methods (with broadly similiar
problems), I don't see that my confusion is so shocking.
Now as I said, I'm sorry if I offended, but to be frank if you are going to take
offense when you quite clearly misunderstood something, then I'm probably better
off being kill-filed....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Cocker wrote:
> 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.
And I will counter with the argument that it would be silly to modify the program
to allow backward frame processing and not also add the ability to detect what
the other instance is working on so that overlapping frames are not rendered.
I'm not sure how easy it would be to do in a cross platform environment.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:3DD50912.DBA86F4A@pacbell.net...
>
> And I will counter with the argument that it would be silly to modify the
program
> to allow backward frame processing and not also add the ability to detect what
> the other instance is working on so that overlapping frames are not rendered.
> I'm not sure how easy it would be to do in a cross platform environment.
Whilst that would be the ideal, in many practical cases, communication between
the two instances would not be possible in any event - e.g. sharing a render
between 2 non-networked pcs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> And I will counter with the argument that it would be silly to modify the
> program to allow backward frame processing and not also add the ability to
> detect what the other instance is working on so that overlapping frames
> are not rendered. I'm not sure how easy it would be to do in a cross
> platform environment.
Hmm... Wouldn't that be quite easy if the computers were connected through
a LAN and shared a directory? Each instance could just write the number of
the frame they are rendering to their own file and then check the other
instance's file if the frame number is same?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
IMHO Tom's point is very valid and logical.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:
> Hmm... Wouldn't that be quite easy if the computers were connected through
> a LAN and shared a directory? Each instance could just write the number of
> the frame they are rendering to their own file and then check the other
> instance's file if the frame number is same?
That still leaves the problem that they *might* start rendering the
same frame when they meet. Of course this is extremely improbable (perhaps
one possibility in millions) so in practice it's not a problem.
An easier solution would be to simply check if the image file which the
process is going to render next already exists (file_exists()).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Cocker wrote:
>
> Forgive me if this has been asked before, but is it possible, when
> rendering on 2 machines, to have the second machine start at the last
> frame, and work towards frame 1, so both machines meet each other at
> some point? Using something like +kff400 +sf400 +ef1 (which doesn't
> work)
Use the render queue to have one machine render frames 0-23, 48-71,
96-119, etc; then have the other machine render frames 24-47, 72-95,
120-143, and so on. It will require a separate .ini file for each
set of files.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> [...]
>
> I think I will just killfile you. Sorry!
>
No matter who is right and who is wrong in this situation or who
misunderstood something i think this is definitely an inadequate reaction
to Tom's postings. Since Tom is a long time user of POV-Ray you can be
confident that he is defending a valid point - whether he misunderstood
something you said does not change anything about that.
And to sum up my opinion on the matter (and not on the discussion that has
evolved from it) - like Tim and Jaime i see no need for a new feature,
POV-SDL is perfectly capable of handling this without any significant
disadvantage.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 15 Nov. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3DD61DBE.23FF80B2@gmx.de> , Christoph Hormann
<chr### [at] gmxde> wrote:
>> I think I will just killfile you. Sorry!
>
> No matter who is right and who is wrong in this situation or who
> misunderstood something i think this is definitely an inadequate reaction
> to Tom's postings. Since Tom is a long time user of POV-Ray you can be
> confident that he is defending a valid point - whether he misunderstood
> something you said does not change anything about that.
I killfiled him because he starts length discussions about something
irrelevant and tries to turn it into another you said this I said this and
vice versa game. I have better things to do than waste my time with useless
discussions.
The original poster (Andrew) assumed that he would have to stop POV-Ray
manually, Warp assumed POV-Ray instances would communicate in some way, and
there is absolutely no way to guess what someone else is assuming if it is
either extremely hard to use (Andrew) or requires some fairly complex
network interaction if done optimally (Warp). I am unable to do
mindreading, and neither assumption is logical, feasible or usable.
So asking for more details while assuming a logical, feasible and usable way
to achieve the desired goal makes me misunderstand the problem in Tom's set
of mind, fine, but I don't have to nor do I want to listen his nonsense.
That is why I killfiled him.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> So asking for more details while assuming a logical, feasible and usable way
> to achieve the desired goal makes me misunderstand the problem in Tom's set
> of mind, fine, but I don't have to nor do I want to listen his nonsense.
> That is why I killfiled him.
You completely refuse to ever listen to anything someone has to say
because you disagree with one position they hold? That's what
killfiling does, at least temporarily. Why don't you just ignore the
thread in question?
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dd63df4@news.povray.org> , "Timothy R. Cook"
<tim### [at] scifi-fantasycom> wrote:
>> That is why I killfiled him.
>
> You completely refuse to ever listen to anything someone has to say
> because you disagree with one position they hold? That's what
> killfiling does, at least temporarily. Why don't you just ignore the
> thread in question?
Huh??? In what way does
"I killfiled him because he starts length discussions about something
irrelevant and tries to turn it into another you said this I said this and
vice versa game."
possibly imply this? Really, don't you have anthing better to do?
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> Huh??? In what way does
> "I killfiled him because he starts length discussions about something
> irrelevant and tries to turn it into another you said this I said this and
> vice versa game."
> possibly imply this?
Because elsewise you would have killfiled him before this thread,
or not killfiled him but simply ignored this thread.
By killfiling someone, you filter out anything they have to say, yes?
> Really, don't you have anthing better to do?
Sadly, no.
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dd631b5$1@news.povray.org...
> The original poster (Andrew) assumed that he would have to stop POV-Ray
> manually, Warp assumed POV-Ray instances would communicate in some way, and
> there is absolutely no way to guess what someone else is assuming if it is
> either extremely hard to use (Andrew) or requires some fairly complex
> network interaction if done optimally (Warp). I am unable to do
> mindreading, and neither assumption is logical, feasible or usable.
Why on earth is my suggestion "extremely hard to use"? IMO it's totally logical, and
useable.
For me (someone who often struggles with the POV SDL), it would be hard (or just a
major
hassle and timewaste) to have to re-write a scene to make it render backwards (I don't
even
know how I would go about doing that).
I admit to not having thought about problems that may arise when running two or more
instances
of POV-Ray on the one machine, and having one or more rendering backwards - with the
Windows
version, couldn't one just disable the feature if Keep Single Instance was unchecked?
I don't
know if something similar is possible on other OS's.
My suggestion / request was for a simple command-line switch that would let POV-Ray
render
from the last frame to the first (when POV-Ray is running on seperate machines!). It
didn't
strike me that this would be a difficult thing to do (but then, what do I know? ;-)).
I never
intended a discussion on networking etc.
I have made (what I consider to be very useful) suggestions in the past, but which
have not
been implemented (I won't say 'ignored', 'cause I don't know) such as having Pause
Render
available by right-clicking on the tray icon. I always assume that there are good
reasons why
these things aren't implemented, and never take it personally. This is just another of
those
things, and is not a problem.
All the best,
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
