I was trying out using the function
void Skeleton::getBounds(float &outX, float &outY, float &outWidth, float &outHeight, Vector<float> &outVertexBuffer)
to retrieve a runtime bounding box for a spine asset. I was drawing selection boxes around the objects using the width and height returned from this function when I noticed it breaks extremely bad when you venture into negative world coordinates.
The attached picture shows the result of drawing a selection box based off the width and height returned from the function. The red square is at (0,0). The bottom left image is negative in x and y.
float minX = FLT_MAX;
float minY = FLT_MAX;
float maxX = FLT_MIN;
float maxY = FLT_MIN;
for()
{
minX = MathUtil::min(minX, vx);
minY = MathUtil::min(minY, vy);
maxX = MathUtil::max(maxX, vx);
maxY = MathUtil::max(maxY, vy);
}
outX = minX;
outY = minY;
outWidth = maxX - minX;
outHeight = maxY - minY;
I looked at the source for the function and the reason the width and height grow as you get more negative is because the reference maxX and maxY are set to
#define FLT_MIN 1.175494351e-38F
so a negative can never max out over this value meaning the max is fixed around (0,0) and the selection box will grow endlessly with the top corner always at (0,0).
Is there a reason it was set up this way and not with a negative value as max to begin with?
#define FLT_MAX 3.402823466e+38F // max value
the max is huge I would have thought FL_MIN would have been a large negative number.
I'll probably just edit the source to have a new copy of the function use negative as the starter for max and the absolute value the width and height calculation. I was wondering if I'm missing the point of this function or something. It seems like a weird restriction to only work in a positive coordinate system.
Thanks
