 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
Recently I stumbled over a link to Chris Bartlett's StairCase macro
and downloaded the files.
The first example in StairCaseDoc.pov traced happily in about 7s
with my AMD Athlon 64 3000+ on Windows XP Home SP2.
Because all the examples trace as an animation, I started it with
+kfi0 +kff50 in the command line box and went doing something
else. After a while I checked the progress and noticed that the
tracing was very slow compared to the single trace before.
I quickly checked the messages for the first example and good only
see a difference in the number of objects :
Single trace: 176 Trace time: 7sec
Animation: 168 Trace time: 68sec
Weird, why is there a difference when everything in the file stays the
same?
In order to check every line of the messages I put them beside each
other and found some more differences:
(In the statistics below the first line is the single trace and the second
line is from the animation)
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------
Box 506223 120663 23.84
Box 89402880 221111 0.25
Cone/Cylinder 21746 3735 17.18
Cone/Cylinder 25703328 8122 0.03
CSG Intersection 484477 59250 12.23
CSG Intersection 51406656 76943 0.15
CSG Union 664369 49209 7.41
CSG Union 59229408 131033 0.22
Lathe 212507 72541 34.14
Lathe 48054048 155648 0.32
Lathe Bound 212507 110827 52.15
Lathe Bound 48054048 195161 0.41
Plane 543940 382586 70.34
Plane 6705216 4650488 69.36
Prism 1338041 272019 20.33
Prism 33526080 352735 1.05
Prism Bound 25342199 2241221 8.84
Prism Bound 275266864 19341721 7.03
Sphere 7470 1798 24.07
Sphere 4470144 1854 0.04
Clipping Object 331882 105405 31.76
Clipping Object 643896 198954 30.90
Bounding Box 8774139 2655932 30.27
No line !!!
Vista Buffer 3915348 2326121 59.41
No line !!!
Conclusion: The bounding is off and the Vista Buffers as well.
That explains the statistics and the long trace time.
To be sure I made an ini-file with:
Bounding=on
Bounding_Threshold=5
Draw_Vistas=on
Light_Buffer=on
Vista_Buffer=on
in it and traced again. The results don't change, however the
Bounding_Threshold=5 and Draw_Vistas=on were there
in the header, but it didn't work. Vistas in the single trace
works normally.
Can anyone check with some different file if there is something
really wrong with version 3.6.1c.
All my animation files are based on clock values and I never
noticed any differences in trace time with a single trace or in
an animation. However I never used the frame system of POV.
In news.povray.org I can't find any reference to such a behaviour.
I will put the files in povray.binaries.scene-files under
Bug-test-files.
Maybe I do something stupidly wrong, but I don't see it.
Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jaap Frank" <jjf### [at] casema nl> wrote in message
news:47d31681$1@news.povray.org...
> Hi,
>
> Recently I stumbled over a link to Chris Bartlett's StairCase macro
> and downloaded the files.
> The first example in StairCaseDoc.pov traced happily in about 7s
> with my AMD Athlon 64 3000+ on Windows XP Home SP2.
> Because all the examples trace as an animation, I started it with
> +kfi0 +kff50 in the command line box and went doing something
> else. After a while I checked the progress and noticed that the
> tracing was very slow compared to the single trace before.
> I quickly checked the messages for the first example and good only
> see a difference in the number of objects :
> Single trace: 176 Trace time: 7sec
> Animation: 168 Trace time: 68sec
> Weird, why is there a difference when everything in the file stays the
> same?
The 'StairCaseDoc.pov' file is designed to use the animation feature to
regenerate all of the 50 different images in the documentation provided with
the macros. When you use the animation feature with this file, the SDL uses
the frame number to work out which image to generate, then sets the macro
parameters for that image. Some of the images contain simple single flights
of stairs with a small number of objects, others contain multiple flights of
stairs with a very large number of objects. The render time therefore varies
a lot from image to image/frame to frame.
> All my animation files are based on clock values and I never
> noticed any differences in trace time with a single trace or in
> an animation. However I never used the frame system of POV.
> In news.povray.org I can't find any reference to such a behaviour.
Even if you just use the clock and don't vary the contents of the scene
between frames, the render times for different frames can still vary
depending on the proximity to the camera of different objects. For example,
a partially transparent or reflective sphere a long way from the camera has
less impact on render times than if it's close to the camera and generates
additional rays to trace.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomailcom> schreef in bericht
news:47d3240f$1@news.povray.org...
>
> "Jaap Frank" <jjf### [at] casemanl> wrote in message
> news:47d31681$1@news.povray.org...
>> Hi,
>>
>> Recently I stumbled over a link to Chris Bartlett's StairCase macro
>> and downloaded the files.
>> The first example in StairCaseDoc.pov traced happily in about 7s
>> with my AMD Athlon 64 3000+ on Windows XP Home SP2.
>> Because all the examples trace as an animation, I started it with
>> +kfi0 +kff50 in the command line box and went doing something
>> else. After a while I checked the progress and noticed that the
>> tracing was very slow compared to the single trace before.
>> I quickly checked the messages for the first example and good only
>> see a difference in the number of objects :
>> Single trace: 176 Trace time: 7sec
>> Animation: 168 Trace time: 68sec
>> Weird, why is there a difference when everything in the file stays the
>> same?
>
> The 'StairCaseDoc.pov' file is designed to use the animation feature to
> regenerate all of the 50 different images in the documentation provided
> with the macros. When you use the animation feature with this file, the
> SDL uses the frame number to work out which image to generate, then sets
> the macro parameters for that image. Some of the images contain simple
> single flights of stairs with a small number of objects, others contain
> multiple flights of stairs with a very large number of objects. The render
> time therefore varies a lot from image to image/frame to frame.
>
>> All my animation files are based on clock values and I never
>> noticed any differences in trace time with a single trace or in
>> an animation. However I never used the frame system of POV.
>> In news.povray.org I can't find any reference to such a behaviour.
>
> Even if you just use the clock and don't vary the contents of the scene
> between frames, the render times for different frames can still vary
> depending on the proximity to the camera of different objects. For
> example, a partially transparent or reflective sphere a long way from the
> camera has less impact on render times than if it's close to the camera
> and generates additional rays to trace.
>
> Regards,
> Chris B.
>
I'm afraid you miss the point. It's about the same example: number 1. The
first
is traced with the first line of your StairCaseDoc.pov en the second with
the
animation option from the second line. They are the same and should trace
equally fast, but with the animation the automatic bounding and the vista
buffer aren't working. You can check that in the statistics (see
messages.txt).
I've checked the other examples too of coarse and everything stays the same,
no bounding and vista buffer in the animation. Some how they are not
working.
By the way, a very good macro!
Greetings,
Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jaap Frank" <jjf### [at] casemanl> wrote in message
news:47d3b864$1@news.povray.org...
> "Chris B" <nom### [at] nomailcom> schreef in bericht
> I'm afraid you miss the point. It's about the same example: number 1. The
> first is traced with the first line of your StairCaseDoc.pov en the second
> with the
> animation option from the second line. They are the same and should trace
> equally fast, but with the animation the automatic bounding and the vista
> buffer aren't working. You can check that in the statistics (see
> messages.txt).
> I've checked the other examples too of coarse and everything stays the
> same,
> no bounding and vista buffer in the animation. Some how they are not
> working.
>
Ah. I see you're right. After a little more investigation, my conclusion is
that it stems from the fact that the first frame (frame '0') is empty. If
you use +kfi1 +kff50 then I think you should find the problem goes away. The
only stuff the scene file does during frame 0 is to clear down the list of
file names used to rename the files for inclusion in the documentation, so
you probably won't need that.
I vaguely recall a discussion about starting an animation with no objects in
the first frame a while ago and reading that POV-Ray makes some assumptions
(maybe about bounding/vista buffering, I can't remember exactly) and that
the assumption then lasts for the entire animation sequence. If memory
serves me correctly I think the conclusion of that discussion was that it
was more a 'feature' than a 'bug'.
I didn't remember having done this myself in this scene file. If you add SDL
for image 0 with just 3 spheres in it the problem goes away for +kfi0
+kff50. Add just 1 or 2 spheres and you still get the slow-down.
> By the way, a very good macro!
Thanks,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomailcom> schreef in bericht
news:47d3f0df$1@news.povray.org...
>
> "Jaap Frank" <jjf### [at] casemanl> wrote in message
> news:47d3b864$1@news.povray.org...
>> "Chris B" <nom### [at] nomailcom> schreef in bericht
>> I'm afraid you miss the point. It's about the same example: number 1. The
>> first is traced with the first line of your StairCaseDoc.pov en the
>> second with the
>> animation option from the second line. They are the same and should trace
>> equally fast, but with the animation the automatic bounding and the vista
>> buffer aren't working. You can check that in the statistics (see
>> messages.txt).
>> I've checked the other examples too of coarse and everything stays the
>> same,
>> no bounding and vista buffer in the animation. Some how they are not
>> working.
>>
>
> Ah. I see you're right. After a little more investigation, my conclusion
> is that it stems from the fact that the first frame (frame '0') is empty.
> If you use +kfi1 +kff50 then I think you should find the problem goes
> away. The only stuff the scene file does during frame 0 is to clear down
> the list of file names used to rename the files for inclusion in the
> documentation, so you probably won't need that.
>
> I vaguely recall a discussion about starting an animation with no objects
> in the first frame a while ago and reading that POV-Ray makes some
> assumptions (maybe about bounding/vista buffering, I can't remember
> exactly) and that the assumption then lasts for the entire animation
> sequence. If memory serves me correctly I think the conclusion of that
> discussion was that it was more a 'feature' than a 'bug'.
>
> I didn't remember having done this myself in this scene file. If you add
> SDL for image 0 with just 3 spheres in it the problem goes away for +kfi0
> +kff50. Add just 1 or 2 spheres and you still get the slow-down.
>
>> By the way, a very good macro!
>
> Thanks,
> Chris B.
>
Yes, that was the problem. Now it is tracing with the right speed.
Thanks for the reaction.
Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
