 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not really a new user since I've been using the program since
DKBTrace. But since I'm new to the POVRay newsgroups, and I've
only really dabbled with POVRay, I'll consider myself a 'noob'.
I also tried searching the help and website for this but I just
don't know what to call the problem to find if it's been discussed.
I am using an external program to generate scene files, which
consist of a few to sometimes thousands of spheres. No problem here.
Each scene renders in 2 seconds. But, I'm doing hundreds of frames
to make an animation. OK, so I generate all my scene files and throw
them in the queue. The annoying thing is that although each scene
only takes 2 seconds to render, POVRay pauses for 5 seconds between
each render, effectively increasing the render time by 250%.
I couldn't find anything in the help files or a brief glance
through settings that affects this, so....
Since POVRay doesn't pause so long between renders when it does
animations, I got the bright (?) idea of turning each scene into
an include file and just rendering one pov file. I used the clock
parameter to generate the include filename on each pass.
Although the method works, the weird thing is that each frame
takes longer than the previous, so that by the 70th frame the
scene is taking over a minute instead of the 2 seconds it should.
Here's some relevant code:
my resolution.ini....
[640x480, No AA, 365 frames]
Width=640
Height=480
Antialias=Off
Initial_Frame=1
Final_Frame=365
Initial_Clock=0
Final_Clock=364
from the pov file....
#declare framenumber = clock+1;
#declare name = "spheres";
#declare frame = str(framenumber, -4, 0);
#declare extension = ".inc";
#declare filename = concat(name, frame, extension);
#include filename
The only other stuff in the code is the usual color, texture,
and shape includes, a light source, a camera, and the obligatory
checkered floor.
The sequence of declares is what I use to generate the filename
to be included in each frame. For example, on the first frame
where the clock is 0, the filename becomes "spheres0000.inc", and
the tenth frame is "spheres0010.inc". This works.
At first I though that each frame doesn't just include the one
include file of the current frame, but all the previous includes
as well!!! But the rendered image is fine. It shows exactly what
it should show with no extra stuff from previous includes.
My other idea is that although POVRay isn't using the previous
includes, they are still resident in memory and are being parsed.
But in the message window, the parse time is always low, less
than 1 second (zero seconds shown). But each successive frame
takes longer to actually render.
If this can't be solved, I'll just go back to generating full
scene files and using the queue.
I'm using v3.6, 3.6.0.icl8.win32 to be exact.
TIA!
Brian
--
http://www.skywise711.com - Lasers, Seismology, Astronomy, Skepticism
Seismic FAQ: http://www.skywise711.com/SeismicFAQ/SeismicFAQ.html
Quake "predictions": http://www.skywise711.com/quakes/EQDB/index.html
Sed quis custodiet ipsos Custodes?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <448259a6@news.povray.org>,
Skywise <int### [at] oblivion nothingcom> wrote:
> I'm not really a new user since I've been using the program since
> DKBTrace. But since I'm new to the POVRay newsgroups, and I've
> only really dabbled with POVRay, I'll consider myself a 'noob'.
> [snip]
> my resolution.ini....
>
> [640x480, No AA, 365 frames]
> Width=640
> Height=480
> Antialias=Off
> Initial_Frame=1
> Final_Frame=365
> Initial_Clock=0
> Final_Clock=364
>
> from the pov file....
>
> #declare framenumber = clock+1;
> #declare name = "spheres";
> #declare frame = str(framenumber, -4, 0);
> #declare extension = ".inc";
> #declare filename = concat(name, frame, extension);
>
> #include filename
>
> The only other stuff in the code is the usual color, texture,
> and shape includes, a light source, a camera, and the obligatory
> checkered floor.
>
> The sequence of declares is what I use to generate the filename
> to be included in each frame. For example, on the first frame
> where the clock is 0, the filename becomes "spheres0000.inc", and
> the tenth frame is "spheres0010.inc". This works.
... on the first frame, the filename is "spheres0001.inc" no ?
but, why not using directly the 'frame_number' variable ?
> At first I though that each frame doesn't just include the one
> include file of the current frame, but all the previous includes
> as well!!! But the rendered image is fine. It shows exactly what
> it should show with no extra stuff from previous includes.
#declare index=0;
#while (index< frame_number)
#declare filename=concat("spheres",str(index,-4,0),".inc");
#include filename
#declare index=index+1;
#end
with your 'ini' this give you "spheres0001.inc" to "spheres0365.inc" and
at each 'frame', all previous "spheresxxxx.inc" are included but of
course, all includes are parsed and parsed and parsed...
--
klp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Skywise <int### [at] oblivionnothingcom> wrote:
> I'm not really a new user since I've been using the program since
> DKBTrace. But since I'm new to the POVRay newsgroups, and I've
> only really dabbled with POVRay, I'll consider myself a 'noob'.
Welcome, fellow DKBtrace person!
> I am using an external program to generate scene files, which
> consist of a few to sometimes thousands of spheres. No problem here.
> Each scene renders in 2 seconds. But, I'm doing hundreds of frames
> Since POVRay doesn't pause so long between renders when it does
> animations, I got the bright (?) idea of turning each scene into
> an include file and just rendering one pov file. I used the clock
> parameter to generate the include filename on each pass.
>
> Although the method works, the weird thing is that each frame
> takes longer than the previous, so that by the 70th frame the
> scene is taking over a minute instead of the 2 seconds it should.
>
> Here's some relevant code:
>
> my resolution.ini....
>
> [640x480, No AA, 365 frames]
> Width=640
> Height=480
> Antialias=Off
> Initial_Frame=1
> Final_Frame=365
> Initial_Clock=0
> Final_Clock=364
>
> from the pov file....
>
> #declare framenumber = clock+1;
> #declare name = "spheres";
> #declare frame = str(framenumber, -4, 0);
> #declare extension = ".inc";
> #declare filename = concat(name, frame, extension);
>
> #include filename
Your code looks fine. I'm just guessing, but I think it may be a memory
issue. Try using #undef to get rid of the data from each scene before
loading the next one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] yahoofr> wrote in news:kurtzlepirate-
12B112.10462204062006@news.povray.org:
<Snipola>
> ... on the first frame, the filename is "spheres0001.inc" no ?
> but, why not using directly the 'frame_number' variable ?
>
<Snipola>
>
> #declare index=0;
> #while (index< frame_number)
> #declare filename=concat("spheres",str(index,-4,0),".inc");
> #include filename
> #declare index=index+1;
> #end
>
>
> with your 'ini' this give you "spheres0001.inc" to "spheres0365.inc" and
> at each 'frame', all previous "spheresxxxx.inc" are included but of
> course, all includes are parsed and parsed and parsed...
I had never used the frame_number parameter before so I simply
went with what I knew. Heck, I had never tried what I am doing
before either. Your code is obviously the better way to do this
as I can leave the clock moving form 0 to 1.
However, this doesn't help the render speed problem. Not sure
if you thought it would or not. Each subsequent frame is still
taking longer.
Brian
--
http://www.skywise711.com - Lasers, Seismology, Astronomy, Skepticism
Seismic FAQ: http://www.skywise711.com/SeismicFAQ/SeismicFAQ.html
Quake "predictions": http://www.skywise711.com/quakes/EQDB/index.html
Sed quis custodiet ipsos Custodes?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"PM 2Ring" <nomail@nomail> wrote in news:web.4482d7ee6c88dcbf76ba2c900
@news.povray.org:
<Snipola>
> Your code looks fine. I'm just guessing, but I think it may be a memory
> issue.
That's what I'm thinking. Although the parse time stays the same
low 0-1 second time, I don't think the program is releasing the
include data from the previous frames, and it's muffing up the
renderer somehow.
These scenes only have up to tens of thousands of spheres. If it
were a matter of each successive frame rendering all the data
of the previous frames, why then does the render time increase
so rapidly?
Here's the render time in seconds of the first few frames along
with the number of spheres in each frame:
frame - time - spheres
1 - 1 - 0
2 - 4 - 92
3 - 9 - 200
4 - 15 - 352
5 - 22 - 502
6 - 27 - 579
7 - 33 - 678
8 - 40 - 774
9 - 54 - 900
10 - 61 - 984
So even if the 10th frame was rendering it's own plus the previous
9 frames spheres, that's only 5,061 spheres, which should still take
only a second or two. One of the more complex frames, with over
13,000 spheres, only takes 4 seconds if I render it on it's own.
It seems like an obvious bug, unless my code isn't right. From other
programming experience, there are times where things don't work the
way they look like they should work. That could be the case here and
to do what I want should be implemented differently.
Try using #undef to get rid of the data from each scene before
> loading the next one.
I may not be understanding your intent. It seems #undef only works
on a variable. What should I be #undef'ing?
Another thing, if I could just get POVRay to not pause so darned
long between entries in the render queue, this really wouldn't be
an issue. Queing a list of files that takes minutes to render, the
5 second delay between files isn't a big deal. But since my files
only take a second or two to render, this delay has great impact
on my total render time.
Hmmm....maybe this isn't such a newbie problem afterall? Perhaps
this should be moved to a different POVRay newsgroup?
Brian
--
http://www.skywise711.com - Lasers, Seismology, Astronomy, Skepticism
Seismic FAQ: http://www.skywise711.com/SeismicFAQ/SeismicFAQ.html
Quake "predictions": http://www.skywise711.com/quakes/EQDB/index.html
Sed quis custodiet ipsos Custodes?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Skywise" <int### [at] oblivionnothingcom> wrote in message
news:4483ebd0@news.povray.org...
> Here's the render time in seconds of the first few frames along
> with the number of spheres in each frame:
>
> frame - time - spheres
> 1 - 1 - 0
> 2 - 4 - 92
> 3 - 9 - 200
> 4 - 15 - 352
> 5 - 22 - 502
> 6 - 27 - 579
> 7 - 33 - 678
> 8 - 40 - 774
> 9 - 54 - 900
> 10 - 61 - 984
>
> So even if the 10th frame was rendering it's own plus the previous
> 9 frames spheres, that's only 5,061 spheres, which should still take
> only a second or two. One of the more complex frames, with over
> 13,000 spheres, only takes 4 seconds if I render it on it's own.
>
> Brian
Hi Brian,
I've not noticed any increase in time with rendering of successive frames in
an of my animations. Indeed I generally do a quick calculation based on the
time for first couple of frames to work out how long the whole thing will
take and it generally works out fairly close to what I'd expect. I would
think your best option would be to reduce the complexity and see whether the
problem persists.
For example, you could try rendering the same frame 10 times and see whether
each successive frame takes the same time or not. That is to say, hard code
the include of frame 5 and see whether it takes the same amount of time for
each of 10 frames in an animation.
If you can simplify it down, so that you end up with a small number of very
short files that illustrate the problem, then you could post your SDL on the
scene-files newsgroup and others could see if they can replicate your
problem.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <c_b### [at] btconnectcomnospam> wrote in
news:448573e1$1@news.povray.org:
<Snipola>
> Hi Brian,
>
> I've not noticed any increase in time with rendering of successive
> frames in an of my animations. Indeed I generally do a quick calculation
> based on the time for first couple of frames to work out how long the
> whole thing will take and it generally works out fairly close to what
> I'd expect. I would think your best option would be to reduce the
> complexity and see whether the problem persists.
>
> For example, you could try rendering the same frame 10 times and see
> whether each successive frame takes the same time or not. That is to
> say, hard code the include of frame 5 and see whether it takes the same
> amount of time for each of 10 frames in an animation.
>
> If you can simplify it down, so that you end up with a small number of
> very short files that illustrate the problem, then you could post your
> SDL on the scene-files newsgroup and others could see if they can
> replicate your problem.
>
> Regards,
> Chris B.
OK, I made my first ten includes all the same as #10. Everything ran
lickity-split like expected. So, I started reducing things and found
that it was a problem with the first include, which happened to be
blank.
Thinking it was just becuase it was blank, I added 1 sphere object.
I manually moved it off screen so the first frame can still be blank.
Nope, same problem. Things slowed down again.
I then thought it was because the rendered scene was blank, so I
put the 1 lone sphere object back in place so it could be seen. Still
slowed down.
So, I went back to duplicating the contents of #10 back into #1.
OK, we're back to it working fine. Time for a process of elimination.
I started chopping away at the number of objects in the first frame.
I get it down to three and things are ok. Any less and things crap
out. 0, 1, or 2 objects and it just freaks out.
OK, fine, I can live with that. I try moving the three objects out
of sight so the first frame can be blank like it's supposed to be.
Everything still works fine!
Seems like the issue is specific to the first include file. It must
have at least three objects in it.
I just let it run through my 365 frames and it completed in 9m 11s.
That's about 1.5 seconds per frame. That's a lot better than 7 seconds
per frame doing it with the render queue! Some of the frames have
well over 10,000 objects in them.
Another advantage of doing it this way is that it seems the render
queue has a limit to it's list size.
Brian
--
http://www.skywise711.com - Lasers, Seismology, Astronomy, Skepticism
Seismic FAQ: http://www.skywise711.com/SeismicFAQ/SeismicFAQ.html
Quake "predictions": http://www.skywise711.com/quakes/EQDB/index.html
Sed quis custodiet ipsos Custodes?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Skywise nous apporta ses lumieres en ce 06/06/2006 15:28:
> "Chris B" <c_b### [at] btconnectcomnospam> wrote in
> news:448573e1$1@news.povray.org:
>
> <Snipola>
>> Hi Brian,
>>
>> I've not noticed any increase in time with rendering of successive
>> frames in an of my animations. Indeed I generally do a quick calculation
>> based on the time for first couple of frames to work out how long the
>> whole thing will take and it generally works out fairly close to what
>> I'd expect. I would think your best option would be to reduce the
>> complexity and see whether the problem persists.
>>
>> For example, you could try rendering the same frame 10 times and see
>> whether each successive frame takes the same time or not. That is to
>> say, hard code the include of frame 5 and see whether it takes the same
>> amount of time for each of 10 frames in an animation.
>>
>> If you can simplify it down, so that you end up with a small number of
>> very short files that illustrate the problem, then you could post your
>> SDL on the scene-files newsgroup and others could see if they can
>> replicate your problem.
>>
>> Regards,
>> Chris B.
>
> OK, I made my first ten includes all the same as #10. Everything ran
> lickity-split like expected. So, I started reducing things and found
> that it was a problem with the first include, which happened to be
> blank.
>
> Thinking it was just becuase it was blank, I added 1 sphere object.
> I manually moved it off screen so the first frame can still be blank.
> Nope, same problem. Things slowed down again.
>
> I then thought it was because the rendered scene was blank, so I
> put the 1 lone sphere object back in place so it could be seen. Still
> slowed down.
>
> So, I went back to duplicating the contents of #10 back into #1.
> OK, we're back to it working fine. Time for a process of elimination.
>
> I started chopping away at the number of objects in the first frame.
> I get it down to three and things are ok. Any less and things crap
> out. 0, 1, or 2 objects and it just freaks out.
>
> OK, fine, I can live with that. I try moving the three objects out
> of sight so the first frame can be blank like it's supposed to be.
> Everything still works fine!
>
> Seems like the issue is specific to the first include file. It must
> have at least three objects in it.
>
> I just let it run through my 365 frames and it completed in 9m 11s.
> That's about 1.5 seconds per frame. That's a lot better than 7 seconds
> per frame doing it with the render queue! Some of the frames have
> well over 10,000 objects in them.
>
> Another advantage of doing it this way is that it seems the render
> queue has a limit to it's list size.
>
> Brian
Looks more like a bounding blocks problem. The default thresshold for bounding is 3.
If the first
frame of an animation don't trigger bounding, it stays OFF for the whole anomation. If
I remember
correctly, it was discused in another thread a while back.
The workaround was effectively to put 3 "dummy" objects out of view, like behind the
camera, under a
ground plane or beyond a world sphere.
I don't think that any infinite object count, or even scene encompassing finite
objects like the
world sphere or box.
--
Alain
-------------------------------------------------
Getting the job done is no excuse for not following the rules.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote in news:4488919a@news.povray.org:
<Snipola>
> Looks more like a bounding blocks problem. The default thresshold for
bounding is 3. If the first
> frame of an animation don't trigger bounding, it stays OFF for the whole
anomation. If I remember
> correctly, it was discused in another thread a while back.
> The workaround was effectively to put 3 "dummy" objects out of view, like
behind the camera, under a
> ground plane or beyond a world sphere.
> I don't think that any infinite object count, or even scene encompassing
finite objects like the
> world sphere or box.
>
Thanks for the hint. I'll look that thread up.
Brian
--
http://www.skywise711.com - Lasers, Seismology, Astronomy, Skepticism
Seismic FAQ: http://www.skywise711.com/SeismicFAQ/SeismicFAQ.html
Quake "predictions": http://www.skywise711.com/quakes/EQDB/index.html
Sed quis custodiet ipsos Custodes?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
