CHRONO CROSS FILE EXPLORATION THREAD

[FaustWolf]

Hopefully when I get a polygon isolated such that we know where the UV map pointer *should* point in Section 1-3, that will help us answer some questions.

I'd like to provide another example of the pointer dilemma at work for further study, since I have one handy. First hex code, then a pic of Serge's shoe:




The UV map labeled "1" is what's in the first blue box and the UV map labeled "2" is what's in the second blue box. Points in yellow are unique to UV map 1, points in, er, "ice" are unique to UV map 2, and points in green are shared between these two maps. So if the pointers operate vertex-by-vertex, we would expect two pointers to be shared. But looking at the red boxes in the code snippet, it would appear that a total of three pointers are shared. Shouldn't happen. So there's another nail in the coffin of the vertex-by-vertex pointer theory, unless someone can save it.

The multiple of 8 rule is interesting, now that you mention it again Luminaire. If this were pointer data, each byte pair should point to someplace in the vertex pool with offsets reading 0xbbb0 and 0xbbb8, is that right? Meaning, the offset number it points to would end in either "0" or "8"? The vertex pool certainly seems to be set up that way -- data aligned in 8-byte rows.

I guess we'll see what happens when I finally track down the UV map corresponding to the vertex pool polygon I saw earlier.

EDIT: Ya know what? I'm looking right at a separate UV map that maps the exact same area as "1" in the above pic. Let's take a look at its data:
                                   - 67 70 56 6E 64 67 59 66
D0 FF B0 FE E8 FF 58 FF -

Serge's shoe texture has to be used at the very least, four times in the model: two sides per foot. So it makes sense for this UV map to have a different pointer from "1" above. The differences are:

("1"'s pointer)                 ->          (This UV map's pointer)

D0 FF D0 FE E8 FF A0 08  -> D0 FF B0 FE E8 FF 58 FF
 
Does this tell us anything?

[Cyberman]

• Those are offsets likely and therefore are pointers to a structure of type vertex. 
• you can have NEGATIVE POINTERS. This is a valid thing to do.  Also FF7 had multiples of 8 to reference a vertex.

Code: [Select]

Pointers Poly 0
1910 -30, -130, -18, 898
Pointers Poly 1
1920 -30, -130, -18, 8A0
Pointers Poly 2
1930 -30, -130, -18, 8A8


• This information points out that 3 pointers are repeated in more than just the 2 polys you are looking at. Therefore it may take some tinkering to figure out what is really going on.
  

I would suggest as an experiment is export the data and 'wind' the polygon's on the texture data (IE go through all the UV data and draw XOR lines on the edges of the polygons).  There is no doubt that is UV map data the question is do we have a list of vertex information OR something completely different.  I'm thinking it might be bone related data.

Silly question time, examining the directory structure a bit I noticed some files have ridiculously large LBA references, what does it mean? Also for the numeric value labeled "file type", what does that value mean? There doesn't seem to be any references as to what 'type' means.  Could it be the length in sectors? (256 * 2048 = 512k) Doesn't seem likely since video data is longer than 256 sectors (usually). Does anyone know?

Cyb

[FaustWolf]

By XOR lines Cyb, what do you mean exactly?

And as for the "file type" question, are you referring to something on the Chrono Cross File Structure wiki page?

On a leap of faith, I'm going to see if the last two bytes in the "pointer data" happen to point into the vertex pool. I know that doesn't necessarily make sense since a lot of the time the values are "D0 FF" and the like, but the "98 08"; "A0 08"; etc., look quite attractive because, as relative offsets, they would point at an area that seems to contain vertices for Serge's shoe. It could be just a coincidence though. I'll report on that later.

UPDATE!: It would appear that UV map "1"'s pointer: D0 FF D0 FE E8 FF A0 08 points to offset 3188 in Section 1-3. When I zero out the data in offsets 0x3188 ~ 0x318F, one of the top vertices in "1" shifts up Serge's leg. "1" is mapped to the inner side of Serge's shoe, so getting a good pic is difficult. What I shall do is repeat the process with one of "1"'s clones, hopefully finding that it maps to the outer side of Serge's shoe for superior viewing.

The pointer in "1"'s pointer data is a relative offset from the beginning of Section 1-3, 0x28E8. I'm not sure what this means for the rest of the pointer data though, since many (perhaps all) of those end with values like D0 FF or something that doesn't nicely conform to the idea of a relative pointer from 0x28E8.

