1
\$\begingroup\$

I am using raycast from screen point to detect if the user has clicked/touched on something.

The following fails 1/10 times; at first I thought due to the raycast missing the subject below, but after adding in the drawline i realise that it randomly doesn't even fire:

// layerMask declared with correct layers
void FixedUpdate(){
    if(Input.GetMouseButtonDown(0)){
        Debug.Log("click");
        Ray ray;
        RaycastHit hit;
        if(Physics.Raycast (ray, out hit, Mathf.Infinity, layerMask)){
            Debug.Log("You clicked on " + hit.collider.gameObject.name,hit.collider.gameObject);
        }
}

If I run this in Update() function instead, it will work perfectly - so FixedUpdate() seems to understandably cause the missed clicks... but i'm told I should always run the raycasts in FixedUpdate() for physics optimisation.

Maybe I should split this basic action over 2 functions?

A friend said i need an event handler

\$\endgroup\$
  • \$\begingroup\$ i'm told I should always run the raycasts in FixedUpdate() for physics optimisation. where'd you see that? not necessarily disagreeing, but I've never heard that \$\endgroup\$ – jhocking Feb 3 '15 at 22:36
  • \$\begingroup\$ most tutorials that I have seen regarding raycasts. consider these answers for a similar topic: forum.unity3d.com/threads/physics-raycast-misses-randomly.92221 I guess object positions get updated each physics frame, so if you were raycasting against a G.O. during render frame it might miss. Then fixedupdate runs special optimisations for it's calculations too (likely comparing layers, movement and such) \$\endgroup\$ – Hicsy Feb 3 '15 at 22:56
3
\$\begingroup\$

Imagine a static menu scene with no physics. There would be no need to use fixed updates because there is no physics involved in a menu. In this case, your raycast is an interface type interaction, not a collision-detection or force-application type interaction. Even if you were going to apply a force based on that click, you would want to schedule that for the fixed update in order to keep those concerns separated.

So yes, you could use an event handler, but the heart of the issue is separation of UI from Physics.

See also Execution Order of Event Functions - particularly the Script Lifecycle Flowchart

Edit: Aha, there's the wording I was looking for. They say specifically to use FixedUpdate "when dealing with Rigidbody." (MonoBehaviour.FixedUpdate)

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ My understanding is (in Unity) Raycasting against a gameobject's collider for detection IS a physics function though (hence the FixedUpdate()), But I think you are saying it IS recommended I split this basic click+detection over 2 functions then? \$\endgroup\$ – Hicsy Feb 3 '15 at 22:26
  • \$\begingroup\$ Yes - interaction and game logic should go in the Update method, things that depend on or affect physics (momentum, collision handling) goes in the FixedUpdate method. \$\endgroup\$ – jzx Feb 3 '15 at 23:15
  • \$\begingroup\$ IMO raycasting shouldn't be part of Physics. You can (mathematically) raycast against static geometry (like planes, triangles). Colliders are just sortof a convenience and probably more complicated than necessary for what they're used for, much of the time. \$\endgroup\$ – jzx Feb 3 '15 at 23:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.