This one puzzles me...
The code below shows 2 bunches of cones. One is called "slow", the other
one "quick". Render the code to see why : render the "quick" ones first
and then the "slow" ones.
The only difference between the slow and quick ones is that the slow
ones have a slightly larger base radius.
POV says that the slow cones are infinite objects !!!!
I came upon this problem when rendering a tree : for some mysterious
reason, some trees took forever to render (not counting parsing time).
The "slow" cones below were (painstakingly) extracted from a file
containing 16000 cones.

Scaling the cones or moving the camera sometimes make the problem
disappear, sometimes not.

Any idea about what's going wrong ?

Gilles


#include "colors.inc"
#declare PdV=<-1, 64 , -1>;
#declare PdA=<-1,64,0>;
camera {location  PdV direction <0.0 , 0.0 , 2 > up y  right 4*x/3
look_at   PdA}
//-----------------------------------------
light_source{<130,40,-200> color White*1.8}
#declare slow=
union{
cone{<-1.4877,62.1686,7.44824> ,0.204866,<-1.58298,62.4111,7.54819>
,0.204862}
cone{<-1.58298,62.4111,7.54819> ,0.204862,<-1.67826,62.6535,7.64813>
,0.204857}
cone{<-1.67826,62.6535,7.64813> ,0.204857,<-1.77355,62.896,7.74808>
,0.204853}
cone{<-1.77355,62.896,7.74808> ,0.204853,<-1.86883,63.1384,7.84802>
,0.204848}
cone{<-1.86883,63.1384,7.84802> ,0.204848,<-1.96411,63.3809,7.94797>
,0.204844}
cone{<-1.96411,63.3809,7.94797> ,0.204844,<-2.05939,63.6233,8.04791>
,0.20484}
cone{<-2.05939,63.6233,8.04791> ,0.20484,<-2.15468,63.8658,8.14786>
,0.204835}
cone{<-2.15468,63.8658,8.14786> ,0.204835,<-2.24996,64.1082,8.2478>
,0.204831}
cone{<-2.24996,64.1082,8.2478> ,0.204831,<-2.34524,64.3507,8.34775>
,0.204826}
cone{<-2.34524,64.3507,8.34775> ,0.204826,<-2.44052,64.5931,8.44769>
,0.204822}
cone{<-2.44052,64.5931,8.44769> ,0.204822,<-2.5358,64.8356,8.54764>
,0.204818}
cone{<-2.5358,64.8356,8.54764> ,0.204818,<-2.63109,65.078,8.64758>
,0.204813}
cone{<-2.63109,65.078,8.64758> ,0.204813,<-2.72637,65.3205,8.74753>
,0.204809}
cone{<-2.72637,65.3205,8.74753> ,0.204809,<-2.82165,65.5629,8.84747>
,0.204804}
cone{<-2.82165,65.5629,8.84747> ,0.204804,<-2.91693,65.8054,8.94741>
,0.2048}
}
#declare quick=
union{
cone{<-1.4877,62.1686,7.44824> ,0.254866,<-1.58298,62.4111,7.54819>
,0.204862}
cone{<-1.58298,62.4111,7.54819> ,0.254862,<-1.67826,62.6535,7.64813>
,0.204857}
cone{<-1.67826,62.6535,7.64813> ,0.254857,<-1.77355,62.896,7.74808>
,0.204853}
cone{<-1.77355,62.896,7.74808> ,0.254853,<-1.86883,63.1384,7.84802>
,0.204848}
cone{<-1.86883,63.1384,7.84802> ,0.254848,<-1.96411,63.3809,7.94797>
,0.204844}
cone{<-1.96411,63.3809,7.94797> ,0.254844,<-2.05939,63.6233,8.04791>
,0.20484}
cone{<-2.05939,63.6233,8.04791> ,0.25484,<-2.15468,63.8658,8.14786>
,0.204835}
cone{<-2.15468,63.8658,8.14786> ,0.254835,<-2.24996,64.1082,8.2478>
,0.204831}
cone{<-2.24996,64.1082,8.2478> ,0.254831,<-2.34524,64.3507,8.34775>
,0.204826}
cone{<-2.34524,64.3507,8.34775> ,0.254826,<-2.44052,64.5931,8.44769>
,0.204822}
cone{<-2.44052,64.5931,8.44769> ,0.254822,<-2.5358,64.8356,8.54764>
,0.204818}
cone{<-2.5358,64.8356,8.54764> ,0.254818,<-2.63109,65.078,8.64758>
,0.204813}
cone{<-2.63109,65.078,8.64758> ,0.254813,<-2.72637,65.3205,8.74753>
,0.204809}
cone{<-2.72637,65.3205,8.74753> ,0.254809,<-2.82165,65.5629,8.84747>
,0.204804}
cone{<-2.82165,65.5629,8.84747> ,0.254804,<-2.91693,65.8054,8.94741>
,0.2048}
}
#declare toto=object{quick} // render this  first
//#declare toto=object{slow} // render this last