In any case I have yet to confirm 100% that I've found a pointer, but I'd say I'm at least 68% confident. I think that figure came from a stats class. We shall see...

[Cyberman]

By XOR lines Cyb, what do you mean exactly?

And as for the "file type" question, are you referring to something on the Chrono Cross File Structure wiki page?

From the Chrono Cross tools (Yaz0r?) there is a 4 byte struct defined as such:

Code: [Select]

typedef struct
{
   unsigned char LBA[3];
   unsigned char type[
} index_record;
Well not precisely as that but basically that's what it said the directory records were in the index table burried at sector 24-35 on CC disk 1.  What I was interested in was "type" what it was or wasn't and also for values of LBA address with the MSB of LBA[2] is set ment.  It must mean something or it wouldn't happen so frequently
It would be interesting to find out at least. Make things a bit easier for me.  These files appear to be sequential sectors of data to what's before and after them.  Not sure of there significance other than there type is always 0.

XOR is a logical operation often done with data that might have a color near that being plotted near it. Thus an XOR changes the pixel data to a state that is guaranteed (almost) not to be the same so it is distinguishable.
Notice the column labeled LS# Some of the columns begin with 8XXXXX the ones that do have type 0 and all point to the same sector (not real files?) 


Cyb

[FaustWolf]

OMG, is that ISOViewer? Looks like the project is coming along very nicely! That is awesome, Cyb! As a file reference that might be of interest to you, there's an STR-format CGI movie that begins at address 0x186BA000, so that would mean it starts at sector 200052 (decimal) or 0x30D74. Not sure if you can use that info as a cross reference in any way.

Also, thanks to Ramsus we've got offsets for the normal TIM files. One of those begins at offset 0x246000 (Sector 1164); another begins at offset 0x24d800 (Sector 1179). Those files should be of the same "type" I imagine, since they should have the same headers. There are some TIMs early on that are not aligned to a sector, which is particularly odd.

I'm updating later; need to gather pics as proof. I believe I've found a pointer in the "Pointer Data" that follows a UV map for Serge's belt buckle. But the position of that pointer is weird; I'll make a big post and people can theorize accordingly.

[FaustWolf]

Alrighty, time for tonight's (er, this morning's) big update!

First pic is the texture piece mapped to Serge's belt buckle, with vertices defined by yellow dots.


Next up is the belt buckle UV map's applicable data in Section 1-2. In the blue box are the UV map coordinates on Serge's texture, and in red is the other data we've been wondering about. I believe that the third byte pair from the left (0x68 09) is a pointer -- but none of the others seem to be...


Taken as an offset relative to offset 0x28E8 in Serge's untextured model file, that one pointer points to offset 0x3250 in the vertex pool. That data follows in the red box:


Now, the very large pic below (click to view) summarizes the results of manipulating the data starting at 0x3250.
http://img181.imageshack.us/img181/5480/pointerproofzo7.gif

I should clarify first of all that when I altered the data in Section 1-3, I only altered the first, third, and fifth bytes. The second, fourth, and sixth bytes always seem to be either 00 or FF, so I steered clear to preserve the basic data structure. Likewise with the seventh and eighth bytes, which follow a very clear progression pattern. I would hypothesize that the first six bytes for each vertex entry in the pool represent X, Y, and Z coordinates in 3D space, but that's just a guess. It can be tested easily enough.

Getting back to the UV map data, and why (90 13); (E0 13); and (90 09) in the red boxed area aren't pointers...when I change the data in Section 1-3 these values should "point" to, areas other than Serge's belt buckle get messed up. If they were pointers from the belt buckle to Section 1-3, only Serge's belt buckle or some area adjacent to Serge's belt buckle should get messed up.

Another fun fact: if the third byte pair in the red box is a pointer (68 09 that is), then its position in the red box corresponds to the position of coordinates (5D,DC) on the texture map, i.e., the bottom vertex on the belt buckle quad I illustrate above. Judging from the big picture I link above (the one you have to click on), when I changed the bytes in Section 1-3 from their original values to "CC", it certainly appears as if this very same texture has been dragged over, warping the quad such that it stretches over the entire belt buckle area. The only weird thing is that it doesn't seem to take the adjacent quads below the belt buckle with it. I'm not sure if that's problematic theoretically.

[FaustWolf]

