DoN's 3D-Pathfinding / Flying-AI system (with full source!)

[VSZ]

The uint32 fiddling has me puzzled too! From Github what I gathered is that the engine calls GetUniqueID() on a primitive component whenever it is added and uses this unique integer for internal management instead of dealing with the primitive component itself. So no easy way to extract the primitive component back from a collision query, you only deal in the uint32 ids it extracted earlier it seems.

Fortunately there's a simple workaround, we shouldn't have to bother with IgnoreComponents at all.

Try changing this: (DonNavigationManager.cpp - 1238)

collisionParams.IgnoreComponents = VoxelCollisionQueryParams.IgnoreComponents;

to

collisionParams.AddIgnoredActors(ActorsToIgnoreForCollision); // ActorsToIgnoreForCollision is the same member variable that VoxelCollisionQueryParams also uses, so this should be equivalent.

[amigo]

[MENTION=14603]VSZ[/MENTION]

Awesome, thank you - it purrs like a kitten.

Changes made in lines 1238 and 1313.


For everyone else, if you wish to compile this plugin code without Engine GitHub source, without a creating a C++ project, but instead in the DonNavigationSamples project folder, try the following command line (make a .bat file for ease of use)

Path_to_UnrealEngine_folder/4.11/Engine/Build/BatchFiles/RunUAT.bat BuildPlugin -Plugin=Path_to_Projects_Folder\DonNavigationSamples\Plugins\DonAINavigation\DonAINavigation.uplugin" -package="Path_to_Projects_Folder\DonNavigationSamples\Plugins\DonAINavigation" -Rocket -TargetPlatforms=Win64

[rsfx]

All, I didn't see the new replies on this thread until now. Somehow the VBulletin thread subscription mail just doesn't seem to work reliably for me. Sometimes it sends an email when there's a new post, more often than not it doesn't!

[MENTION=87223]rsfx[/MENTION] - Thanks for sharing that. I think that's the multi-waypoint setup that [MENTION=32265]lunyBunny[/MENTION] was looking for too. Btw FPS on the video looks really low, is it the recording software or just the way it is? :P I'm a bit surprised to see the bot bumping into obstacles so often, that is not the intended level of accuracy at all! Did you try playing around with the VoxelSize setting to see if that helps? Not sure if you ran into a bug in the system or a fundamental limitation of the overall setup.

[MENTION=1519]amigo[/MENTION] - thanks for bringing that to my attention! I haven't migrated to 4.11 yet so I haven't had a chance to test. When I get some time I'll migrate the sample project over to 4.11.1 and see what happens. Expect it to take a week or so though, it's crunch time for my project ATM and if I start looking at this I know I won't stop :P

Plugin news:

I've made some critical bugfixes and usability improvements that I haven't checked in or uploaded yet. One of them is a serious bug in the dynamic collision task scheduler where unrelated tasks were getting mixed up! That fix should improve accuracy of dynamic collisions dramatically although I don't think that will help with general collision issues like the one [MENTION=87223]rsfx[/MENTION] posted in that video.

I'll try to bundle up these bugfixes and 4.11 testing together into one update.

Sorry for the late answer. The video is a ****, I´m guilty of this, the piece of s(oftware) I used was not such a good choice. As a matter of fact it has been sentenced to uninstallation! And the bot part, well I was changing some code into your solution trying to implement various paths calculation that will not overlap while pointing to the same goal. As I am under a heavy load right now I left it on pause but I have some more ideas that I could implement into the bot class.

Once again I thank you for this tool.

[RJM]

plugin looks awesome and thank you for releasing it to the community.
sadly it doesn't work on 4.11.2.
i'll use it in 4.10.4

i moved the content in DonAINavigitonUE4_v1.2 to my games' Plugins folder.
i start my project and i get this



i select no and get this



then hit ok and get this



which crashes the project.
hope this helps. i haven't looked through the source.
i might check that at some point but just wanted to give you heads up.

[VSZ]

[MENTION=33512]RJM[/MENTION]
Hey, it's a known issue that the latest download (v1.2) doesn't work with 4.11 out-of-the-box. But the fix is available in the posts above (start from this post). The PaperSprite CDO issues should almost certainly be unrelated to the plugin.

