Where do we set the movement info structure fields?

[amadmonk]

Edit: ignore this. I realized that there are much better ways to try to reverse WoW's polygon cache, such as the TraceLine function, which by definition has to find various terrain intersections. Reversing it through a non-static like the movement fields is not a good choice.

Edit2: looks like TraceLine is using D37E24 as a tri cache, but this can't be a global terrain cache because at one point we call qsort on it (sorting by distance from the intersect point, I'm thinking). The loop at 006C46E0->006C4924 is definitely scaling through this list 0xC bytes (three floats, one tri) at a time. There's no way we could be re-sorting the ENTIRE terrain cache for every TraceLine, is there? I wish I could get WoW live so I could look at the contents of D37E24 and how we source this information.

Yeah, D37E20 is the count. Only thing I'm not sure of is who sets these, since IDA shows no meaningful xrefs to D37E20 or D37E24, and no writes at all (which makes no sense, since qsort would trap on null; so this has to be an IDA failure.)

Edit3: looks like the actual structure is at D37E1C, as we use it as a "this" pointer in at least one place. I think that there's maybe a linked list of tri lists? afterwards. I'm guessing that this is maybe the current map tile?

[namreeb]

It's not necessarily a failure. You've probably found a portion of a class or something which is referenced relative to the class instance's location (as opposed to a direct global reference to the position in question). You just gave me a sweet idea, though. Perhaps we can use the data you refer to and generate a mesh from it, for purposes of local steering? Meshing an area that is 'really small', say in WoW terms 100 yard radius, would take probably < 10ms.

Incidentally, have you just not been on MSN all week or is Pidgin acting up on me again?

[amadmonk]

Oh I got off IM since I was getting craptons of porn-spam bots. Bleargh. I'll logon.

Yeah, meshing the local data -- if we can churn it into a small area of tris -- was exactly my intent I figured that we can use that for local steering and probably remesh it on-demand, since it's small enough. But of course, this requires actually GETTING to the data. My reversing skills are decent, but my XMM reversing skills -- not so much. However, I see a number of sqrt operations going on, and I pretty much never see those being used aside from in distance calcs, which is a hopeful thing.

Edit: incidentally, looking at the TraceLine function makes me believe that the cached mesh data already stores all the flags needed to determine if the poly is water or air or lava or whatever. Talk about letting them do the work for you

Now if only I could find a compact heightfield structure

[namreeb]

Well I'm pretty sure that this is the method that ppather used. It's a stupid thing to do for overall navigation, but for local situational awareness (the sort where the corrections from straight-line pathing are "small"), it sounds perfect.

[jjaa]

Well I'm pretty sure that this is the method that ppather used. It's a stupid thing to do for overall navigation, but for local situational awareness (the sort where the corrections from straight-line pathing are "small"), it sounds perfect.

Nah, IIRC PPather read the mpq's at runtime.
EDIT: So i'm taking a look at traceline. 00D37E1C is the start of the structure. What your refering to seems to get set at 006C33AD

[amadmonk]

So what's the mathematical formula for calculating the normal vector of a tri? I'm looking at CMovement__GroundNormal (006105D0 not rebased) and its child function GetGroundNormal (00610300). These might be fruitful for scaling into an in-memory tri list, since you have to figure out what your current tri is to get its normal, right?

---------- Post added at 10:08 AM ---------- Previous post was at 10:04 AM ----------

Nah, IIRC PPather read the mpq's at runtime.
EDIT: So i'm taking a look at traceline. 00D37E1C is the start of the structure. What your refering to seems to get set at 006C33AD

I think that 6C33AD may either be a constructor-type function or a tri-list copy function, since there's a block of code in there that essentially zeroes everything out.

Note to self: important to set comments on IDA's various auto-named float/double constants. I spent 10 minutes being excited about repeated uses of AB8348 before realizing it was just a double constant for 1.0, and we were just initializing a 4x4 identity matrix (in CMovement::GetPosition at 0041F400).

Edit2: I *think* that the code block starting at 0061047A is where we're actually calculating the normal of the tri to return a ground normal. If someone could confirm this bit of floating-point code, I'd appreciate it. If so, we need to figure out where this tri comes from. I REALLY wish that I had the latest HexRays, with better SSE support...

[caowenyu]

the formula to caculate the normal vector is list x/|x|, where x is the vector and |x| is the length of it.

[schlumpf]

the formula to caculate the normal vector is list x/|x|, where x is the vector and |x| is the length of it.

Normalizing a vector is not the same as calculating a normal to a plane. For a convex polygon (such as a triangle), a surface normal can be calculated as the vector cross product of two (non-parallel) edges of the polygon.

[caytchen]

the formula to caculate the normal vector is list x/|x|, where x is the vector and |x| is the length of it.

Nope, thats for normalizing a vector, he is asking about calculating the normal of a plane given a triangle. Given three vertices A, B, C the normal vector of the plane they span would be the crossproduct of AB and AC or whatever other combination you prefer (given that they are independent).

[caowenyu]

thanks caytchen and schlumpf, you guys are right. to calculate the normal of a plane, get the vector from the cross product of the 2 edges' vector of a triangle, which is in the plane, then the normal of the vector is the normal of the plane, right?

[_Mike]

thanks caytchen and schlumpf, you guys are right. to calculate the normal of a plane, get the vector from the cross product of the 2 edges' vector of a triangle, which is in the plane, then the normal of the vector is the normal of the plane, right?

The resulting vector is the normal of the plane. There is no such thing as a normal of a vector. Did you perhaps mean to normalize the vector in to a unit vector?