Forum rules - please read before posting.

Destination Accuracy

Hi there,

A lot has been talked about the woes of destination accuracy but I’m still not sure how to address the problem. I have a 3D point and click setup with Fuse-generated characters and I have "Apply Root Motion" enabled on the character’s Animator. My problem is that the player character does not behave nicely when I click on a hotspot and he has to walk to the marker assigned to it. If I set the destination accuracy to 0.7, he more-or-less reaches close enough and stops but it’s not accurate enough and his stop position differs from one time to the next. Going higher on the destination accuracy comes with the risk of the character doing the neverending spin-o-rama dance around the marker. And even if he does stop at times, clicking the same hotspot again (without moving) causes him to try and locate the same marker again instead of just staying in place.

As the character needs to perform animations and Final IK interactions upon reaching a hotspot’s marker, it is crucial that he stands at the exact position of the marker before he starts doing stuff. I just wanted to understand what was the underlying problem in making the character move from wherever he was standing to the *exact* position of the marker.

Thanks.

Comments

  • On a technical level, it's because the character will always move towards the intended target - but will more often than not step just past it in-between frames.  And since different move speed means this threshold also varies, the destination accuracy is used to determine "how close is close enough".

    Update to the latest version, as some improvements were made in this regard.  Also experiment with setting it to 1.0, as you'll be given an experimental "super-accuracy" option that uses a different method to place the character at the exact target.
  • Thanks, Chris.

    I'm already using version 1.49a and have tested the "super-accurate" experimental feature as well. Unfortunately the results are the same. Either he stops at a position that is not *exactly* like the marker's or he goes into the endless spin-o-rama mode in a failed attempt to reach it. And by "not exactly" i mean that the difference in position is visible to the naked eye. I'm a bit at a loss as to how to proceed.


  • edited November 2015
    What scale is your game at (i.e. what's your character's height in Unity units)?  Also, your movement speeds?  The super-accurate feature should always put them at the correct spot - the reason it's experimental is because the "snapping" effect can sometimes be noticeable.
  • I'm not sure what's the exact info you need so I'll give you everything that might be of interest. The character's fbx states that the Scale Factor is 1 and the File Scale is 0.01. The Height in the character's capsule collider is 1.8, the Radius is 0.5 and the center is at 0, 0.9, -0.06. As for movement speeds, if you mean the ones in the character's Player component, then the Walk speed scale is 1, the Acceleration is 6, Deceleration is 0, Turn speed is 7 and Turn before walking is disabled. Is any of this what you needed?
  • Thanks, that all sounds normal.  And the problem is when the character walks, not just when running?

    This being a visual problem, I'm going to have to see this in action.  Could you post a video or clear screenshots?

    I also need to know more about your navigation / pathfinding set up.  I've been working on improving Unity Navigation pathfinding for v1.50 - which will also provide the option of moving a character using Unity's own NavMeshAgent component.  Perhaps that would improve things in this case.
  • Yes, the problem is while walking, not running. One other thing, I noticed the problem occurs more at low framerates. That's when the spin-o-rama starts.

    I'm not set up for creating a video at the moment but what would you like to see in a screenshot? I can post some screenshots once I know what to capture.

    As for my navigation setup, I use Unity Navigation with a baked navigation mesh created using a set of NavMeshSegments. The Agent Radius is 0.3, Agent Height is 1.8, Max Slope is 60 and the Step Height is 0.31.

  • Update: I tested the game at high framerates and suddenly it's bullseye! The player consistently hits the *exact* position of the target marker when super-accurate mode is enabled. What does it mean?
  • edited November 2015
    I will have to get back to you on that.  How are you testing for different framerates?
  • No prob.

    I change the framerate by turning on and off some heavy real-time lighting but you can try using Application.targetFrameRate to change it.

  • Thanks.  I fear this may have larger implications, so I will be looking into this quite seriously.
  • Thanks! It's perfectly understandable, take your time looking into this. Being framerate independent is a very important issue as we can never know how fast our games will run on any given end-user machine so the game must not make any assumptions in this regard.

  • Heya, just started playing around with AC and ran into this issue immediately, good to hear it's being looked at :)

    Out of curiosity, is there a reason you can't check the distance from the current character position to the target point and compare that against the distance the character would move in the frame? That's usually how i'd stop that overshooting problem. 

    The Vector3.MoveTowards(...) function does this. Although ideally, in a frame where you reach a target point you'd move a bit toward the next point with the remaining frame time too.
  • Well, the character won't always be facing the target, and you also have to account for unexpected collisions.  I've tried a few things and think I'm on the right track now.  However, don't forget about the Destination accuracy slider, as it'll still require tweaking depending on your movement values and game scale.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.