• RuntimesUnity

  • Best Practices for Handling a Large Number of Characters Onscreen?

    engleski

Hi everyone,

I'm planning to have 50-100 characters on screen at the same time in my game, with each one randomly assembled from different body parts and equipment pieces. Currently, I have 20-30 body & equip parts planned, and in the future, I may design many optional skins for each part. I'm still working on how to implement this, and I was wondering if there are any best practices or similar examples regarding performance optimization.

I also have a specific question: In a scenario where 50-100 characters share 22 body parts, should I avoid repacking a single texture for each character individually? Instead, should I repack all the parts that will be used in the scene into one or several textures? If so, what would be the best way to achieve this? Thank you very much! 🙂

Related Discussions
...

To handle a large number of characters onscreen efficiently, you should consider the following best practices:

  1. Pre-pack Textures Smartly: Instead of repacking textures for each character individually at runtime, pre-pack your textures into a few shared atlas pages. This way, you can minimize the number of draw calls by ensuring that many characters can share the same atlas textures. For example, you can have one atlas for common body parts and another for common equipment items.

  2. Runtime Repacking: If you need to mix and match parts dynamically, you can use runtime repacking to combine only the necessary parts into a single texture atlas. However, this approach can be performance-intensive, especially if you have many characters. It is generally more suitable for scenarios where the number of characters is limited, or the skins do not change frequently.

  3. Optimize Draw Calls: Group attachments in a way that minimizes the number of draw calls. For instance, ensure that characters sharing the same atlas textures are rendered together. This can be achieved by organizing your atlas textures based on the most common combinations of body parts and equipment.

  4. Use Efficient Bone Structures: Keep your bone structures as simple as possible. Reuse bones where feasible and favor point bones with attached meshes to reduce clutter and improve performance.

  5. Test on Target Devices: Always test your setup on the target devices to ensure that the performance is acceptable. Different devices may have varying capabilities, and what works well on one device might not perform as well on another.

Here are some relevant links and examples from the Spine documentation and forums that might help you further:

By following these practices, you can achieve a balance between performance and flexibility in your game.

Thanks, bot! Is it possible or recommended to repack all the parts used in a scene into a few texture atlases, rather than repacking a separate skin for each character, to reduce draw calls?

    It seems like the bot doesn't respond a second time, so I'm hoping someone with more expertise can help me. In my case, I have a lot of body parts, and very few (only 1 out of 22) are universal. This makes it difficult to optimize the atlas directly using the texture package during export. Given this, are there any other ideas to effectively reduce draw calls?

    For example, is it possible to:

    1. Pre-calculate and randomly combine the skins for all 100 characters needed in the scene?
    2. Identify and remove duplicate atlas regions from these 100 skins, then repack them into one or a few atlases to be used in the scene?

    Any advice would be greatly appreciated! 🙂

    wpw1221 Is it possible or recommended to repack all the parts used in a scene into a few texture atlases, rather than repacking a separate skin for each character, to reduce draw calls?

    You should theoretically be able to write code to pack multiple skeleton's attachments, via e.g.
    GetRepackedAttachments instead of GetRepackedSkin(), but if this requires multiple atlas pages it won't really work as well due to the way that Unity's texture repack calls work, downscaling items until they fit.

    There is also a theoretical problem with repacking multiple skeleton's attachments at runtime when requiring multiple atlas pages: how should they be grouped, which attachment should go where? If they are grouped badly, it will lead to lots of additional draw-calls when each skeleton uses attachments from alternating atlas pages.

    If you know that multiple skeletons fit on a single atlas page, it's likely best to pre-pack them in the Spine Editor or via the command line by packing via folder structure. As I don't know your project, I can't say how many attachments are shared, what your skeleton count in view at once is, etc, so it may vary from project to project.

        Harald Thank you Harald! In my project, I plan to use 22 parts (11 equipment parts and 11 body parts) to randomly generate highly diverse NPCs based on the same skeleton, with each part having about 20-30 options.
        Every time the player enters a scene, I will randomly generate a map and around 100 NPCs, assigning them various AI behaviors (some as enemies, others as allies).
        After listening to your advice, I plan to first try repacking each NPC individually to see if it runs well on the target platform (PC). If I encounter performance issues, I'll give GetRepackedAttachments a try，and may reach out for more guidance from you then 🙂
        Thanks again!