I'm knee-deep in Section 1-3's hex code still, because I think solving how that works can shed light on any relationship that exists between Sections 1-2 and 1-3. While I'm convincing myself of a few things, I've got a question for Cyb or anyone else who might be familiar with the topic:

How do negative pointers work? If they're relative to some offset, do they point to an address that comes before that offset? For example, if Section 1-2's non-UV data points into Section 1-3 but the pointers are negative when interpreted as signed integers, would I start at the end of Section 1-3 and count down to test where the pointers might be pointing at?

[Cyberman]

In words of one syllable yes.

That's how it should work however let me check the MIPS documentation to be certain.

Likely it's used by lw  with a sign extend (IE if it's negative it's turn into a 32bit word) then the referenced section is added and the resultant register is used to address the vertex structure.

So you negate and subtract the value.
IE
FED0 negated is 130 subtract 130 hex from your reference pointers and you should have something too look at.

Cyb

[FaustWolf]

Okay, thanks Cyb! I'll see if that checks out.

I'm testing some things in the vertex pool right now (Section 1-3) and it may have the following structure:

8 bytes per vertex:
YY ** ZZ ** XX ** AA AA, where:

YY: Magnitude of coordinate on the up & down axis on the screen plane
ZZ: Magnitude of coordinate on depth axis; toward or away from you with respect to the screen.
XX: Magnitude of coordinate on right & left axis on the screen plane
**: A directional reverser byte. If 00, the vertex is placed in one direction on the preceding axis, and if FF, the vertex   gets placed on a coordinate the same "magnitude" but opposite direction on that axis.
AA AA: Two bytes that seem to form an index of some sort for the vertex. These two bytes show the progression pattern we noted a very long time ago: they go 00 00 for the first vertex, 01 00 for the second, all the way up to FF 00, then it progresses to 00 01, etc.

I may be describing these axes all wrong, and I'll post some pics later to illustrate. Also, the "origin" for each vertex in 3D space must be located with respect to a bone or something, so I'm wondering if the AA AA index somehow points to bone info.

Do vertex pools usually operate on this sort of system? Or does this setup look utterly wrong?

- - - - -

Freakin'Tastic UPDATE: I do believe the above scheme holds, based on the experiments I've conducted today. Here's some pics that result from manipulating the vertex info starting at offset 0x3250:

YY ** illustration:
This is extremely difficult to see, but look in the red circle. It appears that whatever vertex is controlled at this address has pushed the belt buckle up into Serge's chest. One can only make it out by virtue of polygon "clipping"...


ZZ ** illustration:
By reversing the ** byte from FF to 00 as well as changing the magnitude on the depth axis, I've succeeded in impaling Serge with his own belt buckle...


XX ** illustration:
First pic involves changing the magnitude on the right-left axis without altering the ** switch...


Next pic involves changing the magnitude on the right-left axis AND switching the ** byte, making the vertex go in the opposite direction on the right-left axis!


 - - - -

ADDITIONAL UPDATE:

I might as well just get all of Section 1-3 out of my system while I'm at it. Section 1-3 has 812 eight-byte "slots", and one vertex can fit in each "slot." Does that mean there are 812 unique vertices in Serge's model? NO!

Here's why I believe there aren't 812 unique vertices. Notice that each vertex "slot" has an index value AA AA following the coordinates in 3D space. In many cases the vertex pool exhibits a byte-progression pattern that affects each 8-byte "slot" as follows:

YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX 01 00
YY ** ZZ ** XX ** 02 00 - YY ** ZZ ** XX 03 00

I shall term this pattern "8 byte mode" for future reference. But in many cases the data in Section 1-3 will enter "16 byte mode" using my terminology. That means two 8-byte "slots" are devoted to each vertex index like so:

YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX 00 00
YY ** ZZ ** XX ** 01 00 - YY ** ZZ ** XX 01 00

Another reason why I believe one "slot" is devoted to each vertex in 8-byte mode versus two "slots" in 16-byte mode can be seen in the following picture. Only unaltered hex code is given along with the pictures; I've long since lost track of what new values I entered in.  In the top-most pic, I modified values in two adjacent "slots" devoted to separate vertices on Serge's shoe. In the bottom-most pic, I modified values in two adjacent "slots" that appear to be devoted jointly to a single vertex on Serge's belt buckle...
http://img526.imageshack.us/img526/5585/structureevidenceaq6.gif

Notice that when two adjacent slots that are in 8-byte mode are altered it affects two vertices, whereas two adjacent slots that are in 16-byte mode only affect one vertex when altered. Weird, huh?

