Consider that we have groups a series of objects by union and call it Object 1.
Now, we want to clone and place a copy of Object 1 (unioned) beside another
object (say Object 2).

Since "translate" moves the object by relative coordinates rather than absolute
coordinates. We have two options:

1. Move Object 1 to <0, 0, 0>, then, translate it by the coordinates of Object
2.

2. Subtract the coordinates of Object 2 from those Object 1 to find the
translate values.


My question is:

1. How to put the center of a unioned object at <0, 0, 0>?
OR
2. How to find the coordinates of the center of a unioned object?
OR
Is there any approach/trick to translate a unioned object (collection of several
objects) to move to a specific point (absolute coordinates)?

Post a reply to this message

Am 24.05.2018 um 19:22 schrieb Kima:

> 1. How to put the center of a unioned object at <0, 0, 0>?

That's trivial: Find the center of the object, then translate it by the
negative of that center's position.

> OR
> 2. How to find the coordinates of the center of a unioned object?

That depends entirely on the unioned objects.

Also, you'd need to decide whether you want center of mass or
coordinate-wise center of max extent.

POV-Ray has no means of figuring this out automatically; with so many
different primitives supported, and some of them being arbitrarily
flexible, it is virtually impossible to come up with a generic yet exact
way to solve this problem.

In your search you may come across `min_extent()` and `max_extent()`;
note that these can be used on any object as a /rough/ estimate of the
region of space occupied by that object, but the values are not
guaranteed to be exact: `min_extent()` may return lower values
(sometimes significantly so), while `max_extent()` may return higher
values (again sometimes significantly so). The only thing guaranteed is
that the entirety of the object lies /somewhere/ within those bounds.

What you /can/ do is use `trace()` and/or `inside()` to probe the
resulting shape; but again this won't be exact for arbitrary cases.

> OR
> Is there any approach/trick to translate a unioned object (collection of several
> objects) to move to a specific point (absolute coordinates)?

That's trivial: Find the center of the object, then translate it by the
target position minus the center's position.


Yeah, I know the answers to 1. and 3. do not help you at all. The point
is, it all boils down to solving 2.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> In your search you may come across `min_extent()` and `max_extent()`;
> note that these can be used on any object as a /rough/ estimate of the
> region of space occupied by that object, but the values are not
> guaranteed to be exact: `min_extent()` may return lower values
> (sometimes significantly so), while `max_extent()` may return higher
> values (again sometimes significantly so). The only thing guaranteed is
> that the entirety of the object lies /somewhere/ within those bounds.
>

I've always been curious about why this is so. For example, assume a short
cylinder (short in y) and with no rotations. Taking the min_extent/max_extent of
that object as-is, the resulting 'bounding box' shape tightly hugs that object
(meaning, the bounding-box 'axis planes' just touch the object.)

