POV-Ray : Newsgroups : povray.programming : Bug? difference of intersections isn't right. : Re: Bug? difference of intersections isn't right. Server Time
29 Jul 2024 12:24:18 EDT (-0400)
  Re: Bug? difference of intersections isn't right.  
From: Nieminen Mika
Date: 22 Jul 1998 07:37:13
Message: <35b5c0d9.0@news.povray.org>
In povray.general Ron Parker <ron### [at] rongwmicrocom> wrote:
: since merges are more expensive than unions

  Can you present some facts to support his claim?
  I once made a test: the camera was in the negative z direction, looking at
the origin. There was 20 semitransparent spheres in the z axis, from to origin
to the positive z direction. The spheres partially overlapped.
  I don't remember render times, but if the spheres were into a union the
rendering time was more than 2 times the time if the spheres were merged.
  I deduced from this that merge is actually faster than union. And this
makes sense. Why? Well, I don't know how povray merges the objects, but
I can imagine a really simple algorithm for that:
  Suppose that we are calculating the ray that is cast from the middle of
the screen, ie. it hits all the spheres at the center.
  First, suppose that the spheres are into a union. What happens? The ray
hits the outer surface of the first sphere. The color and brightness etc
of this point is calculated. Now another ray is calculated. It hits the
outer surface of the second sphere. Again, the color and brightness is
calculated. A third ray is cast: It hits the inner surface of the first
sphere (the 1st and 2nd spheres overlap partially). Again coloration is
calculated. Then a fourth ray is cast, and it hits the outer surface of
the third sphere, and coloration is calculated. And so on, and so on...
  Now, imagine that the spheres are merged:
  We have now a counter which starts from 0.
  The first ray hits the outer surface of the first sphere. Since the counter
is 0. the coloration of this surface is calculated and we increase the counter.
  A second ray is cast. It hits the outer surface of the second sphere. Since
the counter is greater than 0, we just ignore this surface (ie. no coloration
is calculated). We increase the counter (which is now 2, since we are inside
2 objects).
  A third ray is cast. Now it hits the inner surface of the first sphere, so
we decrease the counter. Since it's not 0 after the decrementation, we ignore
this surface too.
  A fourth ray is cast. It hits the outer surface of the third sphere. Since
the counter is not 0, we ignore this surface and increment the counter.
  And so on and so on.
  At last, we hit the inner surface of the last sphere and decrement the
counter. Now the counter becomes 0, so we calculate the coloration of this
surface.
  What happened? With union, we calculated a total of 40 color values, but
with merge we calculated only 2 (and this is logical: with union we see all
the 40 surfaces but with merge we see only 2, since all the inner surfaces
are removed).
  I suppose that povray uses this kind of algorithm. So can you present some
facts why merge is slower than union?

-- 
                                                              - Warp. -


Post a reply to this message

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