XeNTaX

ajmiles, what vertex data do you suspect employs that format?

Those formats are useful for normals where the 10/11bit precision doesn't really matter. If there are any tangents/binormals those could be 3D unit vectors too.

I wouldn't expect to see a material ID of any kind though since the meshes already seem to be split up per material. "chrome", "matte_colors", "plastic" etc. I'm not familiar with smoothing groups so can't say whether those exist or not.

It'll be easier to tell whether the X and Y of the second half4 are UVs or not when we get the textures working, something I can look at doing perhaps this weekend.

EDIT: It's worth bearing in mind that the only formats these vertex attributes can be in are format that are readily consumable by the 360 GPU, so this rules out any sort of strange format. They aren't likely to spend their valuable load time decrypting super-compressed formats.

I do not believe for a moment that they do not allocate a bit of data for smoothing groups of the meshes.
The data is exported from the modeling program to their internal format retentive of all data that it left with.
MaterialID, smoothing groups, etc.
As aj pointed out, the materialID just tells the exporter how to break up the model further so there wouldn't be much need to save those in the model format.
But smoothing groups are a necessity.
The only other option for the engine to decide which areas to smooth on the model and to what degree otherwise would be an automated process.
And as anyone who has used a 3D modeling application knows, this is far too inaccurate. Much less for a triple-A title like Forza 3.

From what I've just read in the last 5 minutes about smoothing groups, that appears to me to be a feature more for the modelling tool that for DirectX/OpenGL to use at runtime. Once the vertices have been exported and given the appropriate normals, I don't see what information can be gained from having smoothing group ids, or what the vertex/pixel shader could do with that information if it had it.

Perhaps I wasn't articulate.
In the past with model formats from:
Halo 1
Halo 2
Halo 3
SDK tools for Halo: Custom Edition
Forza 2
FEAR
As well as a few others, all have used smoothing groups retained from source-exports.

Every current-generation game uses and retains smoothing groups in their model data.
You just cannot go without them.
Artists very carefully create them when making the model, as their poly topology depends on it.
To just... lose those wouldn't make any sense.

Side note:
I fixed up another model export-

ajmiles, if the vertices have normals then smoothing groups are no longer needed, that's right.

Edit: but that said, while the format wont need smoothing groups for rendering on hardware because it has the vertex normals, we are talking about extracting the geometry for use in editors and editors rarely take in vertex normal formats. so while the format might not have smoothing groups we have the reverse situation that we likely have to create the smoothing groups from the vertex normals.
or just live with autosmoothing them when we get them in the editor. auto smoothing will likely do quite well.

add to the mix of issues that we still have the low vertex position precision issue that will also need to be resolved through an algorithm aided by the vertex normals. otherwise the models will look dented because.. it is dented by the poor 16bit float precision. in the game they just fake the smoothness because they have the normals

Dan, you're speaking some sense!

I hope you are able to find a Solution with this Flipped Polygons really quick

I would need hours to fix one car by hand

But I think some days and it's working like a charm, right?

Though it would take longer to model the same car with that level of laser-scanned accuracy in many cases.

Ernegien shouldn't have a problem fixing the flipped faces, I suspect it's just a case of not inverting the winding order every time he hits a triangle strip restart.

I'm not how easy it'll be to reconstitute the smoothing group information. Presumably smoothing groups exist so that vertices can be shared between polygons with different materials? (I think.) After the export to the vertex buffer has taken place any vertices that were shared were instead duplicated in each mesh that needed them. It may then be possible to find all the vertices that exist in more than 1 mesh, collapsed them into a single vertex and provide indices to which meshes/materials they belong?

ajmiles, no, smoothing groups is the information used to make (part of) a mesh not flat shaded. can be same material or across many. that's independent. smoothing group is actually a really sloppy system. a smoothing group is a group of faces that are to be rendered as one smooth surface. it contains no specific normals. all you have is the flat faces and the command to smooth them. the rest is implicit. it has some significant weaknesses but the advantage for editors is that it never has to deal with the extra layer of normals that have to be transformed just the right way which in general is impossible anyway.

since these cars are mostly nice continuous surfaces, the autosmooth function that most editors have will likely do a good job of remaking the smoothing group info. BUT we have to deal with the dented low precision geometry or the dents will just show up in the smoothing.
in the game they hide the dents because the vertex normals have no dents. which also means it's possible to refine the dented geometry with the aid of the presumably smooth vertex normal data.

it's interesting how that which looks so neat and apparent in a game is actually really messy

Mind you autosmooth will never work properly until quads are extracted rather than triangle strips.

I'd be interested to see any evidence of the denting as a result of the 16 bit positions.

ajmiles, well maybe I'm reading too much into it and it might not be a problem in practice after the smoothing but I'm looking at the shaded veyron on page 3, particularly the flat wheel arch. looks like there might be a minor unevenness but maybe that's just a result of optimization reducing the face count.
maybe it's not a problem in practice. would be easier. although clear reflections would amplify any perturbation. we'll see

I've confirmed tonight that at least 2 sets of 4 bytes towards the end of the vertex are one of the 11 bit combination formats, I've just not decided which one yet . Wherever you see 00 00 03 FF in the file, this is effectively 0 0 1023, which, assuming 11 bits for Z (-1023 to 1023) would indicate a vector of 0 0 1. The other common bit pattern you can see in the file is 00 00 04 01, which is 0 0 -1023, or the unit vector 0 0 -1. I've tested many of the non 00 00 00 03 / 00 00 04 01 bit patterns and they're all unit length vectors. The reason I've not quite decided which of the two 11bit packed format they are is because I could just be 1 bit out and the error may not be large enough to notice, and I'm also tired . I'll decide tomorrow which format they're in, and also investigate whether any of the other unknown 4 byte attributes are in a similar format.