Jump to content
  • entries
    941
  • comments
    5,894
  • views
    867,875

"Finding" a "Path"...Get it? Wait a minute...


Josh

4,054 views

 Share

So after about three weeks of pain and frustration, I have successfully calculated my first path using Recast navigation. This has been a new experience for me. I've implemented half a dozen low-level C++ libraries, and never had any serious trouble, but Recast Navigation is something else.

 

The technology underlying Recast is impressive. First they take triangle geometry, convert it to voxels, then calculate navigation, and convert it back into rough polygons. You can read about the process in more detail here:

https://sites.google.com/site/recastnavigation/MikkoMononen_RecastSlides.pdf

 

The results seem pretty reliable, and although the speed of regenerating a tile is slow, it can be done on a separate thread and doesn't have to be updated all that often. I have two criticisms of the library.

 

First, the code is a total mess. I can't complain too much since it's a free library, and I definitely appreciate Mikko putting it out there, but integrating it into the engine was a hellish process. I wouldn't even call Recast a code library so much as it is an open-source program. The amount of work it took to figure out what was going on was far beyond any library I have worked with, and it could have been wrapped up into a set of much simpler commands (which is what my end result was).

 

Second, I believe converting polygons to voxels and back is the technically wrong way to go about this. Constructive solid geometry is perfect for navmeshes, autogenerated or otherwise. It would be very fast to generate. It could be dynamically updated quickly. The results would also be 100% accurate virtually all the time. However, it would require all navigation geometry to be modeled with CSG, and although I would be fine with that, I know others will want to use arbitrary polygonal geometry. So that's one thing I would do different if I were making an engine for just myself. There's an example of why you need to be flexible with your goals sometimes.

 

Still, it's great to be able to build navigation data for any scene and make a character walk around in it without any waypoints or ray casts. Below is my very first result with Recast. There's some obvious strange results with the path, but the point is that it's working, to some extent. It's a minor miracle I am able to plot any kind of path at all. The hard part is done, and I'm sure I'll get any remaining issues ironed out pretty quickly:

blogentry-1-0-68724400-1317410924_thumb.png

 

Building AI features right into the engine will give us better integration than using a third-party add-on, or trying to build it on top of the engine. First example, we can use physics geometry instead of visual polygons, and make the engine automatically invalidate and update sections of a map when objects move. This will give you powerful AI features that work perfectly with the rest of the engine, so you can control characters with just a few lines of script code. When this is done, it's reasonable to expect to be able to program something like Left 4 Dead in just a couple hundred lines of script (or less, if you just feel dragging some premade scripts around and attaching them to entities).

 

Once the pathfinding is all tidied up, it will be a big moment, because it means at that point I will know everything I need to finish Leadwerks3D! When setting out with Leadwerks3D, the things I hadn't done before were what I was most worried about. I attacked the unknown issues first. Now that we are coming to the end of this long research and development phase, all that remains is a lot of hard work. It's all stuff I have done before, so I expect the remaining tasks to go pretty quickly. It's also pretty awesome to have a clear picture of how this massive piece of technology all works...four platforms, with rendering technology stretching from fixed-function graphics all the way to Shader Model 5 hardware tessellation...plus the easiest art pipeline ever and a script and flowgraph system that no one has ever done. The scope of this engine is just so much bigger than anything I have ever done, and it actually works! B)

 Share

17 Comments


Recommended Comments

what are your plans with terrain? will you be able to create the navmeshes with the terrain you have in mind or will this only work on models? Also, do you have a way to 'stitch' sections of navmeshes together? or is it just created at a press of a button based on certain user selected criteria? What are the parameters that we will have control over? stepheight, slope?

Link to comment

This is really good news. I have a question similar to mack's. Will i be able to set a starting point on the terrain in the editor, and a destination point on the 3rd floor of a building and get a navigation route that travels thru the terrain, enters the building and clibs the stairs ? or will i have to generate 4 navmeshs ? one for the terrain and 3 levels of my building ?

Link to comment

Great news. Having recast embedded into LE3 is a huge plus.

 

All nav mesh systems should handle that route easily Wchris so long as there is a viable route between the two points, the fact that there is a vertical displacement between the two points doesn't matter so long as no part of the path exceeds the maximum step height. It would be a single nav mesh as a nav mesh should reflect all walkable areas of a level regardless of where they are placed. You should, as an example, be able to fall or jump off one area onto another previously inaccessible area and still be able to navigate that new area.

Link to comment

so you can control characters with just a few lines of script code

 

Great, i like this :)

It will be incredibly helpfull to make games similar to Dead Space , Bioshock or RPG games using complex indoor dungeons.

Link to comment

..it does sound interesting..however there are some things with recast I don't like...what if navmesh need to be rebuilted in runtime ? im sure it will be noticable performance impact for such task..tested it before, and slowdown was more than noticable..

Link to comment

@Naughty Alien : what if navmesh need to be rebuilted in runtime ?

I think it's to people to avoid that depending on their game type. Perhaps for some type of game avoid having physic objects interacting with the pathfinding system :

A barrel falls in the path , the NPC will try to avoid it, or just push it or destroy it after walking on it ?

Or just put Dynamic models that are tiny , and keep the big ones for large paths or rooms.

 

The pathfinding is a big addition for gameplay, no more worry about NPC needing to chase the player without beeing stuck on the level or dungeon or whatever.

If it incoporates in LE3, with the plugin system perhaps some people will make advanced pathfinding tools for LE3 why not ?

Link to comment

Great work on this. LE3 is going to be really nice.

 

You said that regenerating a tile can be done on a separate thread. Does this mean you will be supporting multi-threading?

Link to comment

Navmeshes can have multiple levels and overhangs, so you only need one for a small or medium sized scene. It's not a per-model thing, it can handle all geometry, and the engine will take care of that automatically.

 

Dynamically recalculating sections can be done by running it on a separate thread and getting the results a few frames later. Again, the engine just does it automatically for you. I don't know if mobile devices will have enough power for this, but when was the last time you worried about waypoint AI not being dynamic?

 

For very large scenes, I think you will need to create multiple navmeshes in the editor, because otherwise the navmesh data might exceed system memory. If you have ten miles of terrain and three towns, you would probably create navmeshes for each town, and then link them together with conventional waypoints that just follow the roads between them.

  • Upvote 1
Link to comment

..im interested to see speed results, on few particular areas..and eventually do some speed comparisons as recast is not a fastest gun out there .. but all in all, its good to have such feature integrated in to system, i just hope as i mentioned before, system will be done in such way that I could have renderer isolated entirely from other stuff, including this pathfinding solution..

Link to comment

Will this be supported with the proposed streaming terrain as well?

 

I think the use of PhysX removes the ability for terrain streaming anyway.

Link to comment

..im interested to see speed results, on few particular areas..and eventually do some speed comparisons as recast is not a fastest gun out there .. but all in all, its good to have such feature integrated in to system, i just hope as i mentioned before, system will be done in such way that I could have renderer isolated entirely from other stuff, including this pathfinding solution..

 

..of which other 'guns' are you aware off?

Link to comment

There are some rather expensive commercial alternatives.

 

The speed doesn't really matter, at some point, because ideally the processing will occur on a separate thread and the engine won't wait for the results.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...