As you cannot instantiate deformers (they do appear but don't do anything) I would say the only way is to create a second deformer for the "other" object, and use XPresso to connect that deformer to the "original" deformer.
The scope of a deformer is set by the parent object or parallel objects in the same hierarchy, not explicitly by some slots (like effectors), so it's just not working like Maya I'm afraid.
Hi Bentraje, thanks for reaching out us.
With regard to your question, although hacks might be put in place to achieve the desired behavior - like using the logic behind a generator to perform a deformation -, it should be remarked that the suggested workflow contrasts with the logic behind Cinema modifiers.
The BaseObject::ModifyObject() is indeed called by the scene execution pipeline, which is responsible for geometry handling and creation, only when the modifier has a parent object whilst it remains uncalled in all the other cases.
Cheers, Riccardo
Thanks for the response.
Just to confirm, to achieve the desired behavior (i.e. deformer affects objects outside hierarchy), I need to create my own logic of the deformer. Or is it still not possible since I have to rely on the BaseObject::ModifyObject() even if its my own logic?
Sorry. I'm new with the C++ or creating deformers. I just use python mainly to automate tasks.
@bentraje I'm not sure that this will address your desired use case, but if I ever need to apply the same deformer to objects in different hierarchies I'll turn to the Surface deformer.
Thanks for the response. The surface deformer still requires the usual deformer behavior (i.e. parent or in the same heirarchy), correct me if I'm wrong.
@bentraje it does, but it essentially behaves as an instance of another deformer. So the deformation is defined in one hierarchy location but can also be re-applied in any arbitrary location.
Like I said, that might not be what you're after, but it's helped me in certain situations.
I'm not sure I understand. I use surface deformer for attaching a geo to a surface. Say a separate eyebrow geo to the head.
If you have time, can you check this illustration file with the surface deformer as you suggested?
https://www.dropbox.com/s/6ygqp2er85cvili/c4d194_deformer_affect_outside_hierarchy.c4d?dl=0
@bentraje Apologies, I was perhaps a bit misleading in my description of the Surface Deformer. It actually behaves more like an 'instance' of the entire deformer stack that's affecting another object.
Thanks for the response and for the file. That was entirely new to me.
Just one little thing, there seems to be a priority issue when hit Undo there is some execution delay.
I can't solve it directly since there are no expose priority parameter in the deformer.
May I ask how did you solve the problem?
@bentraje I don't know exactly what issue you're facing, is this with the file I uploaded or another file?
The objects in the object manager are evaluated from top to bottom, so perhaps making sure the objects with the surface deformers are lower down the list than the object that they're referring to?
Yes, I'm referring to the file you uploaded earlier.
There is some delay when hitting Undo.
You can see it here:
https://www.dropbox.com/s/hayep6r4iyowqt5/c4d194_deformer_affect_outside_hierarchy_02.mp4?dl=0
RE: perhaps making sure the objects with the surface deformers are lower down the list
In your file, yep they are. That's why I was wondering why there is a lag.