clipka <ano### [at] anonymousorg> wrote:
> Am 23.08.2017 um 14:09 schrieb Bald Eagle:
> > Can anyone tell me if this is still the case?
> >
> > From (bottom of page):
> > http://www.povray.org/documentation/view/3.6.0/184/
> >
> > But this automatic bounding is not perfect. There are situations where a perfect
> > automatic bounding is very hard to calculate. One situation is the difference
> > and the intersection CSG operations. POV-Ray does what it can, but sometimes it
> > makes a pretty poor job. This can be specially seen when the resulting CSG
> > object is very small compared to the CSG member objects.
--->8---
> > This didn't seem to me to be a factual representation - I believe there are some
> > straightforward algorithms for determining the bounding box of the intersection
> > for any two overlapping axis-aligned bounding boxes (AABB).
> > Am I wrong?
>
> Eyeballing the axis-aligned bounding box of an intersection as the
> intersection of the children's axis-aligned bounding boxes is indeed
> trivial, and that's why POV-Ray already does exactly that by default.
>
> (*Well, not /totally/ exactly: When planes or quartics are involved,
> POV-Ray tries to come up with tighter bounds for them by using the
> b'boxes of the sibling objects as constraints.)
>
> The problem hinted at by the docs is that sometimes this simple
> algorithm gives you a bounding box far larger than necessary, and in
> such cases providing a "hand-made" bounding box will increase rendering
> speed.
>
> There is no generic algorithm to compute the exact b'box of an
> intersection. Each specific combination of primitives would need its own
> algorithm.
---8<---
> > If this is still an issue, are there certain cases that are especially
> > problematic for certain CSG operations?
>
> Yes: All cases and none at all. Almost /any/ combination of primitives
> can be used to come up with pathological cases.

Interesting, as usual.

I was wondering about this after coming across something about the automatic
bounding from the version 3.5 sample scene chess2.pov while rendering some of
those old files.
Chess2 uses quartics and I changed them to isosurfaces, cone and cylinder for
the various shapes some time ago when I modified it for version 3.7.

Except for the Rook chess piece, removal of the manual bounding appears okay on
all other pieces, and the reason I remember commenting that out for v3.5 was
because of improvements for automatic bounding made back then.
You know, progress; so was thinking move ahead and leave manual bounding behind
if at all possible.

No idea how the malformed Rook was overlooked, if it always was, and I'm unable
to run version 3.5 right now to check on it from there so I can only look at it
from 3.7 with version setting of 3.5. At least the bounded_by { sphere { <0, 5,
0>, 5.831 } } is still there allowing uncommenting as a fix.

According to what is said here, I suppose that particular CSG object must be a
problem due to the intersecting planes and quartics (infinite shapes). And
curiously, for me anyhow, is that the deformation changes depending on
orientation or camera view. From chess2.pov:

#version 3.5;

#include "shapes.inc"

#declare Cylinder_Y =
 quadric
  {<1, 0, 1>,
   <0, 0, 0>,
   <0, 0, 0>, -1
  }

#declare Rook = union {
   intersection {
      union {
         plane { +x, -0.5 }
         plane { -x, -0.5 }
         plane { y, 9 }
      }

      union {
         plane { +z, -0.5 }
         plane { -z, -0.5 }
         plane { y, 9 }
      }

      plane { y, 10 }
      object { Cylinder_Y scale <2, 1, 2> }
      object { Cylinder_Y scale <1.2, 1, 1.2> inverse }
      plane { -y, -8 }
   }

   intersection {
      plane { y, 8 }
      object { Hyperboloid_Y
         scale <1, 1.5, 1>
         translate 5.401924*y
      }
      plane { -y, -3 }
   }

   sphere { <0, 0, 0>, 1
      scale <2.5, 0.5, 2.5>
      translate 2.8*y
   }

//   object { PieceBase }
}

#declare WRook = object {
   Rook

   // bounded_by { sphere { <0, 5, 0>, 5.831 } }

   texture {
     // WWood
      pigment { rgb 1 }
   }
}

object {
    WRook
   // rotate <-90,90,0>/2 // change shape?
}

light_source {<10,100,-100>,1}
camera {location <0,6,-18>}

Post a reply to this message