TotalVec2 and TotalVec3 should probably be bevy::math::u32::UVec2 and bevy::math::u32::UVec3. Is there an advantage to using TotalVec2 and TotalVec3?

UVec2 and UVec3 store integer coordinates. TotalVec2 and TotalVec3 store float coordinates by transmuting them to integers.

So UVec2 and UVec3 could be used, but that might be misleading. Or just create TotalSimpleVertex instead of these two.

But I can get rid of TotalVec2 and TotalVec3 and just replace them with tuples.

I think I understand now. It's a workaround to hash a Vec3 since floats can't be hashed.

I found a relevant discussion for the upstream glam-rs: bitshifter/glam-rs#123. That discussion links to https://internals.rust-lang.org/t/f32-f64-should-implement-hash/5436/33 which does offer the workaround of transmuting to u32.

I'd prefer keeping Total2 and Total3 since it clues the reader in that they're doing something special. Maybe consider renaming to HashVec2 HashVec3. Either way it'd be a good idea to document that their intended purpose is for hashing, unless I'm glossing over some other functionality.

That being said though, I wonder if it would be better to just have duplicate vertices. Would this be intended as more of a prototyping tool and some inefficiencies are acceptable, or should this be optimized?

Maybe consider renaming

OK, I'll try something.

That being said though, I wonder if it would be better to just have duplicate vertices.

Might be a lot of duplication. Consider common mesh like this (e.g. when creating a sphere):

Here each vertex is shared by 6 triangles, and not deduplicating it may result in significant memory usage increase.

Would this be intended as more of a prototyping tool and some inefficiencies are acceptable, or should this be optimized?

I'm not an enterprise game developer, so I don't really know how often people generate meshes programmatically rather than just loading them from GLTF.

Replaced TotalVec2 and TotalVec3 with simpler SimpleVertexHashable.

@ethereumdegen is this something that would be useful for terrain generation?

Yup any proposal for a SimpleX type is an indicator that we need to improve our existing APIs, not add a new one. My gut reaction is that we should enumerate the problems being solved here and try to solve them in the core types.

I'd prefer seeing this in a crate first.

Also, this could potentially be implemented as free functions in the mesh module that take in the &mut Mesh and the fixed list of vertex data and append it to the end of the respective arrays.

Yup closing this out as there appears to be rough consensus that doing this upstream isn't the move.