I cannot explain why some vertices would need only one "slot" devoted to them, whereas others need two "slots." If this interpretation is accurate, however, it gives us the following structure for Section 1-3:

301 vertices in 0x28E8 ~ 0x324F (8-byte mode)
210 vertices in 0x3250 ~ 0x3F6F (16-byte mode)
   5 vertices in 0x3F70 ~ 3F97 (8-byte mode)
 43 vertices in 0x3F98 ~ 4247 (16-byte mode)

That adds up to 559 vertex indices. I'm not comfortable with that number to be honest, becaues Luminaire came up with a figure of 704 based on quad pointers in Section 1-2. I'm not finding pointers to the addresses that mark the boundaries between 8-byte mode and 16-byte mode vertices either (except the pointer from the belt buckle UV map to address 0x3250 in the vertex pool).

As far as the pointers from Section 1-2 to Section 1-3 go, I've found only a couple values that behave as pointers relative to the beginning of Section 1-3, address 0x28E8. We'll have to see what happens when we interpret the non-UV data in Section 1-2 as negative pointers relative to the end of Section 1-3, address 0x4247 (we can make it 0x4248 if that works instead). One quick way to check if this is possible is to take a look at the largest-magnitude negative and positive numbers in the non-UV data pointers. If the magnitudes are within the size range of Section 1-3, things will look up. Luminaire gave us that info awhile back, but I'll have to fish through this thread to find it again for testing.

[FaustWolf]

Grr, the last post is simply too long to add even more stuff. Looks like Luminaire reported that the non-UV pointer values in Section 1-2 go from -496 to +8928.

Section 1-3 is 6496 bytes long (thanx to MDenham for the reminder), so it would appear that the non-UV pointer data doesn't necessarily point into Section 1-3. At least if the pointers are interpreted in this way. Something weird's going on. What's even more strange is that I was able to find a value that acted as a pointer to the address 0x3250, which is one of the vertices for Serge's belt buckle. Coincidence, maybe -- lots of other values that appeared like that pointer don't seem to behave as nicely.

I should mention that Section 1-4 is mathematically linked to 1-3 and consists of "4-byte mode" data in terms of my earlier terminology.

Section 1-4 follows this pattern:
?? ?? ?? 00 ?? ?? ?? 00 - ?? ?? ?? 00 ?? ?? ?? 00
?? ?? ?? 00 ?? ?? ?? 00 - ?? ?? ?? 00 ?? ?? ?? 00

Its purpose is unknown to me as of yet. Every fourth byte is "00", no ifs, ands, or buts. If interpreted as four bytes per "slot", there are 812 "slots" in this section, and 812 possible "slots" in the preceding section. Luminaire noted this earlier as well.

[MDenham]

Grr, the last post is simply too long to add even more stuff. Looks like Luminaire reported that the non-UV pointer values in Section 1-2 go from -496 to +8928.

Section 1-3 is 9744 bytes long, so there's some possibilities here. I should mention that Section 1-3's structure was unfinished in my last post; lapse of brain power. Here's a map for all of Section 1-3, with some weird "4-byte mode" data that I haven't even begun to look at yet:

301 vertices in 0x28E8 ~ 0x324F (8-byte mode)
210 vertices in 0x3250 ~ 0x3F6F (16-byte mode)
   5 vertices in 0x3F70 ~ 0x3F97 (8-byte mode)
 43 vertices in 0x3F98 ~ 0x4247 (16-byte mode)
812 unknown "slots" in 0x4248 ~ 0x4EF7

For review, data termed "8-byte mode" follows this pattern:
YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX 01 00
YY ** ZZ ** XX ** 02 00 - YY ** ZZ ** XX 03 00

"16-byte mode" follows this pattern:
YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX 00 00
YY ** ZZ ** XX ** 01 00 - YY ** ZZ ** XX 01 00

And introducing "4-byte mode":
?? ?? ?? 00 ?? ?? ?? 00 - ?? ?? ?? 00 ?? ?? ?? 00
?? ?? ?? 00 ?? ?? ?? 00 - ?? ?? ?? 00 ?? ?? ?? 00

