Working with additional mesh input

[tkarabela]

OFX supports multiple inputs via inputDefine() on OfxMeshEffectHandle, which is not currently supported by the Blender host.

Use case examples from native Blender modifiers:

• Using the full second mesh in the effect (eg. Boolean), possibly accounting for vertex weights (eg. Mesh Deform) - see #21
• Using just origin and/or transformation of the second mesh (eg. Cast)

We should definitely support the first use case; the second use case is not directly applicable to OFX, since we do not have such metadata for the meshes, but it's handy for interactive use (moving the second mesh vs. tweaking float3 parameter of the effect in UI).

Come to think of it, this feature may need some design work on OFX spec side to make sure it's usable - just giving the effect two meshes in their local coordinates without hinting at their relative position seems quite limiting, considering how one typically works with native Blender modifiers.

---

Edit from @eliemichel:

• [x] Basic integration
• [x] Supporting input transform
• [x] Unsetting the input object crashes blender
• [ ] Objects are not persistent fo file reload (spent some time on this, but unsuccessfully)

[eliemichel]

For the first case, your last note is indeed soemthing I had not taken time to think about. Using local coordinates would really make sense in the spirit of reusing existing data buffer as much as possible, but this means adding some kind of kOfxMeshPropTransform to the spec.

Regarding the second point, where only the transform is used, we can use parameter subtypes. The original OpenFX API has such "role" distinction between parameters of the same underlying type; for instance a double parameter may be an angle, a timecode, etc: https://openfx.readthedocs.io/en/master/Reference/ofxParameter.html#types-of-double-parameters We could have a "locator" subtype. To take the whole transform into account, we'll need to play with group parameters maybe.

[eliemichel]

Additionnal inputs are beginning to get supported. Remaining bugs:

• [x] Unsetting the input object crashes blender
• [ ] Objects are not persistent fo file reload (spent some time on this, but unsuccessfully)

https://user-images.githubusercontent.com/5802849/103464621-8383f200-4d35-11eb-89b2-415ebd601762.mp4

[tkarabela]

This looks great! :) I'll have a look at it this week when I have time.

[tkarabela]

Just noting a bug I found when I started playing around with it:

• switching to edit mode when the input object is selected crashes Blender

This is a bit strange since editing the object to which the modifier is attached does work, just not editing the object selected as input. When cooking, the extra mesh has non-NULL Blender Mesh*, but mloop etc. are all NULL, instead it looks like the data is stored in the edit_mesh attribute.

Possibly BKE_mesh_wrapper_ensure_mdata() is the correct function to get out of this.

[eliemichel]

Oh thanks for this report, as well as the suggestion, I'll look into it!