It's high time I uploaded a patch for v1.2 but I've been so busy of late just haven't had the time for it.

[UCF]

Hey guys,

Respect VSZ!

Anyone got this working on 4.12 or willing to share some tips on compiling it for use in 4.12 ?

We really need this. I don't think you all only wants to make FPS or TPS games with Unreal, are you?
Unreal needs a proper reliable solution for 3D pathfinding and this is - as far as I found out - the most promising solution.

Let's get it on!

[MatzeOGH]

I'm going to start porting the plugin to 4.12 as soon as 4.12 is released.

[VSZ]

[MENTION=22887]MatzeOGH[/MENTION] - Nice! I do have a major update coming soon (with a big surprise feature!) but 4.11 is what I'll be using for that too so feel free to port to 4.12 as you like.


[MENTION=243902]UCF[/MENTION] - Thank you. For newer versions most issues are engine-level API changes/deprecation (unrelated to the plugin itself) so getting the plugin to work shouldn't be a major issue. The real challenge will be making sure the all the usecases that your project needs are met in a reasonable manner by the system. Playing around with the sample project should give you an idea about its strengths and weaknesses...

[MatzeOGH]

When are you planning on releasing your update?

[VSZ]

^ Now!

v1.3 Released

Grab the latest release from this page or from the title post of this thread.

--

Unbound Worlds! (Experimental feature)

Background:

Perhaps one of the biggest limitations in the plugin was its fixed navigable bounds which forced you to set your map size to a small-ish box. Granted, you could use a really large volume and compromise on load-times but in hindsight it was unreasonable for one tiny aspect of the game (AI Navigation) to hamstring your entire thought-process around what map size of your game needs to be. I suspect this may have turned some people away from using the plugin too.

I realized this the hard way while testing my nature game's "Simulation" game-mode where players should (ideally) be able to travel to any distant part of the map and shape the ecology there. So I spent some time adding plants, etc to a distant terrain and when I started adding creatures (AI) to the map, POOF.. nothing happened. Why? The navigable volume was waaaaay back on another side of the map!

So I wrote a new "Unbound Navigation Manager" class that allows you to run navigation queries from anywhere without worrying about the navigable volume box!

How to use:
Simply add the new manager "DonNavigationManagerUnbound" into your map (be sure to delete the old manager). You will now be able to schedule navigation queries from anywhere!

The new manager will still show a navigable bounds box but don't worry, it won't be used unless you explicitly override the variable "IsUnbound" to false.

What's more, dynamic obstacles will not need to call "ScheduleDynamicCollisionUpdate" to register their collisions because everything is calculated on the fly with the unbound manager. That's a huge relief for highly procedural setups like my game where managing dynamic collisions can become a huge burden.

Finally, this is a highly experimental feature that hasn't been fully tested so beware! Even in my own game it is disabled by default. I'm using the new manager though and exposing a simple menu option from which unbound worlds can be activated at run-time for testing or playing around with.

Limitations:
1) The unbound manager is obviously slower, watch out for timeouts on your navigation queries. This is really a compromise between performance and the ability to navigate anywhere.

2) Long-distance navigation is NOT solved by this update! Long-distance navigation continues to remain something that will be really really slow and almost certainly timeout. This update allows you navigate from any starting point to any destination, but that destination still needs to be at a reasonable distance away from your starting point. If your AI needs to navigate from one corner of the world to another I would suggest breaking it up with pre-set waypoints or by creating dedicated obstacle-free airspaces that your AI can rely on for moving between different zones. Once it has arrived at a new zone, it can launch a navigation query to navigate around that space.

--

Looking ahead, there's some interesting stuff possible with the unbound manager like allowing variable voxel sizes for each query. In simple words, an AI can decide what voxel size (precision) to use at run-time depending on its unique needs at that point in time. This could be one way of allowing long-distance travel. An AI could use a really large voxel size for long-distance travel or even progressively increase the voxel size the closer it gets to the target (a pseudo-octree like solution perhaps). This is not implemented though, it's just me day-dreaming about how the birds in my game are going to perform their long-distance migrations to distant lands some day

