哪个数据结构用于基于节点的编辑器?

时间:2013-04-16 11:56:21

标签: c++ user-interface data-structures nodes

某些程序(即声音合成,程序纹理生成......)使用户可以通过图形编辑器以任意方式完全自由地安排程序的各种功能。用户可以放置一个或多个“节点”(每个节点代表某种功能,从一个或多个输入生成一个或多个输出),并以任何所需的方式将它们拼接/连接在一起,以生成最终输出。

我想知道这种软件的最佳表现形式可能是必要的数据结构,包括发电机系统本身以及图形表示。我特别困惑的是如何模拟节点输入和输出可能具有各种数据类型的事实,并且根据节点类型,其中只有一些可能是有效的。

所以如何建模:

  • 节点输入/输出值
  • 节点本身(继承?)及其连接
  • 生成过程,从起始节点传播到输出节点

2 个答案:

答案 0 :(得分:1)

我参与了一些像这样的系统。有许多不同的做事方式。但我过去做过的一个常见方法是让Node对象链接到其他Node对象。节点通过某些IAction接口包含一个操作对象。用户以某种方式指定在特定节点上实现IAction接口的具体操作对象(这通常还涉及为对象指定一些状态,例如要应用的过滤器的参数)。

然后有一个框架,它初始化(编译)并执行(运行)图形,并在输入就绪时安排用节点的输入调用IAction接口,并将输出传递给下游节点。这是一个非常简单的算法:并行运行所有输入的节点(从没有输入的节点开始),然后将其余节点放在等待队列上,直到它们的输入存在。

这只是一种如何做的风格;有许多变化,并且有很多系统使用这种技术,正如你所指出的那样。也有一些框架(TPL Dataflow就是这样,如果我理解正确的话。)

重新提出关于如何确保节点之间的连接一致的问题,我认为这取决于框架的运行量和节点的数量。在一个极端情况下,框架可以在图形“编译时”严格匹配连接类型;另一方面,框架可以将其留给节点以在“运行时”进行检查。如果大多数连接只是相同的类型,后者可能是合适的,例如,例如,它们都是字节流。

btw在Java或C#(或其他HLL)中可能比在C ++中更容易,因为对接口,反射,动态加载对象等的支持更多(例如在C#中,您可以轻松指定类型对于一个对象并从流中动态创建它,而你必须自己在C ++中滚动它。

答案 1 :(得分:0)

您可能需要查看Observer模式,特别是此类事物的信号/插槽系统。 Observer PatternBoost.Signals

我曾经使用C ++使用信号/插槽工作的项目允许不同的音频合成模块在运行时由用户动态连接。但是,在性能方面可以进行权衡。

对于不同可能输入的建模,您可以使信号对象包含实际数据作为void指针和字符串或枚举,指定接收类假定在处理期间正确的数据类型。当您的用户最初连接这些对象时,可以返回一种合同('这些是此对象发送的类型'),并且可以在处理开始之前完成实际验证。