move node running, but movement stalls

[tool55Participant]

I’m using a navmesh and the wander script from the recent update. 2.1.8. My AI wanders fine for a few wander positions, then seems to stall. I have “draw path” checked, and I see a green line and the navmesh, but the AI doesn’t get to the wanderTarget. This is on somewhat uneven terrain, though not terribly steep, and I’ve tried numerous step up heights, cell sizes, max climb angles, thinking that there may be no valid path, but none of it has helped. It seems to stall randomly. The move node just shows “running” in these instances and the AI just sits there. I’m not sure how to debug this because there’s no feedback as to why the movement is stalled. Wonder if anyone else is having this problem.

[primeKeymaster]

If you move the node slightly while it is running (for example, lifting it slightly) does the AI resume moving?

[tool55Participant]

Sorry, I think I said that wrong. I’m not using waypoints. When I said node, I meant the “move” node on the behavior tree. I’m using the wander script from the “hopeless wanderers” in the new patrol example. I’ve got the wander distance set to 75 and I have “stay on grid” checked, and “allow 3D rotation” checked. When I click play, the navigation path is displayed as a green line, and the active navmesh area shows up in lavender, but the AI doesn’t always complete the path. As I said, it will go to 5 or 6 wander targets with no problem, then at some point it stalls. The behavior tree “move” mode remains yellow and displays “running” indefinitely.

But your reply may hold the answer. In the wander script, the “Y” axis isn’t modified, so it’s always going to be at the current height of the AI, which means that on hilly terrain, the next wander target could be underground, or well above the terrain, and therefore unreachable. Am I right about that? I’m no expert coder, so I’m just guessing from looking over the script.

Or perhaps that’s what you meant. I tried modifying the Y value by typing slightly higher or lower values directly into the Memory section of the RAIN console where variables are displayed, but it didn’t seem to do anything. Perhaps for hilly terrain one would need to add a check to make sure the wander target is at terrain level. Does any of this sound right?

[tool55Participant]

OK. I figured out the problem. I have an unusual rig. I have crawling insect AI that needs to follow the terrain normals. The only way I’ve found to do that is to parent the insect model to an empty game object and add the RAIN AI to the empty parent. This way the child can follow the terrain normals through script while the parent stays level. For some reason this messes up the navigation. I tried putting the AI directly onto the insect model and it navigates just fine with the wander script. The problem I have now is that my model remains upright at all times and doesn’t follow the terrain normals, so it looks very unrealistic. I haven’t really found a good way to do this. Back to the drawing board.

[primeKeymaster]

Seems like that approach should work. Did you move the colliders to the base object too?

[tool55Participant]

I have colliders on the child object (the insect model). The empty parent just has the RAIN AI on it, and the kinematic rigidbody that RAIN adds automatically.

[primeKeymaster]

RAIN doesn’t add rigidbody components, so I’m not sure where that would have come from.

I’m guessing that since the colliders are on the insect model and not on the parent, that the child transform is offset some distance from the parent? (I’m not sure why else you would need the AI on a different object from the child).

[tool55Participant]

Oh, interesting. I thought RAIN required a kinematic rigidbody for movement. Guess I’m wrong about that. The only reason I put rain on an empty parent object is so that it could remain upright while the child insect model could move freely in the X and Z axes. This morning I tried putting RAIN directly on the child insect model and eliminating the parent. There seems to be some conflict in the scripting between RAIN and the script I’m using to make the model follow the terrain normals. The model flips on its side when I hit play. It’s a surprisingly difficult problem. I’ve looked at every Unity post on having models follow terrain normals and every post on hover boards that have to follow normals looking for a simple way to approach this. Having a model smoothly follow terrain while pathfinding and continuing to point at the target is tricky, way beyond my programming skills apparently. Thanks so much for the help. I’ll keep plugging.

[primeKeymaster]

Are you using rigidbody physics to keep the insect on the terrain normals? If so, that’s likely causing a lot of problems with RAIN.

Unity physics treats any translation of an object (even if it is done outside of physics) to be a physical force that adds velocity/momentum/rotation. Our rule of thumb is, as soon as you need to move an object with something other than physics, you should abandon physics completely for that object. Instead, we would manually calculate terrain normals and then do a manual rotation of the body to match.

[tool55Participant]

Got ya. The script I’m using does have a gravitational force. I tried it with full physics at one point several months ago, but quickly realized it wouldn’t work well with RAIN, or with any non-physics character controller for that matter. I think the script I’m using for rotating the model isn’t ideal. It uses four raycasts from the corners of the insect and vector math to calculate the average normal, then a Lerp to smooth the rotation. But I don’t claim to fully understand how to optimize it. I took it from one of the many posts I read on the subject and modified it a bit (probably not very well). It was designed to work with a character controller, but I commented out those parts. I’ll post it below in case it’s useful to anyone else, or if someone has ideas about how to simplify/optimize it for RAIN. It’s in Javascript. Thanks very much for your help, Prime.

