 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] pacbell net> 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
|
|
| |
| |
|
|
|
|
| |
|
|