But if the object is rotated (around all three axes, for argument's sake), the
resulting bounding-box (its planes) are generally some distance away from any of
the cylinder's surfaces. I.e., there are gaps of empty space between object and
bounding box. I'm sure that there IS a technical reason for this; but a simple
(naive!) question would be: Why does rotating an object 'mess up' the
bounding-box tightness?

Post a reply to this message

Le 18-05-24 à 17:28, Kenneth a écrit :
> clipka <ano### [at] anonymousorg> wrote:
> 
>>
>> In your search you may come across `min_extent()` and `max_extent()`;
>> note that these can be used on any object as a /rough/ estimate of the
>> region of space occupied by that object, but the values are not
>> guaranteed to be exact: `min_extent()` may return lower values
>> (sometimes significantly so), while `max_extent()` may return higher
>> values (again sometimes significantly so). The only thing guaranteed is
>> that the entirety of the object lies /somewhere/ within those bounds.
>>
> 
> I've always been curious about why this is so. For example, assume a short
> cylinder (short in y) and with no rotations. Taking the min_extent/max_extent of
> that object as-is, the resulting 'bounding box' shape tightly hugs that object
> (meaning, the bounding-box 'axis planes' just touch the object.)
> 
> But if the object is rotated (around all three axes, for argument's sake), the
> resulting bounding-box (its planes) are generally some distance away from any of
> the cylinder's surfaces. I.e., there are gaps of empty space between object and
> bounding box. I'm sure that there IS a technical reason for this; but a simple
> (naive!) question would be: Why does rotating an object 'mess up' the
> bounding-box tightness?
> 
> 

The faces of the bounding box are always parallel to the reference planes.
So,
  cylinder{50*y, -50*y, 1}
have a tight bounding box, while
  cylinder{50, -50, 1}
only touch the bounding box at 6 points (one on each faces near corners) 
and is aligned along one of it's diagonals, leaving the bounding box 
almost empty.
The same thing apply when you rotate your object : The bounding box 
never get rotated in any way and need to expend to completely contain 
the object. The bounding box is created after the object is parsed 
during the bounding phase, between the parsing and the start of the 
render proper.
A test against a rotated bounding box would cost more than against an 
unrotated one.


Alain

Post a reply to this message

Am 24.05.2018 um 23:51 schrieb Alain:
>>> The only thing guaranteed is
>>> that the entirety of the object lies /somewhere/ within those bounds.
>>>
>>
>> I've always been curious about why this is so. For example, assume a
>> short
>> cylinder (short in y) and with no rotations. Taking the
>> min_extent/max_extent of
>> that object as-is, the resulting 'bounding box' shape tightly hugs
>> that object
>> (meaning, the bounding-box 'axis planes' just touch the object.)
>>
>> But if the object is rotated (around all three axes, for argument's
>> sake), the
>> resulting bounding-box (its planes) are generally some distance away
>> from any of
>> the cylinder's surfaces. I.e., there are gaps of empty space between
>> object and
>> bounding box. I'm sure that there IS a technical reason for this; but
>> a simple
>> (naive!) question would be: Why does rotating an object 'mess up' the
>> bounding-box tightness?

It's a combination of multiple things:

- For the sake of performance, perfect tightness is not mandatory.
Reasonable close-ness is perfectly sufficient.

- For the sake of performance, bounding boxes _must_ be axis-aligned.

- For the sake of flexibility, the algorithm to compute bounding boxes
for transformed objects must be able to cope not only with rotations,
but with arbitrary transformations.

- For the sake of developer sanity, bounding boxes must be reasonably
easy to compute.

So in most cases, the algorithm for computing a bounding box for a
transformed primitive (except for pure scaling and translation) is as
follows:

- Compute a preliminary b'box based on the untransformed object.
- Apply the transformation to the preliminary b'box.
- Compute the final b'box to fit snugly around the corners of the
transformed preliminary b'box.

Since the preliminary b'box is guaranteed to contain the entire object,
and this property is unaffected by transformations; and since the final
b'box is guaranteed to contain the entire transformed preliminary b'box;
this algorithm guarantees that the final b'box contains the entire
object, without wasting too many brain cells on figuring out how to
compute the b'box for e.g. a shear-transformed sphere.

In a worst-case scenario, the resulting b'box will present at most twice
as big of a cross section to rays as an ideal b'box would, which I guess
is acceptable in terms of performance.


(You could try to measure the performance loss by taking an arbitrary
scene with axis-aligned primitives, and rotating all of them by 45
degrees around the camera axis. Also, if you are mathematically
inclined, you could implement algorithms to compute better-fitting b'boxes.)

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

>
> The faces of the bounding box are always parallel to the reference planes.

Yes, that's the way I understand it as well.

> The same thing apply when you rotate your object : The bounding box
> never get rotated in any way and need to expend to completely contain
> the object.

Yes again. (Although, years ago, I thought the bounding-box got rotated along
with the object-- before I understood the true nature of the box faces being
always parallel to the reference planes.)

> So,
>   cylinder{50*y, -50*y, 1}
> have a tight bounding box, while
>   cylinder{50, -50, 1}
> only touch the bounding box at 6 points (one on each faces near corners)
> and is aligned along one of it's diagonals, leaving the bounding box
> almost empty.

*Ideally*, that is what I would expect; but a rotated object shows that few if
any of the bounding-box faces actually touch the object. There is excess space,
in other words. As Clipka says, the bounding-box cross section could actually
end up being twice the size of the object itself (sorry if I'm not paraphrasing
his words exactly.)

Here's a "bounding-box tester" scene, to show what I mean, using a rotated
stubby cylinder. (Another object could be substituted in the code, just so its
own 'cross section' is approximately 1 unit in size.)

-------
#version 3.7; // or 3.71 or 3.8
global_settings {assumed_gamma 1.0}

#declare CAMERA_POSITION = 1; // 1 -- front
                              // 2 -- right side
                              // 3-- top
#declare OBJECT_ROTATION = 35; // 0.0, or some other single value,
// for simplicity
//----------
#switch(CAMERA_POSITION)
#case(1)
// FRONT view ((i.e., looking at X/Y plane)
camera {
  orthographic
  location  <9.2, 9.2, 2>
  look_at   <9.201, 9.201, 9.200>
  right     x*image_width/image_height  // aspect
  angle 15
}
#break
#case(2)
// SIDE view (i.e., looking at Y/Z plane)
camera {
  orthographic
  location  <16.2, 9.2, 9.2>
  look_at   <9.201, 9.201, 9.201>
  right     x*image_width/image_height  // aspect
  angle 15
}
#break
#case(3)
// TOP view ((i.e., looking at X/Z plane)
camera {
  orthographic
  location  <9.2, 18.2, 9.2>
  look_at   <9.2, 9.2, 9.201>
  right     x*image_width/image_height  // aspect
  angle 15
}
#break
#else
#end

light_source {
  0*x
  color rgb .7
  translate <200, 400, -200>
}

light_source {
  0*x
  color rgb .3
  translate <-200, 100, -200>
}

background{rgb .1}

#declare OBJ =
cylinder{0,.15*y,.5
     no_shadow
     texture{
          pigment{rgb .8}
          finish{ambient .1 diffuse .9}
          }
     scale 1 // or whatever
     rotate OBJECT_ROTATION
     translate 9.2 // also used below
     }

OBJ

// the bounding box (its visible substitute)
box{min_extent(OBJ),max_extent(OBJ)
    no_shadow
    texture{
        pigment{rgbt <.3,.5,1,.7>}
        finish{ambient .3 diffuse .7}
        }
    }

sphere{min_extent(OBJ),.03} // BLACK-- MIN_EXTENT corner
sphere{max_extent(OBJ),.03 pigment {rgb <0,4,0>}} // GREEN-- MAX_EXTENT corner

#declare CENTER_OF_BOUNDING_BOX =
...5*(max_extent(OBJ)-min_extent(OBJ)) + min_extent(OBJ);

// RED sphere
sphere{CENTER_OF_BOUNDING_BOX, .15
      pigment{rgb <2,0,0>}

      }

#debug concat("\n","CENTER OF BOUNDING BOX at <",
    vstr(3,CENTER_OF_BOUNDING_BOX,",",1,3),">","\n\n")

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> #declare CENTER_OF_BOUNDING_BOX =
> ...5*(max_extent(OBJ)-min_extent(OBJ)) + min_extent(OBJ);
>

???

It should be

..5*(max_extent(OBJ)-min_extent(OBJ)) + min_extent(OBJ);

Post a reply to this message