• Unity

  • Multiple Remapping Question

    anglais

  • ara

    • Message #1
    • Modifié
    • Ce post est en anglais
    Related Discussions
    ...

    • ara

      • Message #2
      • Ce post est en anglais

      My character has a weapon slot.
      There are many kinds of weapons to swap so that I store them in one Unity Sprite altas.

      I put several duplicated characters (same skeletonDataAsset) in one scene,
      Then I randomly pick a sprite to remap original weapon mesh.
      for example: CharacterA holds a sword, CharacterA(clone1) holds a gun, CharacterA(clone2) holds a dagger.

      The problem is after remapping sprite weapons their material are totally different.
      (two for each)
      Even after Runtime Repacking , three runtimeMaterials are individual and of course can't be batched.

      Is it possible to repack original material with the whole weapons atlas first, then random remapping for each skeletonObject?
      Or maybe I should remap for each weapon first and cache them to a collection, then repack & apply one same material for cloned characters?
      Can I keep multiple [sprite-meshAttachment remapping] relation (N sprites vs 1 slot) for one single runtime repacking?

      Any advice would be appreciated.Thanks

      Currently, runtime packing takes all the attachments in a Skin object, reads all the renderable attachments and their backing textures. Then it packs a new atlas, and creates a new set of attachments that use that new atlas, and puts that in a new Skin.

      It sounds like your repacking wasn't done correctly

      in the sense that you didn't include the new weapon attachments into the Skin you were repacking.
      If you want them to be included in the new packed atlas, you need to include the attachments in the skin you're repacking.

      • ara

        • Message #4
        • Ce post est en anglais
        Pharan a écrit

        Currently, runtime packing takes all the attachments in a Skin object, reads all the renderable attachments and their backing textures. Then it packs a new atlas, and creates a new set of attachments that use that new atlas, and puts that in a new Skin.

        It sounds like your repacking wasn't done correctly

        in the sense that you didn't include the new weapon attachments into the Skin you were repacking.
        If you want them to be included in the new packed atlas, you need to include the attachments in the skin you're repacking.

        Thanks Pharan, actually the repacking works fine.
        When I said 3 materials, they're three repacked materials after 3 times individual repacking.

        However, we want reduce the material number so that they can be batched, as the picture below.


        Can we repack a material/atlas which contains more than one skin(instead of overriding way by Skin.Append)?
        In other words, we want swap the weapon attachment after repacking them into a new texture.

        Ah, I understand. This API doesn't exist yet. We can add it in 3.7 but I'm not sure yet what form it will take.

        In 3.6, the only way to do this is include everything (eg, the sword, dagger and spear, and any others) into a single skin. Repack that. Then use Skin.GetClone to get a copy of that skin for each instance you need to customize. Then you can customize each instance to use the attachment you want by assigning the right keys to them.
        (you assign an attachment with a key in a skin by using Skin.SetAttachment)

        1. allAttachments= goblinSkin.GetClone
        2. add all the attachments to allAttachmentsusing allAttachments.SetAttachment. Make each key unique so they don't overwrite each other.
        3. call repackedAllAttachments = GetRepackedSkin(allAttachments...)
        4. for each instance, use repackedAllAttachments.GetClone. Then set the appropriate attachments again using the right values for SetAttachment.
          For example,
          goblin1Skin = repackedAllAttachments.GetClone()
          goblin1Skin.SetAttachment(weaponSlot, "weapon placeholder name", sword attachment)

        • ara

          • Message #6
          • Ce post est en anglais

          You're absolutely my savior, Pharan. Thanks for the workaround, it works as expected.

          One little stupid question: Is there a neat way to change the attachment's name property?
          Since I found that after calling GetRemappedClone method, region attachments were renamed as "name"+"clone" while mesh attachments kept their original name. I want to remove the clone suffix to keep them unified .

          Besides, I'm looking forward to the new API.

          Every attachment has a name. You can change it through its public Name property. It's just a string. You just change it.
          I guess there's an inconsistency in how clones are named in Attachment tools. We'll fix that.

          But in a skin, retrieval is done through its skin key. That shouldn't have the "name+clone" pattern on it.

          Pharan a écrit

          Every attachment has a name. You can change it through its public Name property. It's just a string. You just change it.
          I guess there's an inconsistency in how clones are named in Attachment tools. We'll fix that.

          But in a skin, retrieval is done through its skin key. That shouldn't have the "name+clone" pattern on it.

          Oh sorry.I guess there's some reason for kept its name setter private so I ask the stupid question instead of change it to public immediately.

          Oh, is it private? I hadn't noticed, sorry.
          I guess in 3.7, we can have an optional argument for the new name upon cloning, or make that public.

          That's great, thanks Pharan.