MMaps Redux

[Unkle Nuke]

If I recall, that was due to Liquids causing the crash, wasn't it?

Is there a workaround for this? The last advice I remember was to just use the commit prior to implementing Liquids. Perhaps that commit can be used as a comparison against your updated code to snip out the parts relating to Liquids, sort of an "updated revert"?

[faramir118]

I did you one better. Liquids are off by default, just use it like you would normally.

If you DO want liquids, look at the new command line switch. Core-side implementation still isn't complete (depends on aggro and threat logic), so I don't suggest you use them.

Plus some other fixes.

[cyberium]

Nice to see you back faramir

I hope to see your core mod under "accepted" section soon.

[faramir118]

edit: Nevermind, I wasn't using my brain.

[Unkle Nuke]

That's my general condition for 23 hours each day.

[faramir118]

Ok, so the problem isn't too much data. More data just increases the chance that the bug surfaces! Unfortunately there's no workaround, but I reported it and will try to assist Mikko in resolving.

Also found another problem with navmesh generation for regions that overlap itself - see http://img801.imageshack.us/gal.php?g=spiral.png

[b482518]

Heads up, ...\\VC90\\MoveMapGen.vcproj seems to be missing the closing tag for

        <Filter
           Name="pathfinding"
           >

[Thyros]

news about this?

[faramir118]

I'm updating recast navigation. There were some API changes which implemented features I had hacked into recast earlier. Undoing my hacky modifications and figuring out the new way is fun. (not really)

Also moving a lot of code around. Should make future updates easier, and match mangos standards better.

Unfortunately it's nothing new or fun, which I suppose is the main reason I'm taking so long to do it.

[Unkle Nuke]

I can only try to imagine the moments of frustration you might feel while working on the code for mmaps, faramir.

When you're facing those times, just remember you're working on something that will be a major leap forward for MaNGOS and add so much more to the game play experience for so many people. It's a contribution as fundamental to the entire MaNGOS project as the first code that enabled characters to interact with NPCs.

I can hardly wait to see the end result!

One completed, your work will be an enduring legacy that everyone here will remember with gratitude, every time they boot up their server.

[KiriX]

I have some errors like this when try to build MoveMapsGen:

Building map 035:
We have 4 tiles.
ERROR:StaticMapTree::UnloadMapTile(): Trying to unload non-loaded tile. Map:35 X
:31 Y:31
ERROR:StaticMapTree::UnloadMapTile(): Trying to unload non-loaded tile. Map:35 X
:31 Y:32
ERROR:StaticMapTree::UnloadMapTile(): Trying to unload non-loaded tile. Map:35 X
:32 Y:31
ERROR:StaticMapTree::UnloadMapTile(): Trying to unload non-loaded tile. Map:35 X
:32 Y:32
Complete!

It's normal?

[faramir118]

Yes, that's normal. I should ask Lynx3d to change that to a debug message

[KiriX]

Yes, that's normal. I should ask Lynx3d to change that to a debug message

One more question. How many Gb mmaps? I get mmaps folder - 242Mb - it's normal too?

I think that it's should be more...

And need I a special config tune for work mmaps?

[faramir118]

Unfortunately I generate and delete my mmaps a lot, so I can't say for sure.

242 sounds reasonable for the default generator settings (instance and arena maps).

[KiriX]

Thx =)

How I should extract mmaps (that key?) if I want get npc move like in youtube move from first post? =)

And it will be usefull if you point how many Gb full mmaps and how many files it's contain...

[KiriX]

Tried to extract mmaps with key [--hiResHeightmaps true --skipContinents false]

Got error:

Application Log
Start: Mon Aug 23 04:59:07 2010


**************************

Critical Error - MoveMapGen.exe
Memory manager returned NULL: out of memory?



Expression: data

e:\\test\\rsa-10392\\dep\\include\\g3dlite\\G3D/Array.h:154

3Gb DDR2

Error then extract map 001.

[Patman128]

Memory manager returned NULL: out of memory?

It would appear you don't have enough memory. Try with --hiResHeightmaps false.

[KiriX]

It would appear you don't have enough memory. Try with --hiResHeightmaps false.

Yes, I can understand it, but didn't think that's it is true...

3Gb is not enough??? It's terrible...

Map 000 exstracted normally. Maybe is clean as a memory?

I'll try again without [--hiResHeightmaps true] key.

[Unkle Nuke]

Whoa, wait a minute!

Patman, you're saying that faramir's mmaps generator requires more than 3 GB of RAM?

If this is true, that counts me out for any future testing or use. There's no way I can meet that requirement without replacing my system's core components and OS.

Once this makes it into the core, I'll just have to say goodbye to MaNGOS.

[Darkruler]

well, considering you're using Windows and probably have some stuff open i'd say the extractor uses around 2 GB (1 GB for windows and side-apps)

[Neo2003]

Whoa, wait a minute!

Patman, you're saying that faramir's mmaps generator requires more than 3 GB of RAM?

If this is true, that counts me out for any future testing or use. There's no way I can meet that requirement without replacing my system's core components and OS.

Once this makes it into the core, I'll just have to say goodbye to MaNGOS.

If you have a PC with around 4GB memory and a 32 bits Windows, compile the extractor with "large address aware" settings and activate "/3GB" inside your C:\\boot.ini OS file. This will just let it use 3GB of memory instead of 2GB by default.

Btw I think this is only an interim problem like when I was writing the old version that used 2.8GB of memory just for Stormwind data while at the end it required much much less memory for the same work.

Don't forget this is under development.

[KiriX]

Without key [--hiResHeightmaps true] mmaps was extracted fully without any errors.

What makes this key?

[faramir118]

Inadvertently accumulating some mesh data... sorry!

Insert the following code at MapBuilder.cpp line 201 (inside the for loop):

           allVerts.fastClear();
           allTris.fastClear();

The shameful part is, I'm not using the array that keeps growing and growing.

I would push it to the repo, but I'm in the middle of testing a huge commit. If it weren't for these pesky database updates...

edit: Kalimdor with hi res heightmaps and liquids now averages around 40MB working set, peaks at about 77MB. A long time ago, it used to take over 2GB to do low res with no liquids

[KiriX]

Thx!

If I understand you correctly it should be this:

        // now start building mmtiles for each tile
       printf("We have %i tiles.                          \\n", tiles->size());
       for(set<uint32>::iterator it = tiles->begin(); it != tiles->end(); ++it)
       {
           allVerts.fastClear();
           allTris.fastClear();

           MeshData meshData;

allVerts.fastClear(); is not need - it already in loop...

[faramir118]

allVerts.fastClear(); is not need - it already in loop...

Just good housekeeping in the case continue; is hit before its cleared.

edit: the break; in that same loop should be a continue;