Currently I’m not doing any work on this project due to the uncertain future of ISXWarden / Glider. The point of this project was to create a navigation system that could be used by the public(ish) botting platforms out there. With both of the big ones on the edge of *poof* I have put everything on hold.

For anybody that wishes to pick up the project let me know and I’ll offer you any and all help that I can (knowledge wise, not much time for coding these days). Please understand also that some file formats have changed with the release of WOTLK and as such this project needs to be updated to work in it’s current form. The changes aren’t that major and should be simple enough to fix up.

Joking aside the project is still alive and well, but real life has gotten in the way and bills must be paid (or so they keep telling me). With a few projects dragging on that should have been done and paid a while ago it means I get to work overtime yet again to make up for people being lazy. The good news is they eventually pay and then it’s almost like a bit of time off with pay.

Sorry for the delays!

I went with splitting the terrain all the way down to a 16 x 16 grid for some reason to start. I think a lot of it had to do with the fact that MCNKs happen to be in a 16 x 16 fashion and I thought for some reason that the placement information for models was on a MCNK by MCNK basis (it isn’t if you forgot).

Now just how will the quad trees work? Well we start out with the entire ADT being the top of the tree. Now let’s look at Redridge for an example (my favorite zone to test in):

Now I covered quadtrees in a previous entry, but hopefully this will help enlighten things a bit. The top picture will be our first set of quadtrees that effectively divides the ADT into 4 chunks. Previously if we wanted to check if our character would hit anything we would test it against every single triangle in the scene. This was a complete waste of processing power which normally I wouldn’t care too much about, but it was so bad it would make your mother’s accountant cry (and we both know how much he sucks with a computer).

Using quadtrees the thought process goes like this:

First determine which quad we are in. This is extremely easy as it’s simply finding a point within a rectangle. Now let’s assume we’re in Quad 1 for example. Because we know we are in Quad 1 it’s safe to assume that we do not need to test against any data in Quad’s 2, 3, or 4. We can just ignore them.

After we determine the large quad we are in, we then go ahead and look at the children of that quad (it will have 4) and we see which of those four we are in. We again know that we can ignore the other three.

We repeat this until we hit a quad without children, and then we only test against geometry that is also present in that quadtree.

Now if we are to assume that all of our geometry was equally distributed across the scene (that is to say that there was an equal amount of triangles in every little 1/265th quad) we could also safely assume test would take 1/256th of the time. That means if it took an hour before, it would now just take roughly 15 seconds! Of course that is not exact, but should give you an idea of the benefit of quadtrees (which will later be octrees I think but I’m not there yet).

Now the basic idea is pretty simple, and here’s how we’re going to do it (pseudocode for now, still writing the actual code but I wanted to get a quality update out ASAP).

First is the quadtree class. This is going to be a rather simple class, containing two vectors that represent the tree. The picture on the left shows this with the yellow and blue dot. This class will also happen to contain an array of 4 other quad trees that will be the children (picture on the right). 

That pretty much takes care of the entire structure needed to define the actual quadtree, but we still need to link our data to an each tree. To do this we are going to define the starter tree in the ADT class. It’s a simple enough task to get the minimum and maximum vectors for the quadtree when we create our ADT as we always know the X,Y position of it in the 64 x 64 grid as well as it’s width and height (both are constant).

Now subdividing is simple enough, we are just going to divide down until we’re at 16×16. I.e.

1 -> 4 -> 16 -> 64 -> 256

Now the next thing we need is a link to each M2 and WMO within our quad. So the quadtree class is going to have a list that contains a reference to each M2 and WMO that is used by that quad.

The final thing that is needed is the terrain data used by that quad. Doing a 16 x 16 setup makes this easy enough as when we process a MCNK we will simply put that data over into the proper quadtree and call it a day.

Well I hope this was at least semi-helpful to those struggling with quadtrees and if nothing else it should serve as a good post that progress is being made (just slowly these days).

Not much of an update but better then nothing!

