I'm curious how I should go about structuring hitboxes and hurtboxes for my actors. For context, I'm developing a game engine in OpenGL, using C# and OpenTK. I have developed a working skeletal animation system, which loads animations using Assimp, and then passes BoneIDs, BoneWeights, and Transform matrices to the Vertex shader, which calculates all vertex deforms appropriately for the current animation keyframe (or current interpolation between keyframes).

Is there a set standard for calculating collision in animations? I'd prefer to continue using Assimp, which means using standard, recognizable animation formats that my engine can load in, so I'd rather not store any collision data in the animation files, unless there is a precedent for this or room for metadata or something.

My current thoughts: One option would be to calculate the hitboxes and hurtboxes upon loading an animation, and have a mapping that determines which meshes are hitboxes and which are hurtboxes. The second option would be to create a new file format where I store my hitboxes and hurtboxes in a way that is similar to animation files (minus bone weights, since I'll just be transforming the scale/position of axis-aligned rectangles), where I can determine keyframes for hitboxes and hurtboxes, then interpolate based off of these to get the current collision box for each frame. I could combine the two options by automatically generating these files from the animations, then editing them manually until they are reasonable.

Am I on the right track, or are there smarter ways of going about this? I don't want to reinvent the wheel if there are better options available.


1 Answer 1


Is there a set standard for calculating collision in animations?

No, not really. It largely ends up depending on what you want out of the system.

I'd generally suggest you store the bounding information in the mesh, not the animation, and just weight the bounding primitives similarly to the way you weight the bones. This means the animation can be reused on similar characters of different girth (thicker arms, for example) more easily.

If you just want reasonably accurate, tight-fitting oriented boxes/capsules/rectangles around the actual limbs and body of the character, it's probably reasonable to compute those boxes by processing the bounds of all vertices affected by a given bone ID (that is, all the vertices weighted to the forearm bone are used to compute the bounding capsule of the forearm in the mesh).

However, it may ultimately be easier to just author the collision capsules directly into the mesh, tagged so you can process them appropriately during export/import. Authoring capsules in modelling tools is pretty easy, and this gives you the flexibility of making some special capsules that fit more loosely for special attacks, or the like.

Animations can include metadata for enabling or disabling particular collision capsules (or perhaps just specific collision responses) during the animation, if needed. You may need to export that as a sidecar file.

Basically, you're on a reasonable track. Both of your options are viable, although what I would prefer is probably closer to the second choice. And even if you do the first option you listed I'd recommend trying to do that computation when you export rather than when you load into the game, since it won't change between then and you'll save your users a bit of load time.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .