I’ve been poking around this topic for a bit to see how viable this idea was but I was wondering if there was a way you could have two raycasts collide with each other and code reacting based on whether they hit the whole raycast rather than the hit.point. Is this possible? It seems obvious to me but I wasn’t sure, my idea is that I have a raycast running along the edge of the sword while it runs a swinging animation and then seeing if it hits a sword with a raycast along it if that makes sense.
I suppose I could replicate the effect with very thin colliders but I feel like maybe raycasts would potentially be a bit more accurate, might need to experiment.
There’s many line segment to line segment functions out there you can try, especially on github in C#.
Please note you’ll need to do things like run these functions at a much higher step than the rest of the code or be inventive with dot product + time in order to determine if two line segments have a collision by their distance and if they passed each other. How involved you want the detection to be will vary from game to game.
Thin colliders will pretty much never work accurately. Colliders and raycasting should be providing extra data where necessary.
If you’re looking for robust collision that doesn’t require as much math you can also do something like control the swing animation time instead of just playing it. This means you feed in the precise timestamp (usually 0 to 1) into the animator properties to play back that state manually.
So you could do movement of the animation + collision testing at a far higher framerate, however this could be expensive (or not) depending on your game.
The problem with thin colliders is that the animation is in realtime, so depending on framerate, or even speed of the animation, you would miss a lot even with continuous collision on as it is teleporting, which is why passing in the exact frame (time) of the animation in a loop and testing is immune to that problem.
I’ve done that myself in the past though I tend to lean more on maths these days.
Another way you can do it is how they did it in Chivalry, but improved. What you do is instead of casting forward, you cast multiple rays along the sword length, facing the direction the sword came from.
So the detection occurs when the swords are past each other but the positions are corrected before it is rendered. You could also use a sweep test instead of multiple raycasts, YMMV.
That’s a good idea, I’m wondering how efficient it would be though to have multiple raycasts like that, at the same time, it might also be the best option potentially in terms of keeping it simple. I’m not looking to do anything too fancy, whatever I would do is I would probably have the collisions happening along the sword point and the edge of the blade as that’s how it would be in real life for the most part.
Okay wow, the box collider method is working a lot better than I expected, I’m not looking for something obsessively accurate believe it or not so I’ll experiment with this, if I do want to go that route though I’ll keep the methods you suggested in mind @hippocoder thanks. For those curious what I’ve done is I’ve simply set a box collider on the edges and point of the blade with a rigidbody and froze everything, then turned off the gravity for the rigidbody, set it to continuous, the animation deals with all the movement and now I’m able to poke cubes with my sword.