Open Search

Draw call performance in SceneKit

December 10, 2017 8:29 pm
Categorised in:
Reading Time: 2 minutes

Been watching a few WWDC sessions. Some lovely SceneKit Tips in the SceneKit in Swift Playgrounds video for reducing draw calls and improving FPS performance which is handy for a noob like me. Managed to jot this one down. Just a reminder to myself really.

Draw calls

Draw calls are the times taken for every node with geometry during each frame render (as discussed from around about here in the aforementioned video). Each draw call adds up to the amount of time to render a frame. To achieve 60FPS each draw call should be ~16 milliseconds. The more individual nodes in a scene the more draw calls reducing FPS.

If a group of objects do not move relative to something else or the geometry is not dynamic in some way, flatten that group of nodes to reduce the number of draw calls. This will improve performance as each of these flattened nodes which may contain a lot of pieces of geometry is only called by the renderer once. However, if you have a very large environment which does not fit the screen, do not flatten all the environment into one. This will reduce performance. Instead subdivide your environment into chunks then

Key Takeaways

Store non-dynamic nodes to be flattened in the same parent node and reduce the number of draw calls

Separate & flatten chunks of large environments together to not incur a performance penalty

Animating characters going upstairs

This quickly explains how to animate a character going upstairs, as translating just X and Y creates a floating effect. Inverse Kinematics would allow exact positioning at the expense of lack of motion at the top of the model. The solution is to translate the geometry and not the node, then when complete, update the node position and remove the character offset.

I drew this out as I was watching it for some reason so not much point explaining it as I have above really, I’ll just drop the  picture in below anyway.


Key Takeaways

Translate the geometry’s position, not the node, using a SCNTransaction.

This joint was penned by @elmarko