Our game is experiencing an unusual long waiting time for the render thread during the duration of a projectile shooting. As far as we can tell, this only occurs to certain projectiles out of the many hundred available in our game. It’s a fighting game with a bunch of abilities and whatnot but none of those are really causing frame spikes, for some reason these specific projectiles are. We use the FastCast library to handle them, and it’s the same for all projectiles.
We put debugging profiles for the microprofiler in place to make sure it had nothing to do with the raycasting operations and whatnot, and it was true as you can see from this microprofiler log attached below. Instead, we found that the increased waiting time each frame was caused by an operation profiled as “buildSkeleton”. I am not sure what could be different about these projectiles causing this issue, they are basically the same as any other.
One of the projectiles is a basic arrow mesh, it is not a skinned mesh or anything of the sort. The other one that we currently know causes the same “buildSkeleton” operation to hang is a projectile that is a skinned mesh; however, this projectile gets parented to a folder specifically made to contain projectiles, as I’ve seen other forum threads mention layered clothing/skinned meshes causing similar frame spikes when parented directly to the DataModel, but that is not the case here.
This issue first arised only for specific devices as far as I could tell, the next morning, I continued to find the culprit and ended up having the frame spikes myself, which was surprising first considering that it wasn’t happening just last night, and that my PC also has fairly high specs (3070 Ti, 32GB RAM, i7-12700K).
microprofile-20241102-170757.html (2.9 MB)
This issue was caught by another developer on the team @Synteuro.
Expected behavior
buildSkeleton
to not be causing frame spikes