Possibly nicer interface for all those model/mesh/vertex-data selection functions

[johannesugb]

The function gvk::make_models_and_meshes_selection (which returns std::vector<std::tuple<std::reference_wrapper<const gvk::model_t>, std::vector<size_t>>>) and all the functions which take its returnvalue as a parameter are meant as convenience functions => see:

• gvk::get_vertices_and_indices
• gvk::create_vertex_and_index_buffers
• gvk::get_normals
• gvk::create_normals_buffer
• gvk::get_tangents
• gvk::create_tangents_buffer
• gvk::get_bitangents
• gvk::create_bitangents_buffer
• gvk::get_colors
• gvk::create_colors_buffer
• gvk::get_bone_weights
• gvk::create_bone_weights_buffer
• gvk::get_bone_indices
• gvk::create_bone_indices_buffer
• gvk::get_2d_texture_coordinates
• gvk::create_2d_texture_coordinates_buffer
• gvk::get_2d_texture_coordinates_flipped
• gvk::create_2d_texture_coordinates_flipped_buffer
• gvk::get_3d_texture_coordinates
• gvk::create_3d_texture_coordinates_buffer

The problem is that creating and using std::vector<std::tuple<std::reference_wrapper<const gvk::model_t>, std::vector<size_t>>> is not really very convenient. Especially dealing with the reference_wrapper can become a bit cumbersome - let alone the potential problem of the dangling reference. There is no way of ensuring that the gvk::model_t will outlive a std::reference_wrapper<const gvk::model_t> referencing it. I.e. a dangling reference can occur.

Investigate potential nicer ways of handling such models and meshes selections!

Actually, do not limit yourself to the view that such a selection must consist of a reference to a model_t and a set of mesh indices! Feel free to completely re-think this problem! Feel free to introduce breaking changes.

What should be the outcome of this task is a more user-friendly and easy-to-use way of getting (combined) vertex data from different meshes (of potentially different models).

Hint: When implementing this, please also consider Issue #69.

Definition of done:

• [ ] Usage of the above-mentioned functions is more convenient and clearer
• [ ] Forcing owning_resource::enable_shared_ownership on the used models means probably too high costs for what it accomplishes. On the other hand, there's the problem of the dangling references. What would be the best way to go here?
• [ ] The orca_loader example is adapted to the new way and its code becomes easier to understand.
• [ ] The ray_tracing_basic_usage example is adapted to the new way and its code becomes easier to understand.
• [ ] The ray_tracing_triangle_meshes example is adapted to the new way and its code becomes easier to understand.
• [ ] All of the functions mentioned above are well documented (especially that dangling reference issue, if it still is one in the final solution) and the Contribution Guidelines have been followed.