Hi all,

    I may very well answer my own question here but here goes anyway.

    What are difference CSG operations so darn slow? I had a basic box from
which I was trying to cust about 200 holes. When I did this the render too
for ever and the stats showed LOTS of cylinder checks (the holes were made
with cylinders).
    I decided to fake it by just placing very thin black cylinders instead
of holes because in my case the underside of the box was not to be seen and
since it was dark inside these black cylinders made it look like holes to
the inside. This rendered very quickly with many fewer cylinder checks.
    So, my hopothysis is this...on the second case, as soon as the box or
black cylinder objects are found by a cast ray, the ray is ended and the
pixel is plotted. In the first case, when a ray enters a hole it must check
and recheck many times for other objects as it passes through the hole,
hence the higher stats and the slower render.

    Is this correct? Is there any way to make the holes and have a
reasonable render time?

Thanks,

--Rainer

Post a reply to this message

Rainer Mager wrote:
> 
> Hi all,
> 
>     I may very well answer my own question here but here goes anyway.
> 
>     What are difference CSG operations so darn slow? I had a basic box from
> which I was trying to cust about 200 holes. When I did this the render too
> for ever and the stats showed LOTS of cylinder checks (the holes were made
> with cylinders).
>     I decided to fake it by just placing very thin black cylinders instead
> of holes because in my case the underside of the box was not to be seen and
> since it was dark inside these black cylinders made it look like holes to
> the inside. This rendered very quickly with many fewer cylinder checks.
>     So, my hopothysis is this...on the second case, as soon as the box or
> black cylinder objects are found by a cast ray, the ray is ended and the
> pixel is plotted. In the first case, when a ray enters a hole it must check
> and recheck many times for other objects as it passes through the hole,
> hence the higher stats and the slower render.
> 
>     Is this correct? Is there any way to make the holes and have a
> reasonable render time?
> 
> Thanks,
> 
> --Rainer


  The way the Pov calculates the intersection testing is related
to it's use of internally generated bounding boxes. As you increase
the number of objects in the difference operation the greater the
number of intersecting surface tests the program is required to
perform.
  What I do do cut down on this intersection testing is to manually
bound the difference operation. If you are differencing a 1 unit
cube then add bounding with a 1.1 unit cube at the end of the
difference operation. You should see a noticeable improvement.
  You will also see where pov will issue a warning that you have
unnecessarily used bounding. Ignore this message. It means nothing
in this case. If you used bounding on a two object difference
operation it would be true. Where you have multiple objects in the
difference statement the warning message does not apply.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: If you are differencing a 1 unit
: cube then add bounding with a 1.1 unit cube at the end of the
: difference operation.

  Why 1.1 and not 1? AFAIK the bounding box should be as small as possible
(of course still fitting the bounded object inside it).

-- 
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

Nieminen Mika wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> : If you are differencing a 1 unit
> : cube then add bounding with a 1.1 unit cube at the end of the
> : difference operation.
> 
>   Why 1.1 and not 1? AFAIK the bounding box should be as small as possible
> (of course still fitting the bounded object inside it).
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

  I have been worried about the coincedent surface problem. If you bound
an object using an object that is too small it will end up clipping
the object you are trying to bound. I simply over scale a bit to avoid
this possibilty. All examples I have seen for bounding have always been
scaled larger than the object to be bound and I practice by example.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Tue, 27 Apr 1999 10:10:34 +0900, Rainer Mager wrote:
>    So, my hopothysis is this...on the second case, as soon as the box or
>black cylinder objects are found by a cast ray, the ray is ended and the
>pixel is plotted. In the first case, when a ray enters a hole it must check
>and recheck many times for other objects as it passes through the hole,
>hence the higher stats and the slower render.

Actually, I believe you have it backwards.  Here's what happens:

A ray is shot at the difference object.  It hits a face of the object.
Chances are this is a face of the box, or possibly the end of one of 
the cylinders.  To find this intersection, POV asks every sub-object
of the object to return all intersections of the ray with that sub-object,
then picks the closest one.

POV now must check this intersection to make sure that it is inside the 
box and outside of every cylinder before it is considered a valid hit.  
If it isn't valid (i.e. it's inside one of the cylinders, or it's not 
inside the box) then it gets ignored and we go on to the next-closest 
intersection.  When we finally find a valid intersection, we calculate 
its color and return that as the value for the ray (keeping in mind 
that the shadow calculation for each light source used to calculate 
the color is also a ray and performs the same operation.)  

So, when a ray hits the object you're building, POV first needs to ask 
201 objects to calculate their intersections, then needs to test one or 
more hits against 200 objects to determine if they're valid, then needs 
to do the same thing again for each light source in the scene to calculate 
shadows. In your scene, with one light source, this comes out to at least 
402 hit tests and either 200 or 400 insideness tests (depending on whether
the hit might be in a shadow) for each ray that hits your object.  Bounding 
helps this a lot, clearly, but it's also likely that the bounding structures 
in a CSG could be improved at the source level.

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:   I have been worried about the coincedent surface problem. If you bound
: an object using an object that is too small it will end up clipping
: the object you are trying to bound. I simply over scale a bit to avoid
: this possibilty. All examples I have seen for bounding have always been
: scaled larger than the object to be bound and I practice by example.

  If I have understood correctly how bounding boxes work, then there's no
