Page 1 of 1

Fixture:GetBoundingBox gives irrational results [SOLVED]

Posted: Mon Feb 10, 2020 9:48 pm
by iimurpyh
I'm using Fixture:GetBoundingBox to get the position of rectangular fixtures, but the results of GetBoundingBox are very inaccurate to the actual position of its bounding box.

Here is the code I'm using to get fixture position:

Code: Select all

-- v is a table containing body, fixture, and shape
tx, ty, bx, by = v.body:getWorldPoints(v.fixture:getBoundingBox())
xx = (tx * bx) / 2
yy = (ty * by) / 2 -- get the average between the top left and bottom right corners to find position
print(xx .. ", " .. yy .. " | " .. v.body:getX() .. ", " .. v.body:getY()) -- print the position made with xx and yy, then the actual position
It returns this for an object located at 325, 825:

Code: Select all

-2915349.9361766, 1329839.7915285 | 325, 825
Here is what it returns without v.body:GetWorldPoints(), with the same object:

Code: Select all

-2915349.9361766, 1329839.7915285 | 325, 825
The obvious solution would be to just use v.body:GetPosition() instead of xx/yy, but I'm dealing with a situation where there are multiple fixtures under one body, and I need to draw all of those fixtures with love.graphics.draw (for its image support,) so it wouldn't work.

PS: Why isn't there just a Fixture:GetPosition() function??? :ehem:


Edit: I'm an idiot, I was multiplying instead of adding for the average equation.... Well, at least it's fixed now. (I could have sworn I had similarly weird results when just printing the coordinates of points returned by getBoundingBox() but whatever)

Re: Fixture:GetBoundingBox gives irrational results

Posted: Tue Feb 11, 2020 10:08 am
by raidho36
The obvious solution would be to use proper averaging formula, that being x = ( a + b ) / 2

Re: Fixture:GetBoundingBox gives irrational results

Posted: Tue Feb 11, 2020 2:26 pm
by zorg
Or if you want geometric mean instead of the arithmetic one (as shown above), then you can do x = math.sqrt(a*b) as well... as long as your coordinates aren't signed, or in other words, less than (or equal to) zero; the arithmetic one's probably what gets used most though and doesn't have this issue.