It may not look as if things have moved along too much, but truthfully they really have. The code is much easier to follow now and with all the XML comments I’ll be putting up a HTML documentation for the entire project in the next few days. In addition if you’ve looked in the forums you may have noticed that beserk85 has integrated MPQNav with mpqtool which streams the ADT/WMO/etc… files straight from the MPQ archive. I’m going to be moving it into the trunk (and trying to contact a dev from mpqtool just to ensure they don’t mind me using it in this project) over the weekend and I hope to have a post on that soon.

There is at least one new feature though…

The Console!

Setup by arkwiw I have moved it into the source. To access the console hit the esc key (it’s on the HUD now as well just in case you forget). From there you will be able to execute commands. The only current on is the load command:

Load X Y

This loads up the ADT at (X,Y) for the continent that you have loaded.

app.config

There is now also a configuration file. Currently it has a field for where the MPQ files are extracted to as well as the X and Y of the default map you want to load(and the continent).

Keep in mind that I will be using my app.config on the SVN so it will overwrite yours if you forget and just do an update. I think you can exclude the app.config from the updates if you want but I am no SVN guru.

What no zip?

Right now I just wanted to let people know the code cleanup is finished and ready to play with on the SVN; however, there are a few other changes I want to make before releasing another zip file completely. I am shooting to get those done over the weekend with more of a writeup on just why the code is cleaner to go with it. Until then play with the SVN!

Now if you can’t tell from the picture above there is a single ADT manager (technically a single ADT Manager per continent but that’s beside the point) which manages the… ADTs for that continent. These are all of course loaded on demand. Within each ADT is a WMO and M2 manager that handles their respective files (loaded when the ADT is loaded). If you remember previously our setup more or less looked like this:

I know this is obviously a mini-post but I hope it instill some hope!

Too long without a post is never a good thing for a blog, so I decided to devote as little time as possible to this post as I have a long “To-do” list and not nearly enough time to do it today. Let’s see where we are:

1. I see a lot of people in IRC and I appreciate you all stopping by and/or idling Thanks to everybody that’s said a kind word about the project at hand, you freaking rock!
2. arkwiw has finished an XNAConsole wrapper for the project. Not only has he finished it, he documented how it’s setup, gave the source code, and it looks great. This will be the feature of the next blog post ASAP so all praise be to arkwiw!
3. Most all of the code is refactored now (I’d say 90%) I just have some commenting that needs finishing and to re-write a few other bits and pieces properly instead of 1000 line methods.

I know this update sucks, and it’s not even much of an update, but at least it’s a post!

<redsector> its just like getting into a book
<redsector> but the book is not finished yet
<redsector> i enjoy your writing style

The problem is… this is about all I have:

Refactoring all the code was a big job and a needed one, I still have roughly 25% to go which is where a lot of the holdup is at the moment. To give an idea here’s an excerpt from the new WMOManager (instead of lumping everything into the damned ADTManager like I was):

        /// 
        /// Adds a WMO to the manager
        /// 
        ///
Filename of the WMO from the Adt - i.e. world\wmo\azeroth\buildings\redridge_stable\redridge_stable.wmo
        ///
Base path to where the MPQ is extract - i.e. c:\mpq\
        public void addWMO(String fileName, String filePath)
        {
            if (File.Exists(filePath + fileName))
            {
                this.addName(fileName);
                BinaryReader br = new BinaryReader(File.OpenRead(filePath + fileName));
                WMO currentWMO = new WMO();
                currentWMO.name = fileName;
                br.ReadBytes(20); // Skip the header
                UInt32 nTextures    = br.ReadUInt32();
                UInt32 nGroups      = br.ReadUInt32(); // This is the number of "sub-wmos" or group files that we need to read
                UInt32 nPortals     = br.ReadUInt32();
                UInt32 nLights      = br.ReadUInt32();
                UInt32 nModels      = br.ReadUInt32();
                UInt32 nDoodads     = br.ReadUInt32();
                UInt32 nSets        = br.ReadUInt32();
                UInt32 ambientColor = br.ReadUInt32();
 
                UInt32 WMOID = br.ReadUInt32(); // Column 2 in the WMOAreaTable.dbc
 
                float bb1_x = (float)(br.ReadSingle() * -1);
                float bb1_z = (float)br.ReadSingle();
                float bb1_y = (float)br.ReadSingle();
                float bb2_x = (float)(br.ReadSingle() * -1);
                float bb2_z = (float)br.ReadSingle();
                float bb2_y = (float)br.ReadSingle();
 
                currentWMO.createAABB(Vector3(bb1_x, bb1_y, bb1_z), Vector3(bb2_x, bb2_y, bb2_z));
                currentWMO.total_groups = (int)nGroups;
                for (int wmoGroup = 0; wmoGroup < nGroups; wmoGroup++)
                {
                    String currentFileName = currentWMO.name.Substring(0, currentWMO.name.Length - 4) + "_" + wmoGroup.ToString().PadLeft(3, "0".ToCharArray()[0]) + ".wmo";
                    currentWMO.addWMO_Sub(this.processWMOSub(currentFileName, filePath, wmoGroup));
                }
            }
            else
            {
                throw new Exception("File does not exist: " + fileName + filePath);
            }
        }

