Development Blog

On the first example, it makes sense to me that it didn't go straight down because it won't enter segmented tiles (it considers them walls). Because you had a dark green and a light green segmented tile "blocking the path" (I get that that wasn't the intent), it considered that a full wall and so it went around. It went straight exactly until you hit (or crossed) one of the green tiles. This also relates to most (but not all) of your corner issues. It simply won't enter segmented tiles so it goes around them. Though starting around the 2:20 mark it snagged the corners on normal tiles that it really shouldn't have.

Yep, that's what it looked like when I went back and watched it. Some polys in segmented tiles seem to be invalid.

I don't see any of this behaviour in EKI One which is using Recast, so I'm guessing its just an issue with understanding at this point. You'll get there! Interestingly, why is the nav mesh seemingly being generated as a uniform grid type system of tiles and not optimized. There are huge area there where tiles could be represented by a much larger polygonal area.

 

This is the type of optimized nav mesh generation I am used to seeing with Recast, also shows off the dynamic regeneration quite nicely (you might want to take a look at this Naughty Alien):

Josh, if it was a simulation of me shopping in a hardware store it would be spot-on.

The reason it uses tiles is so that if a single tile changes, you can recalculate only that data, instead of the whole map.

I'd be mostly curious of seeing some API commands. i.e. generating the nav. mesh from a scene, generating a Path, updating a Controller along a Path, etc.

There's basically no API to worry about. You just have a command to find a path, and don't have to worry about anything else. As far as controller movement goes, I think I'll just leave that to the user, and have some example scripts. It's very easy to just point it to the next node and go.

Will it possible to 'weight' sectors?