[NavMesh][MPQ] Geometry parsing issues

[Bananenbrot]

Hi,

While generating nav meshes I encountered some errors in the parsed geometry.
I'd like to know if your parsers have the same errors and if not, how you process the input data.

1. I got a weird M2 hanging into cave entrances sometimes, like into EK(32, 4's goldmine:

That red thing is the offending doodad, namely WORLD\EXPANSION03\DOODADS\WORGEN\WALLS\WORGEN_CITYGATE01.M2. The little knob on top is WORLD\EXPANSION03\DOODADS\WORGEN\ITEMS\WORGEN_WARNING_SIGN02.M2.
Both of them are brought into the scene by an MDDF and thus are not children of the Goldmine WMO.
Both of them have flags == 0 in their respective MDDF entries, so for me there is absolutely no way of identifying them as not-rendered. Those M2s in itself are renderables with collision geometry and you can view them WoW model viewer.

The 2. issues is regarding holes: There clearly must be a hole in Kalimdor(29,13) for the entrance of the barrow dens, but appearently, the whole ADT has hole values set to 0:

Note how the terrain is filling the downgoing pathway in the back.

Thanks for your efforts,
Bananenbrot

[berlinermauer]

Hey Bananenbrot,
I was experiencing just the same as for #1. I have no clue how to get rid of that, despite of manual removal. Is it always CITYGATE01.M2 to filter for it?
Same for that little mine in the Human Startzone. I am wondering why it is not drawn? Does it have a Texture-Value set to 0? Or how does WoW itself deal with it? It maybe has a colission as a trigger like D3D_SetDrawPreference(Fog, enable);?

[Bananenbrot]

That picture #1 was taken from the human start zone. I haven't done any further investigation until then, because I'm quite busy atm.
Plus, I haven't ever looked into collision in WoW, I was just hoping that I could extract the needed information out of the respective .adt or .m2.

[Empted]

That was long time ago, had nearly same problem with cave entrances, but I fixed it with some polygon filtering, can look back into my code, if it's still the problem.

P.S. since names are clearly should not be presented in that region of the map, probably those M2s are part of another doodad set (like mine with the entrance closed). Try to properly implement doodad sets of WMOs.

[Bananenbrot]

Like I stated, those m2s are part of the adt and have an mddf entry.
So no doodad sets and sadly I can think of no other spot to get that info from.
Would be grateful if your search turns something up, though

[Empted]

            while ((offs = ADTReader.SeekString("DRCM", mpqFile)) != 1)
            {
                mpqFile.Position = offs + 4;
                uint size = mpqFile.ReadUInt();
                for (int i = 0; i < (int)(size / 4); i++)
                    referedDoodads.Add(mpqFile.ReadUInt());
            }
                /*
                ..
                */

            for (int i = 0; i < numMDDFs; i++)
            {
                if(referedDoodads.Contains((uint)i))
                {
                    ...
                }
            }
            }  

The thing is that you only need doodads that are referred at MCRD chunks. Do you filter this way?

[Bananenbrot]

            while ((offs = ADTReader.SeekString("DRCM", mpqFile)) != 1)
            {
                mpqFile.Position = offs + 4;
                uint size = mpqFile.ReadUInt();
                for (int i = 0; i < (int)(size / 4); i++)
                    referedDoodads.Add(mpqFile.ReadUInt());
            }
                /*
                ..
                */

            for (int i = 0; i < numMDDFs; i++)
            {
                if(referedDoodads.Contains((uint)i))
                {
                    ...
                }
            }
            }  

The thing is that you only need doodads that are referred at MCRD chunks. Do you filter this way?

I'm pretty sure I don't. Looks promising, thanks

[Empted]

Same with WMOs btw, just parse MCRW chunks. If it's not the case, I'll try to build geometry from 32_48 region and see, may be there is something new.

[Bananenbrot]

