Forza Motorsport Resource Extraction (.carbin)

[Simon]

Wow really great work guys

Do you will write an import Script for Maya or 3DS Max?

[Ernegien]

My application will most likely just export to wavefront .obj where you can import into 3ds afterwards. Thanks to ajmiles, I finally got a programmatic way of decoding some of the stuff and getting it rendered. I'm finishing up the rest of the camera class, then I'll move onto rendering and exporting individual sections or parts of the car...

[Simon]

Wow your work is Amazing!!!

obj is great too

One more Question: What about UVs/Textures?

[Dan Frederiksen]

Ernegien, did you use the xysz format? did that work. so X=x*s, Y=y*s, Z=z*s

and we need those faces too. so get cracking : )
and find that offset allready. how hard can it be : )

[Dan Frederiksen]

we need the smoothing groups too which I would guess is an integer for each face.
material ID might also be an integer per face.
or rgb face or vertex color or int texture ID maybe.

[Ernegien]

Yeah faces are loaded, I'm just using a point rendermode temporarily until I append color data or texture coords to my vertex buffer so it doesn't look like a giant black box with no shading. The format that I'm currently using is <x*z, y*z, z*w>. Smaller detail parts seem to use different transformations (notice the mess towards the origin), or maybe these scales are wrong to begin with since they seem kinda weird anyways. The last 2 floats of the first packed 8 seem to be the UVs and the other 24 bytes we believe to be 32-bit packed data which means plenty of other per-vertex information as well. If someone would like to take a look at decoding the .xds texture files that would be great Honestly I don't know too much about this stuff so it's all a learning experience for me. I was originally just doing this for a buddy so he can use them in his renders

[chrrox]

If you post a model file here ill look at it to help with the format.

[Dan Frederiksen]

Ernegien, look at the vertex math. try renaming the w to z and the z to s. makes more sense does it not..

[Ernegien]

chrrox, what would be easiest for you? Dumps of each section of vertex data prefixed with the unknown floats in their header?

[Ernegien]

Got my app exporting pieces and sections which all seem to render ok. They are a little rough and probably need to be scaled again by some unknown value for perfect precision. These pictures pretty much confirm that the floats in the beginning of each section have something to do with positioning everything (and hopefully include some more scales ), since they all render fine separately...

Also, my buddy brought up some other minor problems that will probably need to be addressed later on for proper skinning which are flipped faces (should be fixed when normals are extracted) or the combination of parallel adjacent triangle strips into a single polygon (not yet sure if this process is calculated or pre-defined). These are most likely caused by my simple model ripping methods, but again, I'm not well versed in this area so I think things are going pretty well at the moment...

I've attached my updated source. It does very basic renders of the vertices and you can decide exactly what gets rendered by unchecking the boxes. It will export all vertex information, or export face information for sections and pieces but does not do selective exporting based on checked pieces yet. I started cleaning up the source but messed it up again, so go easy on me. It's probably time to change the name of the application as well, so if you have any suggestions feel free to make them

[Veegie]

Rendered out the Ferrari F430 Scuderia rim quickly after unifying the normals.

[Dan Frederiksen]

very nice. yes it does look like that 16bit float is not precise enough. what a shame. might be possible to compute a slight repositioning of the vertices by normals if they are there. but wont be the easiest of algos.

but we have geometry at least.

still missing:
element offset (xyz float)
smoothing groups (guessing an integer per face, 8bit)
uv mapping (two floats per vertex, guessing 16bit)
material (might be vertex color rgb 8bit or face color or integer face texture id)

then it's pretty solid : )

[Simon]

Wow

Your work is so amazing

Is there any Way to Export the whole car and all parts on the right location?

Exporting the right offset/pivot would work too





I hope I'm not too annoying to you but I noticed it's only working with Importing the OBJ Files in Blender and then Exporting OBJ Again from Blender if I want the car in Max or Maya?!

And I'm looking forward to new Version with fixed Normals/No Flipped Polys and so on

[Ernegien]

Sure, theres a way, I just haven't figured it out yet...

If someone wants to take a look at decoding the other 24 bytes of data, ajmiles mentioned one solution where there are 3 floats that get packed into 32 bits (10, 11, 11 bits for each float inside) where each one has a sign in the msb, a 4-bit exponent, and the rest is the mantissa. I've calculated the masks and shifts needed to extract the individual pieces from the 32-bit dword. If someone would like to test this theory that would be great, as I probably won't have much time to work on this stuff today... :/

Code: Select all

first		    second		    third		       mask		 shift
1 1111 11111	1 1111 111111	1 1111 111111

1 0000 00000	0 0000 000000	0 0000 000000	& 0x80000000
0 1111 00000	0 0000 000000	0 0000 000000	& 0x78000000 >> 27
0 0000 11111	0 0000 000000	0 0000 000000	& 0x07C00000 >> 22

0 0000 00000	1 0000 000000	0 0000 000000	& 0x00200000
0 0000 00000	0 1111 000000	0 0000 000000	& 0x001E0000 >> 17
0 0000 00000	0 0000 111111	0 0000 000000	& 0x0001F800 >> 11

0 0000 00000	0 0000 000000	1 0000 000000	& 0x00000400
0 0000 00000	0 0000 000000	0 1111 000000	& 0x000003C0 >> 6
0 0000 00000	0 0000 000000	0 0000 111111	& 0x0000003F

[ajmiles]

I'll take another look tonight, but the 10/10/10, 11/11/10 and 10/11/11 formats I'm thinking about aren't in a floating point format, they only expand to that once read in the shader. If you take a look at http://msdn.microsoft.com/en-us/library ... S.85).aspx, that's the sort of format I'm thinking they may be in. That's the 11,11,10 version, the other two have similar structures in that Math library.