So I’ve got a ISMC with a lot of instances…in this case 50,000 of them. They all move around independently, so I’m doing a batch update of the instance transforms every tick using BatchUpdateInstancesTransforms(). I’ve turned off collision and nav mesh updates for the instances (because that just grinds everything to a halt) and only mark the ISMC dirty after all the updates are done. All that gives me a batch update of around 8ms, which is fine.
BUT I’m getting hit with really long BuildRenderData calls in the PostTickComponentUpdate phase. These calls get longer and longer over a period of a few seconds before dropping down, then ramping up again (my framerate graph looks like a sawtooth wave).
However, if I make ten copies of the ISMC and set them to 5,000 each, I don’t see this behavior; same total number of instances, but it runs much more smoothly and much faster overall. There seems to be something non-linear related to number of instances in whatever ISMC is doing with the render data.
I did a separate test where I don’t add or delete instances and leave the xforms alone, but instead only update the per-instance-custom-data (we need a batch version of this command, btw!) – and still see a big hit in BuildRenderData. The hit stays the same if I update a single instance or all of them.
The mesh is single quad, and material lightweight, so rendering is not a bottleneck.
My questions are:
- What’s going on with that BuildRenderData lag ramping?
- Does changing a transform or custom data of even a single instance trigger a complete rebuild of the render data under the hood?
- How does one handle large numbers of instances updating their xforms or custom data?
Thanks!
Lars