OgreCrowd: a crowd component for Ogre using Recast/Detour

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
User avatar
JJJohan
Gnoblar
Posts: 14
Joined: Tue Nov 11, 2008 1:02 pm
Location: Brisbane, Australia
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by JJJohan »

I've been using this wrapper for a few weeks now and it's been a real blast! It's been quite easy to set up and there's been hardly any issues so far. I've managed to link up bullet physics bodies to stay close behind their respective Detour agents. The only thing I've got to add later are temporary obstacles although I am prioritising other tasks in my project for the time being. I've also written a fairly simply saving/loading utility within the OgreRecast class since the nav mesh data is already provided through a char*. Very cool!
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

JJJohan wrote:I've managed to link up bullet physics bodies to stay close behind their respective Detour agents. The only thing I've got to add later are temporary obstacles although I am prioritising other tasks in my project for the time being.
If you would like to share your results with that I'd be very interesting in seeing them (whether it be a video, code, or a description of your approach in general). I'm very interested in how a physics engine would work together with recast, but have not yet gotten to that stage.

To support physics more (and movable obstacles) I need to add some transformation helper functions to my Obstacle class, so you (or the physics engine) can move them dynamically. But it's pretty straightforward to implement.

Just wondering, what part of the navmesh data are you saving out exactly? The navmesh itself or are you using detourTileCache and saving the compressed tiles?
If you need help or ideas about serialization, have a look at the original demo that comes with recast, it contains a few save/load functions.

Also I'm glad to hear you didn't have much problems using and integrating it. That might just mean that I made a few good decisions in how I structured the demo and the API. ;)
Last edited by duststorm on Thu Jul 05, 2012 2:00 am, edited 2 times in total.
Developer @ MakeHuman.org
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

And here I am again with an update.

I managed to make some progress on terrain navmeshes.
Houses are extra geometry added to the terrain.
Houses are extra geometry added to the terrain.
screenshot07052012_012430760.jpg.jpg (86.68 KiB) Viewed 20518 times
Also temporary obstacles work
Also temporary obstacles work
screenshot07052012_000918500.jpg.jpg (80.59 KiB) Viewed 20518 times
House interiors can be navigated
House interiors can be navigated
screenshot07052012_011441532.jpg.jpg (74.94 KiB) Viewed 20518 times
As you can see, many of the familiar features from the dungeon demo are back in the terrain version. There's temporary obstacles, adding extra geometry like houses (for example, roofs are walkable).
One difference with the dungeon demo is that agents are clipped to terrain height. So it's currently not possible for them to actually walk on roofs or anything (you would probably use collision detection from a real physics engine to deal with this). Also all ray picking in the terrain demo happens purely on the terrain mesh.

To accomplish this update I changed some things in the terrain demo:
- Only part of the navmesh is generated, for now the user can test out how it behaves himself by pointing somewhere on the terrain and pressing N to build a few navmesh tiles in an area around the cursor.
- The cellsize is set many times smaller, resolving the issues with steep edges being walkable and making it possible to add in smaller obstacles (otherwise with the navmesh detail too coarse they will just get overlooked by navmesh generation).
- Due to the smaller celsize, tiles are also much smaller and there are a lot of them. This made my inefficient manualObject debug drawing fail big time as it was suddenly generating about 9000 batches in the scene. I improved this by using staticGeometry to batch all navmesh polygons together, and it is updated every frame if something changed to the navmesh.
For line drawing I couldn't use staticGeometry so I quickly borked together a method where I batch all lines together in a single manualObject, also updated whenever the staticGeometry gets updated.
While I create a single batch, I still keep the original 1000s of manualObjects, so I can regenerate the mesh quickly when only a few tiles change. However this results in the fact that all those unneeded vertices are stored on the GPU ram. Not very clean but at the moment it was the quickest solution.
It works but it's still massively inefficient (contributions or ideas how to improve it without too much hassle are always welcome). But it's only debug drawing after all, disable the debug draw and it's a lot faster. :)

I'm not completely satisfied with the speed of tile building/rebuilding either, it should be possible to do it faster. But it's going in the good direction.
The demo is still pretty manual, allowing you to define where you want to build a navmesh yourself. In a real application you would automatically generate the navmesh in a separate thread, based on the camera position. But it's a good demo to try out the possibilities of the system.

One solution to speedup is pre-generating the navmesh and saving the tiles to disk, so they can be streamed in (much like terrain pages can be read in from files in a paging terrain setup). I will look into adding the necessary serialization functions.
Note that it is also possible to cut out temporary obstacles for houses, instead of adding them to the input geometry and regenerating the affected tiles. This is a lot faster (about as fast as the placing of the other obstacles).

