Open osrf-migration opened 9 years ago
Original comment by Z F (Bitbucket: yzfang).
similar to https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/issues/1205/incorrect-model-boundingbox (#1205)
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Original comment by Elte Hupkes (Bitbucket: ElteHupkes).
I just ran into this issue after getting incorrect bounding boxes for Model::GetCollisionBoundingBox()
, after some digging I found out why that happens so I figured I'd report it here; it applies to Model::GetBoundingBox()
as well.
The issue is that the bounding boxes returned by the collision implementations (BulletCollision::GetBoundingBox()
and ODECollision::GetBoundingBox()
) have an extent of EXTENT_NULL
, because they are created with their argument-less constructors. Looking at Box::operator+()
/ Box::operator+=()
, we see that if the extent of a box is EXTENT_NULL
, it simply inherits the min/max values of the box it is being summed with. Since all of the boxes in the bounding box sum have EXTENT_NULL
, the result is practically the same as taking the last box in the sum.
There is an additional issue with Entity::GetCollisionBoundingBox()
(which is what Model
and all other Entity
's use) which occurs when there is at least one child which does not contain collision elements (e.g. a joint in the case of a model). In this case the default argument-less constructed box will be returned for this item, which will have min/max vectors of (0, 0, 0)
. Depending on the situation, these might actually be out of the range of the current min/max vectors, extending the bounding box. Combined with the previous issue it gets even worse: if the last child of a model is a joint, Model::GetCollisionBoundingBox()
will return that last value, i.e. a box of size 0 in all dimensions.
So to fix all of this:
BulletCollision::GetBoundingBox()
and ODECollision::GetBoundingBox()
, I don't think the other engines support bounding boxes at all) should return Box
es instantiated with the min/max constructor so they have an extent of EXTENT_FINITE
.Box::operator+()
/ Box::operator+=()
should noop on sums where the other box has EXTENT_NULL
, which would prevent having to...Entity::GetCollisionBoundingBox()
to positive/negative infinity, like Link::GetBoundingBox()
is doing by the way, so it doesn't affect the sum.Original comment by Elte Hupkes (Bitbucket: ElteHupkes).
Okay, apparently my previous comment only solves part of the problem. The returned bounding boxes also seem to depend on the underlying physics engine in a non-compatible manner. ODECollision::GetBoundingBox()
shows an attempt to return the bounding boxes in world coordinates (which is what you want for AABB's) but depending on the rotation of the object this value is either a little bit or completely wrong - and I'm clueless why. BulletCollision::GetBoundingBox()
on the other hand returns the bounding box in the collision's (or link's, not sure) reference frame, which makes it completely useless for summing it with the other bounding boxes (a bounding box of a rotated object is not equal to the rotated bounding box of the original object).
Unfortunately I've no time to delve into this deeper now, there's a master's thesis involving simulated robots I have to work on which will just have to do without bounding boxes for now ;).
Original report (archived issue) by Andrei Haidu (Bitbucket: ahaidu).
The original report had attachments: kitchen_table.zip
The returned bounding box of a model is the one of its last collision, this might have been overlooked in this issue (#841).
Code snippet (world plugin in the Load method):
I also attached the KitchenTable model.