Question

我在SceneKit应用程序中发现了一个主要的性能瓶颈，原因是该嵌套循环运行了数千次。在该循环中，除了这一行以外，有一堆代码非常愉快地缩放：

var scenePos = presentation.position

这比只要求位置要慢100倍，再加上我在同一循环中所做的数十种其他计算，比较，数组查找和方法调用的组合。令我惊讶的是，似乎没有人对此发表评论。

这是为什么，除了复制每个节点的演示文稿之外，还有其他解决方法吗？将自己放置在每个帧中，这样您就不必一直向演示节点询问它了吗？谢谢。

编辑：presentation.position仅被读取，从未被写入。永远不会编辑boundingBox。我为几个SCNNode使用了动态SCNPhysicsBody，但绝大多数是静态的。

Answer 1

这是我当前正在使用的解决方法（为此，以及如果从未为该节点运行物理操作，则presentation.position可以为零的单独问题）。因为几乎我所有的节点都不是动态的，所以速度快了几个数量级。

// When you're not sure if physics has first run yet
func currentScenePos() -> SCNVector3 {
    if physicsBody?.type == .dynamic {
        var scenePos = presentation.position
        if scenePos.isZero() {
            // Looks like the physics hasn't run on this node yet. Use the regular position.
            // If that's zero too, it must really be at the scene origin.
            scenePos = position
        }
        return scenePos
    } else {
        // Non-dynamic physics. Just use position, it's a lot faster.
        return position
    }
}

Answer 2

我目前正在解决一个错误，该错误涉及到对presentation.transform HANGS的永久更改。该文档说，对SceneKit数据（例如SCNNodes）的引用是线程安全的。例如。如果另一个进程（或3D硬件）正在使用该节点，则它们将等待互斥锁。尽管我还没有发现谁在握我的锁（可能是一个愚蠢的程序错误），但让我震惊的是，您读到的帖子是，如果3D硬件正在使用该节点，则可能要等待几毫秒，直到它通过。这可能会导致您的性能问题。

为什么SCNNode.presentation.position相对较慢，并且有解决方法？

2 个答案: