Lights with radius overlapping with mesh result in sharp specular cutoff

[DGriffin91]

Bevy version Main dcb8a13b223fbc9425f7af01b3941dd80a229384, 0.13

This isn't a new issue. I checked and the same issue occurs in bevy 0.6.

When the radius of a point or spot light intersects with a mesh, it creates a sharp cutoff in the specular reflection. This sharp cutoff is also not aligned with the intersection between the mesh and the light radius.

Point light with radius of 3 at Y=2: (Example code below)

Sphere with same radius and location as point light

The same scene in Blender (4.1 eevee):

With sphere:

Blender also has a "Soft Falloff" setting that is enabled by default for point/spot lights:

use bevy::prelude::*;
fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(Startup, setup)
        .run();
}
fn setup(
    mut commands: Commands,
    mut meshes: ResMut<Assets<Mesh>>,
    mut materials: ResMut<Assets<StandardMaterial>>,
) {
    commands.spawn(PbrBundle {
        mesh: meshes.add(Plane3d::default().mesh().size(100.0, 100.0)),
        material: materials.add(Color::BLACK),
        ..default()
    });
    commands.spawn(PointLightBundle {
        point_light: PointLight {
            radius: 3.0,
            ..default()
        },
        transform: Transform::from_xyz(0.0, 2.0, 0.0),
        ..default()
    });
    commands.spawn(Camera3dBundle {
        transform: Transform::from_xyz(-2.5, 2.5, 9.0).looking_at(Vec3::ZERO, Vec3::Y),
        ..default()
    });
}

[geckoxx]

The faulty calculations are in https://github.com/bevyengine/bevy/blob/ee6dfd35c9fd44c1d1984319e1134f15b87abc7a/crates/bevy_pbr/src/render/pbr_lighting.wgsl#L194 It is based on this: http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_notes_v2.pdf Page 14-16 It contains the following section: "Irradiance for a sphere light is equivalent to a point light if the sphere is above the horizon. Al- though counter-intuitive, this means we only need to address specular lighting if we accept inaccuracies when the sphere dips below the horizon." So, I assume it is a shortcoming of the algorithm and should be documented.