• Unity
  • Bounding box problem

Heyo

I've got a little problem with the bounding boxes. I created the bounding boxes in Spine. The first time i did this, it worked very well in unity (the bounding boxes was correct). After renaming the animations in Spine, and some further work on the animations, not all bounding boxes in Unity are correctly (some are correct). As you can see in the attachment, the lines aren't right and its a big tangle.

Someone other had this problem? Please help me, because i really need this bounding boxes working right.

Related Discussions
...
  • Modifié

Avoid using weighted bounding boxes if you plan to use their shapes as Unity colliders.
Unity physics doesn't support colliders that warp. I don't know any game physics engines that do.

We've added the appropriate warnings in the editor and notes on git to reflect this.

The 3.5 runtime will convert them into PolygonCollider2D correctly but they won't deform.

Thanks for your reply.

Well so I have to work on a workaround. Its a little bit crazy that it worked before an now no more. I had spawned the whole bounding boxes of the character and they were right. With the same Spine animation (just other names).

Edit: I tested again, some of the bounding boxes can be swapned correctly, but not all. The ones which are correct, transforms (deformation) also correctly. You said thats impossible but it worked. Is there a workearound? I have a complex character, which should be good balanced for collision. (jump, slide animations). I can't use a box or circle collider :/

PS: Is 3.5 runtime already released?

3.5 is currently in beta. We're hoping to finish the release version in a few days. Wish us luck!

I tested the same with the beta 3.5 runtime. Same problem, the colliders doesn't spawing correct.

4 jours plus tard

Can you send us your Spine export so we can check? unity@esotericsoftware.com


13 Nov 2016 3:00 am


I just tried it in the 3.5 runtime and the colliders work correctly. It also warns you correctly.
Note that if you use the 3.5 runtime, you also need to export from 3.5 and use in the 3.5 runtime.

I tried your export in 3.4 and the non-weighted bounding boxes work fine. The weighted ones do indeed break. And as I've described, that's because they are weighted. They will not work in any case. Nothing in the code updates collider shapes according to weighted/animated vertices.

Why are your bounding boxes in the same slot as the image? Doesn't it make more sense to give them their own slot?
In any case, BoundingBoxFollower functions best when the boundingboxes are in their own slot and not with the image, because all it does is enable PolygonCollider2D according to the currently active attachment.

Thanks for the check. So I have to recheck with the correct versions, maybe i made a mistake. And we changed the slots also, thanks for this information too.

But there is still one question: Why are weighting available, when it can't be used in Unity or other engines? What's the purpose to have this in Spine?

Weights for Spine BoundingBoxes work. They just can't be used for PHYSICS engines.

You can use the SkeletonBounds class to do point and shape intersection checks. For example, if you need to be able to click/tap on something that deforms.

Allright, thanks for the clarification.

Im trying now with 3.5 beta (runtime and spine), but in Unity when i click on the Bounding Boxes button, it doesn't happen anything. Is this a bug in Unity? Or did you saw this problem also anytime?

Edit:

I saw that in

SkeletonUtility.cs

the following line (45) maybe has a Problem?

skinName = string.IsNullOrEmpty(skinName) ? skinName : skeleton.Data.DefaultSkin.Name;

If the skinName is empty it should take the default and not when the skinName is set?

I switched this but, I saw that i don't get an attachment. Is there anything to setup on Spine, that the bounding boxes are valide for the skin?

Ah, thanks for reporting. That is indeed backwards.

I'm not sure what you mean by "Bounding Boxes" button. Where is that?

Image for "button" attached.

Ah. Confirmed. It's almost fixed but I need to test it with a few more cases.


19 Nov 2016 9:27 am


Fixed. It's in git and the latest unitypackage.