POV-Ray : Newsgroups : povray.programming : this animation is killing me Server Time
18 May 2024 08:42:01 EDT (-0400)
  this animation is killing me (Message 1 to 7 of 7)  
From: danny berne
Subject: this animation is killing me
Date: 15 Nov 2005 09:46:45
Message: <4379f4d5$1@news.povray.org>
I haven't started to even look at the code for povray yet... but this whole
parsing before you render EACH frame deal is killing me. before I go ass
first into the code, has anybody found a way to render each frame without
parsing yet? or better yet... why has this not been done... and don't tell
me that you guys are perfectly happy watching your drives spin for five
minutes for each frame.

danny


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: this animation is killing me
Date: 15 Nov 2005 09:59:26
Message: <4379f7ce@news.povray.org>
danny berne wrote:
> I haven't started to even look at the code for povray yet... but this whole
> parsing before you render EACH frame deal is killing me. before I go ass
> first into the code, has anybody found a way to render each frame without
> parsing yet? or better yet... why has this not been done... and don't tell
> me that you guys are perfectly happy watching your drives spin for five
> minutes for each frame.

This is the wrong group for this question.  This group is for discussion of
the POV-Ray source code.  Questions about using the POV-Ray should be asked
in either povray.general or povray.newusers.  Flamewars should be kept to 
povray.off-topic.

     Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Warp
Subject: Re: this animation is killing me
Date: 15 Nov 2005 10:11:52
Message: <4379fab7@news.povray.org>
danny berne <dan### [at] yahoocom> wrote:
> I haven't started to even look at the code for povray yet... but this whole
> parsing before you render EACH frame deal is killing me. before I go ass
> first into the code, has anybody found a way to render each frame without
> parsing yet? or better yet... why has this not been done... and don't tell
> me that you guys are perfectly happy watching your drives spin for five
> minutes for each frame.

  It's impossible in many cases to create the scene for the next frame
without parsing the scene.
  Objects, textures and other visible properties which depend on the
animation variables (such as 'clock' and 'frame_number') just have to
be parsed again. Moreover, it is possible for the pov file to write
data to an external file for the next frame to use.

  Many things could be made parse-once-use-many-times, but that kind of
thing is not very high in the priority list of new features to add.

-- 
                                                          - Warp


Post a reply to this message

From: danny berne
Subject: Re: this animation is killing me
Date: 15 Nov 2005 10:16:57
Message: <4379fbe9$1@news.povray.org>
then maybe you didn't understand my question... why was this never done?
before I start jumping into the code, I would like to know if I'm wasting my
time, no one would know better than you guys, and this should most
definately be a change to take place in the source code because if would be
a change to the way each pov file is parsed. so don't get all cranky on me.

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:4379f7ce@news.povray.org...
> danny berne wrote:
> > I haven't started to even look at the code for povray yet... but this
whole
> > parsing before you render EACH frame deal is killing me. before I go ass
> > first into the code, has anybody found a way to render each frame
without
> > parsing yet? or better yet... why has this not been done... and don't
tell
> > me that you guys are perfectly happy watching your drives spin for five
> > minutes for each frame.
>
> This is the wrong group for this question.  This group is for discussion
of
> the POV-Ray source code.  Questions about using the POV-Ray should be
asked
> in either povray.general or povray.newusers.  Flamewars should be kept to
> povray.off-topic.
>
>      Thorsten
>
> ____________________________________________________
> Thorsten Froehlich
> e-mail: mac### [at] povrayorg
>
> I am a member of the POV-Ray Team.
> Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: danny berne
Subject: Re: this animation is killing me
Date: 15 Nov 2005 10:51:41
Message: <437a040d$1@news.povray.org>
this is all very true... but when doing a massive scene the program can
spend a lot of time parsing the file and loading the scene when all you want
to do is a camera flyby...

I was thinking of trying to find a way to interrupt the exit routine
somehow... see... I envision two parts to the script a static and variable
section. damn, now that I think about this... this is going to suck. I have
downloaded the source and I'm starting to see why this hasn't been done.
this should have been done in version 1 if it was going to be done... I'm
not trying to put this program down... because it is great... it just wasn't
made to do the animations I want it to do... but if you have any ideas on
where I can start poking around give me a file name.

danny

"Warp" <war### [at] tagpovrayorg> wrote in message
news:4379fab7@news.povray.org...
> danny berne <dan### [at] yahoocom> wrote:
> > I haven't started to even look at the code for povray yet... but this
whole
> > parsing before you render EACH frame deal is killing me. before I go ass
> > first into the code, has anybody found a way to render each frame
without
> > parsing yet? or better yet... why has this not been done... and don't
tell
> > me that you guys are perfectly happy watching your drives spin for five
> > minutes for each frame.
>
>   It's impossible in many cases to create the scene for the next frame
> without parsing the scene.
>   Objects, textures and other visible properties which depend on the
> animation variables (such as 'clock' and 'frame_number') just have to
> be parsed again. Moreover, it is possible for the pov file to write
> data to an external file for the next frame to use.
>
>   Many things could be made parse-once-use-many-times, but that kind of
> thing is not very high in the priority list of new features to add.
>
> -- 
>                                                           - Warp


Post a reply to this message

From: PaulSh
Subject: Re: this animation is killing me
Date: 14 Nov 2006 11:40:00
Message: <web.4559f1165089c4178f8c13730@news.povray.org>
"danny berne" <dan### [at] yahoocom> wrote:
> I haven't started to even look at the code for povray yet... but this whole
> parsing before you render EACH frame deal is killing me. before I go ass
> first into the code, has anybody found a way to render each frame without
> parsing yet?

Isn't that exactly what clockless animation is in the V3.7 beta? The
limitation is that the only thing allowed to move is the camera. Also,
right now it's tied in with the real-time option, but it looks like that is
going to change.


Post a reply to this message

From: Michael
Subject: Re: this animation is killing me
Date: 12 Aug 2007 16:55:00
Message: <web.46bf733c5089c4175139b7910@news.povray.org>
"PaulSh" <nomail@nomail> wrote:
> "danny berne" <dan### [at] yahoocom> wrote:
> > I haven't started to even look at the code for povray yet... but this whole
> > parsing before you render EACH frame deal is killing me. before I go ass
> > first into the code, has anybody found a way to render each frame without
> > parsing yet?
>
> Isn't that exactly what clockless animation is in the V3.7 beta? The
> limitation is that the only thing allowed to move is the camera. Also,
> right now it's tied in with the real-time option, but it looks like that is
> going to change.

Is there any way to untie it from the realtime rendering? I have me an
animation with 8000 frames, and every single frame is described in the
file, so there's no clock needed, just one parse. :<


Post a reply to this message

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