What are bounds?

[NidoAnxari]

I am almost new to scripting and facing trouble understanding the bounds and how they work. As far as I can understand is that they are like boundaries around a gameobject. But following are some questions that I am unable to understand:

1. Do they completely cover/overlap the gameobject or just of some regular shape like circle, rectangle or square.
2. Can we get a point on a bound and convert it to local space position?
3. Can we use colliders as a bound and get a point on that collider and convert it to local space?

[lordofduct]

So GameObject’s don’t have bounds.

Also, bounds can mean many things… like bounds of an array.

From the context though, it sounds like you’re talking about the Bounds struct:

Unity - Scripting API: Bounds

And you can get them from things like:
Collider.bounds:

Unity - Scripting API: Collider.bounds

Mesh.bounds:

Unity - Scripting API: Mesh.bounds

Renderer.bounds:

Unity - Scripting API: Renderer.bounds

The bounds represent different things in each case.

But basically from the documentation:

An axis-aligned bounding box, or AABB for short, is a box aligned with coordinate axes and fully enclosing some object. Because the box is never rotated with respect to the axes, it can be defined by just its center and extents, or alternatively by min and max points.

So a ‘Bounds’ is an axis aligned bounding box… AABB.

This means a box, or rectoid, in 3-space… that can’t be rotated. It’s locked to the x/y/z axes.

In the case of a Collider.bounds. It is a AABB that fits around the collider. Think if you had a sphere collider… the bounds would be a cube in which the sphere perfectly fits.

Mesh.bounds is the same thing… but around a mesh.

And Renderer.bounds is the same thing… but is the space made up of where rendering occurs for that object.

It’s always larger than the thing it’s bounding.

The fact it’s axis aligned though… means that any rotation of oblong shaped things distort the bounding box a lot.

Bounding boxes are good to get very approximate relative locations of things. Since bounding box intersection is a very simple and fast calculation (relative to complex collision or similar)… you can rule out things being anywhere near each other if their bounding boxes don’t intersect. Sure, they might not be intersecting even if the bounds are intersecting… but if the bounds don’t, then they certainly aren’t. It’d be like saying “can Sally touch Sam?”… “Well Sam and Sally aren’t in the same room, so surely Sally can’t touch Sam”.

Or if say you have a view frustum, if the bounding box and view frustum don’t overlap… then the thing isn’t on screen… again, not complex intersection calculations to do… just basic bounding calculations.

[BlackPete]

One gotcha about Bounds to watch out for is code like this:

            Bounds _worldBox = new Bounds();

            for (var i = 0; i < renderers.Length; ++i)
            {
                _worldBox.Encapsulate(renderers[i].bounds);
            }

If you do a “new Bounds()”, the position (0,0,0) is part of the bounds, which you probably don’t want.

[NidoAnxari]

Thanks to both of you guys!

[Vorrin]

Such nice answers, it warms the heart

[ratneshpatel]

The problem with bounds is that it doesn’t work well for rotated objects because then the bounds would be not the same as collider volume.

[jhocking-bundlar]

@BlackPete

If you do a “new Bounds()”, the position (0,0,0) is part of the bounds, which you probably don’t want.

er, could you elaborate on why there is a problem, and what you want instead? I’m currently debugging code that looks like what you posted, so perhaps I am hitting the issue you refer to, but I can’t tell what’s actually wrong.

[lordofduct]

@jhocking-bundlar

er, could you elaborate on why there is a problem, and what you want instead? I’m currently debugging code that looks like what you posted, so perhaps I am hitting the issue you refer to, but I can’t tell what’s actually wrong.

If you call encapsulate, it inflates/grows the bounds from its current position/size to encompass both itself AND the bounds passed in.

The problem is that the starting bounds are of dimensions 0 at position 0. Basically it’s a bounds encapsulating a single point (that point being 0,0,0).

When it inflates to say encapsulate bounds at 100,0,0 with say size 1,1,1… you’ll end up with a box encapsulating both… basically a box that is size 100.5,1,1 and positioned probably around 50.25,0,0.

See the problem?

So in BlackPete’s code… the intent of the code at first glance appears to give you a bounding box that encompasses every bounds in the renderer list… but actually it encompasses every bound in the renderer list AND a 0 sized bound at 0,0,0. If those bounds happen to overlap that 0 bound, it’s fine… but if those bounds aren’t near the origin. Yeah, it’s going to be a big problem.

So really… for BlackPete’s code to properly get what the implied intent is would be to do something like:

var conjoinedbounds = renderers[0].bounds;
for(int i = 1; i < renderers.Length; i++)
{
    conjoinedbounds.Encapsulate(renderers[i].bounds);
}

[jhocking-bundlar]

Thanks for the explanation! That makes sense, and yeah that was the problem I was encountering (my model’s origin was far off the actual mesh). In my case, I couldn’t assume every object had a renderer, so I needed to do descendant.TryGetComponent(out var childRenderer) and then instead of simply using the first object’s renderer, while looping do the check in this first snippet:

How does Bounds.Encapsulate() work?