[Suggestion] Custom path finding metric(aka. dtQueryFilter) for real

Development Programming & Scripting C++
, , ,
1

The engine high level function for path finding is MoveToLocation and MoveToTarget.
Now, I think that it is necessary to allow the user to supply its own metric function for A* algorithm.

For example, a character want to perform hide and flee operation(e.g. citizens that hear fire, or enemy with low health).
Current usual method is to use EQS to find near and safe place to flee(and it may change every frame, which is good).
But if we want to enhance it, you could change the cost in A* algorithm that places which hiding the character from the shooter, which I believe this is smarter.

It took me very long time to investigate the low level code of the actual path finding, Recast library based.

For my sad surprise, I saw this line of code:


const FRecastQueryFilter* FilterImplementation = (const FRecastQueryFilter*)(InQueryFilter.GetImplementation());

What it means that in Recast based navigation algorithm, I can’t really implement my own dtQueryFilter, no real polymorphism.

The API was meant to be flexible, but it turns out it’s not.
The insane workaround is to duplicate some code of UE.

So what I’m asking simply is a way to override dtQueryFilter.
I think it’s the basic for huge features, for really task based navigation, instead of today case that tasks differ only by choosing destination algorithm.

Did I miss anything? What do you think?
I searched and no one really suggest this for UE.

Thanks! And sorry if this is not the correct place for this feature request.

2

I totally agree a lot of this stuff isn’t as easy to customize as it could be. In particular I just don’t understand why so much is based on using a static instance of a UCLASS to define things (e.g. subclass of UNavArea) rather than actual instances. It seems to make implementing dynamic behaviour a whole lot harder.

Anyway, although I’ve not got around to trying it yet, I believe you should just be able to derive from FRecastQueryFilter and override passVirtualFilter, no? What UE4 code do you think you need to duplicate?

3

Agree with Kamrann, this stuff is kind of annoying (the UCLASS usage in nav areas is a good case in point). One approach you could take, is to derive from the navigation system with your own and then implement the findpath methods in a way that does your A* differently. The problem with the query filter method is that the filters really won’t have enough information to go on to do anything useful anyway. Areas are really the only modifiers for path generation and for the reasons Kamrann points out, those are a bit ****.

I think maybe the reason they used UCLASS was to save memory somehow, as you could define a class (nav area type) and apply that in all sorts of places, rather than having to get an instance and then get its uclass. But honestly I think that kind of thinking is rather old school (and I might be complete off about it too).

My own approach is to create Actors that do what I want, then I plan on moving the functionality into classes derived from the UE4 base (NavSys, NavigationData etc).

4

NavSystem could definitely do with better Polymorphism support. I’ve been jumping through hoops trying to get pathfinding to work for pawns that aren’t constantly grounded.

I said this in another post - even Unreal Tournament isn’t using the engines’s default pathfinding, and considering that’s the engines’ heritage, I feel like that’s a pretty clear example of the engine’s nav system not being flexible enough. Data needs to be more abstract too.

5

Thanks for replying, and sorry for the delay.

We should have more generic as you said!

You are correct about your suggestion to derive from FRecastQueryFilter and override getCost().
For some reason I had thought it won’t work…
I didn’t test it, but it should work! Thanks!

I hope that Unreal will push the great things from UT to UE as well, in particular the AI.