POV-Ray : Newsgroups : povray.general : Bug (or feature to design around when animating). Server Time
31 Jul 2024 16:32:22 EDT (-0400)
  Bug (or feature to design around when animating). (Message 7 to 16 of 16)  
<<< Previous 6 Messages Goto Initial 10 Messages
From: Greg M  Johnson
Subject: Re: Bug (or feature to design around when animating).
Date: 8 Feb 2007 21:33:56
Message: <45cbdd94@news.povray.org>
David E. LeMasters wrote:
>  I tested both 3.6 and the latest 3.7 beta.
> All times are in seconds.
> To make it as simple as possible I only ran two frames, 10 and 11.
> 
>                       Linux-Pentium            Windows-AMD
> Command               3.6       3.7           3.6       3.7
> 
> +kff20 +sf10 +ef10    <1        <1            0.39      0.69
> +kff20 +sf11 +ef11    <1        <1            0.30      0.61
> +kff20 +sf10 +ef11    48        1.19         25.63      1.20
> 
> On the 2 frame animation the first frame was less than 1 sec on both
> machines.
> I don't have any idea what caused the slowdown, but it seems to be
> resolved in 3.7


Wow that is most helpful. Hey, pov already fixed it! No ghost!

But for the short term I think I have to do the math for this one project,
as to whether the slowdown for other frames makes up for the speedup in the
speed bump between scenes.


Post a reply to this message

From: David E  LeMasters
Subject: Re: Bug (or feature to design around when animating).
Date: 9 Feb 2007 11:00:01
Message: <web.45cc991018adace69b0419b60@news.povray.org>
I played around with your code a bit more, pulling out things to try
and locate what is causing the problem.  This is what I came up with:

#if(clock<=0.5)
  box{0,1}
#else
  text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
#end

When I run this on my linux box this is what I get:

+kff20 +sf1 +ef10      5 sec.
+kff20 +sf11 +ef20    23 sec.
+kff20 +sf1 +ef20    163 sec.

When I swap the box and text objects like this:

#if(clock<=0.5)
  text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
#else
  box{0,1}
#end

I get this:

+kff20 +sf1 +ef10     22 sec.
+kff20 +sf11 +ef20     4 sec.
+kff20 +sf1 +ef20     27 sec.


When I try this:

#if(clock<=0.5)
  text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
#else
  text{ ttf "COMICBD.ttf" "Caption2" 1,0 pigment{rgb 0}}
#end

The results are:

+kff20 +sf1 +ef10     22 sec.
+kff20 +sf11 +ef20    22 sec.
+kff20 +sf1 +ef20     44 sec.

So there is a problem with 3.6 in the first case.  This problem has been
resolved on the 3.7 beta, so I don't see where it would be worth the
developers time to pursue fixing it on 3.6.   But at least this might give
you an idea of how to structure your code to work around it.


Post a reply to this message

From: gregjohn
Subject: Re: Bug (or feature to design around when animating).
Date: 9 Feb 2007 11:25:00
Message: <web.45cc9ff418adace640d56c170@news.povray.org>
Amazing detective work, David!

Question to Thorsten, et al:

When it comes to fonts, I'm willing to throw any aspect of what I'm doing on
the trash heap.  What are the optimum font file fomats for povray?  Could I
be using a buggy font?




"David E. LeMasters" <dle### [at] comcastnet> wrote:
> I played around with your code a bit more, pulling out things to try
> and locate what is causing the problem.  This is what I came up with:
>
> #if(clock<=0.5)
>   box{0,1}
> #else
>   text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
> #end
>
> When I run this on my linux box this is what I get:
>
> +kff20 +sf1 +ef10      5 sec.
> +kff20 +sf11 +ef20    23 sec.
> +kff20 +sf1 +ef20    163 sec.
>
> When I swap the box and text objects like this:
>
> #if(clock<=0.5)
>   text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
> #else
>   box{0,1}
> #end
>
> I get this:
>
> +kff20 +sf1 +ef10     22 sec.
> +kff20 +sf11 +ef20     4 sec.
> +kff20 +sf1 +ef20     27 sec.
>
>
> When I try this:
>
> #if(clock<=0.5)
>   text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
> #else
>   text{ ttf "COMICBD.ttf" "Caption2" 1,0 pigment{rgb 0}}
> #end
>
> The results are:
>
> +kff20 +sf1 +ef10     22 sec.
> +kff20 +sf11 +ef20    22 sec.
> +kff20 +sf1 +ef20     44 sec.
>
> So there is a problem with 3.6 in the first case.  This problem has been
> resolved on the 3.7 beta, so I don't see where it would be worth the
> developers time to pursue fixing it on 3.6.   But at least this might give
> you an idea of how to structure your code to work around it.


