Add Mesh transformation

[Jondolf]

Objective

It can sometimes be useful to transform actual Mesh data without needing to change the Transform of an entity. For example, one might want to spawn a circle mesh facing up instead of facing Z, or to spawn a mesh slightly offset without needing child entities.

Solution

Add transform_by and transformed_by methods to Mesh. They take a Transform and apply the translation, rotation, and scale to vertex positions, and the rotation to normals and tangents.

In the load_gltf example, with this system:

fn transform(time: Res<Time>, mut q: Query<&mut Handle<Mesh>>, mut meshes: ResMut<Assets<Mesh>>) {
    let sin = 0.0025 * time.elapsed_seconds().sin();

    for mesh_handle in &mut q {
        if let Some(mesh) = meshes.get_mut(mesh_handle.clone_weak()) {
            let transform =
                Transform::from_rotation(Quat::from_rotation_y(0.75 * time.delta_seconds()))
                    .with_scale(Vec3::splat(1.0 + sin));
            mesh.transform_by(transform);
        }
    }
}

it looks like this:

2024-01-21.15-05-43.mp4

[doonv]

I like this, but maybe it would be better to implement this as Add<Transform> and AddAssign<Transform>?

[Jondolf]

I like this, but maybe it would be better to implement this as Add and AddAssign?

Not sure, maybe? But it'd probably be Mul instead of Add. Transformations are typically represented with multiplication, e.g. transform * point is equivalent to transform.transform_point(point); you can't add or subtract transforms.

I could at least add a transformed_by method so that you could create and transform the mesh on a single line instead of having to define a mutable mesh and separately call transform_by on that

[Jondolf]

I ended up adding transformed_by and implementing Mul<Mesh> for Transform. You can now do this:

let transform = Transform::from_xyz(0.0, 2.0, 0.0);

// These are equivalent
let cuboid = Mesh::from(shape::Box::default()).transformed_by(transform);
let cuboid = transform * Mesh::from(shape::Box::default());

let mut cuboid = Mesh::from(shape::Box::default());
cuboid.transform_by(transform);

Feel free to suggest further improvements/changes to the API

[doonv]

Why did you implement Mul<Mesh> for Transform and not Mul<Transform> for Mesh? You could also implement MulAssign<Transform> for Mesh and be able to perform syntax like this:

let mut cuboid = Mesh::from(shape::Box::default());
cuboid *= transform;

// or

let cuboid = Mesh::from(shape::Box::default()) * transform;

[Jondolf]

For consistency. You can't do point * transform or point *= transform, so I don't see why you'd be able to do mesh * transform. Whether or not you should be able to do point * transform is a separate discussion though

For me, the current transform * point or transform * mesh order makes sense, since it reads like "transform point" or "transform mesh". The other way around it'd read something like "to this point, apply transform"

[alice-i-cecile]

I'd like to see equivalent helpers for the translate/rotate/scale operations alone (that skip the unneeded ops and take in a type-safe arg), but that can be a second PR.

I don't personally think that transformed_by is worth duplicating the API over, but I won't block over it.

[blueforesticarus]

Here to mention that I ran into exactly this use-case (wanted a xz plane circle).

I do think the Mul<> operator not being symmetric is a bit weird, and I will most likely used the transformed_by variant.

[NiseVoid]

Looks good. I agree that separate translate/rotate/scale version later would be a nice followup PR

[atlv24]

This doesn't transform normals and tangents correctly. Test non-uniform scaling, they need to be component-wise divided by scale in the original unrotated basis and then normalized, because together they make up a bivector.

[atlv24]

alternatively to avoid a division, (normal.xyz * scale.yzx * scale.zxy).normalized() (component-wise multiplication)

[atlv24]

If any component of scale is zero it will cause a division by zero and result in infinite-length normals, maybe the division-skipping version that uses only multiplications is a better option

[alice-i-cecile]

If any component of scale is zero it will cause a division by zero and result in infinite-length normals, maybe the division-skipping version that uses only multiplications is a better option

Won't the multiplication version similarly fail when we attempt to normalize the product? Or is .normalized implicitly "normalize or zero" behavior?

[Jondolf]

I can use normalize_or_zero for it

[atlv24]

No, the multiplication-only version will work fine, i'm talking about only one component being zero. normalize_or_zero is unneeded. edit: if the normal is perpendicular to the axis being flattened along it will be zero. The vector as a whole will usually not be zero as it will still have some non-zero component. It doesnt quite make sense to scale a mesh on two or more axes by zero, that should be guarded for at the top level imo. It would just get collapsed to a line segment and not render anything because all triangles would be zero-area. Zero scales only make sense for flattening meshes along a single axis.

[atlv24]

Thanks for the patience and the fixes