I just want to natural follow moving to target, but using navmesh agent is very weird…
I just set navmesh agent like Unity’s enemy AI tutorial’s one.
navMeshAgent.speed = moveSpeed;
private void Chase(StateController controller)
{
controller.navMeshAgent.destination = controller.chaseTarget.position;
controller.navMeshAgent.Resume();
}
and result is,
Make sure there is no Rigidbody or anything on it.
Navmesh is simple interface built at top of quite complex solution. Undestanding and configuring it’s movement may take time. For now it looks like it tries to approach position occupied by other agent. Also it has features like acceleration, slowdonw, target tracking, etc. Probaly the surface is not smooth enough.
removed rigidbody, but the same vibrating movement.
hm… then what is good way to make enemy track player and chase movement? just with transform.moveforward and play walking animation? Is this follow surface with just rigidbody with gravity turned on?
Instead of setting player’s position as enemy target, try to find free spot around player far enought from it’s body for enemy to stand free (without collisions with player) there and close enough for enemy’s attack animation to perform nicely. Set this position as target and update it as player moves away from this position.
made target as some child transform that is positioned ahead of character, but still monster’s vibrating motion does not stop.
This might be because not smooth navmesh (show it here) or are you using LookAt anywhere?
I suggest you do a simple test without an animated object to understand where you are going wrong with it.
The documentation illustrates a lot of steps if you are doing root motion, for example. You will need to pay attention for root motion.
That said, I do not use the agents at all, but instead just ask navmesh to give me a set of corners. The agent uses the same data anyway.
At leas then when you have a path of Vector3 from navmesh, you can choose how to move how you wish and avoid all these issues.
Is there a way to calculate a path without even having an agent? I also prefer to handle movement myself, but so far I’ve always been using a NavMeshAgent to find a path.
I previously posted some code in response to a previous post a while back:
https://discussions.unity.com/t/752385/8
Yeah the NavMesh class allows you to calculate a path how you would like. The path also includes any offmesh links and so on, it all just works. Internally, the agent queries the same stuff.
It is not costly really. It’s just written like that in the docs because the agent will do smaller hops there while if you calculate it, there’s nothing stopping you from asking it to calculate miles worth.
In my case I simply restrict path requests to one per frame, and there doesn’t seem to be an impact I can measure much so there you go…
Is there any project that does not eventually grow out of the built in navmesh and moves to A* pathfinding project or similar? 
Yes vibration reason was LookAt function. So I removed it, but now why this monster walking around back and forth?
I just did wrote 2 lines code.
controller.navMeshAgent.destination = controller.chaseTarget.position;
controller.navMeshAgent.Resume();
@leegod , never have one transform look directly at a different transform in a top-down game. That’ll cause a ton of problems (like vibrating) when their y-position isn’t the same. Instead, look at a point that’s at the target’s x- and z-position, and the looker’s y-position:
We did ship a serious game with built-in navmesh. That was a mistake. I wouldn’t say that projects outgrow it as much as it’s not suitable for making anything in the first place.
They’re porting it to DOTS now, for some absurd reason. That’s turd-polishing at scale for you.
I haven’t found any problem I can’t work around but then I am not using the agent. What were the problems you guys were having? Was it with getting manual paths or agent issues?
I didn’t bother with other assets as they created too many allocations for my taste.
Too little hooks for serious AI development. For example we needed to query the navmesh todo custom processing ontop of it, talk abit about it here
Looks like something stops it from reaching it’s destination. Try to disable all physics and remove player and other obstacles, let the beast just reach some destination points to avoid interferences from other objects/physics/ whatever
I solved that by building an open-edge list off the internal mesh that Unity uses. So I know where all the cover points are and it’s no problem for me. I didn’t need to hook in, but I could’ve done with a cleaner way to do it.
Additionally, it’s a shame I can’t get access to the raw navigation mesh before it is optimised by Unity. They allow debug display of it, so it’s there, but they don’t allow access to the initial mesh, only the optimised one, which isn’t much use when you want to figure out the local topology.
Because they don’t make games with it.
Wasn’t a blocker but I see where you are coming from for sure. Unity needs to do some complex AI such as bots for their shooter. This would give them a clear picture, I’m sure.
But I would not go as far as to say that you can’t make a decent game with Unity’s built in (recast) navigation. Most AAA games also use the same source code (as does A* project), but as you point out, the access to the internals does suck.
It’s not even a package yet. I don’t think they have any real interest in it. At least it’s not crashing and seems stable enough.
It’s a stupid black box. If I want it to do something specific, I can’t, I instead have to tweak arcane, poorly documented knobs to get something in the vicinity of what I want. There’s no hooks to do anything meaningful. Everything is poorly coupled.
Baking is horrid. You have to give it a bunch of geometries and settings and hope for the best.
Any baking based on looking at input geometries divorced from any knowledge about the game they’re in is going to be bad, but that’s the only way you can do things in Unity’s setup.
Baking is a good option for games with very, very simple geometry, and for prototyping, but you really want to be able to just feed in the correct mesh based on what you know about your own game. We spent countless hours fighting against thin slivers, bad corners, weird shapes, and other stuff like that.
Also, If I want to have to navmeshes next to each other - say a land-based one for land creatures and a water-based one for water-based creatures - then they’ll automatically connect to a single mesh, which means that water-based things will be partially on land and land-based things will be partially in water. Woop woop.
And the agents are worse:
I can’t meaningfully define how the agent takes corners - it will always hug it as tightly as possible, usually in a way that looks bad. I can’t define how agents avoid each other, just what their radius is. Their radius when taking corners and avoiding each other is tied together.
The agent’s acceleration and deceleration is the same variable, and I can’t do anything about that.
There’s no built-in way to say things like “move by turning”. Instead, the agent moves in a straight path towards it’s target, always. The way you’re supposed to work around that is to use root motion, which is a hack on top of a hack. It also, by default, doesn’t take it’s facing into account when deciding speed.
CalculatePath returns true when it can’t find a path, as long as it can find a partial path.
The navmesh defines the points where the agents can have their center position. This means that all solutions for agents with different radiuses will be bad.
Automatic off mesh links only go down. If you want to automatically be able to jump up, you have to place those out manually.
Stuffing a bunch of agents into a tight corridor doesn’t handle gracefully at all either, last time I checked. Putting a bunch of agents close to each other also performed pretty poorly.
So the agents are dumb, slow, and look bad.
This really make me turn off interest on NavMesh permanently.
Then what do you use for monster, characters movement?