• Editor

  • Customizable character workflow.

    anglais

I've got my own custom build gpu skinning shader working and now I'm thinking about how I want to support character customization. This seems like a real puzzler.

Skins seem problematic. It's a lot of data to maintain and I don't see how its compatible with mod authors. If someone adds a new type of head, I could create a dynamic attachment, but don't I have to now bind additional textures or re-stitch the atlas? That doesn't seem to scale well.

I could generate a small atlas per character at runtime, cached and keyed by the selected options, but that's wasting a lot of texture memory for duplicated body parts.

I had the idea that I could send uvs in a uniform buffer, instead of making them vertex attributes. Or I could calculate a UV offset for a given appearance. So if you chose orc head 0, it would use the attachment uvs. If you chose orc head 1 it would offset the uvs by the positional difference of head 1 in the atlas. This would be pretty efficient, but still doesn't work with mod authors images.

I'm sure I'm overlooking the obvious simple answer. Searching the forums hasn't been very illuminating.

I think I need to break the problems apart. What's the best way to handle third party images for replacements for attachments?

Related Discussions
...

To handle third-party images for replacements for attachments in a customizable character workflow, you can consider the following approach:

  1. Dynamic Attachment Creation: Allow mod authors to add new attachments dynamically. This can be done by creating new attachments at runtime and specifying the texture and UVs for these attachments. This way, you can support new images without needing to modify the original atlas.

  2. Runtime Atlas Repacking: Instead of maintaining a large number of skins, you can generate a new atlas at runtime that includes only the images currently needed. This can be done using a runtime texture packer. For example, in Spine-Unity, you can use the GetRepackedSkin method to repack the atlas with the selected attachments.

  3. AttachmentLoader: Use an AttachmentLoader to control the loading of textures. This allows you to load only the textures that are actually needed, which can be particularly useful for handling a large number of potential attachments.

  4. Uniform Buffer for UVs: As you mentioned, you can use a uniform buffer to send UVs instead of making them vertex attributes. This can help in managing UV offsets dynamically based on the selected attachments.

  5. Template Images for Mod Authors: Provide mod authors with template images or a full texture atlas that they can paint in. This ensures that the new images fit the existing mesh texture coordinates. The mod authors can then upload their painted versions, and you can load them as new attachments.

Here are some useful links and examples from the context that might help you implement these solutions:

By combining these approaches, you can create a flexible and scalable system for character customization that supports third-party images and dynamic attachment creation.

Regarding dynamic attachments, do you recommend each attachment be rendered as a separate mesh? I currently mesh the entire spine character and use a depth buffer for sorting. I could instead render each attachment as its own mesh, but this increases code complexity and draw calls.

I could, perhaps, bind multiple textures for the different parts, but this would lead to a lot of bindings.

I'm not using Unity. Is there source code for the atlas packer? I could pack my own atlases, I already do this for some wangtile assets in the game. But I don't see, yet, how I can square this with the uvs Spine generates at skeleton build time.

Templates make sense for entire reskins, but mixing their heads with our bodies, etc, is a bit more complicated. Either requires binding multiple textures or generating a small atlas per character. And at runtime, I don' thave any of the unity tools available.

    Rubber ducking...

    1. Given a particular combination of attachments, we generate a mesh. Cached by some hashable key that represents that combination. Any character with the same combination, uses the same mesh.

    2. We bind an array of textures being used by that mesh.

    3. We bind a buffer of structs of attachment metadata. These indicate which texture that attachment uses and which slot it is associated with.

    4. We bind a buffer of structs of slot metadata. This is how we get color/darkcolor/deform. This updates per frame for animation.

    5. We encode in the vertex attributes the attachment that vertex is associated with. This lets us get to the other uniforms.

    6. We bind a buffer of bone mat4's for skinning. This updates per frame for animation.

    7. We bind a buffer of weights from when we create the mesh.

    This supports dynamic attachments, since we would create a new mesh. Could be a lot of meshes?

    Ah, maybe I'm overly hung up on generating a single mesh per spine. I'll try meshes per attachments and see what that looks like perf wise. It definitely makes customization simpler.

    rr-reinhart

    I'm not using Unity. Is there source code for the atlas packer? I could pack my own atlases, I already do this for some wangtile assets in the game. But I don't see, yet, how I can square this with the uvs Spine generates at skeleton build time.

    The source code can be found here:
    EsotericSoftware/spine-runtimesblob/4.2/spine-unity/Assets/Spine/Runtime/spine-unity/Utility/AtlasUtilities.cs#L231

      I ended up modifying how I mesh things and my shader and have made a ton of progress! At this point, I don't see any barriers to fully moddable character customization. The key was to switch to separate meshes for body parts and use batching.