Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

Performance impact of having several slots

adrian

Hi,

I'm using the mix-and-match approach to create a modular character.
The character has 1 head bone with the following 4 slots: Head (shape), Eyes, Hair, and Facial Hair

I've tried to be mindful of the # of slots, but if I were to add several additional slots to the head bone (eye brows, nose, mouth, ears, blemishes, tattoos... etc) will there be a large performance impact? I'm not seeing any major performance hits during my initial tests, but I wonder if this scales, once my atlas has several different attachments included.

Thanks in advance for any insight!

Regards,
Adrian

Nate

Take a look at typical renderer code:
https://github.com/EsotericSoftware/spine-runtimes/blob/3.8/spine-libgdx/spine-libgdx/src/com/esotericsoftware/spine/SkeletonRenderer.java#L91

If you have many slots, it will go through that loop many times. If the slot has no attachment, it is just skipped. The number of slots doesn't affect performance, but the number of attachments that need to be rendered does. For attachments a better metric than the number shown is how many vertex transforms are required. See the docs here:
Metrics - Spine User Guide: Vertex transforms
Metrics - Spine User Guide: Performance

adrian

Thanks Nate this is helpful. These additional slots copy the position of the head bone, so there aren't too many additional vertex transforms.

I noticed there's also a squared pixels metric. Assuming many of these additional slots use attachments that are relatively smaller in size, does that generally help?

I guess what I'm really asking is, is it wise to allow for this level of modularity in my game, or is it best practice to limit the number of configurable slots/attachments and create different preset face combinations instead.

Regards,
Adrian

Nate

How many pixels you are drawing is relevant for the fill rate of the device your app is running on. The device can render up to some maximum number of pixels in the time you allocate in order to keep a target frame rate. As long as you are rendering less than that, then you are good. Of course, other things use up the time you have to render a frame.

The way performance works is that it doesn't matter to your users at all, except if it impacts their experience. You are wasting your time and likely unnecessarily complicating your project if you are optimizing things that don't affect the user experience. The best way to go about it is to consider how you want your app to scale, then simulate that load and see how it performs on the lowest and medium level hardware you are targeting. To do that you could, for example, draw your skeletons multiple times instead of once. Say you find you can draw everything 100x before the frame rate drops on low end hardware, then you have some idea of how much more complex you can make your skeletons. Be sure to consider that you may want to render many different skeletons at once.