这个问题已在Nuke-dev 邮件列表中得到解答:
如果您知道 Op 输入的实际类,则可以将输入转换为该类类型并直接访问它。一个简单的例子可能是下面的这个片段:
//! @file DownstreamOp.cpp
#include "UpstreamOp.h" // The Op that contains your custom data.
// ...
UpstreamOp * upstreamOp = dynamic_cast< UpstreamOp * >( input( 0 ) );
if ( upstreamOp )
{
YourCustomData * data = yourOp->getData();
// ...
}
// ...
更新
参考我通过电子邮件收到的问题进行更新:
我正在尝试做同样的事情,将自定义数据从一个 Iop 插件传递到另一个。但这两个插件是在不同的 dso/dll 文件中定义的。你是怎么让它工作的?
简短的回答:
将您的 Ops 编译为单个共享对象。
长答案:
说
定义依赖的 Ops。
在第一次尝试中UpstreamOp.cpp
,我像往常一样使用 only 编译了第一个插件。对于第二个插件,我将两者都编译DownstreamOp.cpp
到
UpstreamOp.cpp
该插件中。
奇怪的是,它起作用了(在 Linux 上;没有测试 Windows)。
但是,通过覆盖
bool Op::test_input( int input, Op * op ) const;
事情会破裂。使用上述插件创建和保存 Comp 仍然有效。但是再次加载相同的 Comp 会破坏和之间的节点图中的连接,UpstreamOp
并且DownstreamOp
不再可能再次连接它们。
我的假设是这样的:因为两个插件都包含符号,如果节点使用
来自第一个插件或来自第二个插件的UpstreamOp
实例,它取决于插件的加载顺序。UpstreamOp
因此,如果UpstreamOp
使用第一个插件,则任何dynamic_cast
输入Op::test_input()
都将失败,并且两个 Op 无法再连接。
令人惊讶的是,Nuke 甚至会费心从上述配置开始,因为它对插件中的符号可能相当挑剔,例如,如果它们丢失了。
无论如何,为了解决这个问题,我做了以下事情:
- 将两个 Ops 编译成一个共享对象,例如 myplugins.so,并且
- 添加指示 Nuke 如何正确加载 Ops 的 TCL 脚本或 Python 脚本 (init.py/menu.py)。
可以在开发指南中找到 TCL 脚本的示例,并且 menu.py 的说明可能是这样的
menu = nuke.menu( 'Nodes' ).addMenu( 'my-plugins' )
menu.addCommand('UpstreamOp', lambda: nuke.createNode('UpstreamOp'))
menu.addCommand('DownstreamOp', lambda: nuke.createNode('DownstreamOp'))
nuke.load('myplugins')
到目前为止,这对我们来说是可靠的(在 Linux 和 Windows 上,还没有测试过 Mac)。