MMaps Redux

[DuB]

hello faramir118

tested your mmaps, works nice

still got a question

should I deactivate vmaps or is it still ok with mmaps?

[Auntie Mangos]

should I deactivate vmaps or is it still ok with mmaps?

vmaps are used for different purpose than mmaps. One is the height maps, while the others are for movement. You use both at once.

[qsa]

Haven't done the math (too lazy) but I don't think it 16x16 is too much for 64bit refs. However, it does create some stupid detours (that visibility optimization trick would fix it)

(max map tiles)*(our sub tiles) = (64x64)x(16x16) = 2^20 maximal number of tiles possible on single map. With 64 bit polyRef, we can afford it with no problem. So it wont create us any issues.

The only thing worries me is, us, losing really nice optimization we have, not have to generate paths while destination on same polygon as we are. So, small polygons -> less chances for this to happen -> more calculations. But I guess its a price we have to pay.

In 2x2, 8x8, 32x32, all of the tiles are unconnected. I think it's a float precision problem....

It is, GRID_SIZE = 533.33 dividing it by those portions will result in X.666, rounding to X+1, while dividing by 4, 16 will be X.333 rounded to X. There is multiple parts in code where mathematical conversion is used and not ceil/casting float to int. Actually, this is not consistent use, sometimes its round, sometimes its ceil/cast. May need some checking.

Which brings me to next suggestion, using TILES_PER_MMTILE = 13. This value chosen for 3 reasons:

1) it minimize the precision error in this range.

2) it is in 16x16 range - which seems to give nice results.

3) it is slightly bigger tiles, better optimization.

* we don't really have to worry about not using power of 2. The only thing it will change, is us, having less tiles but using same amount of bits to hold them in polyRef. But since we are not in shortage, its fine.

I think I'll push that patch for 64bit polyRef, from post #683.

Push this one and the one for core, to save/load multiple tiles in same file.

Then we'll have something that can be tested + fine-tuned.

[faramir118]

13x13 doesn't work either

Why did they have to pick a number that can't be represented in base 2?

Going to play around with the calculations a bit to see if I can make it work more reliably.

edit: fractions work much better, and this seems to work with any number of subtiles

#define TILE_SIZE (16 * 100) / (3 * TILES_PER_MMTILE)

However, rounding/truncation creates a small gap between mmtiles. This can be minimized by using a multiple of 3.

edit2: findNearestPoly fails if you're in the aforementioned gap... back to the drawing board.

[qsa]

13x13 doesn't work either

Same it doesn't, it looked logical.

Worst case, 16x16 can be used, if nothing better works/found.

[DuB]

I tested mmaps with playerbots, it seems like the playerbots dont use pathfinding system

If I play alone creatures, pathfinding witout to fly in the air and so on, but then I add them and it seems like i didnt use mmaps

have someone a hint for me to solve this problem?

[Unkle Nuke]

That would have more to do with how Playerbot implements the other characters on your account as bots and handles their behavior.

Best to direct this question at blueboy over in the Playerbot thread.

[DuB]

ok i wasnt sure where this belongs to, thanks

[Thyros]

why is this only for instances and not for maps Azeroth etc?

[Konctantin]

use the run with arguments

MoveMapGen.exe 0
MoveMapGen.exe 1
MoveMapGen.exe 530
MoveMapGen.exe 571

[faramir118]

Pushed changes to the mmtile file format. Requires all maps to be extracted.

• 16x16 dtTiles per mmtile.
  Fixes some detours caused by crappy tessellation
  There will be some new detours as a result, due to A* heuristic... tons better than before though. And we can probably compensate with some of the optimizations from Mikko (visibility stuff from CrowdManager.cpp).
  
• the generator now skips tiles which have the proper format and version information
  If you want to rebuild a tile, you should use the --tile parameter or delete the corresponding mmtile file.
  

There are some TODO items related to this push:

• adding debug/error logging to mmap load/unload
  
• review mmtile load/unload
  There is potential for leaks: when tiles don't unload correctly, their data will linger in memory after a grid has been unloaded by TerrainInfo
  
• Larger padding border, will make tile connections better in some places
  

Also, merged with [10793] and fixed conflicts and broken generator build files.

[qsa]

Looks lovely, thanks - I'll check it out as soon as I have time.

And we can probably compensate with some of the optimizations from Mikko (visibility stuff from CrowdManager.cpp).

Can you point to something we haven't discussed before? I couldn't find anything we can use, which we haven't yet.

unrelated: I made few tests playing with agent size to see the real ingame impact, and I ahve to say, that having it around 0.5 makes wonders on creatures scratching corners.

