Utilities for refactored Blender add-on

[Speierers]

This PR contributes necessary updates and utilities for the major refactoring of the Mitsuba-Blender add-on.

Proposed changes:

• The MeshHolder shape plugin, a wrapper around Mesh to hold a mesh instance in a Python dictionary using tensors.
• Improvements to the blender shape plugin.
• Improvements to the mi.xml_to_props routine for importing Mitsuba scenes in Blender.
• Introduction of the mitsuba.blender submodule, that implements performance critial routines in C++, exposed in Python to be used by the add-on.
• The Mesh constructor now takes an optional displacement_map texture nested object that's used during construction to displace the vertex positions.

[wjakob]

Hi Sébastien, this looks fantastic. Two quick comments:

• Naming: I think I would prefer the name BufferMesh instead of MeshHolder.
• XML parser: this is pretty central infrastructure, so I would appreciate a run-down of the changes there.

[wjakob]

A high level question: what do you think about making a separate repo that only contains the blender conversion code? (For images, BlenderMesh CPU-side conversion code, etc.).

Sometimes blender changes the internal layout of data structures (has already happened several times). It's weird that this then creates a constraint on compatible Mitsuba versions. It would be better if we could tell users to install mitsuba-blender-iface==1.2 for Blender version X, etc.

[Speierers]

XML parser: this is pretty central infrastructure, so I would appreciate a run-down of the changes there.

@wjakob those changes are actually minimal, and not really touching the central parsing infrastructure. Also they are not necessarily related to Blender, but also general improvements on current codebase:

1. In xml_v.cpp, we now rely props.named_reference to store instanced during loading, instead of allocating a separate map for that (which is how it is done in xml.cpp).
2. When we expand the object, if the object is a null pointer, then it is not set into the properties
3. xml_to_properties now returns a map of { ID -> (type, props) } instead of just a list of instances. This is to match the API of dict_to_props which needs to return the data in this format as in the case of Python dictionaries, instance IDs are not always the same of the ID stored in props.

[Speierers]

A high level question: what do you think about making a separate repo that only contains the blender conversion code?

Although I understand the constraints of Blender being a moving target, I am not a fan of the idea of putting this code in a seperate repo. I doubt we will be able to maintain an interface for all Blender versions in any case, and it adds another layer of compilation / installation that will confuse the users. IMO it makes more sense to either contraint the users to use a specific range of Blender versions, are let the code handle the different versions (as done currently in the shapes/blender.cpp plugin.

[wjakob]

Hi Sébastien -- can you explain what the issue would be? To me, this sounds much simpler: we to wrap a function which extracts the mesh and gives back an nd-array with vertex positions, normals, etc.

We could compile provide this as a binary wheel (e.g. mitsuba-blender-extras). If should be doable in a way that has no dependence on Mitsuba. If this is compiled with a stable ABI, it will work independently of future Python versions, and the only remaining gotcha would be to replicate whatever ABI changes Blender performs in the future.