Even with CCD on, sword collision skips overlaps - is my own collision system the only choice?

Hello everyone,

I am trying to make my game as frame independent as possible. I capped the FPS in my game to 20fps to temporarily test how it would handle collision, and it was pessimal. When the player slashes his sword, due to the velocity the sword is swung at, the collision is skipped. I thought that the purpose of CCD was to remedy that problem by sweeping in-between frames, but even with it on the collision still misses. Is my only solution to create my own collision system that manually does a rectangular (or linear for flat objects) trace in-between the last and the current frame?

Thank you.

While I can’t give an answer to that exact problem, here’s what I do in my game:

Instead of having the hitbox move with the sword, just make a big hitbox appear for 0.1 seconds which is the size of the sword slash. If your animations are somewhat simple slashes and not wildly over the top, this should work really well, reduce future problems, and allow you to adjust hitbox size easily.

That’s actually a pretty nice way of going about it. If the game were any different I would probably go with that method. My only issue is that it’s not accurate enough, and would require fine tuning for every different animation, making combos a hassle. Also if you hurt multiple entities then they wouldn’t get affected sequentially and would all get hit at the same time. Thank you so much for the reply though!

I do believe that CCD is only for physics simulation collision and not animation/code, etc (not 100% sure, but worth checking out). If do you end up at a loss with this, could work by extending the collision box of the sword to trail behind the slash somewhat. If the pivot is on the front side, you can even dynamically scale the length of the box for each attack based on the current FPS. So high FPS will be unchanged, while low FPS will extend the hitbox behind the sword, leaving a ‘trail’ box that will still catch enemies when the fps dips too low. Goodluck!

Ahh so it doesn’t work with kinematic objects then? That makes sense, I just assumed that since it sweeped it would do it regardless of physics simulation. Thanks for the advice! I’ll see what I come up with.

Ah sorry to double post, but I wanted to ask: are there any reasons for which I shouldn’t go with my own collision system? It seems relatively simple to create a component which performs traces in-between (such as smash bros, chivalry, etc.). Are there any reasons why I shouldn’t be open to this solution?


So rather than relying on physics collision during rigid body simulation, you use line traces.
(If you do use Rigid body collision, be sure to use substepping).

You can use a line trace or capsule trace on appropriate weapon points between subsequent frames of animation.

Another option is to check out Rama’s Melee Weapon Plugin - he traces shapes.

Thanks for the reply! That’s what I think I will do, I’ll go with line trace between weapon points. I also looked up Rama’s Melee Weapon Plugin; it does exactly what I need, but for learning purposes I rather try to achieve this myself.

CCD works on Kinematic Objects as of 4.14, but really you need to think about why it isn’t working. The order of operations in PhysX is important. When CCD is on, it just means that the object always ‘sweeps’ towards it’s target destination.

But - objects are processed in serial order, not parallel - so only one object moves at a time. If the sword moves towards a target but doesn’t hit it first, then the target moves and goes through the sword second then the sword won’t trigger collision. You don’t have control over the order of solving in PhysX, so this is why you typically use sub-stepping, those extra steps make a big difference.

CCD is an unfortunate naming convention which confuses people I think - it’s not a solution for always accurate collision detection.

1 Like

Thank you for the clarification! I tried enabling sub-stepping but nothing changed as far as the collision accuracy is concerned. When it comes to the sword, it has remained identical. I’m probably doing something wrong. My sword is a class which has a SkeletalMeshComponent, with *generate overlap events *and *CCD *turned on. In the mesh’s physics asset I have the physics type on its main collider set to default, with *CCD *and collision response enabled. In-game, I attach the weapon to the player’s hand socket. Then the animation plays with the slash. I’m lowering the FPS to 20, which seems like a realistic drop someone could experience. Unfortunately, the slash goes undetected at this frame rate unless I position myself in a very specific way.

I really want to use Unreal’s collision for my game, it just seems overall like a cleaner method, so any help is appreciated!

So thinking about it - I would honestly avoid using collision altogether. It’s prone to error and it’ll be very difficult to ‘tune’ it to get desirable results.

Typically when you swing the sword, you probably only want to deal damage once right? My suggestion would be to setup the code so that during the sword ‘swing’ animation, you have a timer which deals damage to whatever is in front of the player (you can fine-tune how you determine what the target is) and apply damage that way. It’ll probably feel a lot better, and you save performance doing constant collision checks on the sword (which 99% of the time isn’t touching anything).

If you’re doing VR / AR with motion controllers or something then that’s probably not an option - but IMO using actual collision for physical weapons is not always going to be reliable.

1 Like


I worked on a AAA project that used 1:1 physics collision for weapons and we ran into all sorts of problems. The two big ones being:

  • Animations tend to have large changes in velocities between frames (e.g. a sword swing) which can cause “Bullet through paper” problems for physics. Even if you bake out the changes in velocity per frame and do multiple substeps - you can still end up with this issue in the right circumstances. This is what you’re currently running into.
  • Tying physics to an animation means your animation now has a direct impact on Gameplay. So, if your melee swing doesn’t hit smaller enemies (rats for example), you now have to re-do the animation. This also means when adding new attack animations you have to verify it works on EVERY enemy, in all their different poses, before you can say it’s truly done.

In the end, we just used the 1:1 physics for visual effects (sparks, blood splatters, etc) and did a simple Sphere/Cone AOE in front for damage - which made things much more reliable and just felt better.


I believe ‘Rama’ has a Melee tutorial which might offer useful insights as well iirc.
Separating ‘visuals’ from ‘programmatic detection’ sounds familiar as a solution.

I can’t believe I didn’t think of that! That actually sounds very interesting; the performance gain part is enticing, and the smaller enemies issue is definitely something that could be annoying. I’ll give it a shot.

Also, I’m not creating a VR game, but that leads me to wonder (if anyone feels like answering), how would someone create a reliable sword collision system for VR? I don’t have any experience in VR but I find the concept interesting. Would you just use fixed frame rate?

Using physics engine for things like this is like relying on collision to make a match3/tetris game.

  • don’t do it *

On old platforms, physics simulation other than blocking character movement was prohibitive; still devs managed to do plenty of sword attacks/damage detection.
Just using raw cone trigonometry and distance measurement they got it done; MMOs still won’t use physics for this and results on today’s titles are still as effective.

Newest Tekken and Street Fighter games are made on UE4 and they rely on AnimNotify events combined to basic trigonometry without any dependency on any physics engine to compute their attack/damage detections.

For game development sometimes just a little bit of ‘ancient math’ is the right way to go instead of relying on complex systems to solve every single problem =]