AIController::MoveToLocation doesn't use navmesh query extend

Development Programming & Scripting AI
, , , ,
1

For UE 4.7.4;

Inside AAIController::MoveToLocation at AIController.cpp, line 553: ProjectPointToNavigation is being called with AgentProps.GetExtent(), which seems to be related to the agent’s height and not the value specified in SupportedAgents in navmesh settings.

Is this the intended behavior? In what case is the default query extend used?

2

You’ve found an interesting inconsistency! Let’s talk about it :smiley:

In general default query extent specified in NavigationSystem::SupportedAgents is supposed to be used when an extent has not been otherwise specified. Now in the case of movement we’d kinda want the process to take agent’s properties into consideration, but I agree that projecting in this case should use the default extent.

To be honest I don’t have a recipe on handling it. Normally a rule of thumb I follow is “what would people expect?”, and I guess in this case they’d expect the default extent being used. But what if agent is a lot larger then the extent? Should we use the maximum on both? I don’t think so, the other rule is: keep it simple. I’m for just fixing it and using the default extent in this case (and look through other cases that might need that as well).

Thoughts?

Thanks for pointing this out!

–mieszko

3

Now I see what you mean. Is there a disadvantage to using the max of both? Does increasing the extend have a significant impact on performance?

In what case would I want my moveto request to fail because the extend was too small and the project to navmesh fails?

Thanks for the reply Mieszko.

4

The only disadvantage of using “max” is the “where did this come from” feeling while looking at debug-drawing of navigation queries. There is a CPU cost as well, but that’s negligible.

In general you never want your pathfinding requests to fail as long as there’s navmesh, unless “it seems” it should fail. Unfortunately the “it seems” algorithm is not trivial to implement :wink: I’d like to avoid adding flags that will transfer the burden of making the decision to users - it end up blowing in people faces way to often.

Like I said, it’s not an obvious pick. I’d go with using default extent - you can always expand the value in project settings, and you do it once for all agents, and it’s consistent. But I need to chat about other AI folks - they’re pretty smart and often kill my ideas with one counter-use-case :smiley: And please share any further thoughts you might have on this one as well - don’t hesitate to crush me! :wink:

5

Hi!

I’m having problems with this as well. I only know the position in the XY plane and thought ProjectPointToNavigation would be able to project the point to the navigation mesh using the default query extend.

I’m not that informed of other use cases but it seems strange to me that the agent’s height and width is used as an extent, why? Does it really have anything to do with the agents size? I would definitely expect the move method to use the closest point at the navmesh if any available regardless of the agent’s size (provided that it would be walkable for the agent).

Anyhow, how are you supposed to solve this issue? Should I trace before calling the move method and use that location instead. Meaning basically re-implement the ProjectPointToNavigation method myself?’

6

Is there a good work around for this aside from calling ProjectPointToNavigation with a custom extent before calling MoveTo?