Post a reply to this message

From: Alain
Subject: Re: Bug (or feature to design around when animating).
Date: 9 Feb 2007 22:53:44
Message: <45cd41c8@news.povray.org>
gregjohn nous apporta ses lumieres en ce 06-02-2007 12:31:
> I have experienced a problem with an extreme render slowdown and I just came
> up with a workaround.

> Consider:

> //BEGIN SOME SDL-------------------
> #switch (clock)
> #range (-2/180,8/180)
>   #include "LOGO_SCENE.pov"

>   // LOGO_SCENE.pov is three lines of text object
>   // and a proximity pattern.
>   // Very few objects and fewer variables are called

> #break

> #range (8.0001/180,28/180)
>     #include "CHARACTER_SCENE.pov"

>   // "CHARACTER_SCENE.pov" has a few objects,
>   // but boxes with layered patterned pigments,
>   // a blob object with hundreds of components and
>   // multi-layered deep object textures,
>   // and maybe a thousand variable declarations.
> #break
> // END SOME SDL----

> Now consider this rendering scheme:

> SF  EF   TIME    WHAT IS IT
> 183 192   18 s   ten frames of "LOGO_SCENE.pov"
> 193 202    4 s   ten frames of "CHARACTER_SCENE.pov"

> Comment: Neither scene takes long to render, if one renders them alone by
> themselves.

> Now consider what happens if your render session contains both (which would
> happen if you let it render overnight):

> SF  EF   TIME    WHAT IS IT
> 188 197   80 s   five frames of "LOGO_SCENE.pov", five of
> "CHARACTER_SCENE.pov"

> Comment: The character scene now takes 36X longer to render!!


