Wierd mesh movement?

Hi,

I have implemented a Raycast Graph and I’m using the FollowerEntity AI for my unit.

There are a couple of things that are happening that I’m not understanding why…

  1. the unit is moving through walls. I thought that colliders would block it? What do I have to do in order for the environment (in general) to block the path?

  2. I’m using Link2 to connect the floors vertically. the unit goes up and does done but not on all the places has you can in the video below. What am I doing wrong? (Note: this was previously working fine with Unity NavMesh and links and replaced it with an A* Link2 with the same distance and position)

  3. I understand that the FollowerEntity already provides gravity. How can I control it? thigh now the unit feels a bit light when it falls and I want to make it fall faster.

  4. how can I control the speed the unit tales to cross certain Links and if the crossing is instantaneous (teleport) or if it should follow a different speed than the movement speed?

Many thanks in advance.

Hi

  1. It does not use colliders, but it will respect the navmesh, and the navmesh, in turn, can be generated to take colliders into account.

2,4. For those vertical movements, you will want some custom movement logic. The default logic just moves the agent using the normal movement code towards the other side of the link. It doesn’t expect to handle vertical movement. You can find out how to do this at the bottom of this page: Off-mesh links - A* Pathfinding Project

  1. It uses the project’s gravity setting (Project Settings → Physics).

on (2) ignoring the animation, why is the unit getting to the link and not crossing it and instead goes somewhere else ? and then tries to go back and go somewhere else?

Shouldn’t it be crossing the link? The links up work, why don’t the links down work also?

The default off-mesh movement moves the agent towards the other end of the link, but it still uses physics to position itself on the ground.
I do see some limitations in the current code, though. For example, to check if it reached the other end, it only compares the X and Z coordinates, but not the Y coordinate. Since your links are vertical, it believes that it has completed the link almost as soon as it starts traversing them.
I’ll consider improving this.

But in any case, you’ll want to use custom code for the off-mesh link traversal (see the previous post).

but if that’s the case, wouldn’t “going up” movement also fail?

I think what’s happening in that case is that the agent instantly completes the off-mesh link, and then the agent thinks “oh, I’m really far below the navmesh”, and clamp its y coordinate to only be slightly below the navmesh, in order to try to fix this.

But why would going down be different from going up?

that’s what I don’t understand :S

The agent only clamps its position to ensure its not too far below the navmesh, but it doesn’t do that for being too far above the navmesh.

ok… made some more tests (because it was actually working before) and it seems that

  • RichAI → works fine
  • Follower Entity → only works going UP

So, what could be different about RichAI that makes it work compared with FollowerEntity?

This is how it looks when using RichAI

And This is how it looks when using FollwerEntity

The RichAI’s default off-mesh link logic just interpolates its position between the start and end points of the link. The FollowerEntity still uses gravity in its default logic.

Trust me. This will all work if you add custom off-mesh link traversal logic. Check the example script at the bottom of the page that I linked.

Ok will have a look at it. May need to come back to confirm if I understood how to do it correctly but we get there when/if we get there. :sweat_smile:

Just one last question (again trying to understand the reason for things to behave like they do)

With the RichAI when I try it on the “proper environment” I’m having a very weird behaviour where the unit starts jumping all over the place (see below).

Any idea what could be causing it?

And I also tried to include the colliders in the rasterisation but they are still not blocking the navigation in the mesh.
What may I be missing?

Mesh config

Hi

Do you have a collider on your agent? I see that your agent has a raycast mask that is set to include itself. This could lead to the agent trying to stand on its own head.

It doesn’t have any collider on the agent.

btw, was able to make the link-cross script as you suggested and it works fine as you suggested.
I would just suggest you have a look at it for a future update or something because it seems like something that would work fine out of the box.

In my case it actually works well having a script because I will want to use special animations to go up or down the ladders.

that problem is solved. Just one last question to close that topic… lets say that I have different types of units and each unit may cross the links in different ways (like a walking unit vs a flying unit vs a teleporting unit etc…)

What would be the best way to address this?

many thanks.

Do you mean that different units may have different rules for if they are allowed to use the link?
In that case, you can mark the off-mesh links with a tag, and then specify on your movement script if that particular agent is allowed to traverse that tag.

Yeah, perhaps I should go back to just interpolating between the start and end point. It’s guaranteed to always work, but it will not look good by default for common things like jumping off a ledge.

Do you mean that different units may have different rules for if they are allowed to use the link?

No, I mean like for example) the animation, the speed and how the link movement is performed.
For example, some units may teleport between the start-end while others may climb the ladder and others may float through the ladder. Stuff like that.

If you use the custom off-mesh link code, then you can control exactly how the agents traverse the off-mesh link.
You can even access the link’s or the agent’s gameObject to check for extra components that may have more metadata for you to use.

1 Like