YEAH! All we need is Luminaire, and the team will be fully assembled!!
![SPRINGTIME OF YOUTH :lee:](https://www.chronocompendium.com/Forums/Smileys/default/icon_rocklee.gif)
Yeah, I haven't even tried investigating bone data in depth yet; I've gotta review and digest halkun's notes on that once we get the UV triangles nailed down. I'll write up a report on the triangles tonight.
UPDATE: The triangles are still bothersome, but I'll report my findings so far. First, the really good news -- it seems the UV triangles are consistent wth M's description of them as far as which columns have positive pointers that must be divided by two and which are "straight" positive pointers, though they all need to be divided by 8 on top of that to yield vertex indices. I conducted some experiments with the UV triangle beginning at address 0x2658, and it would seem the rules for positive pointers lead to the correct vertices in the vertex pool.
The UV and non-UV data for this triangle are as follows:
00002658 69 EC 67 FB 5D EB-08 10 50 20 D0 21
And here's where that exists on the UV map:
![](http://img443.imageshack.us/img443/2395/triangle2658va3.gif)
Coordinate #1 is 0x(69, EC); #2 is 0x(67, FB); #3 is 0x(5D, EB).
The non-UV value 1008, divided by 0x8 due to its first-column position, yields vertex 0x201. The next slot over, value 0x2050, is divided by 0x2 because it's in the second column, then by 0x8 to yield vertex 0x205. Rinse and repeat for the third non-UV slot, value 0x21D0, to get vertex 0x21D. Here's what happens when each of those vertices is altered:
![](http://img242.imageshack.us/img242/7327/vertex201ck5.gif)
![](http://img242.imageshack.us/img242/8016/vertex205zb3.gif)
![](http://img242.imageshack.us/img242/4632/vertex21ddh8.gif)
Now notice something really interesting. It's quite clear that coordinate #1 is mapped to vertex 205! So the first UV coordinate for a triangle apparently gets the second pointer!
This odd swap principle can be further illustrated. Take a look at the following code for the first triangle followed by another triangle in this section of UV & pointer data:
00002658 69 EC 67 FB 5D EB-08 10 50 20 D0 21
00002664 5A EF 5D EB 56 F9-50 11 70 22 D0 FF
There is one negative pointer in the second triangle beginning @ address 0x2664. To make sure it points somewhere back into the first triangle's non-UV pointers, let's see if the triangles are connected by blacking them out:
![](http://img256.imageshack.us/img256/5881/tangenttg2.gif)
It's not 100% conclusive (clipping issues may make it appear as if the triangles are separated by a pixel or so), but highly suggestive that the triangles are connected at the third coordinate, or 0x(5D, EB). But how can we use the negative pointer such that the 0x(5D, EB) in the second triangle is mapped to the same vertex as the 0x(5D, EB) in the first triangle?
According to my notes, it would appear that the second UV coordinate gets the third pointer. The value of the negative pointer is 0xFFD0, which leads 3 spaces back in the non-UV data when converted to decimal and divided by 16. That would lead three spaces back in the non-UV data, and we would land at the last pointer of the first triangle. Problem with that is, my notes tell me that the third UV coordinate might get the first pointer; the last goes to the second UV coordinate.
I'll have to spend more time theorizing on this weirdness later. At least we can conclude with some certainty based on actual visual evidence that the first UV coordinate gets the second pointer for triangle data. Anyone know why the heck that would be the case? For the quads, I always believed that the first UV coordinate got the first pointer, the second the second, etc, in logical order. This is very
illogical at first glance.
EDIT: Looking at the positive pointer experiments for that first triangle, it does seem that the second UV coordinate is mapped to the third vertex pointer and the third is mapped to the first. I'll have to see if the scheme works out consistently via another thought experiment.