> Now consider making povray thinking about all of those variables and objects
> in its first frame (Even if they don't appear on screen!!)


> //BEGIN SOME SDL-------------------
> #switch (clock)
> #range (-2/180,8/180)
>    #include "LOGO_SCENE.pov"

>    // LOGO_SCENE.pov is three lines of text object
>   // and a proximity pattern.
>   // Very few objects and fewer variables are called

>   #include "CHARACTER_SCENE.pov"
>   // HEY, I added this!

> #break

> #range (8.0001/180,28/180)
>     #include "CHARACTER_SCENE.pov"

>   // "CHARACTER_SCENE.pov" has a few objects,
>   // but boxes with layered patterned pigments,
>   // a blob object with hundreds of components and
>   // multi-layered deep object textures,
>   // and maybe a thousand variable declarations.
> #break
> // END SOME SDL----


> SF  EF
> 188 197   13 s   five frames of "MODIFIED_logo_scene", five of
> "character_scene"

> Now there is no render slowdown!



> DISCUSSION.
> It is problematic to have to do this for proper design of an animation
> sequence. Could it be that povray is deciding how much memory to allocate
> for an
> entire render session based solely on the complexity of the very first
> frame?

> I could imagine that either it's an oversight, or something impossible for
> povray to do. I at least now know to #include the most complex scene file
> in frame 1 of an animation.  Hope this note helps others.
How many objects in the first set of frames? Is it less than the bounding threshold?
If the answer the second question is YES, then there will be NO bounding at all 
for the entire animation.
A solution: add 1 or 2 dumy objects, like small sphere with no_image, no_shadow 
and no_reflection or objects placed off field: behind the camera or 
behind/inside some opaque object.
Others have been hit with that problem in animation with a growing number of 
objects: 0 to 2 objects in the first frame and eventualy 1000s in subsequent frames.

-- 
Alain
-------------------------------------------------
The tree of liberty must be refreshed from time to time with the blood of
patriots and tyrants.
Thomas Jefferson


Post a reply to this message

From: Charles C
Subject: Re: Bug (or feature to design around when animating).
Date: 10 Feb 2007 02:05:00
Message: <web.45cd6d9e18adace6e33c01c00@news.povray.org>
Alain <ele### [at] netscapenet> wrote:
> How many objects in the first set of frames? Is it less than the bounding threshold?
> If the answer the second question is YES, then there will be NO bounding at all
> for the entire animation.
> A solution: add 1 or 2 dumy objects, like small sphere with no_image, no_shadow
> and no_reflection or objects placed off field: behind the camera or
> behind/inside some opaque object.
> Others have been hit with that problem in animation with a growing number of
> objects: 0 to 2 objects in the first frame and eventualy 1000s in subsequent frames.

That's interesting but doesn't fit with my experiences...  I made a simple
system for doing "distributed" animation rendering where basically each
machine or instance of POV-Ray renders an empty frame if a flag-file has
been produced by another machine on a shared drive.  Anyway, I haven't seen
or at least I haven't noticed a slow-up for starting with empty frames.
Also see my results I posted for a variation of Greg's sample. Slow up
occurs on late frames but only after a period of empties, even if the early
frames aren't empty.   I guess I replied in the wrong place, but here's
where it's at:

http://news.povray.org/povray.text.scene-files/message/%3Cweb.45ca98cae9bbeb3a632e613b0%40news.povray.org%3E/#%3Cweb.45
ca98cae9bbeb3a632e613b0%40news.povray.org%3E


Post a reply to this message

From: Charles C
Subject: Re: Bug (or feature to design around when animating).
Date: 10 Feb 2007 17:40:00
Message: <web.45ce496218adace6e94cc5130@news.povray.org>
"Charles C" <nomail@nomail> wrote:
> Alain <ele### [at] netscapenet> wrote:
> > How many objects in the first set of frames? Is it less than the bounding
threshold?
> > If the answer the second question is YES, then there will be NO bounding at all
> > for the entire animation.
> > A solution: add 1 or 2 dumy objects, like small sphere with no_image, no_shadow
> > and no_reflection or objects placed off field: behind the camera or
> > behind/inside some opaque object.
> > Others have been hit with that problem in animation with a growing number of
> > objects: 0 to 2 objects in the first frame and eventualy 1000s in subsequent
frames.
>
> That's interesting but doesn't fit with my experiences...  I made a simple
> system for doing "distributed" animation rendering where basically each
> machine or instance of POV-Ray renders an empty frame if a flag-file has
> been produced by another machine on a shared drive.  Anyway, I haven't seen
> or at least I haven't noticed a slow-up for starting with empty frames.
> Also see my results I posted for a variation of Greg's sample. Slow up
> occurs on late frames but only after a period of empties, even if the early
> frames aren't empty.   I guess I replied in the wrong place, but here's
> where it's at:
>
>
http://news.povray.org/povray.text.scene-files/message/%3Cweb.45ca98cae9bbeb3a632e613b0%40news.povray.org%3E/#%3Cweb.
45
> ca98cae9bbeb3a632e613b0%40news.povray.org%3E


I have to take back part of what I said... I tried my little distibuted
rendering system with a more complicated scene which I guess needs the
bounding more than my other one.  Instance #1 on Machine A flags frame #1
and renders it in seconds.  Instance #2 on Machine A sees that frame #1 has
been flagged and renders an empty frame and goes on and flags frame #2 and
starts rendering it at a snail's pace (read ~1+ hours? instead of < ~1min).
 Instance #1 finishes frame #1 renders an empty frame #2 and goes on to
render frame #3 at a snail's pace.  Any other instance of POV-Ray on any
machine render at a snail's pace.  The distro system itself works like a
charm but there's not a lot of point when running into this.....

Charles


Post a reply to this message

From: Tom York
Subject: Re: Bug (or feature to design around when animating).
Date: 11 Feb 2007 00:45:01
Message: <web.45ceac6718adace67d55e4a40@news.povray.org>
Alain <ele### [at] netscapenet> wrote:
> How many objects in the first set of frames? Is it less than the bounding threshold?
> If the answer the second question is YES, then there will be NO bounding at all
> for the entire animation.
> A solution: add 1 or 2 dumy objects, like small sphere with no_image, no_shadow
> and no_reflection or objects placed off field: behind the camera or
> behind/inside some opaque object.
> Others have been hit with that problem in animation with a growing number of
> objects: 0 to 2 objects in the first frame and eventualy 1000s in subsequent frames.

Couldn't the +MB option help here? Can you not set it to +MB5 or less (I
think the default is 25 objects)? No dummy objects would be needed in that
case.

Tom


Post a reply to this message

From: Charles C
Subject: Re: Bug (or feature to design around when animating).
Date: 11 Feb 2007 01:35:00
Message: <web.45ceb7d918adace67d5894630@news.povray.org>
"Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
> Alain <ele### [at] netscapenet> wrote:
> > How many objects in the first set of frames? Is it less than the bounding
threshold?
> > If the answer the second question is YES, then there will be NO bounding at all
> > for the entire animation.
> > A solution: add 1 or 2 dumy objects, like small sphere with no_image, no_shadow
> > and no_reflection or objects placed off field: behind the camera or
> > behind/inside some opaque object.
> > Others have been hit with that problem in animation with a growing number of
> > objects: 0 to 2 objects in the first frame and eventualy 1000s in subsequent
frames.
>
> Couldn't the +MB option help here? Can you not set it to +MB5 or less (I
> think the default is 25 objects)? No dummy objects would be needed in that
> case.
>
> Tom

