Frustum intersects AAB about silenceengine HOT 4 CLOSED

I'd like to know about those cases, as this is working pretty well for me in Blox. This is the intersection code I'm using.

public boolean intersects(Vector3 position, float width, float height, float thickness)
{
    float halfWidth = width / 2;
    float halfHeight = height / 2;
    float halfThickness = thickness / 2;

    float x = position.x;
    float y = position.y;
    float z = position.z;

    for (Plane plane : planes)
    {
        if (checkPlane(x + halfWidth, y + halfHeight, z + halfThickness, plane) ||
            checkPlane(x + halfWidth, y + halfHeight, z - halfThickness, plane) ||
            checkPlane(x + halfWidth, y - halfHeight, z + halfThickness, plane) ||
            checkPlane(x + halfWidth, y - halfHeight, z - halfThickness, plane) ||
            checkPlane(x - halfWidth, y + halfHeight, z + halfThickness, plane) ||
            checkPlane(x - halfWidth, y + halfHeight, z - halfThickness, plane) ||
            checkPlane(x - halfWidth, y - halfHeight, z + halfThickness, plane) ||
            checkPlane(x - halfWidth, y - halfHeight, z - halfThickness, plane))
            return true;
    }

    return false;
}

That is, an AABB intersects if there is at least one point is intersects with the plane. I'll take a look at that page when I got home, thanks for that.

from silenceengine.

The problem with this algorithm is that it's essentially simplifying the plane-AABB intersection test to a plane-sphere intersection test. That is why it is using the "half-size" of the box as the sphere's radius in each dimension.
Section "2.3 Basic VFC algorithm" of that paper explains this algorithm, which I believe is what you are implementing, and its drawbacks.
One case where the described algorithm is failing is when having a view frustum plane that is diagonal to the AABB, as shown in the illustration under 2.3.

from silenceengine.

I took a look at that paper, and also your JOML sources, but I found it difficult to use, because of two reasons. Firstly, it appears that you are not normalizing the planes you retrieved from the matrix. And second, it seems to use a corner, not the center of the box.

void AABox::setBox( Vec3 &corner,  float x, float y, float z) {
    this->corner.copy(corner);

    if (x < 0.0) {
        x = -x;
        this->corner.x -= x;
    }
    if (y < 0.0) {
        y = -y;
        this->corner.y -= y;
    }
    if (z < 0.0) {
        z = -z;
        this->corner.z -= z;
    }
    this->x = x;
    this->y = y;
    this->z = z;
}

This is from the C++ code of the tutorial by LightHouse3D which I found here. And then, I found that (dx, dy, dz) are not diameters, but instead the diagonals of the box. I'll quote that part of the tutorial here.

Vector (mx,my,mz) represents the center of the AABB. Absolute values of the normal vector of the plane (a,b,c) transform all possible values to the first octant so its dot product with the vector representing a half of the AABB diagonal (dx,dy,dz) will be always positive.

I've been in doubt, I never saw the corner approach of the AABB, I only know of min/max and center/halfSize ways. Blindly assuming that it is center and not the corner (Which I know is definitely wrong), I copied the code directly (from that same article) and I got weird results, it sometimes works and sometimes not. Where sometimes meaning at different views.

However, I did find a small bug in my original method and solved it. Now, it works pretty good for both spheres and AABBs. The difference is the corners are tested for the AABBs whereas for sphere, it is tested as a single point (the center) which is in the size of the radius.

from silenceengine.

Glad you found a solution that works for you.
Yes, there are basically two ways to represent a box, either via center and half-size or via their min/max corners. The algorithm I use is geared towards the second min/max representation.
The plane equations do not have to be normalized, since no actual "distance" is computed between the box corners and the plane. This is different than what the sphere-plane test needs to do. There, we do have to normalize the plane equation (or the sphere's radius) to get both into the same reference frame in order to compare distances.

from silenceengine.