#pragma strict
var moveSpeed: float = 6; // move speed
var turnSpeed: float = 90; // turning speed (degrees/second)
var lerpSpeed: float = 10; // smoothing speed
var gravity: float = 10; // gravity acceleration
var isGrounded: boolean;
var deltaGround: float = 0.2; // character is grounded up to this distance
var jumpSpeed: float = 10; // vertical jump initial speed
var jumpRange: float = 10; // range to detect target wall
var bugParent:Transform;
var backLeft:Transform;
var backRight:Transform;
var frontLeft:Transform;
var frontRight:Transform;
private var lr:RaycastHit;
private var rr:RaycastHit;
private var lf:RaycastHit;
private var rf:RaycastHit;
private var surfaceNormal: Vector3; // current surface normal
private var myNormal: Vector3; // character normal
private var distGround: float; // distance from character position to ground
private var jumping = false; // flag "I'm jumping to wall"
private var vertSpeed: float = 0; // vertical jump current speed 
private var bugCollider:CapsuleCollider;
function Start(){
    myNormal = transform.up; // normal starts as character up direction 
    rigidbody.freezeRotation = true; // disable physics rotation
    // distance from transform.position to ground
    bugCollider = GetComponent(CapsuleCollider);
    distGround = bugCollider.bounds.extents.y - bugCollider.center.y;
}
function FixedUpdate(){
 Physics.Raycast(backLeft.position + Vector3.up, Vector3.down, lr);
			    Physics.Raycast(backRight.position + Vector3.up, Vector3.down, rr);
			    Physics.Raycast(frontLeft.position + Vector3.up, Vector3.down, lf);
			    Physics.Raycast(frontRight.position + Vector3.up, Vector3.down, rf);
			    surfaceNormal = (Vector3.Cross(rr.point - Vector3.up, lr.point - Vector3.up) +
			                	         Vector3.Cross(lr.point - Vector3.up, lf.point - Vector3.up) +
			               	             Vector3.Cross(lf.point - Vector3.up, rf.point - Vector3.up) +
			               	             Vector3.Cross(rf.point - Vector3.up, rr.point - Vector3.up)).normalized;
    // apply constant weight force according to character normal:
    rigidbody.AddForce(-gravity*rigidbody.mass*myNormal);
    myNormal = Vector3.Lerp(myNormal, surfaceNormal, lerpSpeed*Time.deltaTime);
    // find forward direction with new myNormal:
    var myForward = Vector3.Cross(bugParent.right, myNormal);
    // align character to the new myNormal while keeping the forward direction:
    var targetRot = Quaternion.LookRotation(myForward, myNormal);
    transform.rotation = Quaternion.Lerp(transform.rotation, targetRot, lerpSpeed*Time.deltaTime);
    transform.position.x = bugParent.position.x;
    transform.position.z = bugParent.position.z;
    // move the character forth/back with Vertical axis:
    //transform.Translate(0, 0, Input.GetAxis("Vertical")*moveSpeed*Time.deltaTime); 
}

[grotesqueParticipant]

Hey Prime, in the second post you mentioned,

If you move the node slightly while it is running (for example, lifting it slightly) does the AI resume moving?

i ran into a similar problem. The AI stucks at the a 90 degree corners. In my case i have to move the Object the AI is attached to slightly and its resumes moving.

I’m using the Basic Motor, a at runtime generated NavMesh (which seems to work finde) and the path is also ok.
Changes in Walkable Radius doesn’t solve the problem.

The Code is from the wiki

void Update()
    {
        _aiRig.AI.Motor.UpdateMotionTransforms();
        _aiRig.AI.Motor.MoveTarget.VectorTarget = _destination;
        _aiRig.AI.Motor.Move();
        _aiRig.AI.Motor.ApplyMotionTransforms();
}

Any ideas ?

[primeKeymaster]

Can you point me to where in the Wiki that code resides? That must be describing some very specific usage - it isn’t the standard code for moving.

Are you trying to face another object as you move, or is the above code your only call to the motor?

Are you using RAIN 2.1.10?

[grotesqueParticipant]

Never mind, sorry
The object had the controlling script attached twice…

Nevertheless Thanks for replying

[alok@junesoftwareParticipant]

Hi @Prime,
I am facing the same problem AI is stalling after moving to couple of way points and yes changing waypoints position in editor resumes moving, but get stuck at random locations.

Few details regarding the AI and Move node:

1> Move node is a child to Waypoint node with Repeat Never.
2> No FaceTarget is specified in the Move node.(But adding it doesn’t help either)
3> I am using MecanimMotor with CloseEnoughDistance = .1, CloseEnoughAngle = .1, FaceBeforeMoveAngle = .001, StepUpHeight = 1.5,
Allow3dMovement = Allow3dRotation = AllowOffGraphMovement = false, UseRootMotion = OverideRootMotion = false;

Changing FaceBeforeMoveAngle = 90 does help, but i need my AI to follow and lookAtEnemy to shoot at the center hence the value 0.001.

Help…..

• This reply was modified 1 month, 3 weeks ago by  alok@junesoftware.

[primeKeymaster]

Change your face before move angle to 360. That won’t stop the AI from looking at the enemy. If you want the AI to face the target before moving, then add a Move node with only a face target prior to the main move node. If you want the AI to face the target while moving, then add it as a FaceTarget in your move node.

[Author]

Posts