Did some research on this last night and got pretty much the same results. Haven't really looked at the bounding box portion of the data (which I had just been calling the header).
All the headers I've checked can be searched for by the last match of the same regex when searching as hex with spaces between each byte:
[CODE title="Regex"][0-9]{2} ([A-F0-9]{2} ){3}C[A-F0-9]{1} ([A-F0-9]{2} ){3}4[A-F0-9]{1} ([A-F0-9]{2} ){3}C[A-F0-9]{1} ([A-F0-9]{2} ){3}4[A-F0-9]{1} ([A-F0-9]{2} ){3}4[A-F0-9]{1} ([A-F0-9]{2} ){3}4[A-F0-9]{1} ([A-F0-9]{2})[/CODE]
Last byte in the header being the number of cut groups.
As an example:
[CODE title="Coco-Nutty Pirates LB (Lahn)"]header
00 B8 40 8F C1 30 2A 5A 41 2D B2 5D C1 B8 40 8F 41 CB 21 EF 42 12 A5 2A 41 06
groin cut
04 5A 5E 02 C1 00 00 80 BF 0C 3F 4B BA EE 2E BC 38 8E C0 E0 C2 3D 82 E6 34 3C 32 76 3F 86 55 8C BE 98 74 02 C1 00 00 80 3F 4D 3A 42 BA 2A 89 5D 39 9C 0A C1 42 00 00 00 00 6E 4D 7E BF DE 74 EB 3D
left leg
05 BC 4F 6F C1 97 1D 56 BF 92 76 33 3E 0A F5 04 BF DB 75 C6 C0 D1 96 7F BF F1 FA 67 3D 82 D1 EE B1 92 E0 E0 C2 FB C3 75 34 3C 32 76 3F 86 55 8C BE AB C2 F3 C1 24 F0 7F 3F FC 06 DC BB 75 7F AB BC C8 E5 8C 41 00 00 00 00 00 00 80 BF D7 C5 03 34
right leg
05 AD 75 C6 C0 D1 96 7F 3F F1 FA 67 3D 82 D1 EE B1 D7 4F 6F C1 97 1D 56 3F 92 76 33 3E 0A F5 04 BF 90 E0 E0 C2 AC 0C 92 33 3C 32 76 3F 86 55 8C BE A2 9D F7 C1 00 00 80 BF E7 27 F3 39 D8 52 7A AE C8 E5 8C 41 00 00 00 00 00 00 80 BF D7 C5 03 34
second groin cut
04 FE 7C C5 C2 00 00 00 00 05 8C 76 3F 2B D9 89 BE F3 3C 96 42 00 00 00 00 58 FF 7F BF 6E 6C 93 3B B7 8C 3C 41 DA 20 7B BF 3F 1F 45 BE 66 47 CF 3C B7 8C 3C 41 DA 20 7B 3F 3F 1F 45 BE 66 47 CF 3C
right breast
05 34 98 BD C1 CC 28 36 3F 44 C2 D7 3D AE D6 31 BF D4 FE 09 C3 DD 5D C7 BE 4F CB 6B 3F 85 7D 16 3B C0 91 6B 42 AA F2 11 BF 35 40 E1 BE 06 A0 31 3F 26 8B F9 42 DD 5D C7 3E 4F CB 6B BF 84 7C 16 BB 4D C8 CB C1 C2 A2 26 3F EB FC 8B 3E 98 4C 35 3F
left breast
05 31 91 B2 C1 96 40 36 BF 88 4C C9 3D 21 02 32 BF EB 3B 0A C3 28 EF C3 3E 66 83 6C 3F 34 08 E9 B4 56 70 3E 42 AB E8 1B 3F 89 EC BB BE AC FF 33 3F A5 99 F0 42 C0 77 E3 BE B0 AC 64 BF 7D 87 8C BD F2 0E 06 C2 F7 E5 20 BF 39 60 A7 3E 36 AD 34 3F[/CODE]
So, 6 cut groups as defined by the header. For each cut group, you have the number of positions as the header byte, from which you can determine how long that cut is going to be, as each group is 16 bytes. So 02 would be 32 bytes, 03 would be 48 bytes, etc (plus the header byte). In randomly picking pacs to examine, the highest I've seen was 06.
Your hypothesis on there potentially being a correlation from the cut type index of the relation to the cut group index is interesting. With the above example, we have two groin cuts (first and fourth), which would seem pretty needless unless they are meant to cut different things (nude vs underwear, for example). However, the Lowerbody relation only lists three cuts:
Edit: Re-checked and both groin cuts are necessary for this one. First one is higher than the second cut, which, when combined with the two leg cuts, makes it so that the little big of leg that is exposed in the pants shows.
[CODE lang="xml" title="Lowerbody"]<Relation CutType="Lowerbody">
<Cut>Underwear</Cut>
<Cut>Nude</Cut>
<Cut>UnderUp</Cut>
</Relation>[/CODE]
Interestingly, this relation lists Underwear before Nude, unlike most of the other relations, but I haven't seen a meaning to their order. When creating new cuts (or excluding cuts), I've generally been appending new cuts to relation cut list with no unexpected results that might occur due to them being ordered.
Next step will be for me to start playing with the individual cuts themselves to see if I can get to the point of creating custom cuts. It's currently pretty easy to manipulate the groups, but I still have to load up BDO to verify what is getting cut.
