Hi Nate,

Yeah I agree, Box Collider approximation would be horrible, which is why I was thinking the user could just create them manually if they really need performance increases. Optimal Convex Decomposition is definitely do-able, but just a little overkill for the application perhaps. I'm trying to wrap my head around it anyway. http://mnbayazit.com/406/files/OptimalC ... azelle.pdf

The collider attachment idea is a good one, it's sort of what I was trying to achieve. The current implementation of Bounding Boxes that I sent you do attach to child GameObjects representing Bones and transform along with the animation. The individual colliders are also switched on and off at runtime as stipulated within the animations to represent attach/detach. However you're right that it could be easier to build in Unity, and I am coding in an option to allow the Bounding Box to be built as a mesh collider as per above and then have the user go in and 'trace/build' over it with Box, Sphere and Capsule primitive colliders, which will then be used instead of the mesh collider at runtime. In fact we can even allow the user to toggle between the two if they have built the primitive version, based on what hardware they are running on. UnityBoundingBox.cs could easily be renamed to and house all of the functionality required by ColliderAttachment.cs.

At the moment when you want to change Bounding Boxes during an animation, given that both are present, one is simply switched off (but not destroyed) and the pother switched on. If the second one is not present it is created then switched on. Afterwards it is persisted, so that next time it needs only to be switched on.

I will be looking into the triangulation stuff that you sent me, I have to admit that I am still trying to wrap my head around it, and also I would love to investigate a surefire solution to Concave triangulation. Given that the meshes/Bounding Boxes people are likely to generate going to have a low number of vertices, I imagine that you triangulation won't mess up though. Also given this expected low number of vertices, an exhaustive search to optimally triangulate may be okay too. I'm not sure though.

Also, at the moment it is worth mentioning that bounding boxes are matched on name only, so unique names are required for bounding boxes. Also, if Bounding Boxes are not found upon skeleton initialisation their geometry will have to be created at runtime when they are encountered. I would therefore like to include an option to quickly step through all of the animations and determine all Bounding Boxes that will be present as well as their default size and orientation. At the moment I use bone.WorldScaleX and so on to do my initialisation and mesh vertice creation. Is there a way to iterate through like I want to find the colliders and have their calculate their correct scales, rotations etc. Or will I have to somehow grab the information from the .json file and work out the relative unity sizes, rotations, etc associated with the instance of the skeleton within Unity myself?

Many thanks,

Rob

Yeah that sounds great Nate. I had thought about doing a generic implementation of creating child GameObjects for different bones, allowing the user to attach various bits and pieces to them, and you mentioning attaching particle emitters and so on makes it sound like it could be quite useful.

Regarding the bone.WorldScaleX thing, sorry for my poor explanation. At the moment what I do is create a child GameObject and place it at a location equivalent to the Bounding Boxes parent Bone. I do this by setting its transform.localPosition to the Bone WorldX/Y, it's transform.localRotation is set to Bone WorldRotation and scale equivelantly too. I am able to do this because they (WorldX/Y) are relative to the root GameObject, which is the direct parent of this child GameObject.

I then create the mesh from the supplied polygon, however I create it relative to the Bone GameObject I just created rather than the root GameObject, something like this when grabbing the vertices...

vertices.Add(new Vector2(polygon.Vertices[i] - parentBone.WorldX, polygon.Vertices[i + 1] - parentBone.WorldY));

Above, you can see that I offset against the Bounding Box's bone's position. Given the above setup, I then only have to update the position/rotation/scale of the child GameObject each frame to reflect the Bounding Box's bone's position/rotation/scale. The Mesh representing the Bounding Box is inherently transformed by doing so. Therefore, I avoid having to update the mesh collider's vertices each frame to match the Bounding Box polygon. It seemed like a good solution at the time as I thought it would have less overhead. But the issue is that if a Bounding Box is not present on initialisation (switched off) then the mesh geometry will not be created. When it then needs to be switched on for the first time in an animation, the mesh geometry will need to be caculated at runtime. I just wanted a way to iterate through all potential Bounding Boxes, even those switched off at the start, so I can create them. However, I figured looking in the .json file for them might not be sufficient for setup given that I also need the WorldX/Y and so on calculations for the initial position, rotation and scale of the parent Bone.

