Is anyone working on Bounding Volumes updating correctly?

BoundingVolumes not updating with rotation correctly (Sphere OR box)

This seems like a pretty important bug to squash. Definantly needs to be fixed before a new release. Anyone working on it? Just curious.

I agree, this is a high priority fix. I will work on it if no one else takes up the reins. However, with my current schedule it might take awhile for me to fix. It should actually be a fairly easy fix (I hope). Anyone want it? If not I’ll see what I can do.

When my editor was displaying BoundingVolumes I noticed an error with updating. I thought that it was my fault. :smiley:

I can contribute one solution that definitely does not work: adding the line

bound = bound.transform(localRotation, localTranslation, localScale);


to updateModelBound() in Geometry doesn't fix the problem. Still looking for a proper fix.

Which leads me to believe that transform for the bounds is not working properly in BoundingBoxes. If you pass localRotation in, you’d expect it to rotate.

Ok I’ve <cough> fixed the problem… I think. There’s an update in the CVS that rotates boundingbox correctly. The problem is that the boundingbox needs to know it’s original center and extent at all times.



So I treat the original extents as vectors, rotate/scale the 4 vectors of the box on the Z+ side, and use the greatest X/Y/Z value of each corner as the new “extent” of the box.



I have no doubt it can’t be done without the AABB knowing its original rotation, but I’m pretty sure there’s some way to get away with doing just one rotation and calculating from there, but I can’t quite figure it out just yet. The solution works for all cases when the scale is uniform. When the scale isn’t uniform some wackyness goes on I can’t quite put my finger on.

Sounds good, haven’t looked yet though. Have you evaluated the impact your changes have on performance at all?

Well it’s some major operations inside the main loop so it’s gonna take some speed hit, but I didn’t “notice” anything on simple examples.

Is it optional, or will this affect all of us using bounding boxes?

Well it affects you all, but the alternative is to do it the wrong way. The speed hit isn’t something you should notice too much. Test it out and let me know.



I should clarify that when the application is doing ‘only’ rotating lots of bounding boxes, I could see a tiny FPS decrease but if your application is doing anything else at all you shouldn’t notice any change other than models culling correctly.

"Cep21" wrote:
Well it affects you all, but the alternative is to do it the wrong way.
Quote:

I agree. When I was using bounding boxes parts of my seen were diapering when I was looking at them with an angle. no one would play game that the people disappear at the wrong time. They would not care about the speed.

I sat down and did some math and made BoundingBox.transform() much shorter and faster. You shouldn’t notice any speed hit at all now, and it works. I’m sure if I was an uber genius (or patient) enough I’ld figure out the formula to make it work without having to convert the quat rotation to a matrix3f first, but that’s life :slight_smile: Anyhow check it out and let me know.

I don’t know if this is from your changes Cep21 but i noticed that bounding spheres seem to be too large in the StarterGuide.HelloIntersection example with todays cvs and the code pasted from the StarterGuide.



I remember this being discussed sometime ago as a bug and being fixed by renanse ??

computeFromPoints does call containsAABB, however, there is averagePoints which is a minimal sphere. You can manually call this method to use a smaller sphere, or you can change computeFromPoints to call averagePoints instead on default.

averagePoints only calculates minimum bounding spheres on symetric objects. I was talking about a minimal sphere for any set of points.

average points will handle any array of points.



the center is calculated as the average of the points, then the radius is determined as the shortest distance to contain the furthest point.



These points do not require any symmetry.

Yes but it’s not a “minimum” bounding sphere. For example, think of a long skinny rectangle (a rod) with 4 points on the left and 996 points on the right. It’s the exact shape of a rod and should have the center as it’s bounding sphere center, but the “average” point would calculate somewhere way on the right, which would give it a large radius as it tries to reach the left.