改善您的节点图

尽可能早地修剪位置

的Prune节点用于从场景中删除对象。给定Geolib3-MT使用的处理模型，场景中修剪场景场景位置/对象的时间越早，下游Ops和Geolib3-MT本身所需的工作就越少。在这方面，可以将Prune视为提供过滤操作，从而减少必须由下游Ops处理的场景图的大小。

在以下示例中，资产由AssetsIn节点生成100个位置的场景图。边界框由ProcessBounds然后，从场景中修剪所有100个位置上的Op，然后修剪该镜头不需要的场景图位置。但是，如果将“修剪”节点放置在更靠近AssetsIn节点，场景图由ProcessBounds大小的一半。这直接转化为节省内存和处理成本。

尽可能早地修剪场景图对象/位置。这样做减少了下游Ops必须处理的位置数量，这相应地减少了内存和场景处理时间。

了解并行场景处理尺寸

Geolib3-MT的场景图处理系统搜索可以独立评估的，计算独立的任务。广义上讲，并行处理Geolib3-MT有两个方面可以利用：

• Scene Graph Parallelism -在延迟/延迟评估的场景图中，例如Katana，场景图包含潜在的工作。之所以可能，是因为它仅在场景图位置及其子项通过展开而已知后才进行计算。
  场景图位置的每个子代代表一个计算独立的任务，仅取决于其父代位置。一旦计算了场景图位置，就可以并行计算其所有子级。

• Op Tree Parallelism -Op树的子部分可以并行处理。这样，Geolib3-MT会在正在处理的Op树的子部分完全扩展场景。有些操作自然可以并行化，例如源操作（即那些没有输入的操作）。某些构造也可以自然地并行化，例如Merge Ops，其中每个Op树分支都是可独立计算的。

利用这两个方面的并行性，可以为Geolib3-MT提供已知待处理的独立计算任务的最大积压。

将合并分支用于计算独立场景图

一个的每个分支Katana可以将节点图视为生成独立的场景图，并通过使用合并节点进行组合。

由于“合并”节点的每个分支都代表一个计算独立的场景图，因此Geolib3-MT利用这一事实来并行扩展每个分支。如果不希望出现这种情况，可以在RenderSettings节点。要从Op树枝的这种并行扩展中受益，需要考虑许多事项：

• 将场景图视为不是一个大型场景图，而是多个较小的场景图，每个场景图都是由一个或多个相连的Ops生成的。
• 考虑场景图中存在的数据依赖关系，以及负责生成它们的Ops节点。是否有机会重构您的节点图，以利用多个独立分支机构提供的并行处理优势？
• 确定必须在多个位置上进行操作的受CPU约束的操作。虽然Geolib3-MT利用场景图本身内部可用的并行性（通过并行处理独立的位置），但也可以通过复制CPU绑定的节点和操作来并行评估CPU绑定的操作。

在此示例中，虽然由Alembic_In节点是并行生成的，并行性可用于CPUBoundOperation节点仅限于场景图。

示例重构节点图版本，其中CPUBoundOperation放在每个分支内，这意味着可以在两个维度（场景图和Op树）中利用并行性。

将可折叠节点/操作链放置在一起

为了处理特定Op上的场景图位置，Geolib3-MT必须执行许多步骤，包括但不限于：

• 确保位置的依赖关系（父位置及其从中继承其属性的位置）也已评估。
• 已分配内存以存储处理场景图形位置的结果。
• 在烹饪位置之前，已应用了所有继承的场景图属性。
• 使用Op的烹饪功能评估实际位置。

虽然此过程有效，但并非没有成本。检查依赖关系需要检查中央Cook结果存储，内存分配需要（潜在）系统调用，并且cook调用会产生少量开销来调用函数（即使cook()调用不会更改场景图）。

考虑到这一点，可以采取任何减少厨师数量的措施来改善场景图处理时间并减少内存使用量。

Geolib3-MT的新Op树优化功能执行预处理步骤来分析Op树的拓扑。一种这样的优化是折叠相同类型的操作链。例如，一系列四个AttributeSet作用在同一位置上的操作可能会分解为一个位置AttributeSet在那组位置上行动。这减少了缓存子系统中烹饪结果的数量，从而减少了场景遍历的内存占用。