Do you see what I see? Comments, not doing everything in one little huge method, error checking, proper variable usage… OH HOW SWEET IT IS!

Now imagine doing that to all the code and changing the entire control flow, that’s what I’ve been doing. When I’m not doing that but still find freetime somewhere somehow I have also been reviewing a few other nifty little options for the program that are on my list of implementation.

Over at codeplex is a great little setup for a console in XNA: http://www.codeplex.com/XnaConsole

Google code has a C# implementation of MPQ extraction: http://code.google.com/p/mpqtool/

Both are going to make their way into the source at one time or another (with due credit of course) and both should really make things a lot more fun. Instead of having to hardcode which maps to load, it will become a console command. Where you extracted MPQ files are located will be an external setting. The MPQExtractor will look to see if the files exist in said location, and if they don’t it will automatically extract them.

This will also allow me to run incremental collision tests (say a small area at a time) without have to constantly start and stop the program (of course it will let you do it as well).

Another big addition I’d love to put in for fun/ease of use is mouse control for the camera. I’ve been digging and it shouldn’t be too difficult at all (that’s at the very end of the list though).

Well this wasn’t much of an update but I should get brownie points for the Photoshop mastery at least!

Most of the following information is from GameDev.net which has tons of amazing articles / how-to’s / etc… on everything gaming related. Here’s the quick and dirty on what a quadtree is an how it’s going to help speed things up. First let’s look at my laughable 1 minute drawing of RedRidge in Photoshop:

It’s not perfect but you get the idea. Green = land, blue = water, yellow = WMO, and red = M2. Make sense? I hope so, because it doesn’t get any easier from here.

Now a quick count shows that we have 16 M2’s in our scene and 3 WMO’s for a total of 19 objects (actual number in game is roughly 300 total for this map tile). So let’s say we wanted to see if our character hit anything at a certain spot in the scene:

The white dot is our player (isn’t she pretty). Now currently what would happen is we’d test to see if that box (the player) intersected with any of the other objects in the scene. After it ran through we’d get the answer that it didn’t. That works just fine, but we can speed it up! Let’s take this map tile and divide it into 4 sections:

Now what we would do is first find out what quadrant our toon is in, and then test the toon against only the obstacles that exist within that quadrant. In this case the toon is in the top-left quadrant and there’s 6 items (3 WMOs and 3 M2s) that we would test against.

6 instead of 19 means our test should run 69% faster assuming that all tests cost the same amount of time (which should be true in an OBB OBB intersection test). What if we were to take this further though?

Now the thought process goes like this:

1. Find the quadrant (of the 4 large ones) the character is in -> Top Left
2. Do not test in any remaining quadrants
3. If that quadrant has children (sub-quadrants) find out which one of those the toon is in -> Bottom Left Sub-Quadrant
4. Do not test any of the other quadrants
5. Repeat until we have no more sub-quadrants.

In this case we would only test against 2 WMOs instead of the 19 total objects, which should take 1/10th of the time or so.

You can subdivide as small as you want without giving up too much speed due to the way a Quad-Tree is stored. Here’s my pretty Photoshop representation:

So say our toon was in 1.4 :

See how much data we can ignore? See how that would speed things up quite a bit?

Well I hope this has helped some!