Unity Physics frame rate. void FixedUpdate

I have a problem with Physics frame rate.
Sometimes spheres don’t detect collision, sometimes they do.
Its not just little things, its a big problem, I’m trying to use vr controllers and my sword just goes through the collision, if I swing bit fast.

I don’t know how to put the codes and scripts that don’t even use void Update into void FixedUpdate

I really need an advice here or maybe try and put this script, into FixedUpdate, so I can repeat it on other scripts.{

public Transform brokenObject;
	public float magnitudeCol, radius, power, upwards;

	void OnCollisionEnter(Collision collision)
		if(collision.relativeVelocity.magnitude > magnitudeCol)
			Destroy (gameObject);
			Instantiate(brokenObject, transform.position, transform.rotation);
			brokenObject.localScale = transform.localScale;
			Vector3 explosionPos = transform.position;
			Collider[] colliders = Physics.OverlapSphere (explosionPos, radius);

			foreach (Collider hit in colliders)
				if (hit.GetComponent<Rigidbody>())
					hit.GetComponent<Rigidbody>().AddExplosionForce(power*collision.relativeVelocity.magnitude, explosionPos, radius,upwards);

Thank you.

So, if you want to discuss options for improving collision detection for fast-moving objects, we can get into that.

Before we get creative, you can try changing the sword’s rigidbody interpolation mode. Here’s a fairly through explanation of each mode - just try each one and see if a different mode will solve the issue. (Fairly unlikely, but it’s worth a try.)

Assuming there’s still a problem, we’ve got several options. What I recommend is basically the same solution described for bullets in my comment above: Using linecasts to “fill in the gap” created by moving the object too far in a given frame. It’s more complicated because it’s a sword, but it shouldn’t be too bad.

Note: What I am proposing is the least-sophisticated way to implement this idea. If you wanted to get fancy, you could make the sword’s traversal in a given frame into a proper arc by using multiple sets of linecasts. Only do this if you really need the extra fidelity, because it will quickly become harder to manage / understand.

So, what we want to do is address the gap created by moving the object too quickly. By drawing linecasts between the sword’s old position (last frame) and new position (current frame) we can see whether those lines intersect an object.

You’ll probably want to do this for several points along the length of the sword. You can achieve this with pure math if you feel comfortable doing so, but it may be easier to understand if you use some dummy objects.

Create some empty game objects along the blade of the sword. One at the hilt, one at the tip, and three or four in between. Expose and populate a collection of these objects in your script:

public Transform[] blade_helpers;

We also want a record of their previous position. Let’s use a collection that is the same size as the one above, where each entry corresponds to one of the objects:

private Vector3[] blade_history = new Vector3[ blade_helpers.Length ];

In FixedUpdate(), create a linecast between each helper object’s old position and its new position. After performing these linecasts, update the history to reflect the current position of each helper object.

Note that you’ll get weird behavior unless you populate the history with the current positions in the first frame, but that’s easy to fix. Let’s move on instead:

If any of your linecasts hit something, you’ll know you’ve hit something with your sword. You’ll need to adapt your current logic which responds to collisions to also respond in a similar way to these linecast results.

We can get into that too if need be. Let me know if this requires more explanation.

Note: What we’re doing here is creating a kind of simple “trajectory” test along the length of the blade. We’ll get information about the tip and hilt and all points in between separately. Another method, perhaps just as good, would involve using linecasts that represent the sword blade itself. You’d create a “fan” of linecasts to fill in the gap, whereas what I’m suggesting is more like a “trail”. Either way, the idea is to fill in the gap created by fast motion.


So, I guess the sword is a rigidbody. Just set it’s collision detection to continuous or continuous dynamic and you should be good to go.

It is never a good idea to do this but for one object it should not hurt the performance at all.

Once you’ve tested different collision modes (as @TheDiamondPlay suggested), you can do the following to debug.

To make sure you are never moving anything in an update, go to Project Settings > Time and change Fixed Timestep to something ridiculously big like 1 or 2. If you are affecting position from somewhere other than FixedUpdate, the object will “jitter” or teleport itself. If everything is smooth than you are fine.

You can try lowering the Fixed Timestep to 0.016 (60 Hz), though that will consume more CPU.