#declare i=-2;#while (i<5) #declare j=0;#while (j<20)
object{toto translate <i,0,j> pigment{Red}}
#declare j=j+1;#end #declare i=i+1;#end
background{White}

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
: Any idea about what's going wrong ?

  Perhaps there's something wrong with the automatic bounding? Just a guess.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Gilles Tran wrote:
> 
> This one puzzles me...
> The code below shows 2 bunches of cones. One is called "slow", the other
> one "quick". Render the code to see why : render the "quick" ones first
> and then the "slow" ones.
> The only difference between the slow and quick ones is that the slow
> ones have a slightly larger base radius.
> POV says that the slow cones are infinite objects !!!!
> I came upon this problem when rendering a tree : for some mysterious
> reason, some trees took forever to render (not counting parsing time).
> The "slow" cones below were (painstakingly) extracted from a file
> containing 16000 cones.
> 
> Scaling the cones or moving the camera sometimes make the problem
> disappear, sometimes not.
> 
> Any idea about what's going wrong ?
> 
> Gilles

It obviously has something to do with the small difference between the base and
the top of the slow cones. The difference here is more or less redundant. I
changed them into cylinders and it rendered fast and seamless.
I don't know what the actual cause is, it's somewhere in the code, but assuming
you don't want to make a patch for this I guess there's not much more you can do
then adapt your scene-code or sit and wait.

Regards,

Remco

Post a reply to this message

It's very strange in fact. Sometimes it also happens when the difference between top
and base is not so small (and doesn't happen when there's no difference). In fact,
it seems that even when pov doesn't say they're are "infinite" some cones render
very slowly under certain circumstances, as if POV would consider them as very large
for some of its calculations.
After Nieminen's suggestion, manual bounding of the cones removes the problem so at
least there's a possible workaround to investigate.
Of course, this is a problem only when there are many (hundred) cones like this in a
scene so maybe it's not worth reporting as a bug.

G.

Remco de Korte wrote:

> It obviously has something to do with the small difference between the base and
> the top of the slow cones. The difference here is more or less redundant. I
> changed them into cylinders and it rendered fast and seamless.
> I don't know what the actual cause is, it's somewhere in the code, but assuming
> you don't want to make a patch for this I guess there's not much more you can do
> then adapt your scene-code or sit and wait.
>
> Regards,
>
> Remco

Post a reply to this message

Gilles Tran wrote:
> 
> This one puzzles me...
> The code below shows 2 bunches of cones. One is called "slow", the other
> one "quick". Render the code to see why : render the "quick" ones first
> and then the "slow" ones.
> The only difference between the slow and quick ones is that the slow
> ones have a slightly larger base radius.
> POV says that the slow cones are infinite objects !!!!
> I came upon this problem when rendering a tree : for some mysterious
> reason, some trees took forever to render (not counting parsing time).
> The "slow" cones below were (painstakingly) extracted from a file
> containing 16000 cones.
> 
> Scaling the cones or moving the camera sometimes make the problem
> disappear, sometimes not.
> 
> Any idea about what's going wrong ?
> 
> Gilles

Perhaps the programs epsilon limit is causing rounding errors ?

  Your slow cones are only .000004 pov units different between the
radius at each end. Adding .000010 to the first radius in the cone
statement at least removes the infinte object problem but it still
renders slowly.

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
: Of course, this is a problem only when there are many (hundred) cones like this in a
: scene so maybe it's not worth reporting as a bug.

  If it really is a bug, I think it should be reported.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

