Make meshes manipulation easier

[EtaLoop]

Hey, just wanted to discuss about adding a few things.

Correct me if I'm wrong but, Document isn't very easy to manipulate : you have to browse the whole tree to find your meshes (vertex positions, normals, ...). What would you think about adding methods like Document::meshes() or materials() that will return iterator/list of Mesh with primitives where we could find vertex positions, normals, triangle indices, ... In order to make it more convenient to manipulate.

Basically, something like this gltf parser : https://docs.rs/gltf/latest/gltf/struct.Document.html.

This wouldn't affect the actual tree structure, but only adding methods to make things easier.

[digama0]

There are already some tools for being able to do this, although they are not particularly discoverable. Specifically, you can use the Document::local_map function with the type of the object kind you want to get a hashmap structure you can use for lookups, the Document::library_iter method for getting top level (Library<T>) objects, and Document::iter method for getting other objects by type. For meshes, you could thus do something like document.iter::<Geometry>().filter_map(|g| g.element.as_mesh()). (Some information relevant to the mesh is in the Geometry though, so you probably don't want to just get the mesh itself and ignore the geometry like this.)

[EtaLoop]

You can filter by mesh, yes. But you still have to go into Mesh.elements to search for inputs types (vertex/normal/textcoord). Then, you search in Mesh.vertices for your vertex positions that refer to something in Mesh.sources (Same for normals).

That's a lot of things to do. If all people need to do this on their side, it's pretty annoying. Why not doing this filtering/research directly in the project?

[digama0]

Yes, it is a lot of steps. But most of it is just because collada is a complicated format with a lot of pieces which were designed to be mixed and matched in a huge number of ways, so while most individual use cases don't need all this complexity, I don't think it is possible to present a simpler interface that doesn't significantly reduce the applicability to other shapes of usage, and I don't have enough concrete applications or reverse dependencies to be able to confidently determine a least common denominator interface which isn't overspecialized. That's why the API looks the way it does, they are all APIs that assist you to use the collada puzzle pieces as intended, but don't skip any steps.

If you have a concrete API implementation to suggest, feel free to suggest one here or make a PR. Collada is not gltf (although quite frankly I think the khronos group did a better job with gltf) and I don't think the API transfers cleanly, but you are welcome to try.