While I was analysing the hex data of aaac.p today(I printed it out cause it was too tedious to read it on the screen), I noticed something that might interest some of the people here. Maybe some of you might already have noticed it but I wouldn't know so I'll just tell you guys just in case.
Here's a snippet of aaac.p from address
00000270 - 000002E0
**********************************
0200 0000 0000 0300 0300 0100 0000 0400
0400 0300 0000 0500 0500 0600 0600 0000
0200 0500 0100 0700 0700 0800 0800 0100
0700 0900 0900 0800 0300 0700 0800 0200
0400 0700 0400 0900 0500 0A00 0A00 0600
0A00 0B00 0B00 0600 0A00 0C00 0C00 0B00
0D00 0C00 0C00 0500 0500 0D00 0C00 0900
**********************************
Here you can obviously see that a hex value of '00' appears after every one value.
Refering to the example of a .PLY file,
the #poligon section contains no. that are alternated by spaces. This is what I think the hex represents. Any other opinions?
If the .P files are in fact "not compressed",
then the .PlY, .GRP and .MAT files should only be combined into one file and their text would be written in a different ASCII order(assumption again).
If this proves to be the case, then all I have to do is do a statistical appearance of all characters in the .P file. Then, I can check for characters that occur less than 3 times, since the '@' can only appear a maximum of 3 times as a header to describe the version of the .PLY, .MAT or .GRP file.
Anyone have any other opinions on how the files would be combined?