Navmesh agent jagged movement

Hi everyone!

There is a weird small visual glitch happening with the navmesh agents. Not sure what is the problem, but I can replicate the issue with a playground. Take a look at this:

https://playground.babylonjs.com/#6AE0RP#3

What is wrong with this, you might ask? Well, it is a subtle jagged movement that happens from time to time. In the following picture I try to illustrate what I mean:

Sometimes when you click a point (T as Target in the picture) and the cube starts moving, it kind of switches position a bit to previous one, I think. I think this is showing now, since the camera is locked to the target cube and all the small “nudges” are really visible. It is even more visible when you have a fully fledged animated character in your scene instead of the cube :slight_smile:

Any idea what might cause this?

pinging @Cedric

1 Like

I couldn’t repro …or my eyes are not efficient enough :slight_smile:
The only thing I can see is the deltatime that is not really what it should be.
By default, timesteps and fixed, you can try with this variable timestep:
Navmesh agent jagged movement | Babylon.js Playground

1 Like

Could this have anything to do with my monitor, it is 120hz… Also tried with timestep set to 0, and I get the same result. This is really tricky to reproduce, but if you stare it long enough you might notice it too :laughing: Also tricky to capture on video…

Kind of wondering if this is navmesh problem after all or something deeper :thinking: I used a simple animation example with cube and I get the jagged movement here as well. Not sure if the camera or the animation are the culprit? Really confused now! :smiley:

See here:
https://playground.babylonjs.com/#7V0Y1I#607
If you uncomment the camera.setTarget(box) you see how the box moves. Am I only one seeing the problem?

I can clearly see the problem here!
I think animation and camera and working correctly … but not together.
Might be because of order of operation (camera computation before animation, or the reverse)
Do you have an idea on what’s causing that? @sebavan @Evgeni_Popov

1 Like

camera.setTarget is taking a Vector3, not a Mesh:

https://playground.babylonjs.com/#7V0Y1I#610

1 Like

How is it still somehow working? Also in the docs it says it takes Vector3 or AbstractMesh as a parameter so it should work, right? :thinking:

Could there be something going wrong with calculations when the mesh target is set? Digged the code a bit here Babylon.js/arcRotateCamera.ts at master · BabylonJS/Babylon.js · GitHub

And finally, how would we use the raw Vector3 in this playground? In line 76 we set the target camera to mesh, but using its position does nothing… https://playground.babylonjs.com/#6AE0RP#4

I can still see the issue when the camera is not using setTarget.

https://playground.babylonjs.com/#6AE0RP#5

1 Like

I had looked at the TargetCamera doc, not ArcRotateCamera

Indeed, ArcRotateCamera.setTarget also allows to pass an AbstractMesh.

Replacing this._targetHost.absolutePosition by this._targetHost.getAbsolutePosition() line 713 here fixes the problem, but I’m not confident enough with everyting related to the camera/input system to make the change. @Deltakosh and @PolygonalSun what do you think?

1 Like

This is fine to change. I see no problem

1 Like

Yeah I think I see the problem too without the setTarget, but I’m not 100% sure :smiley: Starting to feel like a lunatic… :sweat_smile:

But in my real use case, the game I am making, I am using setTarget to attach the camera to the player that is controlled by nav mesh. Would be nice to see if it looks better with the code changes to the arc rotate camera :slight_smile:

Also @Evgeni_Popov , in the line 712, there is the call for this._targetHost.getAbsolutePosition but shouldn’t that be this._targetHost.getAbsolutePosition() ? Or why is it missing the () at the end?

Line 712 is ok, it’s only testing that the method does exist.

I will make a PR to make the change line 713.

[EDIT] PR:

2 Likes