As bare as possible :

camera {location  -z*200} light_source{<1,1,-1>*1000 color 2}
cone{0 ,15,<8,90,8> ,15.1 pigment{rgb <1,0,0>}}

This is a pretty normal infinite cone... There maybe something about the
epsilon value, but in this case there's nothing uncommon about this cone, at
least nothing you wouldn't hand-code.

Actually, the fact that some non-infinite cones render more slowly than others
bother me more than the infinite cone problem itself, because at least I can
hunt down the infinite cones but can't do anything for the slow finite ones
when they pop up randomly in a 16000-cone tree and make it useless.

Well, I think I'll report it (and I supported Ken Tyler some time ago when he
said it was better to let the pov-team develop pov instead of bothering them
about unusual bugs <sigh> ).

Gilles

Ken wrote:

> Perhaps the programs epsilon limit is causing rounding errors ?
>
>   Your slow cones are only .000004 pov units different between the
> radius at each end. Adding .000010 to the first radius in the cone
> statement at least removes the infinte object problem but it still
> renders slowly.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
> http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

Gilles Tran wrote:
> 
> As bare as possible :
> 
> 	
> 
> This is a pretty normal infinite cone... There maybe something about the
> epsilon value, but in this case there's nothing uncommon about this cone, at
> least nothing you wouldn't hand-code.

Strange !
 

> Well, I think I'll report it (and I supported Ken Tyler some time ago when he
> said it was better to let the pov-team develop pov instead of bothering them
> about unusual bugs <sigh> ).
> 
> Gilles

  And Ken Tyler appreciated that support when everyone was accusing me
of blasphemy :)

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

On Tue, 20 Jul 1999 14:00:14 +0200, Remco de Korte
<rem### [at] xs4allnl> wrote:

>It obviously has something to do with the small difference between the base and
>the top of the slow cones. The difference here is more or less redundant. I
>changed them into cylinders and it rendered fast and seamless.
>I don't know what the actual cause is, it's somewhere in the code, but assuming
>you don't want to make a patch for this I guess there's not much more you can do
>then adapt your scene-code or sit and wait.
>
>Regards,
>
>Remco

This is odd as cylinders are internally represented as cones with two
equal radii.


Peter Popov
ICQ: 15002700

Post a reply to this message

> This is odd as cylinders are internally represented as cones with two
> equal radii.
>
> Peter Popov
> ICQ: 15002700

And manually bounding each cone by the corresponding cylinder removes the whole
problem (-UR setting necessary)...
BTW, manually bounding the cones speeds them all, see below (compare slow_cone_finite
and slow_cone_finite_bounded for instance).
This problem may have been with POV since the very beginning but until POV 3.0 few
people ventured to make scenes with tens of thousands of cones so it never appeared.

G.

camera {location  -z*1000} light_source{<1,1,-1>*1000 color 2} background{rgb 1}
#declare slow_cone_infinite= cone{0 ,15,<8,90,8> ,14.9}
#declare slow_cone_infinite_bounded= cone{0 ,15,<8,90,8> ,14.9
bounded_by{cylinder{0,<8,90,8> ,15}}}
#declare slow_cone_finite= cone{0 ,15,<8,90,8> ,14.8}
#declare slow_cone_finite_bounded= cone{0 ,15,<8,90,8> ,14.8
bounded_by{cylinder{0,<8,90,8> ,15}}}
#declare fast_cone= cone{0 ,15,<8,90,8> ,10}
#declare fast_cone_bounded= cone{0 ,15,<8,90,8> ,10 bounded_by{cylinder{0,<8,90,8>
,15}}}

#declare testcone=object{slow_cone_infinite}
#declare testcone=object{slow_cone_finite}
#declare testcone=object{fast_cone}

#declare testcone=object{slow_cone_infinite_bounded}
#declare testcone=object{slow_cone_finite_bounded}
#declare testcone=object{fast_cone_bounded}

#declare i=-10;#while (i<10) #declare j=0;#while (j<200)
object{testcone translate <i,0,j>*35 pigment{rgb<1,0,0>}}
#declare j=j+1;#end #declare i=i+1;#end

Post a reply to this message