Also I want to add an informative system that keeps track of the memory used for storing all recast data, and probably also profile the build times. I want to show this in the demo hud somewhere to help tweak the performance.


The new controls for this demo are:
H add a house at the cursor position
N Generate or re-generate navmesh tiles in an area around the cursor

Most other controls are identical to the dungeon demo.
The stacking of pallets of the dungeon demo is not included, since it does not make much sense when agents are clipped to terrain height anyway, but houses are actually the same thing as the pallets (walkable geometry added to the original mesh, note how the roofs of the highlander houses are walkable).


Here's a video to show it in action:
Developer @ MakeHuman.org
User avatar
JJJohan
Gnoblar
Posts: 14
Joined: Tue Nov 11, 2008 1:02 pm
Location: Brisbane, Australia
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by JJJohan »

I'll be sure to post what I have when I get the time, however I'm not at my main workstation right now so it'll have to wait for the next post I make, hopefully later today. What I can tell you is I'm saving the unsigned char* navData, which I imagine is the computed data that generates the final mesh (which takes less then a second for me if I load that in from the previous run)

However, there is one issue that I've ran across so far which seems rather odd to me. I have a list of level geometry that correctly calculates walkable spaces, but the actual detour agents refuse to patrol unless I set the cell height to a value around 1.0 or 2.0. The problem with this is, that some of my geometry has certain ceilings, such as walkways and things. It isn't anything complex, but it does have a height limit which is of course higher than the actual agent, yet even with an agent height of 0.001 the navmesh will never go through the walkways.

The problem is, if I set the cell height to something more reasonable, say anything less than 0.5, the paths correctly build through these walkways but the detour agents are refusing to patrol. They will simply walk off to either the origin (0,0,0) in debug and some massive offset in the bottom corner of the map in release. After further inspection it seems I am dealing with an uninitialised variable with the agents when trying to calculate findNearestPoly. It doesn't necessarily seem to be a problem with your wrapper though since it's inside the detour/recast functions themselves.