We defiantly should use it as default.

About bigger models, we we already spoke about having multiple meshes. But for now, 0.5 will work just lovely.

[blueboy]

Hi,

I'm afraid the latest code does not compile on *nix sytems. I'm getting the following errors

I'm running OpenSuse 11.3 gcc 4.5-4.2 MaNGOS[10797]

CXX MoveMap.o

In file included from ../../../src/game/MoveMap.cpp:19:0:

../../../src/game/MoveMap.h: In function void dtCustomFree(void*):

../../../src/game/MoveMap.h:34:15: warning: deleting ˜void* is undefined

../../../src/game/MoveMap.h: At global scope:

../../../src/game/MoveMap.h:44:5: error: uint32 does not name a type

../../../src/game/MoveMap.h:45:5: error: uint32 does not name a type

../../../src/game/MoveMap.h:46:5: error: uint32 does not name a type

../../../src/game/MoveMap.h:47:5: error: uint32 does not name a type

../../../src/game/MoveMap.h:58:10: error: extra qualification MmapTileReader:: on member check

../../../src/game/MoveMap.h:59:53: error: uint32 has not been declared

../../../src/game/MoveMap.h:59:10: error: extra qualification MmapTileReader:: on member read

../../../src/game/MoveMap.h:62:5: error: FILE does not name a type

../../../src/game/MoveMap.h:64:5: error: uint32 does not name a type

../../../src/game/MoveMap.cpp: In member function void TerrainInfo::LoadNavMesh(int, int):

../../../src/game/MoveMap.cpp:78:40: error: no matching function for call to MmapTileReader::read(unsigned char*&, uint32&)

../../../src/game/MoveMap.h:59:10: note: candidate is: bool MmapTileReader::read(unsigned char*&, int&)

../../../src/game/MoveMap.cpp: In constructor MmapTileReader::MmapTileReader(char*):

../../../src/game/MoveMap.cpp:195:7: error: class MmapTileReader does not have any field named m_mmapTileFile

../../../src/game/MoveMap.cpp:195:29: error: class MmapTileReader does not have any field named m_currentTile

../../../src/game/MoveMap.cpp:197:5: error: m_mmapTileFile was not declared in this scope

../../../src/game/MoveMap.cpp: In destructor MmapTileReader::~MmapTileReader():

../../../src/game/MoveMap.cpp:211:9: error: m_mmapTileFile was not declared in this scope

../../../src/game/MoveMap.cpp: In member function bool MmapTileReader::check():

../../../src/game/MoveMap.cpp:218:10: error: m_mmapTileFile was not declared in this scope

../../../src/game/MoveMap.cpp:221:18: error: struct mmapTileHeader has no member named mmapMagic

../../../src/game/MoveMap.cpp:224:18: error: struct mmapTileHeader has no member named dtVersion

../../../src/game/MoveMap.cpp:227:18: error: struct mmapTileHeader has no member named tileCount

../../../src/game/MoveMap.cpp: At global scope:

../../../src/game/MoveMap.cpp:233:6: error: prototype for bool MmapTileReader::read(unsigned char*&, uint32&) does not match any in class MmapTileReader

../../../src/game/MoveMap.h:59:10: error: candidate is: bool MmapTileReader::read(unsigned char*&, int&)

I thought you should know

Cheers

[Skirnir]

Finished uploading maps, vmaps, mmaps ... gee what a session

Patch extracted, hundreds of trailing whitespace errors had to be fixed, libmpq was double didn't want it that way ... took some time.

Waiting half a day, going online a minute ... seeing it was worth doing so. Attacked a guard in undercity and watched them follow me down to the lowest floor. Just one word: Awesome!

Extracted all 4 continents and instances with --hiRes... true. Debian x64, now I'll continue testing

Regards

Skirnir

PS: The only warnings I got: http://paste2.org/p/1118051 . Revision was faramir118s gcc fix.

[blueboy]

Hi,

I just wanted to to thank all the mmap team for their hard work and rapid response to issues posted.

I can confirm, that the revised code now compiles without any errors or warnings on *nix

Thanks again

[scargo]

Great, pets gently follow hunters , no more, as far as i can see, "long triangles" just remain bridges like in darkcloud pinnacle and turning stairs like in shadowfang

Compiles and extract on win7 x64 used --hires with all maps

Again, great work

tnx

Edit: i'm not sure if it is related to mmaps, but on terrain like scaldig pool mobs fall under the map a little when aggroed

[faramir118]

hundreds of trailing whitespace errors had to be fixed

