/*
Don't know if this is a known bug but the functions min_extent()
and max_extent() are not correct with cylinders and cones whose
ends are not parallel to an axis. Have not tested in 3.7.
Works correctly when rotated and translated into position.
*/
#version 3.6;

camera {
  location  -10*z
  look_at 0
  right     x*image_width/image_height
}

light_source {<-100, 100, -100> color rgb 1}

#declare Cylinder1 =
  cylinder { 0, 5*y, 1
    rotate degrees(atan(4/3))*-z
    translate <-2, -3, 0>
    pigment {color x}
  }

#declare Cylinder2 = cylinder { <-2, 0, 0>, <2, 3, 0>, 1 pigment {color y}}

#debug concat("Min 1 = ", str(min_extent (Cylinder1).z, 0, -1), "\n")
//Returns "Min 1 = -1.000000"
#debug concat("Min 2 = ", str(min_extent (Cylinder2).z, 0, -1))
//Returns "Min 2 = -1.400000"

object {Cylinder1}
object {Cylinder2}

Post a reply to this message

"Stephen Klebs" <skl### [at] gmailcom> wrote:
> /*
> Don't know if this is a known bug but the functions min_extent()
> and max_extent() are not correct with cylinders and cones whose
> ends are not parallel to an axis. Have not tested in 3.7.
> Works correctly when rotated and translated into position.
> */

This is actually not a bug, but merely a case of "doesn't work as I expected".

According to the documentation, min_extent() and max_extent() functions return
the dimensions of the bounding box - but this is *not* necessarily the smallest
extents the object might fit in.

If you add the following statements to your scene, you will see that both boxes
properly bound the respective cylinder (albeit not optimally in case of
Cylinder2):

box { min_extent (Cylinder1), max_extent (Cylinder1)
  pigment { color rgbt <1,0,0,0.5> }
}

box { min_extent (Cylinder2), max_extent (Cylinder2)
  pigment { color rgbt <0,1,0,0.5> }
}

This has something to do with the way cylinders are represented internally, and
the way the bounding box is computed: All cylinders are actually
cylinder{<-1,-1,0>,<1,1,1>},1}, equipped with a base transformation that
orients and resizes the cylinder as desired. Note rotating the cylinder about
its axis will not hurt, and the algorithm to compute the transformation may
actually do that for the sake of code simplicity.

Enter bounding box magic. Like many other objects, a cylinder's bounding box is
computed in two stages:
- Build a "prototype" bounding box around the untransformed object
- Build a final bounding box around the transformed prototype box

It seems that in your particular case, the base transformation includes not only
a rotation around the Z axis, but also around the cylinder's axis (by something
close to 45 degrees). Although it does not affect the geometry in any way, it
does affect the orientation of the "prototype" bounding box, and therefore the
extent of the final bounding box.

Post a reply to this message

Thanks, clipka

So for min_extent/max_extent a cylinder/cone is treated as a box. This would
account for the result for min_extent (Cylinder2).z = -1.4, since that is half
the height of a diagonal of a bounding box of a cylinder with radius = 1 when
rotated by an angle, in my instance, atan(4/3). I should have guessed
since the Ray->Shape Intersection output in the message window for the
two cylinders actually describes 1 Cone/Cylinder and 1 Box. Cylinders
created along an axis and then transformed otherwise keep the accurate
orthogonal dimensions of the bounding box.

It seems that a correcting function could be applied to this discrepancy.

Post a reply to this message

"Stephen Klebs" <skl### [at] gmailcom> wrote:
> Cylinders
> created along an axis and then transformed otherwise keep the accurate
> orthogonal dimensions of the bounding box.

Not necessarily. Try

    cylinder { <0,0,0>, <0,1,0>, 1
        rotate z*45
        rotate y*45
    }

for instance. This, too, will have some "bounding slack".

> It seems that a correcting function could be applied to this discrepancy.

I guess that would only be possible if the "slanted" cylinder wasn't represented
by a "unit cylinder" + initial transformation, bacause if the user adds its own
transformation later, they're merged witth the initial transformation and it's
impossible from then on to tell them apart. And with a user-supplied
transformation, this could basically be any linear transform, including severe
skewing and such. I wouldn't want to be the one to put this all in a simple
correcting function.

The current approach isn't ideal, but it works, and is easy to understand (from
a software development point of view).

Post a reply to this message