Thoughts on implementing precise, framerate-safe melee weapon collisions

Just thinking out loud here. Writing up my thought process often helps me figure things out. At worst, this might be useful for someone

I've been thinking about how to implement melee weapon collisions, and I was wondering if you guys had a better or less costly idea.

For reference, let's suppose we have to implement melee weapon collisions for Dark Souls. That means:

• Hit detection can't just be instantaneous for the entire weapon swing area. It has to follow the animation frame-by frame
• We need to make sure this is as framerate-independant as possible (must not be possible to miss a hit because the framerate dropped a little and the weapon went from one side of the enemy to the other in a single frame)
• Hits must have direction information (to inform the hit entity which way it has to react to the hit)
• Different parts of the weapon can have different attack properties (hitting with the blade of an axe deals lots of damage, but hitting with the wooden handle deals only a little)

So here's the solution I came up with:

This is an example for a warhammer, because it pretty much has every particularity that the system has to handle. The strategy here would be to place sphere colliders all over the weapon, and each frame make them SphereCast from their previous position to their current one, on top of checking for OverlapSphere at their current position. This way, it would be impossible to miss a target, unless the framerate is so low that the animation literally doesn't have time to play. But in that case, we can manually sample animation poses through code and do our intermediate spherecasts using that information. Plus, the hammer part and the handle parts could each be assigned their own separate damage.

The only problem I see with this is that it seems to be awfully costly, especially if you imagine an extremely long greatsword weapon;


Handling the collisions for this weapon would require 9 SphereCasts + 9 OverlapSpheres per frame per weapon. Seems like it might become problematic. And you can't handle this gracefully through CapsuleCast or BoxCast, because rotation wouldn't be supported.

Does anyone have better ideas?

 

Actually..... I just thought of something. It should be always possible to calculate the swept area of a box collider from one pos/rot to another, in 3 steps:


We'd go from 9 SphereCasts + 9 OverlapSpheres per frame per weapon to 3 BoxCasts + 1 OverlapBox per frame per weapon. This is starting to look much more reasonnable. As an added bonus, it even rounds out the movement between the two frames a little!

But this approach seems to fall apart as soon as there's a position offset on top of the rotation. Doesn't really work anymore:


Unfortunately, I think the spheres method is still a better strategy

 

ahh... but wait!

I think it's safe to assume that the vast majority of the time, the framerate will be high enough that the distance traveled by each sphere between two frames will be less than its diameter. In that case, no sphereCast would be necessary, because the spheres overlap in both positions. That means we only have to spherecast if we detect that the movement was greater than the diameter of the sphere, which will not happen too often. Like this;


This should save us a bunch of SphereCasts each frame. This might cause tiny gaps of undetected damage between red spheres, but I could live with that. It's probably worth the optimization

 

very informative post.
do you have any more updates to share? can't wait to learn more