In a current project I’m drawing hundreds of spheres, of varying sizes. I discovered at one point that with them all in view simultaneously, performance was very bad (<10 FPS on my 6970M). Trial and error revealed that changing the geometry complexity – by changing the segment count of my spheres – made a huge difference. Seems logical.
Unfortunately, it turns out frequently recreating that geometry (as is necessary each time you change the segmentCount of an SCNSphere) is not cheap. So I went from a consistent but low frame rate to a fast but wildly varying frame rate – with stutters of a second or more at a time. Ick. It seems the GPU can handle that – the bandwidth involved is pretty tiny, and I don’t have any relevant latency concerns [yet], but the CPU cost is substantial.
An obvious thought is to create multiple versions of each sphere, one for each desired segmentCount, and then swap them in and out on demand. This does actually work “fine”, though I worry about its efficiency – I haven’t yet measured the RAM cost of the cached geometry, let alone what impact it might have on the OpenGL side (e.g. does it store every one in an FBO for the lifetime of the SCNSphere? OpenGL Profiler shows a lot of FBOs active at one time).
The best solution would probably be a geometry shader to perform the generation on the fly (or tessellation in some form). Unfortunately SceneKit doesn’t currently support geometry shaders.
