-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working with additional mesh input #35
Comments
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 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. |
Additionnal inputs are beginning to get supported.
Blender_.C__tmp_untitled.blend.2021-01-02.19-50-06_reenc.mp4 |
This looks great! :) I'll have a look at it this week when I have time. |
Just noting a bug I found when I started playing around with it:
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 Possibly |
Oh thanks for this report, as well as the suggestion, I'll look into it! |
OFX supports multiple inputs via
inputDefine()
onOfxMeshEffectHandle
, which is not currently supported by the Blender host.Use case examples from native Blender modifiers:
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:
The text was updated successfully, but these errors were encountered: