[NavMesh][MPQ] Geometry parsing issues menu

These ads disappear when you log in.

Page 1 of 3 123 LastLast
Results 1 to 15 of 41
  1. #1
    Bananenbrot's Avatar Contributor CoreCoins User
    Reputation
    152
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/2
    Trade Feedback
    0 (0%)

    [NavMesh][MPQ] Geometry parsing issues

    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:
    [NavMesh][MPQ] Geometry parsing issues-ek_32_48_goldmine-jpg
    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:
    [NavMesh][MPQ] Geometry parsing issues-kalimdor_29_13_barrowdens-jpg
    Note how the terrain is filling the downgoing pathway in the back.

    Thanks for your efforts,
    Bananenbrot

  2. #2
    berlinermauer's Avatar Master Sergeant
    Reputation
    3
    Join Date
    Mar 2010
    Posts
    89
    Thanks G/R
    0/0
    Trade Feedback
    1 (100%)
    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);?

  3. #3
    Bananenbrot's Avatar Contributor CoreCoins User
    Reputation
    152
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/2
    Trade Feedback
    0 (0%)
    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.

  4. #4
    Empted's Avatar Contributor CoreCoins User
    Reputation
    82
    Join Date
    Aug 2011
    Posts
    117
    Thanks G/R
    0/4
    Trade Feedback
    2 (100%)
    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.
    Last edited by Empted; 05-12-2013 at 07:13 AM.

  5. #5
    Bananenbrot's Avatar Contributor CoreCoins User
    Reputation
    152
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/2
    Trade Feedback
    0 (0%)
    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

  6. #6
    Empted's Avatar Contributor CoreCoins User
    Reputation
    82
    Join Date
    Aug 2011
    Posts
    117
    Thanks G/R
    0/4
    Trade Feedback
    2 (100%)
    PHP Code:
                while ((offs ADTReader.SeekString("DRCM"mpqFile)) != 1)
                {
                    
    mpqFile.Position offs 4;
                    
    uint size mpqFile.ReadUInt();
                    for (
    int i 0< (int)(size 4); i++)
                        
    referedDoodads.Add(mpqFile.ReadUInt());
                }
                    
    /*
                    ..
                    */

                
    for (int i 0numMDDFsi++)
                {
                    if(
    referedDoodads.Contains((uint)i))
                    {
                        ...
                    }
                }
                } 
    The thing is that you only need doodads that are referred at MCRD chunks. Do you filter this way?
    Last edited by Empted; 05-16-2013 at 09:48 AM.

  7. #7
    Bananenbrot's Avatar Contributor CoreCoins User
    Reputation
    152
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/2
    Trade Feedback
    0 (0%)
    Originally Posted by Empted View Post
    PHP Code:
                while ((offs ADTReader.SeekString("DRCM"mpqFile)) != 1)
                {
                    
    mpqFile.Position offs 4;
                    
    uint size mpqFile.ReadUInt();
                    for (
    int i 0< (int)(size 4); i++)
                        
    referedDoodads.Add(mpqFile.ReadUInt());
                }
                    
    /*
                    ..
                    */

                
    for (int i 0numMDDFsi++)
                {
                    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

  8. #8
    Empted's Avatar Contributor CoreCoins User
    Reputation
    82
    Join Date
    Aug 2011
    Posts
    117
    Thanks G/R
    0/4
    Trade Feedback
    2 (100%)
    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.

  9. #9
    Bananenbrot's Avatar Contributor CoreCoins User
    Reputation
    152
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/2
    Trade Feedback
    0 (0%)
    Originally Posted by Empted
    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
    Last edited by Bananenbrot; 05-17-2013 at 04:47 AM.

  10. #10
    Bananenbrot's Avatar Contributor CoreCoins User
    Reputation
    152
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/2
    Trade Feedback
    0 (0%)
    Originally Posted by Empted View Post
    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.

  11. #11
    Empted's Avatar Contributor CoreCoins User
    Reputation
    82
    Join Date
    Aug 2011
    Posts
    117
    Thanks G/R
    0/4
    Trade Feedback
    2 (100%)
    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:
    [NavMesh][MPQ] Geometry parsing issues-29_13_hole-jpg
    I didn't get such a problem. Hope I can help you. Here is some code for hole handling:
    PHP Code:
           //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 08; ++i)
                        for (
    int j 08; ++j)
                        {
                            if (
    ADTReader.HolesCheck(jholes))
                            {
                                
    //..add triangles
                            
    }
                        }
                     
            
    //now the hole checking function:
            
    public static bool HolesCheck(int puint holes//true if there is no hole, false otherwise
            
    {
                
    uint checkBits=0x1;
                for (
    int i 016i++)
                {
                    if ((
    holes checkBits) != 0)
                    {
                        
    int holeCol 4;
                        
    int holeRow = (int)(4);
                        
    int temp=16*holeRow+holeCol*2;
                        if ((
    == temp) | (== temp 1) | (== temp 8) | (== 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.
    Last edited by Empted; 05-17-2013 at 08:20 AM.

  12. #12
    Bananenbrot's Avatar Contributor CoreCoins User
    Reputation
    152
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/2
    Trade Feedback
    0 (0%)
    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.

  13. #13
    Empted's Avatar Contributor CoreCoins User
    Reputation
    82
    Join Date
    Aug 2011
    Posts
    117
    Thanks G/R
    0/4
    Trade Feedback
    2 (100%)
    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.
    Last edited by Empted; 05-22-2013 at 11:42 AM.

  14. #14
    Bananenbrot's Avatar Contributor CoreCoins User
    Reputation
    152
    Join Date
    Nov 2009
    Posts
    384
    Thanks G/R
    1/2
    Trade Feedback
    0 (0%)
    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.

  15. #15
    ostapus's Avatar Active Member
    Reputation
    43
    Join Date
    Nov 2008
    Posts
    164
    Thanks G/R
    1/0
    Trade Feedback
    0 (0%)
    Originally Posted by Bananenbrot View Post
    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

Page 1 of 3 123 LastLast

Similar Threads

  1. Parsing mpq files for navmeshes
    By karnkore in forum Diablo 3 Memory Editing
    Replies: 1
    Last Post: 04-23-2014, 03:17 AM
  2. [Release] [Mpq][C#] Geometry parser/viewer
    By Bananenbrot in forum WoW Memory Editing
    Replies: 19
    Last Post: 03-11-2014, 05:35 AM
  3. [Question] MPQ compile issue
    By Aliv3 in forum WoW ME Questions and Requests
    Replies: 1
    Last Post: 10-14-2007, 04:44 AM
  4. patching issue
    By Marlo in forum World of Warcraft General
    Replies: 0
    Last Post: 07-22-2006, 07:35 PM
  5. [Patch 1.11] - Known Issues (6-20-06)
    By Cypher in forum World of Warcraft General
    Replies: 1
    Last Post: 06-24-2006, 12:42 AM
All times are GMT -5. The time now is 02:48 PM. Powered by vBulletin® Version 4.2.3
Copyright © 2019 vBulletin Solutions, Inc. All rights reserved. Digital Point modules: Sphinx-based search