Hmmmm... I hope you can make sense of the above, because reading it back, it does sound a little convoluted. Also if you think the above method is stupid then I can move to updating vertices each frame (which is simply copying your polygon vertices each frame).

Again many thanks for your time Nate

Rob

Aha, of course the bounding box vertices do not change, my mistake. I think with my current implementation though, there is not even a need to calculate the polygon each frame, instead we just update the Bone GameObject transform to match that of the bone. I looked at the 'one giant mesh' approach, but put it aside as it doesn't allow the user to tell which bounding box actually did the collision, which the current method does. I also don't think moving GameObjects has too much overhead, but without trying both and benchmarking I cannot be sure.

Thanks for the SkeletonData skin tip, I will look into that The reason I wanted this is in case people wanted to have all Bounding Boxes, even infrequently used ones, available in the editor. Then they could attach collision scripts to them, other scripts or components, fiddle with them (e.g. approximate with box/sphere/capsule colliders) and so on before running the game. The, when they are encountered in the game, even if for only one frame in one animation, everything is setup for them to work as the user wants. Was just an idea though, I know I would find it useful.

Thanks for all your help, advice and tips so far Nate, I really appreciate you taking the time

Rob

Unity is a massive pain. It does not allow attaching multiple colliders to a single GameObject, which is why I went for the 'attaching individual ones as children' method. I agree that it may seem a bit fragile attaching scripts to the GameObjects that are created for the Bounding Boxes, but I thought it would be alright since they aren't going anywhere. That is, once they are created, they aren't removed unless done so by the user. It's also another reason why I wanted to iterate through all Bounding Boxes. I figured if I found one not being references anymore, then it would be disabled (but not removed) and a warning would be logged informing the user that this Bounding Box is now redundant. Then they could decide what to do with it and when. If they were to re-implement it in their animation at some point, and they had left it there doing nothing, then it would simply be re-enabled and mesh geometry updated to new geometry. All their initial scripts and so on would still be intact and ready to roll. This is why I figured it would be okay, but I will look into callbacks/delegates as a way of implementing collision functionality instead. I guess I just personally wanted the ability to store scripts on the GameObjects, but others may not want this. Also, at the moment the implementation would obviously not support FFD Bounding Boxes, so I'm guessing I will also need to provide an implementation with the updating mesh vertices every frame based on polygons calculated in order to support this feature when it is implemented.

Cheers Nate, I wish Unity wasn't such a pain in the ass but that's kinda why I figured I would help at tackling it, I seem to have run into quite a few of its annoying flaws by this point

Just in case anyone is re-directed here for Bounding Box physics integration please find attached the state of my experimentation so far. It is highly untested and I haven't been able to work on it in ages but because of recent interest in physics integration I figured I would post for others.

I had to modify the following files:

// Modified to include Bounding Box support
SkeletonComponent.cs

// Added store/retrieval of Bounding Box Attachment Bone which I needed
// Pretty much a one line code addition in each
SkeletonBounds.cs
BoundingBoxAttachment.cs

Then the rest of the new files are in the root of the project. in the existing runtime files i modified i'm pretty sure i managed to mark everything I slotted in there with an /** Added **/ comment. Searching for that should bring up all modifications/additions. I also used the triangulator from the Unity forum.

Adding/toggling the SkeletonCollisions.cs script on the root gameObject (the one with SkeletonAnimation) should enable/disable collisions. Automatic Rigidbody params just sets the Rigidbody to kinematic and the constraints to 2D. The rest is as in the above posts, so boxes should update/disable/enable as required by animations. Currently only works with 3D physics engine, will create concave colliders which will not collide with other concave colliders (need to work on convex decompositions or some other solution).

Will continue to work on this soon, as my project is starting to need robust Spine && Unity physics integration. Can't wait to get these two playing together nicely.

Kind regards to all,

Rob