coincident surfaces problem with them. I'll try to explain:

union
{ object { Object1 }
  object { Object2 }
}

  Suppose that those two objects have a coincident surface. Now povray
will test ray-object intersections with those objects. When it's done, it
has to decide which one is nearer than the other. Since they are exactly
at the same place, the result is undefined.

  Now, suppose we have this:

object
{ Object1
  bounded_by { Object2 }
}

  You seem to think that this works like the union above.
  No. It works this way:
  First povray makes ray-object intersection tests with Object2. If the ray
doesn't hit Object2, then it forgets Object1.
  If the ray hits Object2, then it makes ray-object intersection tests with
Object1.
  The critical difference between these two things (union and bounding) is
that in the second case povray does _not_ calculate which object is nearer
(it doesn't need to). Since it doesn't have to calculate this, there's no
coincident surfaces problem. Povray calculates if a ray hits Object1 only
if it hits Object2.

  This has an interesting consequence: The bounding box doesn't need to be
surrounding the object it's bounding; it's enough that from the point of
view of the camera it completely covers the bounded object on screen.
  You can have your Object1 at 100000 units away from the camera and the
bounding Object2 at 0.01 units away from the camera (or viceversa). If the
Object2 completely covers Object1 on the screen, then the image will render
properly.
  Of course it's more easier to put bounding boxes aroung the objects they
are bounding. This way you can move the object and/or camera freely without
needing to change the position of the bounding object. But it's an
interesting detail which helps to understand how bounding boxes work.

  So why the bounding box should be as small as possible? The smaller the
bounding box is on screen, the less ray-object intersection tests povray
will make for Object1.

-- 
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

On 27 Apr 1999 12:41:04 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>  This has an interesting consequence: The bounding box doesn't need to be
>surrounding the object it's bounding; it's enough that from the point of
>view of the camera it completely covers the bounded object on screen.

You neglect reflected and shadow rays, but other than that this explanation 
seems reasonably correct.  As a result, you could use this effect to create 
a "vampire object" with no reflection and no shadow (bound it with a small
sphere around the camera), or an invisible object that casts a shadow (bound
it with a small sphere around the light source.)  Don't forget the -UR on 
the command line.
 
It's also worth noting that if you specify two or more bounding objects, the 
ray must hit all of them before it will be tested against the real object, 
so if you want to bound by multiple disjoint spheres, make sure to union 
them first.

Post a reply to this message

Ok, I follow all of this but what happens why you are doing a lot of
differences which take up a majority of the image.

For example, I have something like this:

difference {
    box {
        <-10,0,-10>, <10,1,10>
        texture...
    }
    #while...lots of cylinders like this...
        cylinder {
            <xx, -0.1, zz>, <xx, 1.1, zz>, rr
        }
    #end
}

and my view of this scene basically is just this box thingy. Is there any
way to speed this up? If I bound the whole thing it doesn't help because
every ray hits it anyway. I can try to strategically bind the cylinders but
this doesn't seem to help much at all. The only way I can think of that
would help significanly is making a lot of small boxes with singly cylinder
differences and then putting all of them together to seem like a single
large box. For my real scene, however, this might be difficult. I'll look
into it.


--Rainer


----- Original Message -----
From: Ken <tyl### [at] pacbellnet>
>
>   The way the Pov calculates the intersection testing is related
> to it's use of internally generated bounding boxes. As you increase
> the number of objects in the difference operation the greater the
> number of intersecting surface tests the program is required to
> perform.
>   What I do do cut down on this intersection testing is to manually
> bound the difference operation. If you are differencing a 1 unit
> cube then add bounding with a 1.1 unit cube at the end of the
> difference operation. You should see a noticeable improvement.
>   You will also see where pov will issue a warning that you have
> unnecessarily used bounding. Ignore this message. It means nothing
> in this case. If you used bounding on a two object difference
> operation it would be true. Where you have multiple objects in the
> difference statement the warning message does not apply.
>
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net

Post a reply to this message

On Wed, 28 Apr 1999 11:46:37 +0900, Rainer Mager wrote:
>and my view of this scene basically is just this box thingy. Is there any
>way to speed this up? If I bound the whole thing it doesn't help because
>every ray hits it anyway. I can try to strategically bind the cylinders but
>this doesn't seem to help much at all. 

You are correct.  When POV is testing whether a hit is inside, it ignores 
bounded_by.  To me, that feels like a bug.  But you wouldn't gain much by
bounding the cylinders anyway.  What would be nice is if POV could use better
internal structures to allow it to do bounding more efficiently on large
CSG objects, as it currently traverses a linked list to find hits and/or
test insideness.

>The only way I can think of that
>would help significanly is making a lot of small boxes with singly cylinder
>differences and then putting all of them together to seem like a single
>large box. 

I tried this when I was trying to model a sponge and I never did get something
that looked quite right.

Post a reply to this message

Ron Parker <par### [at] my-dejanewscom> wrote:
: You neglect reflected and shadow rays, but other than that this explanation 
: seems reasonably correct.  As a result, you could use this effect to create 
: a "vampire object" with no reflection and no shadow (bound it with a small
: sphere around the camera), or an invisible object that casts a shadow (bound
: it with a small sphere around the light source.)  Don't forget the -UR on 
: the command line.

  I have never thought about that. It's even more interesting.

-- 
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