Error in frustum math.

[ixru]

Bevy version

0.6.0

What you did

When trying to use the new frustum from 0.6 I noticed it being too inclusive when using the intersects_sphere method, causing some flickering when loading new meshes within it.
Looking at the code I think I see an error in how the radius is handled. Adding radius directly to the normalized dot product causes it to add multiples of the vector's original length instead of the radius * length of normalized normal vector I assume it is meant to use.

[superdump]

I think it is correct. The frustum plane normals are inward facing and normalised. Given the equation for points in a plane ax + by + cz + d = 0, a,b,c is the unit normal, and d is the d value. Given a point p, the shortest distance from p to the plane is along the normal to the plane. How far turns out to be (a,b,c,d) dot (px, py, pz, 1) as I recall, and given inward facing normals, if this value is positive, the point is inside and if it’s negative the point is outside. For intersecting with a sphere we want to expand the frustum plane out by the radius which means the dot product now needs to be <= -radius or dot product + radius <= 0. I got most of this from Eric Lengyel’s Foundations of Game Engine Development Volume 2: Rendering. Maybe there is a bug in there. I’m not 100% certain.

Could you give more details about the flickering bug and either provide a minimal example that reproduces it or give instructions?

[ixru]

Sorry for the bad description. An example of how I think it works:
Given the default far value of 1000 and looking down the z-axis [0,0,-1] the far plane is defined by plane = [0, 0, 1, 1000]
Normalized that gives something approximate to plane_n = [0, 0, 0.0009, 0.999].
Choosing a point far outside the plane point = [0,0,-2000].
Now plane_n * point.extend(1) ~= -1 or plane * point.extend(1) = -1000.
A radius of 10 will then give -1 + 10 = 9 which is inside the frustum, or the point actually at [0, 0, 8000].
While the non-normalized one -1000 + 10 = -990 is still outside. This is what I meant by the radius adding multiples when the plane is normalized.

[ixru]

use bevy::{
    prelude::*,
    render::primitives::{Frustum, Sphere},
};

fn main() {
    App::new()
        .add_startup_system(spawn_camera)
        .add_system(test_frustum)
        .run();
}

fn test_frustum(frustum_query: Query<&Frustum>) {
    let frustum = frustum_query.single();
    let sphere = Sphere {
        center: Vec3::new(0.0, 0.0, -2000.0),
        radius: 10.0,
    };
    // frustum.intersects_sphere(&sphere), only far plane
    let inside = frustum.planes[5].normal_d.dot(sphere.center.extend(1.0)) + sphere.radius > 0.0;
    // Prints true, but should be false
    dbg!(inside);
}

fn spawn_camera(mut commands: Commands) {
    commands.spawn_bundle(PerspectiveCameraBundle::default());
}

[superdump]

Thanks. In my re-reading I had missed that the Vec4s were being normalized including all 4 components. I understand the problem now.

[superdump]

I'll add this to the rendering project board. Given no one has noticed this so far suggests it's not that bad of an impact in practice, and to fix it I would like to add a bunch of tests for these intersection checks, and that will take a bit of time.