Added Mesh::ATTRIBUTE_POSITION_2D (VertexFormat::Float32x2)

[brianreavis]

Objective / Solution

This PR introduces support for 2D meshes without a dummy 0.0 z value (for a bit of memory savings) via a new attribute: Mesh::ATTRIBUTE_POSITION_2D.

Testing

• I tested this on a local project.

Migration Guide

To make any custom 2D vertex shaders work with Float32x2 meshes, you'll want to use the VERTEX_POSITIONS_2D flag like below. Note: VERTEX_POSITIONS will still be defined (the two flags are not mutually exclusive).

// Before
struct Vertex {
    ...
#ifdef VERTEX_POSITIONS
    @location(0) position: vec3<f32>,
#endif
    ...
}

// After
struct Vertex {
    ...
#ifdef VERTEX_POSITIONS_2D
    @location(0) position: vec2<f32>,
#else ifdef VERTEX_POSITIONS
    @location(0) position: vec3<f32>,
#endif
    ...
}

// Before
    var world_from_local = mesh_functions::get_world_from_local(vertex.instance_index);
    out.world_position = mesh_functions::mesh2d_position_local_to_world(
        world_from_local,
        vec4<f32>(vertex.position, 1.0)
    );

// After
#ifdef VERTEX_POSITIONS_2D
    let vertex_position = vec4<f32>(vertex.position, 0.0, 1.0);
#else
    let vertex_position = vec4<f32>(vertex.position, 1.0);
#endif

    var world_from_local = mesh_functions::get_world_from_local(vertex.instance_index);
    out.world_position = mesh_functions::mesh2d_position_local_to_world(
        world_from_local,
        vertex_position
    );

[JMS55]

I'll actually raise a point against this PR. Mesh data size shouldn't be a concern for 2d, so I don't think optimizing for performance makes sense, right?

In which case if we're optimizing for ergonomics, then the current experience (less shader def combinations and things that could go wrong) is better, maybe with a helper on the Rust side of things for building specifically 2d meshes.

@IceSentry what do you think?

[IceSentry]

So, 2d meshes do have a Z value that is used. It's used for z-sorting and it's also used to write to the depth buffer for opaque meshes. So I don't think it makes sense to have this in the engine. If you want to do a custom material using this it can all be done user side, but from the engine perspective for the general case we do need a Z value in 2d.

And yeah, I don't think the memory savings are worth it for the general case.

I know some people want a Transform2d component to make the high level api friendlier, but from the renderer's perspective 2d is just 3d with an orthographic projection and I'd prefer if we kept it that way as much as possible instead of needing a separated 2d path for everything.

[brianreavis]

Mesh data size shouldn't be a concern for 2d, so I don't think optimizing for performance makes sense, right?

I think it depends on the use case. If rendering high-poly 2d meshes on mobile, it adds up – but I'm not sure what the threshold is for it making an actually-noticeable difference.

2d meshes do have a Z value that is used. It's used for z-sorting and it's also used to write to the depth buffer for opaque meshes.

True, but the Z typically comes from the Transform versus being baked into the mesh per vertex.

---

If there's no demand for this in Bevy, I'm cool with it being in user-land / a patched version.