Running into the same issue as mentioned, today I tried adding +MB, +MB0,
and Bounding=on to an animation ini file.  None of it helped in my case.
What did work was using those dummy objects... Mind you, a single tiny
invisible sphere didn't have any affect unless using +MB0 or +MB1, but a
ring of ten tiny invisible spheres did work with the default.  Some quick
testing it seems that the default threshold is (for 3.6.0 anyway) 10, not
25 as indicated in the docs.  Can anybody verify that for 3.6.1?  Anyway,
Woohoo!  Rendering fast again!
Charles


Post a reply to this message

From: Alain
Subject: Re: Bug (or feature to design around when animating).
Date: 11 Feb 2007 08:50:55
Message: <45cf1f3f$1@news.povray.org>
Charles C nous apporta ses lumieres en ce 11-02-2007 01:29:
> "Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
>> Alain <ele### [at] netscapenet> wrote:
>>> How many objects in the first set of frames? Is it less than the bounding
threshold?
>>> If the answer the second question is YES, then there will be NO bounding at all
>>> for the entire animation.
>>> A solution: add 1 or 2 dumy objects, like small sphere with no_image, no_shadow
>>> and no_reflection or objects placed off field: behind the camera or
>>> behind/inside some opaque object.
>>> Others have been hit with that problem in animation with a growing number of
>>> objects: 0 to 2 objects in the first frame and eventualy 1000s in subsequent
frames.
>> Couldn't the +MB option help here? Can you not set it to +MB5 or less (I
>> think the default is 25 objects)? No dummy objects would be needed in that
>> case.

>> Tom

> Running into the same issue as mentioned, today I tried adding +MB, +MB0,
> and Bounding=on to an animation ini file.  None of it helped in my case.
> What did work was using those dummy objects... Mind you, a single tiny
> invisible sphere didn't have any affect unless using +MB0 or +MB1, but a
> ring of ten tiny invisible spheres did work with the default.  Some quick
> testing it seems that the default threshold is (for 3.6.0 anyway) 10, not
> 25 as indicated in the docs.  Can anybody verify that for 3.6.1?  Anyway,
> Woohoo!  Rendering fast again!
> Charles

What you need is to add Bounding_Threshold = 1 or even 0 to your ini file. The 
default is set to 3 in the file povray.ini.
+bm2 is used to turn on binary tree bounding, instead of using the bounding box 
method. This flag don't work in version older than the 3.7 beta.
So, you need 1 dummy if the first scene have 2 finite objects, 2 dummy if you 
have 1 finite object and 3 dummy if you only have infinite objects and no finite 
ones.

-- 
Alain
-------------------------------------------------
EVERYTHING HAS A GENDER

You may not know this but many nonliving things have a gender...

An Hourglass is Female, because over time, the weight shifts to the bottom.


Post a reply to this message

From: Charles C
Subject: Re: Bug (or feature to design around when animating).
Date: 12 Feb 2007 00:20:00
Message: <web.45cff79018adace69926319c0@news.povray.org>
Alain <ele### [at] netscapenet> wrote:
> Charles C nous apporta ses lumieres en ce 11-02-2007 01:29:
> What did work was using those dummy objects... Mind you, a single tiny
> > invisible sphere didn't have any affect unless using +MB0 or +MB1, but a
> > ring of ten tiny invisible spheres did work with the default.  Some quick
> > testing it seems that the default threshold is (for 3.6.0 anyway) 10, not
> > 25 as indicated in the docs.  Can anybody verify that for 3.6.1?  Anyway,
> > Woohoo!  Rendering fast again!
> > Charles
>
> What you need is to add Bounding_Threshold = 1 or even 0 to your ini file. The
> default is set to 3 in the file povray.ini.

Yes, as I mentioned I tried both +MB0 and +MB1 with the single sphere but I
prefered in this instance to make something that works well with default
settings.  I see the "Bounding_Threshold = 3" in POVRAY.INI but strangely
10 sphere's stopped the problem while 11 did not, making me conclude that
the real threshold being used (without my adding anything)was 10, but I'm
not sure why....  Strange.
Charles


Post a reply to this message

<<< Previous 6 Messages Goto Initial 10 Messages

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