Add a global transform property on meshes

[eliemichel]

As pointed out by @tkarabela in eliemichel/OpenMfxForBlender#35 there would be a fair need for a kOfxMeshPropTransform to provide a global transform matrix. So also we need a way to have matrices in properties maybe.

[eliemichel]

I was thinking, if a Transform property is attached to inputs, we'll have to have one attached to the output. By default it'll be the main input one, but if a plugin writer wants to change this it makes the effect become a constraint rather than a modifier. In blender it is not possible to do both at the same time.

[eliemichel]

Added kOfxMeshPropTransformMatrix:

Matrix converting the mesh's local coordinates into world coordinates

• Type - pointer X 1
• Property Set - a mesh instance (read only)

This points to an array of 16 doubles representing a transform matrix in row major order.
Some mesh effect inputs may be used only for their location or matrix. Some others might
ignore this property as they operate in local coordinates. This pointer may be NULL in which
case the transform is assumed to be the identity.

[tkarabela]

So, if I understand correctly, we have:

  /  m[ 0] m[ 1] m[ 2] m[ 3]  \  / p[0] \    / q[0] \
  |  m[ 4] m[ 5] m[ 6] m[ 7]  |  | p[1] |    | q[1] |
  |  m[ 8] m[ 9] m[10] m[11]  |  | p[2] | == | q[2] |
  \  m[12] m[13] m[14] m[15]  /  \ 1.0  /    \ 1.0  /

where m is the kOfxMeshPropTransformMatrix pointer, p is a value from kOfxMeshAttribPointPosition (point in local coordinates) and q is a point in global coordinates?

[eliemichel]

Correct!
In particular m[3], m[7], m[11] is the object's position.

[eliemichel]

I think we should change this a bit and add a way for the effect to request the transform first, a bit like what we intend for attributes. Because as it is now the effect should theoretically be recomputed every time the object's transform change, in case the effect uses it, which is stupid for many cases!

[tkarabela]

I was thinking about adding kOfxMeshEffectPropDependsOnTransform, since I generally think that an effect will either not care about transform at all, or need to know relative position of all input meshes, so making it granular on mesh level seems needlessly complex.

In the same vein, we may want kOfxMeshEffectPropDependsOnTime in the future, though I'm not clear on how time-dependent effects should work (as opposed to eg. animating their parameters in the host application or animating their input meshes) - but that's for another ticket :)

[eliemichel]

I was thinking about adding kOfxMeshEffectPropDependsOnTransform, since I generally think that an effect will either not care about transform at all, or need to know relative position of all input meshes, so making it granular on mesh level seems needlessly complex.

I agree with the fact that there is little use in knowing the location of only one of the inputs but these unimaginable edge cases would really suffer from it when they will exist and the overhead for adding input-level switch is reasonnable, so I'd lead toward a kOfxInputProp rather than kOfxMeshEffectProp.

In the same vein, we may want kOfxMeshEffectPropDependsOnTime in the future, though I'm not clear on how time-dependent effects should work (as opposed to eg. animating their parameters in the host application or animating their input meshes) - but that's for another ticket :)

I should check out again how they do in Image Effects, but I agree that time mostly is a parameter like any other as long as we don't allow "solver"-type modifiers that read the previous frame to generate the next (I don't think that image effect allow this neither).

[tkarabela]

I agree with the fact that there is little use in knowing the location of only one of the inputs but these unimaginable edge cases would really suffer from it when they will exist and the overhead for adding input-level switch is reasonnable, so I'd lead toward a kOfxInputProp rather than kOfxMeshEffectProp.

kOfxInputProp sounds fine :) Most hosts will probably implement this using some scene dependency graph, so having it per-object will match the underlying logic.

I should check out again how they do in Image Effects, but I agree that time mostly is a parameter like any other as long as we don't allow "solver"-type modifiers that read the previous frame to generate the next (I don't think that image effect allow this neither).

It would seem handy for video (denoising, warp stabilization, etc.) and apparently OpenFX does have support for this: https://openfx.readthedocs.io/en/master/Reference/ofxRendering.html#rendering-sequential-effects

In terms of Open Mesh Effect, one way it could be useful would be with the "generator" context - you could use a plugin for reading animated data in some format, without needing direct support for the format in the host application.

[eliemichel]

Fixed with kOfxInputPropRequestTransform, see #11