Just entered wow into human starting zone (32 4 and mentioned that all those doodads on your screenshot are presented in the game and the mine is closed indeed, also there is sign on the entrance and everything matches (trees and boxes on the floor near the entrance, so I guess it's alright).

Thank you. Kind of stupid, didn't think that it would be closed and so didn't actually look at it ingame, was creating a human and scanning memory for the string.
Any hints about the second issue? I'll check now if it there is really a hole.
Edit: There really is a hole in that den.

P.S.: Hope you don't mind publishing your PM

[Bananenbrot]

Same with WMOs btw, just parse MCRW chunks. If it's not the case, I'll try to build geometry from 32_48 region and see, may be there is something new.

As I realize now, I already parse MCRD and MCRW do get M2s and WMOs respectively.
Edit: But am not using it any further. Fail.

[Empted]

Yeah, I don't mind Just didn't want this theme to be flooded, but since info was useful, then ofc I don't.
Now concerning the hole:

I didn't get such a problem. Hope I can help you. Here is some code for hole handling:

       //just some general code, deciding whether i should add a square of 4 triangles or there is a hole.
                //i numerated all squares and i pass that number to the hole check function as well as the hole bitmap
                uint holes = Chunks[c].header.holeBitmap;
                for (int i = 0; i < 8; ++i)
                    for (int j = 0; j < 8; ++j)
                    {
                        if (ADTReader.HolesCheck(i * 8 + j, holes))
                        {
                            //..add triangles
                        }
                    }
                 
        //now the hole checking function:
        public static bool HolesCheck(int p, uint holes) //true if there is no hole, false otherwise
        {
            uint checkBits=0x1;
            for (int i = 0; i < 16; i++)
            {
                if ((holes & checkBits) != 0)
                {
                    int holeCol = i % 4;
                    int holeRow = (int)(i / 4);
                    int temp=16*holeRow+holeCol*2;
                    if ((p == temp) | (p == temp + 1) | (p == temp + 8) | (p == temp + 9))
                    {
                        return false;
                    }
                }
                checkBits=checkBits << 1;
            }
            return true;
        }
// there are 8x8 squares each of 4 triangle that form a chunk. Holes are some greater scale with possible only 4x4 positions. So i get the number of chunk square total of 0-63, then I iterate through all holes and see if there is one that "consumes" the square . Since there is 4 squares per hole (2x2), I match the hole number with the square number by holeRow*16+holeCol*2 (since it's 2:1). Then the square is consumed by the hole if their number is equal or (+1). Or if square is one line down (+8) or it's down and adjucent (+9 total). Now i see that's easier to first get hole number from the square number, and then do some very simple actions, but who knew :D  

P.S. I know that's rather shitty function, I had much mess in my head while writing this, because of blizzard million coord systems and no consistency or style at all. So probably it's much easier to read something about holes here: wowdev adt/v18, but since you have some holes in right places i guess there is a mistake somewhere in your code probably, just check it
When writing this code i had a paper with some ( 145 ) nodes painted and that was rather easy to understand those magic numbers.
P.P.S. And btw those MCRD and MCRW chunks are needed not to overlap WMOs between adjacent adts (as some memory comes to me). All WMOs that are at the border of the map ADTs are referenced twice in both ADTs, but only once presented in MCRW. Same with some trees at the borders and so on.

[Bananenbrot]

Thanks for your effort, but it's not that I don't handle hole values correctly. I just get a hole value of zero for the whole ADT at (29, 13), specifically for the offending tiles (0, 8 ) and (1, 8 ).
I have uploaded the .adt part here Filebeam - Beam up that File Scottie!. It has a CRC of 73D160CD. Would you mind checking for yours?

It's helpful to see that it works for you, so it must be a bug in how/what I parse.
I'm only using the main If I parse the main .adt part for hole values. If I also parse the _obj0.adt part, I get weird holes everywhere. Definitely not right.

[Empted]

Mine is E9873632, while yours is what you've posted. Uploaded it, you can try build with it. Don't know how it's possible, though.
Kalimdor_29_13


Edit: tried to build geometry with your file, got MCVT chunk offset = 0xC0C0C0C0 and then error of course. So I guess you just need some new files.

[Bananenbrot]

Hmm.. when running it through a binary differ, it shows that the differences are only small in a numerical sense: often the differing bytes were only incremented or decremented. I fear this is a bug internal to CrystalMpq, since MPQEditor produces files with exactly the same hash as yours.

[ostapus]

Hmm.. when running it through a binary differ, it shows that the differences are only small in a numerical sense: often the differing bytes were only incremented or decremented. I fear this is a bug internal to CrystalMpq, since MPQEditor produces files with exactly the same hash as yours.

do you apply all patches when loading mpq ? just a thought