4-byte mode's purpose is unknown to me as of yet. Every fourth byte is "00", no ifs, ands, or buts. It should be noted that the "4-byte mode" section is mathematically linked to the data that precedes it: 812 "slots" in this section, and 812 "slots" in the preceding sections if you count 4 bytes per "slot" in the data from 0x4248 ~ 0x4EF7 and 8 bytes per "slot" in the data from 0x28E8 ~ 0x4247. Luminaire noted this earlier as well.

Well, 0x4248-0x4EF7 is Section 1-4, not the tail end of Section 1-3, according to posts earlier in the thread (page 7, and, in fact, your post).

I suspect 1-4 may be the bone data, but I'm not entirely sure about that (it seems awfully short for that, combined with the earlier observations that changing it had no apparent effect).

A couple of hunches here:

* The "pointers" in 1-2 may be using the top three or four bits for something else (since everything is guaranteed to be a multiple of 8 for whatever it's pointing at, it'd make a little sense to shift out the extra three zeros and pack in some additional information).  If all of the pointer values are multiples of 8 already (or all of them are identical modulo 8, which amounts to the same thing), disregard this.

* Is there a chance that the 16-byte vertex data pertains to the quads, while the 8-byte vertex data pertains to triangles (perhaps including normals for quads, while just implying them for triangles)?

--

Edit, after looking up earlier on the page, and not related to the rest of the post:  Cyb, it looks like all of the 0x8XXXXX entries are followed, at the end of any sequence of them, by an entry that's 0x0XXXXX where the last 40 (maybe the last 47) bits are identical.  I think the 0x8XXXXX entries just carry additional information (long file names, possibly - not having much luck looking up any sort of info that'd help here).

[FaustWolf]

  Oh, shoot! You're right. Thanks for reminding me what I wrote earlier.  I've rescinded the inaccuracy.

I'll do some more tests with Section 1-4 to make absolutely sure it has no effect when it's changed; I can't believe Square would just stuff extraneous data into their models and waste storage space. Changing it has to have some repercussions, and I'll explore further.

