Forza Motorsport Resource Extraction (.carbin)

[Ernegien]

The contents of this post was deleted because of possible forum rules violation.

[Simon]

Wow this would be awesome to get the 3D Models of Forza in my Maya

[Dan Frederiksen]

you used some cryptic version of zip that even winrar can't unpack. could you upload a new pack?

[Ernegien]

You'll need to read the "Extraction" section and download Aluigi's QuickBMS and the zip.bms script in order to extract the archive.

The good news is I've been able to figure out most of the .carbin layout since my last posting, with exception to everything before encountering the first car section. I wrote a small program in c# to parse through everything which I'll probably be posting in another day or two.

Right now, I'm just having a hard time finding a reliable way to calculate the first section offset. Here is a generic outline on how the .carbin file contents are layed out. I'll be posting more detailed information on the individual structures once I've had a bit more time to research them.

Code: Select all

Header (unknown size)
UnknownDataList (most likely array of shorts)
Section1
   Name
   Header (size depends on value of first dword: 0 = 88 bytes, 2 = 12 bytes)
   Piece1
     Header (76 bytes)
     Name
     Indices (list of triangle strips separated by 0xFFFFFF)
   Padding (16 bytes)
   Piece2
     Header
     Name
     Indices
   Padding
   Piece3
     Header
     Name
     Indices
   Padding
   Piece...
   Vertices
Section2
   Name
   Header
   Piece1
     Header
     Name
     Indices
   Padding
   Piece2
     Header
     Name
     Indices
   Padding
   Piece...
   Vertices
Section3
...

Also, attached is an archive of a few car part's vertex data. Each vertex is 40 bytes in length and I have no idea how they are encoded at the moment so feel free to throw me some tips or suggestions

[Dan Frederiksen]

sounds good although it would probably be better if you actually rezipped the pack for everybody

have you ruled out that the first 3x4bytes are xyz 32bit floats? and since the xbox360 gpu is an ATI and the powerpc can switch endian it might just be straight intel 32bit float? or an intel float stored in 4 bytes in reverse order.

the first byte of 4 seems to always have the msb to 0 which might indicate a sign bit

we might speculate that the coordinates are kept between -6 and 6 with a meter as a unit and the model arranged near 0,0,0. what I would do. maybe 0,0,0 at the mass center projected down to the ground. so maybe x +-1.25, y +-3, z 0-2.5

would be really cool to have the models

[Ernegien]

Yes, I've obviously analyzed it enough to determine that they aren't using the standard floating point format. I've scanned for singles and doubles in either endian format on every byte boundary. It is probably fair to assume the first values are xyz coordinates, but I'm not sure if they are 4-byte values or 2-byte values yet. I did some quick tests converting 16-bit integers to floats by assuming they are clamped between -1 and 1, and then 0 and 1, but I guess it could be just as true they use 32-bit ints instead to provide more precision. That would honestly make the most sense so I'll run some tests and see what happens

[Dan Frederiksen]

do you know any 3d hardware that uses anything other than 32bit float for geometry? 16bit seems extremely unlikely to me as it's very low precision and require translation that would slow it down. 64bit is whopper overkill and couldn't be benefitted from by any graphics hardware anyway.
32bit integer would be greater precision for bounded geometry than 32bit float but again it would be useless since the hardware would run 32bit float anyway..

I think it must be a good premise to assume they are 32bit floats.

maybe try hunting for the mantissa first. only so many places the MSB of the mantissa can be and only two endians for the 4 bytes.
load as integer, mask the bits and convert to float and display or export it to see if there is any geometry resemblence. even without the exponent I'd guess there will be continuous surfaces

the implied 1 msb of the mantissa shouldn't matter too much for this

[Ernegien]

It's actually quite common for programs to pack floats into 16-bit integers. When relative to a bounding box, they can be just as precise. The extra processing power is also pretty negligible compared to the amount of time saved from cutting disk access in half. Now this might not be the case here, since these files are compressed anyways, but there would still probably be some space saved regardless...

The thing that throws me off the idea of data being packed to save space is that each vertex is already 40 bytes in length, and I can't imagine them containing much more information than that. Since the data is not in any standard floating point format though, this leads me to believe that the data is instead possibly packed for extra precision? It seems like I will have to go your route and pick apart the bits and assume this being a nonstandard 32-bit floating point format. Looks like one sign bit, anywhere from 0-5 bits for an exponent, and the rest as the significand. Guess I'll be experimenting with all the possible combinations and hopefully something shows up in my render window eventually

[Dan Frederiksen]

try big endian first, msb is sign, then exponent 6-9bits, then mantissa.
load as big endian integer, shift up 9 bits, divide by 1000000000.0f

shift up from 1-10 in both big and small endian. if it isn't in any of those I think they have intentionally shuffled the bits to make it harder to read. that could be varying degrees of gruesome but let's see if it isn't there in plain text.

[Ernegien]

Been busy lately, so I haven't been able to work on this as much as I'd like, but I know enough to fully parse through lod0 and cockpit .carbin files so here's a little stubbed out application written in c# where you can experiment with decoding vertices or other information...

[Dan Frederiksen]

looks good but I'm pretty busy on many other projects, like saving the world in all kinds of ways and some programming projects so I don't really need to be spread out more than already. so the task is really yours and you are already well into it. just a little further. will be a great scoop. keep on trucking.
I really do think you can assume 32bit float. and if it doesn't make sense, maybe consider they could have rearranged the bits to make the format harder to read.

[ajmiles]

Once you do a 4 byte endian swap over the entire vertex buffer, the first 16 bytes are 8 16 bit floats, which will correspond to 2 Half4 elements in a vertex. The first 3 halves appear to be xyz. I'm still working on the remaining 24 bytes, but I anticipate that they're either "10,10,10", "11,11,10" or "10,11,11" 32 bit packed 3D floats. This from the Ford Fiesta linked elsewhere on the Xentax forums: http://aj.uwcs.co.uk/f3/fiesta.png.

[Ernegien]

Much appreciated . I'm at work right now so I won't be playing with this to later but the other information might be related to the Granny 3D library as I've found references to it in the .xex

[Dan Frederiksen]

ajmiles, cool, certainly looks like geometry although I don't quite recognize a fiesta there.
and what format is that 16bit decimal value? if it's a float with only a 10bit mantissa that's just too low precision for a quality object. something like 5-10mm per step for a car size object. unless the implied 11th bit can bring it down to less than 1mm which I guess might just barely be enough

there should also be a facelist somewhere right? part of the vertex data somehow?

[Ernegien]

The index data is separated from the vertex data, and is in the form of a list of 0xFFFFFF delimited triangle strips. Each segment piece has it's own indices that reference the bigger vertex block of data for each main segment. The image he showed just might not be rendering all of the parts of the car, but I can definitely pick out the rear quarter panel and a gas cap