 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] inapg inrafr> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Some time ago I had (epsilon-related) problems with near-cylindrical cones. Not
render time, though, but incorrect placement.
Margus
Peter Popov wrote:
>
> This is odd as cylinders are internally represented as cones with two
> equal radii.
>
> Peter Popov
> ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
> 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.
As an after thought the reason that bounding helps is a two fold process.
First an infinite object that has a finite bounding object applied to it
becomes clipped to the size of the bounding object where they intersect.
Secondly manual bounding of a large number of objects in a csg operation
often helps speed up intersection testing.
I know this does not solve the problem but it does explain why bounding
will help to correct for it.
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: First an infinite object that has a finite bounding object applied to it
: becomes clipped to the size of the bounding object where they intersect.
Not exactly.
The projection of the infinite object on screen becomes clipped by the
projection of the bounding object on screen.
If you want true bounding _and_ clipping you have to make this:
bounded_by { Object }
clipped_by { bounded_by }
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The big problem is that POV encloses the origin of the cone in the cone's
bounding box. The origin is the place where the cone narrows down to a
single point. So although your cone is only 30 units long or so, POV
makes the bounding box big enough to fit a 1000 unit long cone (or some
other really big number).
-Nathan
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
>
> #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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Not only this is explains very clearly the problem, but it makes me think of a
relatively simple workaround when the cones are produced by a macro or a
utility : when the cone looks too much like a cylinder (rule to be defined,
problably a simple one), replace it by a cylinder !
Thanks Nathan.
Thanks also to Smellenbergh for providing the temporary code fix.
Unfortunately there's no way I can compile a patched version myself but it
will be helpful to other people.
Gilles
Nathan Kopp wrote:
> The big problem is that POV encloses the origin of the cone in the cone's
> bounding box. The origin is the place where the cone narrows down to a
> single point. So although your cone is only 30 units long or so, POV
> makes the bounding box big enough to fit a 1000 unit long cone (or some
> other really big number).
>
> -Nathan
>
> 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
> >
> > #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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 22 Jul 1999 00:03:16 -0400, Nathan Kopp <Nat### [at] Koppcom> wrote:
>The big problem is that POV encloses the origin of the cone in the cone's
>bounding box. The origin is the place where the cone narrows down to a
>single point. So although your cone is only 30 units long or so, POV
>makes the bounding box big enough to fit a 1000 unit long cone (or some
>other really big number).
Hi, Nathan. It's been many years but I once did an impromptu comparison to
see how much difference manual bounding could make on simple shapes or CSG
objects. I experimented with ever tighter-fitting boxes and spheres to see
what the rendering speed improvement could yield. I also used other shape
primitives since any of them can be used for bounding purposes, though the
box and sphere are the most highly optimized, according to the docs section
4.5.6.2. For example, is it advantageous to bound a cone with a
tight-fitting cone as opposed to a box?
It made a difference back then with an older version of POV-Ray but I
don't know how relevant or practical this would be today, using v3.1g. This
was before Dieter implemented the vista and light buffers as a speed-up.
While sometimes the improvement was dramatic I do recall that there was an
apparent (and not unexpected result) of diminishing returns as the bounding
shapes were dimensioned closer and closer to the object size.
--
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alan Kong wrote:
> Hi, Nathan. It's been many years but I once did an impromptu comparison to
> see how much difference manual bounding could make on simple shapes or CSG
> objects.
> --
> Alan
I have had signifigant success manualy bounding certain types of csg
operations. Particularly an object or group of objects created within
a loop and then a csg applied to the that or during the loop. I have
seen as much as a 50% increase in rendering times depending upon the
number of objects and how many are intersected by the csg'ing object.
The photon patch also bennifits from manual bounding in certain situations
in both calculation times and for non internaly bound objects such as
polygons, quartics, quadrics, etc...
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 22 Jul 1999 09:01:24 -0700, Ken <tyl### [at] pacbellnet> wrote:
> I have had signifigant success manualy bounding certain types of csg
>operations. Particularly an object or group of objects created within
>a loop and then a csg applied to the that or during the loop. I have
>seen as much as a 50% increase in rendering times depending upon the
>number of objects and how many are intersected by the csg'ing object.
Ken, would that be a 50% *decrease* in rendering times? If so, that's
really significant and I'll have to keep that in mind the next time I write
a scene using a loop.
--
Alan
------------------------------------------------
"Master Yoda, is the Dark side stronger?"
"No! No. Easier, more seductive, quicker to join
in a fight. If once you start down the Dark path
forever will it dominate your destiny, as it did
Obi-Wan's apprentice." -------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote in message <37974054.E309C52B@pacbell.net>...
>
>
>Alan Kong wrote:
>
>> Hi, Nathan. It's been many years but I once did an impromptu comparison
to
>> see how much difference manual bounding could make on simple shapes or
CSG
>> objects.
>> --
>> Alan
>
> I have had signifigant success manualy bounding certain types of csg
>operations. Particularly an object or group of objects created within
>a loop and then a csg applied to the that or during the loop. I have
>seen as much as a 50% increase in rendering times depending upon the
>number of objects and how many are intersected by the csg'ing object.
However, if manual bounding of a CSG object is done wrong or unneccesarily,
it can result in an order of magnitude slowdown.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alan Kong wrote:
>
> On Thu, 22 Jul 1999 09:01:24 -0700, Ken <tyl### [at] pacbellnet> wrote:
>
> > I have had signifigant success manualy bounding certain types of csg
> >operations. Particularly an object or group of objects created within
> >a loop and then a csg applied to the that or during the loop. I have
> >seen as much as a 50% increase in rendering times depending upon the
> >number of objects and how many are intersected by the csg'ing object.
>
> Ken, would that be a 50% *decrease* in rendering times? If so, that's
> really significant and I'll have to keep that in mind the next time I write
> a scene using a loop.
>
> --
> Alan
That would indeed be a 50% decrease in rendering times. I discovered this
when going through that menger sponge fractal craze a couple of months
ago. Without the manual bounding some of the images I posted may still be
rendering even now :) 50% is by no means gauranteed or substantiated but
it is my best guess for some circumstances.
If you are interested in testing this for your self I might be able to dig
up so code that illustrates it fairly well for you though I suspect you
could, with your experience, easily set up your own working test scene.
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
> However, if manual bounding of a CSG object is done wrong or unneccesarily,
> it can result in an order of magnitude slowdown.
>
> Mark
Amen to that !
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 22 Jul 1999 21:39:43 -0700, Ken <tyl### [at] pacbellnet> wrote:
>If you are interested in testing this for your self I might be able to dig
>up so code that illustrates it fairly well...
Thanks for the offer, Ken, but I'll commit the technique to notes for now.
I'm trying to think up with a decent radiosity scene, having been inspired
recently with examples by Warp and others. Their scenes look much nicer than
anything I've ever done and I'm examining their work and (hopefully)
learning how they place objects and lighting in the room.
--
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
