- Modifié
SkeletonAnimationMulti 自定义部分 slot 的材质问题
我的项目每个角色有多个骨架，我使用了SkeletonAnimationMulti，我想自定义部分插槽的材质
SkeletonAnimationMulti 运行时，会在包含SkeletonAnimationMulti组件的物体下自动生成各个骨架的 SkeletonAnimation 游戏物体，是需要自己在运行时，通过代码设置 各个子物体（SkeletonAnimation 游戏物体）的 部分 slot 的材质么？有没有更简单的方法？
使用 SkeletonAnimationMulti 示例组件时，您可以使用 CurrentSkeletonAnimation 属性访问当前活动的 SkeletonAnimation 子项，或使用 List<SkeletonAnimation> SkeletonAnimations 属性访问所有这些子项。 如果您想在所有实例或仅在活动实例中替换材料，这取决于您的用例。
When using the SkeletonAnimationMulti example component, you can either use the property CurrentSkeletonAnimation to access the currently active SkeletonAnimation child, or use the List<SkeletonAnimation> SkeletonAnimations property to access all of them. It depends on your use case if you would want to replace the material at all instances or only at the active one.
@Harald 谢谢你的回复
不好意思，我没有描述清楚我的问题。
使用 SkeletonAnimationMulti 组件时，我不能像使用普通的SkeletonAnimation一样，可以手动给所有的SkeletonAnimation游戏物体添加 SkeletonRendererCustomMaterials ，并配置相关数据（skeletonRender，插槽，材质）。
我猜要实现改变部分插槽材质的需求，得在运行时，通过代码SkeletonAnimationMulti.CurrentSkeletonAnimation获取到SkeletonAnimation后，再通过代码给它添加SkeletonRendererCustomMaterials 组件并配置数据
我的项目角色比较多（每个角色有2-4个骨架），我不太想这么做... 我希望也能像单独使用SkeletonAnimation一样进行手动设置，或者有其它不太麻烦的方法么？
我现在想到了，也许，将需要替换材质的插槽统一命名，并使要替换的材质保持一致，就会简单很多
总之，谢谢你的回复 :heart: 。如果没有更简单的方法，我将按我想到的方法试试看
如果你想手动设置每个骨架的材质覆盖，你可以避免使用 SkeletonAnimationMulti 示例组件。 您可以创建在编辑模式下创建子 SkeletonAnimation 实例的组件（或 SkeletonAnimationMulti 的子类）。 您可以在新组件的顶部添加 [ExecuteAlways] 以确保它在编辑器中被调用，然后在实例化骨架之前检查它们是否已经存在。
最简单的解决方案可能是手动创建子 SkeletonAnimation 实例，并让替换 SkeletonAnimationMulti 的组件仅在活动实例之间切换。
无论如何，拥有一个统一的命名方案是一个非常好的主意，通过代码以统一的方式应用材质覆盖是有意义的。 这取决于您的个人喜好和您的用例。
If you want to manually setup each skeleton's material overrides, you could just avoid using the SkeletonAnimationMulti example component. You could create your component (or a subclass of SkeletonAnimationMulti) that creates the child SkeletonAnimation instances in edit mode. You would add [ExecuteAlways] at the top of your new component to ensure it's called in the Editor, and then before instantiating the skeletons check if they already exist.
The simplest solution would perhaps be to just manually create the child SkeletonAnimation instances and let your component that replaces SkeletonAnimationMulti only switch between the active ones.
Anyway, having a unified naming scheme is a very good idea, applying material overrides via code in a unified way makes sense. It depends on your personal preferences and on your use-case.
@Harald Thank you for your suggestions, if there are relevant applicable scenarios in the future, I will give it a try