Search Unity

Question Cinemachine 3rd Person Aim Extension - Crosshair Not Correct?

Discussion in 'Cinemachine' started by ozzyonfire, Sep 18, 2021.

  1. ozzyonfire

    ozzyonfire

    Joined:
    Dec 18, 2012
    Posts:
    6
    Maybe I'm misinterpreting exactly what this extension is supposed to do... So I apologize if this is wrong.

    I thought this extension was supposed to take the Follow transform of the Cinemachine and basically project a ray to see what it would hit, then move a target reticle to that position on screen.

    However it only seems to do this in very specific scenarios, also the accuracy of the crosshair seems to strongly depend on the Shoulder Offset and Vertical Arm Length of the rig. I was thinking we could set up our camera however we like (aesthetically) and then the crosshair would be exactly where it needs to be on-screen.

    If I cast a ray from the Follow target and see where it ends up on screen, it's usually very different. You can see this in the AimingRig sample scene.



    It looks like the camera is aiming exactly at the crosshair for long distance casts, but when something is close to the player the raycast is way off.

    Except when the Extension takes over and you can see the red dot is exactly where the Raycast hit is!

    So my question is this by design? Why does the Extension move the crosshair in some scenarios but not all (even when there is something in the way).

    I've also tried this in the other Cinemachine Project (Third Person Camera Demo) and the result is the same.
     
  2. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,730
    A crosshair is projected from the camera position in the direction of the follow target's forward. The intent is that when the player fires, you would force the direction so that the camera's indicated target gets hit. The hit target is relocated only in the case where there is an obstruction preventing a line of sight from the player to the camera's hit target.

    The logic is this way because it creates a more stable camera: the camera is the true controller of the aim, and the player follows that whenever possible. If we used the player's true forward, then the aim would be less stable for the human controlling the camera.
     
  3. ozzyonfire

    ozzyonfire

    Joined:
    Dec 18, 2012
    Posts:
    6
    Okay this makes way more sense! Thanks for clarifying!!
     
    Gregoryl likes this.
  4. ozzyonfire

    ozzyonfire

    Joined:
    Dec 18, 2012
    Posts:
    6
    So I've been thinking about this for a bit and something is still strange to me.

    If the camera is the true point of reference for aiming, then how do we show a projectile (like the arrow) coming from the player?

    In the Cinemachine Third Person Camera Demo, this problem shows itself. The arrow originates from the Fire Point transform, which is not the position of the camera... so if there is something in the way, the aiming reticle would appear off.

    Here is another video I made demonstrating this.



    The white line is a line from the Follow Target position, the Blue line is from the Fire Point position. You can see that the arrow appears to not go where the reticle is pointing, except when the Aiming Extension takes over and moves the reticle to the closer point.

    I guess it may be better for the Cinemachine Aiming Extension to take a custom "Fire Point" transform and do the raycasting from that point every frame, and then update the reticle based on what it has hit, rather than using the camera transform?

    I'd like to use the camera transform for the origin of projectile, but if we're instantiating game objects, this would look very strange as arrows would appear (in some cases) way above the character model.

    Thanks for you help on explaining this.
     
  5. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,730
    You should use the gun as the origin of the projectile, not the camera. As the destination, use vcam.State.ReferenceLookAt - this is the actual hit point as calculated by the vcam. It seems that the tutorial didn't do that. It was a mistake.
     
  6. ozzyonfire

    ozzyonfire

    Joined:
    Dec 18, 2012
    Posts:
    6
    Great! yes this seems to be the piece that I was missing.

    I actually was working on my own version of the same thing. I just modified my code to use the ReferenceLookAt. Still things don't look right...

    This is what I have going on, let me know if this is the proper thought process.

    I have a reference to the "barrel of the gun" called projectileOrigin. So all I am doing is basically using the ReferenceLookAt position to create a direction of where to shoot the projectile.

    Everything looks great, until the crosshair takeover happens. It seems like it updated the position of the crosshair, but doesn't change the Camera's ReferenceLookAt position, so it still points off past the updated position.

    Here is a code snippet:

    Code (CSharp):
    1. Transform aimReference = projectileOrigin.transform;
    2.     LayerMask layerMask = CameraManager.Instance.collisionMask;
    3.  
    4.     Cinemachine.CinemachineVirtualCamera activeCam = (Cinemachine.CinemachineVirtualCamera)brain.ActiveVirtualCamera;
    5.  
    6.     Vector3 aimPosition = activeCam.State.ReferenceLookAt;  // CameraManager.Instance.crosshairTarget;
    7.  
    8.     ray.origin = aimReference.position;
    9.     ray.direction = aimPosition - aimReference.position;
    10.  
    11.     if (Physics.Raycast(ray, out hit, Mathf.Infinity, layerMask))
    12.     {
    13.       Debug.Log(hit.collider.gameObject.name);
    14.       Debug.DrawLine(ray.origin, hit.point, Color.white, 1f);
    15.     }
    And here is what it looks like:
     
    gaborkb likes this.
  7. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,730
    Your thought process is correct. I think the ThirdPersonAim code is wrong. It should update the target position but doesn't. I will log a bug for this. The fix should be in the next version of CM. Thanks for digging into this!
     
    gaborkb likes this.