Mikko didn't want my whitespace patch... apparently Xcode will just mess everything up again. If you have a script or something he can run before each commit to clean whitespace, great!

libmpq was double didn't want it that way

Can't believe that went unnoticed for so long

on terrain like scaldig pool mobs fall under the map a little when aggroed

Can you give me mapid and xyz coordinates?

[Skirnir]

If you have a script or something he can run before each commit to clean whitespace, great!

Something like this should work:

https://gist.github.com/722672

Maybe it could be more sexy, but it's late and I'm not creative enough and haven't used sed enough My test showed it works, but who knows

Regards

Skirnir

[Schmoozerd]

cd .git/hooks

mv pre-commit.sample pre-commit

and your whitespace errors are reported before commiting

further information:

http://www.kernel.org/pub/software/scm/git/docs/githooks.html

[faramir118]

Mikko uses SVN on google code

We could correct the whitespace in git, but future merges with recast SVN would be more trouble.

[scargo]

Can you give me mapid and xyz coordinates?

Map 571, x 4264, y 5076, z 14. Around there

[Skirnir]

Just to show what the above posted script creates:

https://github.com/SkirnirMaNGOS/Detour/commits/

Regards

Skirnir

[Despo]

  CXX    MoveMap.o
In file included from ../../../src/game/MoveMap.cpp:19:
../../../src/game/MoveMap.h:53: error: expected initializer before '<' token
../../../src/game/MoveMap.cpp: In member function 'void TerrainInfo::LoadNavMesh(int, int)':
../../../src/game/MoveMap.cpp:77: error: 'tileRefList' was not declared in this scope
../../../src/game/MoveMap.cpp:77: error: 'newTiles' was not declared in this scope
../../../src/game/MoveMap.cpp:77: error: expected type-specifier before 'tileRefList'
../../../src/game/MoveMap.cpp:77: error: expected ';' before 'tileRefList'
../../../src/game/MoveMap.cpp:98: error: 'tileRefList' cannot appear in a constant-expression
../../../src/game/MoveMap.cpp:98: error: template argument 2 is invalid
../../../src/game/MoveMap.cpp:107: error: 'tileRefList' is not a class or namespace
../../../src/game/MoveMap.cpp:107: error: expected ';' before 'itr'
../../../src/game/MoveMap.cpp:107: error: 'itr' was not declared in this scope
../../../src/game/MoveMap.cpp:117: error: type '<type error>' argument given to 'delete', expected pointer
../../../src/game/MoveMap.cpp: In member function 'void TerrainInfo::UnloadNavMesh(int, int)':
../../../src/game/MoveMap.cpp:135: error: 'tileRefList' was not declared in this scope
../../../src/game/MoveMap.cpp:135: error: 'tiles' was not declared in this scope
../../../src/game/MoveMap.cpp:136: error: 'tileRefList' is not a class or namespace
../../../src/game/MoveMap.cpp:136: error: expected ';' before 'itr'
../../../src/game/MoveMap.cpp:136: error: 'itr' was not declared in this scope
../../../src/game/MoveMap.cpp:156: error: type '<type error>' argument given to 'delete', expected pointer
make[4]: *** [MoveMap.o] Error 1

what did i do wrong?

[faramir118]

Found this while looking into the new detours: http://img140.imageshack.us/gal.php?g=demob.png

How did our code generate a different poly path?

what did i do wrong?

I pushed something that should fix that.

[qsa]

Found this while looking into the new detours: http://img140.imageshack.us/gal.php?g=demob.png

How did our code generate a different poly path?

You can see on the picture, that the first waypoint not exactly where you stand.

I can only guess its due to some problem with our new format.

One other thing I noticed, is path's gets "trapped" in polygons while trying to pass between neighboring tiles.

You can observe it nicely on map 33. try making path from -209.369, 2242.350, 79.850 to -205.268, 2213.742, 79.764. or from -177.160, 2212.520, 80.096 to -223.471, 2196.717, 79.764.

You get maximal length path which trapped inside connection between tiles.

After spending half day, trying to understand why we cannot make custom sized tiles and how do the actual linking works. I realized, we took wrong approach.

Auto-linking between neighboring tiles is really, really primitive and will totally fail (path wise) when there's "fragmented" borders.

You can see this phenomenon on some tile connections : generate path that should have been straight between two neighboring tiles : you sometimes (rather often

) will get zig-zag at tile connection.

Started working on different way to generate polygons. Something that doesn't involve having small tiles.

I'll post it soon enough. So, if you plan making some huge changes, better wait a little bit.

Best regards.