Added CPUMeshGenerator

[SOF3]

This allows users to create modified meshes (especially custom UV definitions) reusing information like angle/theta/phi instead of deducing them from the position buffer.

[SOF3]

I am not sure if it is OK to use dynamic dispatch here. Another possible way without introducing 5 type parameters in everywhere is to create a trait and use associated types, but that feels like too much work for a simple use case.

I suppose the compiler can inline the dynamic dispatch anyway, and even if it doesn't, users shouldn't call mesh generation functions in hot paths anyway.

[SOF3]

I was a bit lazy here, didn't verify if the cylinder and cone functions are really the same except with the (1.0 - v.x) multiplier.

[asny]

Can you elaborate a bit on the motivation for this? I'm a bit concerned that it adds extra complexity. Also, it is a bit orthogonal to the focus of this crate. All the fields in CPUMesh are public so you can easily add custom uv coordinates or advanced mesh generation features outside this crate.

[SOF3]

For example, I would like to generate a sphere mesh like this:

CPUMesh::sphere_gen(
    "sphere",
    angle_subdivisions,
    CPUMeshGenerator {
        positions: &mut |v| [v.x, v.y, v.z],
        normals: Some(&mut |v| [v.x, v.y, v.z]),
        tangents: None,
        uvs: Some(&mut |v| [v.theta / PI, v.phi / PI / 2.]),
        colors: None,
    },
);

If I were to derive the uvs here from positions, I would need to use atan2 to guess the values of theta and phi (and deal with atan2(0, 0) at the two endpoints). This adds a bit of complexity, and sounds quite unreliable to interpret position values in an arbitrary manner.

[asny]

Sorry for the late reply, I caught the flu 🤧

Isn't the problem just that there are no uv coordinates generated in CPUMesh::sphere then? We can easily add that. And if your texture doesn't fit the generated coordinates then you can use a texture transform. Or just create a sphere the way you like in another tool, export it and load it into three-d.

[SOF3]

Texture transform only works with linear transformations right? Sometimes textures are not continuously joined, e.g. some might split the texture into multiple disjoint grids and arrange them horizontally or some other discontinuous way.

Actually I generated my own sphere mesh anyway, just thought this might be a useful addition to the API.

[asny]

Yeah texture transform is only linear and yeah there are a million different use-cases that are not supported with regards to mesh generation, you are absolutely right. However, the point of three-d is not mesh generation, that I would rather leave to other crates/tools (I actually maintain tri-mesh also, where I think this would fit better 🙂 ) and focus on visualisation. The reason for having a bit of mesh generation anyway is to make it simple to get started, just get something on the screen, and when you have that and realise you want a sphere with very special uv coordinates, then you have to use something else.

I really hope you understand my reasoning and are not offended by this 🙂

Anyway, I will see if I can incorporate some of it to generate meshes internally because I really like the reusing of information.