faramir118

Take a look at these: http://img692.imageshack.us/img692/4753/variabledepth.png http://img130.imageshack.us/img130/5977/variabledepth2.png I'm not happy with how many polygons it creates though. I'lll have to play around with it... but at least I started using my brain edit: Here's a better example.

Can't push repo yet, here's a patch

Hm, just had an idea that might make this all much simpler: Instead of 'water', I can use 'shallow water', 'water', and 'deep water' or something. That way the navmesh is more flexible. After all, I have 16 possible terrain types to work with. The only ones I currently use are: * ground * water (includes 'water' and 'ocean') * lava * slime * dark water (not sure what this exactly means) * unspecified liquid (a height is specified in the client data, but not a type)

Wasn't getting the answers I expected, so I'll give you guys more information to work with: Here is what is produced by the current revision on github (just something to compare with): Current navmesh picture Here is the same map, but with liquid included: Liquid picutre As you can see, the surface of the water (blue area) becomes a part of the navmesh. Here is the reason I asked the question about walkable depth * the water navmesh must be lower than the surface of the water in order for creatures to swim in the water instead of walk on top of water I have ideas on how to handle in mangos core, so it isn't a huge concern * there is water that is shallow enough to walk through, but it hides the ground underneath - as far as the navmesh is concerned, creatures that cannot swim can only get to the water and as a result can't pass through the water. This can only be done at build time, so whatever height we pick will be used by every creature in the game no matter how tall or short they are Lowered liquid picture As you can see, I lowered the level of the liquid (by 1 yard in this example), thus exposing more of the ground. This allows all creatures to 'walk' across that 'ground' - even if they are so short that they are actually swimming through water. In some cases, this may cause conflicts with other parts of mangos core - my pathfinding may determine that a location is solid ground, while the core may determine that the same location is underwater. It's a complicated concept, and I don't feel like I'm expressing it very well. In any case, there are still some issues that I have to work on. You may notice in the picture all of the tiny black dots where the water meets the ground - these are gaps in the terrain mesh, which create holes in the navmesh. It messes up pathfinding from one surface type to the other. edit: here is some lava

Hmm, I'll try to fix that. My local repo conflicts with github, so it may be a bit before I push a change. Sort of offtopic rambling: I don't understand why it's happening - the string should never be longer than 16 characters long, and I allocated space for 18. Someone else (vladex maybe? I don't remember) had reported a similar issue with the old mmap generator on tiles with the number 00. Perhaps it's related to x64... That warning dialog you posted only appears when you compile for Debug, which adds a lot of overhead and really slows down execution. If you compile for Release, the maps get extracted a lot faster!

I was planning on using the shortest creature as a standard, but I thought about it again and I should be doing something taller than that. Otherwise water may end up being a barrier to tall creatures that can't swim, even if the water is shallow enough to wade through. Probably a tauren-sized monster, or a small ogre? I don't know about any existing flags, that's why I asked! I'm learning all of this as I go

1: If you experience a crash with the generator please include the following information: * The map # * The tile # * The last message printed in the console before the crash * The settings you used 2: I've made progress with liquids. A bit more work to do, but I need some information: * What is the maximum water depth I should allow creatures to walk through? Keep in mind some creatures are shorter than others - gnomes have to swim in water that other creatures can stand in. * Are there any creatures that should be allowed to swim through non-water (lava, slime, ocean, dark water) liquids? I can save some processing time and disk space if we can toss out certain data types. Also, after that last feature addition I had a ton of bugs. I want to try and make this a smoother experience than the last one. It takes a lot of time to build the maps, and I don't want to compound that with bugs that make you start over all the time.

Do you have any examples of parallel pathfinding algorithms? I've had a hard time finding implementations.

Try the last commit. If it doesn't work, send me a pm and I'll walk you through how to run the visual studio debugger with it.

I commented them out and pushed it to github, along with some other stuff

The ASSERT fix Vladimir pushed doesn't work on windows unless HAVE_CONFIG_H is defined, and that probably has unwanted side effects.

Not for windows

removeVertex crash should be fixed, unless there's a tile out there with A LOT of model data.

Search for ASSERT in MapTree.cpp and comment the lines out. I noticed that on some maps while I was testing hiResHeightmaps true, but I wasn't able to figure out what was causing it. I'll invest more time in it soon.

Fixed, dunno why it affected only some maps.

Lastest change, feels good to have it out of the way. Example is the cave leading to the exit of instance 269 - CoT Dark Portal Before: http://img9.imageshack.us/i/outsidec.png/ After: http://img824.imageshack.us/i/outside2.png/ If you want to take advantage of this change, you must recompile both contrib/extractor and contrib/mmap, and run them both.

"invalid start or end polygon" can happen under normal circumstances If a player is airborne, such as from a knockback effect or jumping off of a cliff, he may go too far from the navmesh. This makes the end polygon invalid, and thus no path can be generated. I have some ideas on how to deal with this. In the mean time, try to reproduce it to verify that the failure is a problem with the navmesh, and not with my core implementation (which I'll improve later) Only way to do this is to go to the creature with the GUID that produced the error and try to make it happen again (make sure you stay on the ground). edit: There is indeed a problem with Zul'Gurub. It's now on my list of things to fix. Question about pet behavior - if you jump off of a cliff, should they follow using pathfinding or should they go over the cliff with you?

Ok, that tile-connection problem is fixed. Go ahead and generate mmaps now (if you want, not mandatory if you already have working mmaps). I think I might work on map liquid next.

Ok, those shenanigans are fixed. But I realized that there is a problem with doing load-per-tile... the tiles heightmaps can't get sewn back together. Need to load adjacent tiles' heightmaps (maybe only partially load) so that the tiles are in contact with each other as they're built. Generating mmaps will be a waste of time till I fix this. Sorry for the inconvenience.

Sorry about that, another wow -> recast coord conversion problem. Works now. edit: you should still see the 'no vertices' warning on some instances. their model doesn't extend to all tiles, but we're still building correctly. edit2: nevermind, I fixed the broken ones and broke the working ones.

No, you won't need to rebuild the mmaps. Only need to do this in a few situations: * Map data changes (client patch) * structure of navMesh changes (recast update) - you will get an error on mangos console if this happens * someone complains about a broken section of navmesh, like monsters not fitting through a door my current commit has this issue, need tweaks to make it not happen (for example, on map 34 some doorways are blocked)

Pushed big changes, read the commit note. I will pull Lynx's vmap_rewrite updates in a while, just want to make sure mine work before adding more on top of it. I added some linux code for getDirContents, but I don't know if it works. I don't even know if it returns relative or absolute paths.

need to switch paths to forward slashes There's probably more, let me know what it fails on

try https://gist.github.com/433300/cc256e3a793530094fbd3f1a7b07dffd8e263d76 InputGeom and MeshLoaderObj are for RecastDemo, I should probably move them into the Debug directory. If that compiles, it still won't work. Need some code changes to make linux happy

Well, I tried without the chunky mesh and loading 1 vmap tile at a time, and it doesn't bound the model data - ended up with a lot of very large mmtiles, even though it was just the models for 1 tile. There's no built in method other than rcGetChunksInRect to exclude the non-overlapping parts, so I'll use the chunky mesh. Eventually the difference between [vmap loading/unloading overhead] vs [efficiency of intersecting heightmap and model data] will matter. But for now it's not that big of a deal, because the latter isn't happening for a while.