Jump to content

MMaps Redux


Guest auntieMangos

Recommended Posts

  • Replies 1.2k
  • Created
  • Last Reply

Top Posters In This Topic

Ok, I updated it.

There's one caveat - I broke the generator's *nix build in order to do some major code changes.

I did a rebase, so you *nix users will still be able to pull from my branch and then reset to commit fafeb6ba05becea36f472e71cb8f65da2b5ea313 'makefile typo fixes' - you get most recent mangos.

I would appreciate someone's help with creating working automake files. Just send me a pm

Link to comment
Share on other sites

i have looked at ModelContainerView::generateHeightMap

and got some questins:

why need to load(and process) nearby maps

for (int x1 = x-1; x1 <= x+1; ++x1)

{

for (int y1 = y-1; y1 <= y+1; ++y1)

also this methtod creates a new 2 polygons each two(!) yards

this is a crazy amount of polys

ofcourse my understanding of this can be wrong, i have started look at the code only now

Link to comment
Share on other sites

why need to load(and process) nearby maps

Derex's initial implementation did this because some WMOs get split on tile edges. I didn't read his code to find out why this was important.

For Recast, the best way to do it would be to load ALL .map and .vmap tiles from a map into memory at once, then process them with Recast to generate a tiled navmesh.

Tiled navmesh will allow us to have complete pathing information for a map, whereas right now each tile is self-contained and can't generate a path to another tile.

also this methtod creates a new 2 polygons each two(!) yards

Yes, and if I'm not correct it creates 2 polygons because some triangles were the wrong way, and the result was meshes that didn't have a surface on the outside

this is a crazy amount of polys

It is a lot of polys, but that is an intermediate step. The final data we are after doesn't (shouldn't?) contain all of those polys.

Recast/Detour data is broken into two discreet parts:

The Detail mesh stores all geometry data.

The Nav mesh stores only important vertices for turning around corners, going up and down inclined surfaces, etc.

We only care about the Nav mesh - the rest of the data we already have in .map and .vmap files. I have been meaning to figure out how to save ONLY the Nav mesh, but at this point I'm not 100% positive that we can throw out the Detail mesh at all. If it also contains data that the navmesh needs to function, then I'll be very very sad.

And I apologize for not keeping up with this project. vmap_rewrite seems to be stable now, and it works on windows. At this point I am debating whether I should merge vmap_rewrite and mmaps. I don't want to make the tiled navmesh generator work now, and then have to rewrite it later for vmap_rewrite. What do you all think?

Link to comment
Share on other sites

I don't want to make the tiled navmesh generator work now, and then have to rewrite it later for vmap_rewrite. What do you all think?

get the vmap rewrite ready for mangos/master and get it commited there, then you don't have to bother about it anymore and can work on mmap ;)

btw, nice work (i only read your thread, didn't try it myself, sorry :/).

Link to comment
Share on other sites

Is it possible to convert the mmaps system for mangos-0.12?
i guess it's not of any use to do this right now. when mmaps is done and ready for master i'm sure, that it'll be possible to backport it. doing the backport now will only cause much work which will have to be done twice.
Link to comment
Share on other sites

mmap not created:

Now reading D:\\Games\\1\\of\\vmap_extract_assembler_bin/vmaps/000_25_32.vmap

Now reading D:\\Games\\1\\of\\vmap_extract_assembler_bin/vmaps/000_26_32.vmap

Size: 537 x 538

Found 0 starting point(s)

Link to comment
Share on other sites

I have done some tests and was really surprised:

i have used two types of input meshes to generate the navigaton data:

first mesh contained vertices that can be shared among nearby triangles

second mesh - vertices with same coordinates can be found many times, 3 new vertices per each triangle

Mesh with no shared vertices (second type):

Loaded tile for map: 33 [32][27]

396246 verts 132082 triangles

Process Tile for map: 33 [32][27]

NavMesh generated in 0 minutes 21 seconds

Mesh with unique and shared vertices (first type):

Loaded tile for map: 33 [32][27]

79172 verts 132082 triangles

Process Tile for map: 33 [32][27]

NavMesh generated in 1 minutes 20 seconds

looks like logic "less vertices - better performance" doesn't works for recast generator or doesn't works at all..

Link to comment
Share on other sites

From what i understand, recast does not care at all if polygons are connected or not, it voxelizes every polygon that comes in right away.

No idea how you created that second mesh, does the time include finding vertices with identical coordinates?

Link to comment
Share on other sites

I have some changes to make before I upload the code.

  • * No VC90 or linux build yet, so... Once again requesting a linux guru's help!
    * Many maps have models above or below the terrain. I believe I have the answer to it
    * Not actually building navmesh yet... just obj file for RecastDemo

And a more general todo:

  • * implement liquids (heightmap, maybe vmap)
    * implement low-res heightmap

Pictures here:

http://img195.imageshack.us/gal.php?g=bgav1.png

bgav2.png is the important one - shows that tiled navmesh works!

Link to comment
Share on other sites

i am not sure if this is the correct thread to ask about it, but looks close to me, so if i am wrong please feel free to let me know *lol*

is there a new ad.exe in the works for 400? we have an alpha on HSC but wanted to know if someone has made progress with it or not..

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use