Screenshot with high cell height: http://i.imgur.com/Avz4n.jpg
Screenshot with low cell height (notice the blue lines going through all kinds of stuff. The blue line connects the physics body to the detour agent which is at (0,0,0): http://i.imgur.com/nx1TV.jpg

Again, I'll probably add information that's actually useful such as some screenshots of what I mean when I get back to my main computer later on.

The terrain mesh navigation looks really cool so far, unfortunately for my project I'm using Unity as a level editor and exporting its terrain as a regular Ogre XML mesh.
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

JJJohan wrote:After further inspection it seems I am dealing with an uninitialised variable with the agents when trying to calculate findNearestPoly. It doesn't necessarily seem to be a problem with your wrapper though since it's inside the detour/recast functions themselves.
The findNearestPointOnNavmesh functions return a bool, which says whether a point on the navmesh was found. If your queried point was too far off it will not find anything. If that return value is false, it means the returned point is unaltered (and thus could be uninitialized).

Maybe there is something wrong with the way you pick destinations (ray query scene intersection perhaps?)
That part of the demo is pretty specific to the demo (since it's not the main purpose), but could be reused if changed somewhat. A safe way to do it is to debug draw your navmesh in the scene (you can hide it) and perform only ray intersections on that. Then you are sure you are picking valid points on the navmesh.

Your cell height indeed needs to be lower than agent height, as the voxel grid is discretized in these units, and geometry can be missed because of too coarse resolution. Part of the performance of recast comes from this discretization, but it means you need to tweak and come to an acceptable tradeoff.
JJJohan wrote:The terrain mesh navigation looks really cool so far, unfortunately for my project I'm using Unity as a level editor and exporting its terrain as a regular Ogre XML mesh.
That shoudln't be a problem. Like the dungeon demo illustrates, it generates navmeshes from Ogre entities just fine ;)
Developer @ MakeHuman.org
ppClarity
Gremlin
Posts: 194
Joined: Sat Sep 02, 2006 12:27 am
x 2

Re: DetourCrowd and Recast in Ogre demo (update)

Post by ppClarity »

How omniscient are the agents?

Let's say I give them a goal where the shortest path takes them through a doorway. If the door is shut and locked (becomes impassable) do the agents sense this even though the door is not within their line of sight and replan or select the open path or do they travel to the locked door first and then replan?

Thanks.
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

ppClarity wrote:How omniscient are the agents?
I believe if the door in the distance closes the agents will notice this after a short while, and immediately replan a different route if there is one available.
I have not experimented with it on such a scale, but one of my videos shows how they can react adaptively to a changing environment.

You do have a point that it is not completely realistic that agents know from miles away that a door is closed and will replan their path too early. This might be solved either by making pathplanning more localized (which will also reduce computing power) or by imposing higher level AI behaviour on top of detour, that just assigns waypoints to sub goals.
Striking this balance between local planning and global pathfinding is hard, as with local planning you can become stuck in local optima, but global planning is expensive and can sometimes look unrealistic (as agents have more knowledge about the world than they are able to see).
Developer @ MakeHuman.org
ppClarity
Gremlin
Posts: 194
Joined: Sat Sep 02, 2006 12:27 am
x 2

Re: DetourCrowd and Recast in Ogre demo (update)

Post by ppClarity »

Yeah. For more natural behavior it sounds like I'd need to keep an "assumptive" map in addition to the current state. To be perverse, one could argue that if an agent found the door locked a certain number of tries it should weight that route lower during initial selection :lol:
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: DetourCrowd and Recast in Ogre demo (update)

Post by Zonder »

ppClarity wrote:Yeah. For more natural behavior it sounds like I'd need to keep an "assumptive" map in addition to the current state. To be perverse, one could argue that if an agent found the door locked a certain number of tries it should weight that route lower during initial selection :lol:
it could trigger logic to try and find the key :)
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

I guess these scenarios are just not that common in today's games, which is why it hasn't gotten that much attention.
It's pretty rare for AI characters to follow long non-trivial paths, that's mostly up to the player.
In most scenarios AI characters only wander around in a very local area, and often they even disappear when the camera gets too far off (like crowds in city roaming games such as GTA or Assassin's Creed).

If you're doing a project where you really need intelligently and realistically navigating NPCs, I guess you will have a lot of high-level AI behaviour to work out.
Another possible approach could be embedding more specific information in your navmeshes. Things like jump links, cover areas, points of interest, traffic flow controls, ...
Developer @ MakeHuman.org
ppClarity
Gremlin
Posts: 194
Joined: Sat Sep 02, 2006 12:27 am
x 2

Re: DetourCrowd and Recast in Ogre demo (update)

Post by ppClarity »

duststorm wrote:I guess these scenarios are just not that common in today's games, ...
Sure generic crowds just need to provide "flow" and can spawn and despawn as needed. But for task level NPC's like a guard with a defined patrol route or a shopkeeper going home at night it's something that needs a bit of thought.

One of the things that really irritated me about GTA: Vice City was that in player vs. AI race and chase situations if you outdistanced or fell too far behind the AI the AI would perfectly dodge obstacles and perfectly adhere to the limits of their physics engine (avoiding unintentional slides). If the player can cause the path to get blocked it would suck if the AI knew about it in time to pick an alternate path that was clear without "eyes on" by itself or an ally that can communicate with it. *
Another possible approach could be embedding more specific information in your navmeshes. Things like jump links, cover areas, points of interest, traffic flow controls, ...
Yep.

* I never felt so vindicated hacking a game when I modded Hilary's vehicle to work like the ice cream truck. :lol:

edit: fixed game title
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

ppClarity wrote:Sure generic crowds just need to provide "flow" and can spawn and despawn as needed. But for task level NPC's like a guard with a defined patrol route or a shopkeeper going home at night it's something that needs a bit of thought.
Quite right, and I've been thinking about this scenario too.
But I wonder whether you would do this kind of off-screen navigating using the full navmesh and obstacle avoidance, or rather keep track of at what times an npc should be at what place.
Of course the problem with that is what you mentioned about GTA, the AI having a perfect route to destination, since it doesn't have to bother with actual steering.

It does, however, help scale your application. I wouldn't really consider having more than 200 detour agents running at one time, so for large world applications this means that you will only have navigating agents for characters that are actually in view.
Developer @ MakeHuman.org
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: DetourCrowd and Recast in Ogre demo (update)

Post by Zonder »

I would give guards a way point system still and use this to avoid obstacles. And like you say the position in the way point system could be calculated based on time when part of there way point path comes into view.
EDIT:

Oblivion had navigation across the world for NPC's but I think way points were used for the complete path with localised detor when the NPC was in view
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

Zonder wrote:Oblivion had navigation across the world for NPC's but I think way points were used for the complete path with localised detor when the NPC was in view
I believe so too. I'm interested in knowing, though, whether they made those waypoints manually or whether they extracted them from the navmesh.

I think detour is currently missing the higher hierarchy feature, which would also help making non-local path plans. Once a path goes of the currently loaded navmesh it should end up on a more coarse network of waypoints that stores how all navmesh tiles of the world are related and from which tile one can walk to the next.
A path plan will then look like: leave the current navmesh tile with this path, then traverse these tiles in order. In the same way as oblivion did it would be possible to deduce at which navmesh tile a character currently is using time and the coarse waypoint grid.
Developer @ MakeHuman.org
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: DetourCrowd and Recast in Ogre demo (update)

Post by Zonder »

yeah would be interesting to know exactly how they did it.
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

A smaller update this time. I took the time to catch up on my documentation, and documented almost all new methods that didn't get proper documentation yet. All documentation is in the header files, I haven't tested yet whether it properly exports using doxygen, though. For those exploring the demo sourcecode, you will notice that there are plenty of comments that useful remarks to get you started, too. (which sometimes makes the code a little messier, but as long as it's useful...)

I also want to refer to an interesting reflection I made in another thread about manually editing navmeshes and, more specifically, whether it would be possible to manually edit detourTileCache generated navmeshes (allowing you to manually edit a navmesh and still have dynamic temporary obstacles at runtime).
Developer @ MakeHuman.org
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

ppClarity wrote:How omniscient are the agents?
Have a look at this post on the recast creator's blog
The agents in the Ogre recast demo exhibit the exact same behaviour as I'm using the latest recast trunk version. And I'm keeping it up to date with any new changes.


Another update:
I had a go at compiling the demo with msvc, and managed to do a few minor modifications to suppress the compiler errors.
Now the source is updated so it also compiles with vc++ out of the box, and I added the msvc solution I used (based on the appwizard).

I'm also happy to announce that I made a downloadable windows binary package (about 27MB in size). It's compiled with Ogre 1.7.3, as that is the SDK I still had setup on my windows installation (I don't boot to windows very often ;)). Now you can quickly try it on windows without the hassle of compiling it yourself ;).
Developer @ MakeHuman.org
User avatar
Xplodwild
Goblin
Posts: 231
Joined: Thu Feb 12, 2009 3:49 pm
Location: France
x 13
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by Xplodwild »

Hi,
Your ZIP seems faulty, I downloaded it twice, it is properly downloaded, but half of the files won't extract :/
User avatar
Mind Calamity
Ogre Magi
Posts: 1255
Joined: Sat Dec 25, 2010 2:55 pm
Location: Macedonia
x 81

Re: DetourCrowd and Recast in Ogre demo (update)

Post by Mind Calamity »

Xplodwild wrote:Hi,
Your ZIP seems faulty, I downloaded it twice, it is properly downloaded, but half of the files won't extract :/

Use 7ZIP. This is a problem that I've seen before... WinRAR doesn't seem to understand 7Zip's compression.
BitBucket username changed to iboshkov (from MindCalamity)
Do you need help? What have you tried?
- xavier
---------------------
HkOgre - a Havok Integration for OGRE | Simple SSAO | My Blog | My YouTube | My DeviantArt
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

Mind Calamity wrote:Use 7ZIP. This is a problem that I've seen before...
Ha... you're correct, I've used 7zip to create it. Good to know that it's not compatible.
I'll create a new zip and upload it, that should work.
Developer @ MakeHuman.org
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by jacmoe »

Why, it is.
7zip is totally compatible.

It is WinRAR which is utter crap.

Anyone using it should be kicked in the arse, IMO.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

Good to know ;)

Well I've created a new zip file on my linux system and I'm uploading it now. I hope everyone will be able to open it now...
Edit: it's uploaded, it's the same link.
Developer @ MakeHuman.org
Yati
Greenskin
Posts: 115
Joined: Thu Jun 09, 2011 5:41 am
Location: Melbourne, Australia
x 5

Re: DetourCrowd and Recast in Ogre demo (update)

Post by Yati »

Hi,

I trying using a terrain of world-size 513 instead 12000.
The problem is the nav-mesh is not made then.

I tried scaling the values of OgreRecastConfigParams down by 513/12000 but that resulted in the tile cache failing to initialize. The params were invalid.

When I change the terrain world-size to 12000 and leave the OgreRecastConfigParams as they were it all works fine.
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

Yati wrote:I trying using a terrain of world-size 513 instead 12000.
The problem is the nav-mesh is not made then.
Try modifying the terrain offset parameters in InputGeom (the constructor with terrainGroup). It's hardcoded to 6000 at the moment, and I think that is your issue.
I still need to make it work with arbitrary terrain setups, it's a TODO that I sidestepped for the time being (but it's a good reminder, it's an important thing to fix).
You can verify whether the inputGeom corresponds to the geometry in your scene by uncommenting the mGeom->debugDraw() call in createScene. It draws the vertices of the inputGeom as points, you should move the camera under the terrain to be able to view them. They should match the terrain. I know I should modify that to draw triangles, but it was just a very quickly done debug test.

I don't think you should change any of the recast parameters. Those should only be changed when the agent size is changed.
The only things you could tweak are the error correction and min area size settings, and the detourTileCache tile size.
Developer @ MakeHuman.org
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: DetourCrowd and Recast in Ogre demo (update)

Post by duststorm »

Update:

Thanks to your request I looked into different terrain generation parameters, yati. Thanks for that, it was a good thing to explore those ;)
The inputGeom now retrieves the correct terrain tile offset in a generic way, so it should work now.
I also added config parameters to the terrain demo where you can play with different terrain parameters. Those parameters can be set from the
config file, have a look at OgreRecast.cfg for explanations.

Currently the config file is set to the original values used in the demo from before, here is a suggestion of an alternative config you can try out:

Code: Select all

	Terrain Tiles X=2
	Terrain Tiles Z=2
	Terrain Tile Size=512
	Terrain Height Scale=3
I noticed that it works a lot better with smaller tile sizes, it's a lot faster, even if the polygon count of the terrain goes up.
This shows that recast can easily handle multiple millions of polygons for building a navmesh from. The main thing that makes it slow is too high world sizes or too many cells (or the relationship worldSize/cellsize).
The number of navmesh cells is the ultimate factor that determines how fast navmesh generation is.
DetourTileCache tileSize influences how long it takes to rebuild an individual tile (the smaller the tile the faster it goes, but too small tiles have a negative influence on the aggregate performance of generating a lot of tiles at once).

This means there is a limit on the worldsize (the total size of multiple tiles in world coordinates) you feed to detourTileCache, more specifically worldSize/cellSize has an upper bound, determined by the available memory. But for performance reasons it's probably also better to stay well under it. This means that if you increase the number of terrain tiles, you need to reduce the terrain tile size (note that you don't need to change the tile resolution, I have not yet met polycount limitations with recast, it's really fast).
As a result a solution that scales to a massive world with streaming of terrain will have to reuse an allocated tilecache and transform the world coordinates to coordinates local to the tilecache. The same transform will have to be done with navmesh and agent positions afterwards.

One other very obvious thing I need to improve is retrieving only the part of the terrain polygons to inputGeom that I need when building or rebuilding navmesh tiles. You can notice that it really takes a long time by placing houses (where tiles are rebuilt from new inputGeom), if you compare it to temporary obstacles which happens almost instantaneously (only the time needed to mark a convex polygon and recreate the compressed tile in the cache), and even convex obstacles are still implemented horribly inefficient (compared to cylindrical ones). The code for faster convex obstacles is already available, I'm just waiting till it gets committed to the official recast trunk instead of modifying recast myself (I'd like to keep it as unchanged as possible for easy integration of future updates).

When testing with different height scales and terrain tile sizes I noticed that the bounding box of the input geom sometimes appears to cut off part of the bottom of the geometry:
Skirts leave the inputGeom bounding box, but not the terrain geometry itself
Skirts leave the inputGeom bounding box, but not the terrain geometry itself
screenshot_bounding_box_skirts.jpg (116.52 KiB) Viewed 20230 times
But this appears to be a non-issue, as it is only the terrain skirts (that are useless and not fed to recast anyway) that stick out of the bounding box.

Some other screenshots:
Navmesh in a canyon
Navmesh in a canyon
screenshot_canyon.jpg (181.61 KiB) Viewed 20230 times
Mountain climbing by finding a walkable route along less steep mountain slopes.
Mountain climbing by finding a walkable route along less steep mountain slopes.
screenshot_mountain_climbing.jpg (153.13 KiB) Viewed 20230 times
I've drawn over some of the lines with a thicker brush to make them more visible, especially after scaling the images.
The black lines are the edges of the navmesh, red is the path followed by the agent. Note that sometimes navmesh polygons dissappear under the terrain because of simplification. This makes it harder to see where a navmesh actually stops and where it is simply hidden under the terrain.
Last edited by duststorm on Mon Jul 09, 2012 2:43 pm, edited 1 time in total.
Developer @ MakeHuman.org
Post Reply