PS: Separate downloads for 4.11 and 4.12 in v1.3. If you want to use it in other Unreal versions like 4.10, you'll need to fix compilation errors (arising out of engine API changes) in Visual Studio, should be very straightforward to do that though.

[Ryan Darcey]

Anyone else run into this issue when setting up their DonNavigationManager? Are we still required to have a navmesh just so this condition is satisfied? Seems like I'm probably missing a setting or something...

https://answers.unrealengine.com/que...mynavdata.html

Also...just gonna echo everyone else here and say that [MENTION=14603]VSZ[/MENTION] is a hero This is my first time working with AI in UE4 and got a simple 2 state AI character chasing me around the level within 4 hours!

[VSZ]

[MENTION=43607]rcdarcey[/MENTION] - You don't need the native navmesh.

First thing I'd ask is if you're using the Character class for your AI instead of the Pawn class (which IMO is the only sensible base class for flying creatures).

Remember that Epic's own flying template uses a Pawn rather than a Character class! And with good reason too; I've been down the road of building a flying Character and trust me, it's not worth it. You will have to fight against the native flying mode's moody physics and it's hard to move your AI intuitively. For my own project I ended up redoing months worth of work by discarding my previous Character AI and building it from scratch with a Pawn just like Epic's flying template. Made life so much simpler.

In summary, prefer Character for humanoids that mainly "walk". Prefer Pawns for everything else. If your humanoid needs to perform both complex land pathfinding and complex aerial pathfinding only then would I recommend using a Character (so you can easily tap into navmesh, etc) along with my plugin for aerial. But then be prepared to run into strange issues like the one you described (I've replied to your answerhub post for this specific issue)


PS: I noticed you're using 4.10. The latest plugin (v1.3) will only compile with 4.11 (although you can easily fix the compilation errors to use it with 4.10 if you need to)

[Ryan Darcey]

[MENTION=14603]VSZ[/MENTION], I am using a pawn derived from the Character class. At first I started with a regular Pawn like the flying template, but then changed course cause I wanted to leverage the additional networking support in the Character class. Granted, the additional overhead/assumptions I'm taking on with Character class may not be worth it in the long run. I'll have a think about porting my work back to a regular Pawn.

That said, unless I'm missing something, it looks like the PathFollowingComponent in the AIController class is what wants the navmesh to be there. Are you not using this class for your pawns?

I originally downloaded version 1.2 and got it up and running with just a couple compilation errors that needed fixing. Will upgrade to 1.3 when I make the jump to 4.11

Thanks again for everything!

[VSZ]

Yep I'm also using AIController for everything, that should be perfectly fine.

I don't know what execution path is causing the crash for you but it's coming from a Nav Agent data lookup (which intentionally crashes if it can't find the stuff it needs) so I don't think the AIController itself is at fault, you have a nav agent coming in from somewhere (probably Character).

FWIW I changed the bot in the sample project now to derive from Character instead of class and although it was wobbly (flying physics stuff) it did work without crashing! So there's some specific setting somewhere that needs to be disabled in your setup. Sadly I've never used Unreal's native navigation much so I'm not sure which setting you need to tweak...

Try starting from a fresh Character (or preferably Pawn) so it's easier to narrow down the issue.

[Ryan Darcey]

Yep I'm also using AIController for everything, that should be perfectly fine.

Gotcha. Thanks for the quick reply. I'll take it from here. Obviously something specific to my setup.

FWIW I changed the bot in the sample project now to derive from Character instead of class and although it was wobbly (flying physics stuff) it did work without crashing!

Yeah! I've got it setup on a Character derived class and seems to work pretty well Took some time to tweak the acceleration & max flying speed values to make sure the pawn didn't have trouble reaching minimum distance to navpoints, but other than that all goody so far!

I'd love to hear how other folks on this thread are implementing their flying pawns. I agree using a Character might be overkill if your pawn is never going to actually walk, but what about a Pawn w/ a UFloatingPawnMovement component? Maybe still not the best choice if you're using this plugin since it derives from UNavMovementComponent.