Yimec

  • il y a 16 jours
  • Inscrit 30 août 2023

    @Yimec You likely need to set much larger values like Offset -100, 0, chatGPT likely suggested -1 as this counters z-fighting, but you don't have your objects on the same depth plane fighting.

    In general however, it's likely a better idea to think about your scene setup, what do you want in the first place. You are creating two quads at a 30 degree angle to one another and don't like that they are intersecting. Now you can solve this in various ways, but you need to understand what you're doing. Think about the desired sorting and desired depth writing and interaction. If you don't know what you are doing and are just adding shader statements that chatGPT suggests to you, you will sooner or later run into problems as your scene starts to fall apart.

    BTW: I just remembered this related forum thread on an isometric game as well, perhaps it's of some help to you:
    https://esotericsoftware.com/forum/d/25182-render-spine-in-3d-world

    @Yimec Theoretically you could also adjust (a copy of) the used shaders and add a z-bias to offset the mesh slightly. Likely this introduces undesired intersections with other parts however.

    I'm not quite sure I understand your exact setup (camera, skeleton and Unity sprite angles) and what is actually intersecting, could you please show a screenshot which shows you issue, best including both Scene view and Game View?

    @Yimec We've just released a bugfix for this issue.
    Details: The URP version define IS_URP_14_OR_NEWER should now again be recognized and set correctly after Unity has changed a define on their end.

    A new Spine URP Shaders UPM 4.2 package is available for download:
    https://esotericsoftware.com/spine-unity-download
    Please let us know if this resolves the issue on your end as well. Thanks again for reporting!

    Issue ticket URL for later reference:
    EsotericSoftware/spine-runtimes2878

    @Yimec Unfortunately I could neither reproduce your observed behaviour with Unity 6000.1.5f1 nor with the latest 6000.1.9f1, everything compiled without issues on our end. Thus I assume it's related to your project and render settings, affecting the defines used while compiling the shaders.

    Could you please send us a minimal Unity project which still shows this issue? You can send it as a zip file to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we should be able to reproduce the issue on our end more easily as well.

    • Modifié

    @Yimec You could separate (split) your slots for each customizable color: you would then duplicate each multi-colored attachment into a red part and have transparent areas where it should not be colored (the white part), then have the same attachment with the white part and red parts transparent, and so on for each color. You would need to make sure the pair of attachments is always active at the same time, and deformed in the same way (e.g. use Linked Meshes).

    Another solution where you don't have to duplicate slots and attachments would be to write a custom shader (or Shader Graph) where you first author mask textures for each color (or a single mask texture use RGB channels, R for color1, G for color 2, B for color 3, and A for something else) and then multiply (or otherwise tint) the masked areas of your atlas texture.

    Note that you could create the mask images on the attachment level (one mask image per normal attachment) instead of drawing masks based on the exported atlas. Otherwise you would need to re-do the mask when the exported atlas layout is changed.

    When authoring masks on the attachment level, you would via a script run the Spine CLI texture packer to pack the attachments programmatically the same as your normal attachments. Just make sure to have the same transparent areas (whitespace), or disable whitespace stripping to not end up with a different atlas layout.

  • @Yimec I see two main ways to solve this.

    • a) Not really use Spine's new physics constraints but instead use the existing SkeletonUtilityBone Create Hinge Chain 2D functionality:
      https://esotericsoftware.com/spine-unity-utility-components#2D-and-3D-Hinge-Chains-for-Physics
    • b) You could change the setup in Spine so that you can move and rotate the piñata around and have the rope follow, instead of the other way round, plus limit the distance of the piñata bone to the ceiling-anchor (via constraints or in game-code). Then you can use a hierarchy of SkeletonUtilityBones with the piñata bone GameObject set to Mode Override and having a Collider2D and a Rigidbody2D attached.
    • Modifié

    @Yimec We have now also pushed an improved bugfix to the 4.2 branch via this commit. This should now provide proper handling of disabling updates when all SkeletonPartsRenderers are invisible and re-enable updates when at least one SkeletonPartsRenderer is visible.

    If you want to use this commit in your 4.1 project, you would need to manually integrate the commit's changes.

    • @Yimec We have just pushed a safe bugfix on both the 4.1 and 4.2 branches. Now whenever a SkeletonRenderSeparator is active, the SkeletonRenderer counts as visible and no longer disables the updates upon seemingly becoming invisible. This should fix your issue, however no longer provides the benefits of disabling updates when truly invisible and off-screen.

      We are working on an improved bugfix as well which tracks visibility of each SkeletonPartsRenderer. This fix however will be released on the 4.2 branch only due to the necessary changes.

      New 4.1 and 4.2 spine-unity unitypackages are available for download here as usual:
      https://esotericsoftware.com/spine-unity-download
      Please let us know whether this fixes the issues on your end as well. Thanks again for reporting!

      Issue ticket for later reference:
      EsotericSoftware/spine-runtimes2519

    • @Yimec No worries, just mentioning for the future so it saves us some time. I'll write here on the forum once we have a bugfix ready.

    • @Yimec Thanks for sending the reproduction package.

      In general please send the Unity projects as zip packages as requested (without unnecessary dirs like e.g. the library dir) and not as unitypackage, since this involves more steps for us to have a clean separate reproduction project.

      We'll get back to you here on the forum once we've figured out what's going wrong.

      • @Yimec Thanks for the update, IIRC version 2023-08-14 is recent enough so you're not missing any bugfixes regarding this topic.

        Also, checked the problem and why it was happening only to a few objects and found out the issue appears with separator enabled objects. Does this mean something to you?

        This sounds interesting, it might likely be that the SkeletonRenderer no longer receives OnBecameVisible events since the MeshRenderer at the same GameObject is then disabled. Still it would be much appreciated if you could send us a minimal Unity project, as it might be depending on the order and timing of activating the SkeletonRenderSeparator and similar events.

      • @Yimec Which exact version of the spine-unity runtime are you using?

        • @Yimec glad to hear, thanks for getting back to us!

        • @Yimec Hm, this is strange indeed. Anyway, glad to hear you've resolved the issue!

          In case this issue occurs again in the future and you know how to reproduce it, please don't hesitate to send us a minimal reproduction Unity project, as we hope it's an issue that can be fixed on our end.

          • @Yimec Sorry, just noticed you already answered, I was late to post. Glad to hear you've figured it out, thanks very much for your kind words! 🙂

          • @Yimec glad to hear you've figured it out! Yes, SkeletonAnimation can be used as any normal GameObject in regards to manipulating its Transform values. SkeletonAnimation just fills its MeshRenderer every frame with the updated mesh and materials.

          • @Yimec Thanks for sending the code. I can see nothing obviously wrong with the above code. As mentioned before, trackShaq.MixBlend = MixBlend.Add; should not be set if you also don't set it to additive in the Spine Editor Preview.

            Could you perhaps send us a minimal Unity project that still shows your issue? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum URL so that we know the context. Then we can have a look at what's going wrong.

          • @Yimec Thanks for the additional info! Judging from the Spine Editor preview settings, you are not using MixBlend Additive on the second track (the shake track), so you don't need to set it on the Unity side either.

            Could you please share the code you use to set the animation in Unity?

          • Yimec When I preview the animation in the preview window in spine everything works just fine

            @Yimec How did you preview the animation on the second track in the Spine Editor? Did you set the animation on the second track to Additive via this button:
            https://esotericsoftware.com/spine-preview#Additive
            Or do you want to just play the animation normally on the second track, overriding keys on lower tracks?

            If you want to apply animation additively, you need to set the TrackEntry MixBlend mode to MixBlend.Add.
            trackEntry.MixBlend = Spine.MixBlend.Add

            Yimec is in Unity where the problem occurs.

            What is "the problem", what kind of problem does occur? Please always describe what result you expect to see and what you see instead. Otherwise we have to guess.

            If you see rotations adding up with additive animation every frame and rotating more and more, you have not keyed the same property (e.g. the same bone's rotation value) on the base track (the idle animation on track 0). That then leaves the previous frame value and adds to that, in an ever increasing way.

            If it previews fine in the Spine Editor, it might be due to the skeleton being set to the setup pose before applying the preview animations, which is not what you typically do every frame in Unity.