Ah, okay. Thanks for clarifying.

So as I see it now, there's two possibiliities for the pointers. First is the intermediary pointer possibility as Sora described above (which could apply to pointers besides the first and third red-boxed pointers I listed above; I'm fairly confident those are straight pointers).

Secondly, as MDenham described, the non-UV data may be composed of pointers as well as other unknown info. Perhaps bone info, perhaps some other kind of orientation info for the polygons. This info would not be needed for the first red-boxed pointer a few posts above, and probably not for the third one either if I'm correct in assuming it is also a "working" pointer. But this info might be in the second red-boxed pointer, meaning we would have to "discount" the pointer by some value to get the true pointer. Here's a theoretical illustration of what that would mean:

First red-boxed pointer: 0x968 = [(Pointer, value 0x968) + (other, value 0x00)]

Second red-boxed pointer: 0x970 = [(Pointer, value ???) + (other, value ???)]

Third red-boxed pointer: 0x988 = [(Pointer, value 0x988) + (other, value 0x00)]

One way to test would be to try and find the vertex to which UV coordinate #4 on Serge's belt buckle maps (I don't have a pic up for that, so don't worry if it doesn't make sense -- coordinate #4 would be the UV coordinate corresponding to the non-UV value 0x990, just to the right of the first red-boxed pointer above).

- - - -

**UPDATE:** I think I may have just found three more working pointers from the non-UV data in Section 1-2 to the vertex pool. I'm getting some pics together to illustrate where the pointers are in terms of hex addresses and their impact on vertices specified by the UV coordinates.

**Also, I should point out that I've noticed the 3D coordinates for the vertices specified in Section 1-3 are given in reference to the bone the vertex is on. For example, I changed the up-down magnitude and direction for a vertex on Serge's sock, and the vertex crawled up his leg diagonally, i.e., the vertex moved in accordance with the bone's angle. So the vertex indices given in Section 1-3 may refer to bone data in some way.**- - - -

**Promised Update:** Okay, here's an illustration of four working pointers (i.e., what appear to be pointers relative to address 0x28E8, the beginning of the vertex pool), which will hopefully give everyone a full idea of what I've been looking at today. Sorry, pics are big, so click to view.

First pic: three working pointers on Serge's shoe. Hex code insets show the code in Section 1-2 (top inset) and the code in Section 1-3 the pointers point to (bottom inset). Pointers are in red boxes as always. There are three polygons numbered in red here, and I've given the order in which each each coordinate in each polygon's UV map is listed. So the label "1-#2" is the first polygon's second UV map coordinate on Serge's texture. The circled coordinates apparently correspond to vertices in Section 1-3, i.e., altering the coordinate in Section 1-3 suggested by the vertex's non-UV byte pair makes this vertex on Serge's model shoot out somewhere.

http://img257.imageshack.us/img257/5940/shoepointersyb6.gifLet's run through an example. The coordinate "1-#4" (0x59, 66 in hex) has a suggested pointer of hex value 0x0898 (fourth byte pair of polygon 1's non-UV data). This points to address 0x3180 in Section 1-3, and when this vertex is altered, sure enough the circled point on Serge's model does funky things. It should be noted that this vertex is in "8-byte mode".

Second pic: one working pointer on Serge's belt buckle; this is the one I used to determine the various purposes of the byte positions in the vertex pool.

http://img339.imageshack.us/img339/3926/bucklepointersor4.gifThe coordinate "1-#3" (0x5D, DC in hex) has a suggested pointer of hex value 0x0968 (third byte pair of polygon 1's non-UV data). This points to address 0x3250 in Section 1-3, and when this vertex is altered, sure enough the circled point on Serge's model does the funky things I've reported in previous posts. It should be noted that this vertex is in "16-byte mode." Thus, the data starting at address 0x3258 pertains to the same vertex as the data starting at 0x3250.

To tell everyone the truth, I've never seen more than one "working" pointer in each row of Section 1-2's non-UV data. This "working" pointer doesn't seem to have a definite position in the row though -- the shoe pic shows that the working pointers are all the fourth byte pair of non-UV data, but the belt buckle pic shows a working pointer as the third byte pair of non-UV data. The next step I'm going to take is to pick a random triangle and a random quad and see if each has at least one "working" pointer. It may tell us that only one pointer is necessary for each polygon, and the rest of the data can somehow be devoted to bones or other orientational aspects.

Whew! I'm going to take a day off and go collect 2D data (the EASY stuff) from another game. This will hopefully give everyone some time to digest the findings from page 18 onward in this thread. I'll check back though to clarify on things as necessary.