Forza Motorsport Resource Extraction (.carbin)

[aliann34]

Great news
Well now it's better. Just need fix materials thing and UV.
Is there a way to get models and correct scale? they are very big.
And doors are in wrong position.

Congratulations keep going like that.

[TheOnlyFillo]

So, I have the raw model files.. How do I get them to work with Make2HO?

[shakotay2]

Is there a way to get models and correct scale? they are very big.

I don't know about the "correct scale", just applied the values from the modelbin files. As I wrote before (for blender) press s, then 0.02, <ENTER> and you're done.

And doors are in wrong position.

yep, and hoods, too, dunno about the reasons. Just applied the positions from the modelbins, as above.

(But I'll look whether it's a constant offset for all models - then I could try to fix it.
Ok, wait, for the doors it's not possible so far since they need to be separated from each other before.)
edit: required offsets for hoods are different

So, I have the raw model files.. How do I get them to work with Make2HO?

Not sure about your picture.
From the readme (from zip in my sig):

Make_H2O-ForzaHor.exe doesn't create H2O files, no.
It directly logs wavefront obj data but it needs a filelist as input.

Copy dir_modelbin.cmd to a modelbin folder and execute it
(or doubleclick it in the explorer).

This will create a modelbins.txt file with a filelist.
Then open that txt file with the exe.

[aliann34]

New about new version Forza Studio(FM6A and FH3 support) ?

[TheAdmiester]

New about new version Forza Studio(FM6A and FH3 support) ?

How about stop asking and be patient?

yep, and hoods, too, dunno about the reasons. Just applied the positions from the modelbins, as above.

(But I'll look whether it's a constant offset for all models - then I could try to fix it.
Ok, wait, for the doors it's not possible so far since they need to be separated from each other before.)

Do you mean positions from each model's modelbin or the "main" modelbin? Just wondering because I experimented with a part swap: I put the Porsche 911's licence plate on the Audi R8, and the positioning of it was totally wrong. I don't precisely know which file could be controlling it, but the fact that it happened might possibly be helpful.

[shakotay2]

Do you mean positions from each model's modelbin or the "main" modelbin?

I'm talking about the separate objects like hood_a.modelbin which contain the position offsets each (what is the "main" modelbin?).
(But it's true, I've a deja vue of having skipped some promissing sections 'cause of lazyness.
Still unsure whether it might be a matter of hierarchy.)

[TomWin]

I think the position for doors might be saved in CARNAME_skeleton.modelbin or CARNAME_skeleton.gr2?

[shakotay2]

yep, makes sense that moveable parts like doors and hoods are being tied to the skeleton,
and when I use -0.884457 0.618187 0.656853 from boneDoorLF (in AST_DB11_17_skeleton.modelbin)
for re-positioning doorHandleLF_a it moves, but not enough.

Guess this position is relative to the root (bone)?

Maybe additional scaling is required, but to be honest, my motivation is low to spend more time for such details.
Would be more important to improve the uvs, imho.

[minime891]

Tried some more parts with varying success. Some polys still attached to different LODs.
I had problems with \lr_rangeroversvr_15\scene\interior\details\dashpad_a.modelbin the dash, steering wheel and steering column was one object and scaled wrong.
Also when trying to load the rear bumper i got the message "more than 15 submeshes in part - break".


As you can see in the image below the issue i mentioned with the steering wheel etc.

[shakotay2]

Some polys still attached to different LODs.

This is due to the autocreation of groups.
I don't see a simple solutions there other than manually moving the group lines (such as g body_a_001) between the triangles (f 128/128 129/129 130/130).

Obviously there's the need of two different versions, one for the "straight" sections and one for the messed up sections.
("Straight" means that the face indices increase moderately, not such as f 15399 15401 15400, f 1023 15402 15403)
This would require a two pass scanning but it's more senseful to get the magic table that holds the grouping infos, if any.

edit: two pass scanning done and rewrite of grouping part
(You'll need the dlls from the zip in my sig for the exe to run.)
Forza-h 2-pass-grouping; Make_H2O-ForzaHor-h.zip
----------------------------------------------------------------------------------------------------

I had problems with \lr_rangeroversvr_15\scene\interior\details\dashpad_a.modelbin the dash, steering wheel and steering column was one object and scaled wrong.

All moveable parts are tied to a "skeleton" and need a special treatment. Their positions will always be wrong unless someone creates the skeleton hierarchy including "root". (Should be solvable but my "time stock for this project" runs out of contence atm. )

I didn't pay attention to the steering wheels so far, will try to fix the scaling. The "one object problem" is a matter of missing group lines. (I'll try to improve the autocreation algo but there's sections in the triangles list that tend to confuse it massively.)

Also when trying to load the rear bumper i got the message "more than 15 submeshes in part - break".

That's easy to fix, though I'm wondering why it needs more than 15 submeshes per object (=part). Guess the autocreation algo creates groups where they aren't needed.

Thanks for your feedback!

[aliann34]

It seems almost complete.

[gpfan]

........
Would be more important to improve the uvs, imho.

Do you think it´s possible to create a tool to extract the texture from the swatchbin to understand how they done the job and to do some tests on the models to see what parts are good and what need to be improve eventually??

I confirm that some meshes still come with all lods together and other comes partially separated, usually the ones that are together are the last 2-3 lower lod´s, higher lods are separated.
- Some parts from the interior with lod´s are also being imported as one piece.
- Steering wheel is scale with wrong dimensions.

yep, and hoods, too, dunno about the reasons. Just applied the positions from the modelbins, as above.

(But I'll look whether it's a constant offset for all models - then I could try to fix it.
Ok, wait, for the doors it's not possible so far since they need to be separated from each other before.)
edit: required offsets for hoods are different

So no go for positioned doors and hoods/trunks/windows?
That´s not big deal since it´s easy to place them on the right place manually, that´s all one question of some love and talent...

Maybe you could further improve the Make_H2O-ForzaHor-gc.exe for better import of separate objects?
i uploaded the sample rollCage_a.modelbin i´m not able to import with separate parts, maybe it helps you to improve the exe....

https://1drv.ms/u/s!AvtMXnUqCvTviTepx6ftZce8vpM0

[Andrakann]

Done some research of modelbin structure.
Header, 20 bytes:

List of entries, 24 bytes for each entry:

lekS (Skel) entry - skeleton:

hprM (Mrph) entry - I think it's morphing data for characters models, looks empty:

ItaM (MatI) entries - materials data:

hseM (Mesh) entries - mesh data:

BdnI (IndB) entry - (?):

yaLV (VLay) entries - vertex layers?:

BreV (VerB) entries - vertex buffers?:

fuBM (MBuf) entries - ?:

ldoM (Modl) entry - model?:

(it's last index entry and no next entry header start offset is present, so global "data start" from main Grub header must be used)

So, we have 100 entries in sum: 1 Skel entry, 1 Mrph entry, 10 MatI entries, 69 Mesh entries, 1 IndB entry, 5 VLay entries, 8 VerB entries mixed with 4 MBuf entries and 1 Modl entry.

Material data entries looks like file-inside-file, they have personal Grub header with local adressing, I cut out one for closer look:

As you can see, two entries is present "MATI" and "MTPR" and those entries is also using local adressing.

Another strange thing is Name entry - this entry must have name lenght in symbols for correct reading, and it have it, but in strange format, like mirrored byte:

...or in some hex format I'm not familiar with:

18 is 12h and 31 is 1Fh - I can see some logic here, but it's strange.

Code: Select all

...
0x140b emaN b0 00 10 00 xoBB 80 01 13 body_a_LOD5 -0.753424 0.755402 -1.765556 0.753425 1.081711 0.620197 
0x143e emaN b0 00 10 00 xoBB 80 01 13 body_a_LOD5 -0.966901 0.000073 -1.803357 0.966901 0.578240 -1.000934 
0x1471 emaN b0 00 10 00 xoBB 80 01 13 body_a_LOD5 -0.815528 -0.002078 -2.096735 0.815527 0.179026 1.001929 

0x14a4 emaN` 00 10 00 xoBB 80 01 0e Shadow -0.961083 -0.000369 -2.319926 0.961083 1.047848 1.001929 
0x14d2 emaN` 00 10 00 xoBB 80 01 0e Shadow -0.802868 -0.000369 -2.130043 0.802868 0.184148 1.001929 
0x1500 emaN` 00 10 00 xoBB 80 01 0e Shadow -0.879130 0.141074 -0.786225 0.879130 1.016461 0.669687 
...

An error here: "emaN`" is "Name 60h" where 60h is 6 symbols in name "Shadow".

[shakotay2]

Do you think it´s possible to create a tool to extract the texture from the swatchbin

I would try to add a suiting header (bc1, bc5?).
Meanwhile you could look at Andrakann's results using PVTTexTool.

Maybe you could further improve the Make_H2O-ForzaHor-gc.exe for better import of separate objects?

I could try it but the better solution would be to find the magic table (if any) I spoke of.

[aliann34]

Seriously you are all wonderful. So continue. I love you all.