MDenham, your suggestion regarding "16-byte mode" being quad data and "8-byte mode" being triangle data is intriguing. First of all, the switches between "8-byte mode" and "16-byte mode" in Section 1-3 are analogous to the switches between triangle data and quad data in Section 1-2 (we'll need to see if the proportion of vertex indices in offsets 0x3F70 ~ 3F97 to triangle maps that sneak unexpectedly late into Section 1-2 is realistic). If that many triangles could reasonably be composed of 5 vertices, I'd say we have a winner here! Secondly, we already know that the info starting at offset 0x3250 controls a vertex on Serge's belt buckle, which is composed of quads!

EDIT: Darn, those 5 vertices in 0x3F70 ~ 0x3F97 would have to be applicable to 12 triangles (Luminaire reported the 12 triangle figure earlier, and it's correct). I've also checked the 5 vertex figure in the vertex pool, and that's correct. However, it would complicate things in a good way if those triangles were defined by those 5 vertices as well as vertices controlled by surrounding "16-byte mode" "slots." Hope that makes sense.

The thing to do next, then, is definitely to check whether the "8-byte mode" data only affects triangles.

- - - -

ADDITION: It'll take some doing to definitively prove whether or not "8-byte mode" data in Section 1-3 refers to triangle vertices whereas "16-byte mode" data refers to quad vertices. But for now, here's a side-by-side comparison of Sections 1-2 and 1-3, so that we can draw some preliminary conclusions:

SECTION 1-2 STRUCTURE                           SECTION 1-3 STRUCTURE
0x0358 ~ 0x0FB7: Triangles, 264                 0x28E8 ~ 0x324F: "8-byte mode", 301 vertices
0x0FB8 ~ 0x2657: Quads, 362                     0x3250 ~ 0x3F6F: "16-byte mode", 210 vertices
0x2658 ~ 0x26E7: Triangles, 12                   0x3F70 ~ 0x3F97: "8-byte mode", 5 vertices
0x26E8 ~ 0x28E7: Quads, 32                       0x3F98 ~ 0x4247: "16-byte mode", 43 vertices
= 670 polygons (176 tris, 394 quads)            = 559 vertices (306 in "8-byte mode" and 253 in "16-byte mode")

...Which is a bit wonky. Why would there need to be 306 vertices for only 176 triangles, yet only 253 vertices for so many quads? But depending on how they're all connected, perhaps it could still work out somehow. I think the map of Section 1-2 is correct -- Luminaire, can you back me up on that from memory? I think 670 polygons was the final figure we arrived at back in November.

As an upbeat note to all, Sections 2 and 3 (Big Sections, that is, not subsections) are both relatively small -- only 816 bytes between the two of them I think. And I believe the rest of the model is probably animation data. If Section 1-4 turns out to be inconsequential again, we can look into Sections 2 and 3 for bone data perhaps.

I'll try for an update to the File Structure wiki this weekend so we can get all this stuff in one place so we don't have to slog through 18 pages of posts to find basic info.

Oh! But let's not forget about Section 1-1 either. I still don't know what that is, and it's difficult to test because the game goes all spastic and dies when it tries to load a model with this subsection altered. This may be bone data too, considering Cyb said FF7's bone data is stored toward the beginning of those models IIRC.

- - - -

ADDITION: Checked Section 1-4 again, and sure enough, when I 00'd it out, nothing happened. Serge is still fully intact, and all his animations work just fine even without Section 1-4. I suppose we can safely ignore it.

Also, the file structure wiki is finally up-to-date. MDenham, if you haven't checked it out before, everything we know (or think we know) about the Chrono Cross battle model structure is here:
http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html#Character_Battle_Models

[MDenham]

ADDITION: It'll take some doing to definitively prove whether or not "8-byte mode" data in Section 1-3 refers to triangle vertices whereas "16-byte mode" data refers to quad vertices. But for now, here's a side-by-side comparison of Sections 1-2 and 1-3, so that we can draw some preliminary conclusions:

SECTION 1-2 STRUCTURE                           SECTION 1-3 STRUCTURE
0x0358 ~ 0x0FB7: Triangles, 264                 0x28E8 ~ 0x324F: "8-byte mode", 301 vertices
0x0FB8 ~ 0x2657: Quads, 362                     0x3250 ~ 0x3F6F: "16-byte mode", 210 vertices
0x2658 ~ 0x26E7: Triangles, 12                   0x3F70 ~ 0x3F97: "8-byte mode", 5 vertices
0x26E8 ~ 0x28E7: Quads, 32                       0x3F98 ~ 0x4247: "16-byte mode", 43 vertices
= 670 polygons (176 tris, 394 quads)            = 559 vertices (306 in "8-byte mode" and 253 in "16-byte mode")

...Which is a bit wonky. Why would there need to be 306 vertices for only 176 triangles, yet only 253 vertices for so many quads? But depending on how they're all connected, perhaps it could still work out somehow. I think the map of Section 1-2 is correct -- Luminaire, can you back me up on that from memory? I think 670 polygons was the final figure we arrived at back in November.

Well, that throws a little bit of a monkey wrench into my original idea that 8-byte vertices are solely for triangles, though I'm still pretty confident that the 16-byte vertices are a vertex plus a normal at that vertex.  (This means that there are "curved" triangles, potentially, if any of their entries hit a 16-byte vertex.)

So now comes the easy test for whether or not I'm right about these carrying a normal:

Change the second half of a 16-byte entry that's in a relatively obvious place (I'd suggest the head, if you can pin one down there).  If there's no obvious or major effect, the second half is, in fact, a normal.  (Don't zero out the normals completely, because that'd cause potential problems with division by zero.)

I'm willing to wager that 1-4 originally was color weighting for the vertices, and isn't paid attention to anymore because either the effects weren't what Square wanted or it slowed down the PSX too much to do the model that way (it is faster to just piece a texture around it than to interpolate colors as needed, though not drastically so).  If/when we can actually get a full model put together correctly, it'd be interesting to see what happens when the model's colored according to this idea.

[halkun]

Dumb question:

Why are you using the battle screen to test when you can use the character view screen to see you changes? The character view screen has a much higher resolution so you can see things better....

[Luminaire85]

My guess is FaustWolf has been wanting to see how the battle animations are affected by his hex modifications. But you bring up a good point about looking at vertex/face effects.

670 was indeed the most recent poly count.

Don't forget that the triangle data in Section 1-2 has 6-byte pointer sections rather than 8-byte. This means that whatever decisions you make about what the pointer data means must be adaptable to both the triangle and quad data.

I'm willing to wager that 1-4 originally was color weighting for the vertices, and isn't paid attention to anymore because either the effects weren't what Square wanted or it slowed down the PSX too much to do the model that way (it is faster to just piece a texture around it than to interpolate colors as needed, though not drastically so).  If/when we can actually get a full model put together correctly, it'd be interesting to see what happens when the model's colored according to this idea.

That's what I was thinking too.