Fox.glb has incorrectly scaled normals

[NotAFile]

Bevy version

35e107c

What went wrong

The Fox.glb model has incorrect scaling of the vertex normals.

e.g. for the first vertex, the normals are:

0.176476 -0.507666 -0.242626

correctly scaled would be:

0.299268 -0.860901 -0.411446

This has led to issues such as #6528. That has been fixed, but it would be good to fix this at the source anyway.

[alecgarza96]

New to Bevy, would love to help out. Still learning the codebase

Does this change involve edits to the 3D model itself? I looked under examples/animated_fox.rs and didn't find any code performing scaling.

I've been searching under crates/bevy_render as well for where this error could be originating

[james7132]

Does this change involve edits to the 3D model itself? I looked under examples/animated_fox.rs and didn't find any code performing scaling.

Looks like it. There's no normalization code we do on any meshes by default. IMO we should any or all of the following:

• Update the 3D model itself to include normalized normals
• Add a validation step when loading meshes to ensure normals are normalized.
• Add a asset preprocessing step to do this when that pipeline is ready (contingent on the asset rework @cart's working on)

[alecgarza96]

Does this change involve edits to the 3D model itself? I looked under examples/animated_fox.rs and didn't find any code performing scaling.

Looks like it. There's no normalization code we do on any meshes by default. IMO we should any or all of the following:

• Update the 3D model itself to include normalized normals
• Add a validation step when loading meshes to ensure normals are normalized.
• Add a asset preprocessing step to do this when that pipeline is ready (contingent on the asset rework @cart's working on)

Looking into adding the validation step for when meshes are normalized

I found the compute_flat_normals method which utilizes the face_normal

would it be possible to reuse this functionality for the validation check, or do we want to calculate the standard normals instead of flat?

Also, at what point should the validation check occur? My initial thoughts are in either ::new() or inert_attribute()

[JohnTheCoolingFan]

While you are figuring out validation, I've been trying to fix the model itself. I've loaded it into blender, recalculated normals (removed duplicate vertices, recalculated, disconnected faces back, export). Visually nothing changed (judging by blender's normal visualization), I tried it on commit specified in #6528 and it's still black. I've uploaded my updated model to a fork: https://github.com/JohnTheCoolingFan/bevy/blob/dfdda55edb9e1ac6f6d497259faed32dd300068b/assets/models/animated/Fox.glb

[NotAFile]

For reference, the way I personally did the normalization was via MeshLab, which has a "normalize normals" option. I unfortunately could not get to output a drop in replacement .glb file though.

[mockersf]

I would prefer to not change the model at all. It should come straight from https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/Fox without any modification. If it's wrong and need updating, could you submit your fix on the gltf sample repo?

[nicopap]

I believe one of the aim of glTF is avoiding the kind of pitfall where everything needs to be sanitized and recomputed, it's "GPU ready". The glTF standard unambiguously says the normal attributes are normalized so if the model doesn't have normalized normals, it's probably in infraction of the standard.

[mockersf]

If the wrong normals are confirmed on the upstream fox, fixing them would be very nice. If not, we can update ours with the original 👍

[NotAFile]

There's been a commit about "fixing validation errors" upstream that's newer than the in-tree copy, perhaps pulling that in would actually already be enough.

[rparrett]

Am I crazy or does Fox.glb not contain normals? I looked at both the current version of Fox.glb in our repo, and the latest version in glTF-Sample-Models.

[rparrett]

It seems that this was fixed at some point. Maybe there was an issue with computing normals?

On the latest main, I added the following to animated_mesh to peek at the first normal:

fn show_first_normal(query: Query<(Entity, &Mesh3d)>, assets: Res<Assets<Mesh>>) {
    for (entity, mesh3d) in &query {
        let mesh_asset = assets.get(&mesh3d.0).unwrap();
        if let Some(VertexAttributeValues::Float32x3(normals)) =
            mesh_asset.attribute(Mesh::ATTRIBUTE_NORMAL)
        {
            info!("{} first normal: {:?}", entity, normals[0]);
        }
    }
}

And got:

2025-02-11T14:35:04.298302Z  INFO animated_mesh: 38v1 first normal: [0.29926783, -0.8609013, -0.41144586]