Forza Motorsport Resource Extraction (.carbin)

[Andrakann]

These Shadow meshes seems to be missed in Make_H2O output, they skipped or makes unwanted garbage somewhere?..

There's some datasections with 16/24 bytes blocks (first block rectangled) where I don't get proper uvs or vertices from:

unknown_data.JPG

Maybe first part it's 2 vertex coordinates for 2 corner vertices of plane? Like for bounding boxes.
And second part is transform or simple planar mapping?
They probably dont have UV maps, and this can be a clue where to find UVs for lods meshes, because of differencies mentioned earlier:

I don't really need those shadows, just curious about why there's 16 of them for a single back light?..
They can be just a dummies for holding positions for light glow effect (lots of LEDs).

but some unwanted splitting occurs.

I've little control about that. You simply can join objects (or submeshes) in blender by selecting them and pressing ctrl-J.

(The problem I have is the missing "wanted splittings". )

Yeah, it's not a big problem for sure

But what about possible wrong reading of meshes in updated part of my post?..

[javadst]

(doors , wipers position is not valid and some wrong lod parts attached to body_a and another models).

I dont have this problem in version "i1".
My modelbins.txt contains only one link to body_a, and the result is:

Nothing unwanted is attached to LODS0 parts, as far i can see, but some unwanted splitting occurs.

Upd: But, if i put some random materials to different parts, some errors becomes visible:

Red and black meshes mixed and have errors in geometry.

If i my modelbins contains only one link to body_a, yes the result is OK but mesh is not valid because the mesh is wrong detached .
i use two method (only 1part or all parts) but after i put some random materials to different parts and then rendered this parts in 3dsmax, all part is rendered to black color and material is not showed on it and i have some error in geometry: (higgledy-piggledy in geometry preview when i zoom and rotate mesh).

error.jpg

[Andrakann]

Tested BMW_i8_15 body_a mesh with "gc" version of "Make_H2O":

A lot more pieces of LODS0 here, but first and last ones have errors in splitting.
First one is with "concrete" material on my pic, and last one is selected and highlighted.
First have pieces of roof and "invisible" parts and last one have piece of body and "invisible" part of LOD1.

If i my modelbins contains only one link to body_a, yes the result is OK but mesh is not valid because the mesh is wrong detached .

Not sure about "wrong detached", but it looks wrong scaled by one axis, but my result from "gc" version looks more or less proportional:

(top ortho projection)

Version from "i1" output have exactly the same proportions:

[shakotay2]

And second part is transform or simple planar mapping?

it's uv mapping:

FOR_body_chan1_2.JPG

But what about possible wrong reading of meshes in updated part of my post?..

Your doing a great job here, Andrakann, but to be honest, I don't have the time to read/understand that all.

It's too complex for me and sooner or later ForzaStudio will be updated, I'm pretty sure.
Atm I feel finished, more or less. I'll try to improve the mapping, though, from time to time.

btw: you might try to uncomment "extra-groups" (delete the '#') in the obj file. Doesn't make sense though,
if it follows another g-line directly like here:
g body_a_000
#g body_a_1_ex

[Andrakann]

I'll try to improve the mapping, though, from time to time.

Mapping looks not really important for this models, because it seems like there's no textured parts, except gauges and livery.
Other parts uses shader materials without maps, and UVs for them can be any - converted or re-generated in 3d software.
But those errors in splitting parts is more disturbing...

btw: you might try to uncomment (delete the '#') "extra-groups" in the obj file. Doesn't make sense though,
if it follows another g-line directly like here:
g body_a_000
#g body_a_1_ex

Didn't find any "#g" or "# g" match in BMW_i8_15_body_a.obj from "gc" and "i1" outputs

[shakotay2]

But those errors in splitting parts is more disturbing...

what does 'errors' mean exactly? Talking about "unwanted" splitting? This could be healed easily by joining the parts manually (ctrl+J in blender). If I reduced unwanted splits, many wanted splits would be lost; I have little control about that, since it's just a simple stupid brute force algo used for it.
(What could be done is a free choice of params: threshold and meshsize; I'll think about that.)

Didn't find any "#g" or "# g" match in BMW_i8_15_body_a.obj from "gc" and "i1" outputs

try version -j

btw: if you could send me BMW_i8_15 body_a.modelbin I'd have a look

[Andrakann]

But those errors in splitting parts is more disturbing...

what does 'errors' mean exactly? Talking about "unwanted" splitting? This could be healed easily by joining the parts manually (ctrl+J in blender). If I reduced unwanted splits, many wanted splits would be lost; I have little control about that, since it's just a simple stupid brute force algo used for it.
(What could be done is a free choice of params: threshold and meshsize; I'll think about that.)

Didn't find any "#g" or "# g" match in BMW_i8_15_body_a.obj from "gc" and "i1" outputs

try version -j

btw: if you could send me BMW_i8_15 body_a.modelbin I'd have a look

There's wanted splits missing in first and last meshes of LODS0.
But i missed version "j"
Anyway, here's this body_a: http://www.mediafire.com/file/4nga2gnyq ... body_a.zip

Upd: In version "j" first mesh looks good:

Part of LODS0 for matte black material (invisible).

But last part of LODS0 (for carpaint material) merged with some polys from first part of LOD1 (black/invisible):

(i select some of them here, light magenta highlighted)

Only one part is commented, and it splits bottom part (probably black/invisible) from grille background part (black/invisible too):

(and they have UV layout for different maps, so it's better to split them)

[shakotay2]

But last part of LODS0 (for carpaint material) merged with some polys from first part of LOD1 (black/invisible):

yeah, that's a known bug I forgot to fix. (to be honest, I didn't know WHY the algo missed it because it clearly should be able to "see" the delta of (1128-22356= -21228) because it's set to detect a delta threshold of +/-100 atm; facecount of submesh is >49, too, so I've to debug this ):

f 20329/20329 20308/20308 26432/26432
g missing
f 1127/1127 1128/1128 1129/1129

[Andrakann]

f 20329/20329 20308/20308 26432/26432
g missing
f 1127/1127 1128/1128 1129/1129

Waay better now!

Generic shader materials looks good also for this part

[shakotay2]

wow, I'd really like to have that car (I mean when it's complete )

btw: meanwhile I found that I already had a "solution" for the problem but the code line was commented out because it led to an infinite loop.
(I placed the 'g missing' line manually)

gosh; I've solved it (too ridiculous, missed a "+1"):

f 26433/26433 26432/26432 20308/20308
g BMW_i8_15-body_a_044
f 20329/20329 20308/20308 26432/26432
f 1127/1127 1128/1128 1129/1129

But I've got 79 groups now; I'll have to check that.

well, this will take some time. There's some senseful new groups (maybe):

f 6658/6658 7065/7065 7066/7066
f 6657/6657 6658/6658 7066/7066
g BMW_i8_15-body_a_008
f 7065/7065 7062/7062 7067/7067
f 7062/7062 7064/7064 7067/7067
----------------------------------------

f 4857/4857 8227/8227 4855/4855
f 4858/4858 4855/4855 8227/8227
g BMW_i8_15-body_a_011
f 8225/8225 8226/8226 8228/8228
f 8228/8228 8227/8227 8225/8225

but a lot of superfluous ones:

f 3510/3510 3509/3509 2548/2548
g BMW_i8_15-body_a_002
f 3509/3509 3510/3510 3511/3511
f 3512/3512 3513/3513 3514/351
----------------------------------------

f 3606/3606 3610/3610 3608/3608
f 3611/3611 3609/3609 3608/3608
f 3609/3609 3611/3611 3612/3612
f 2637/2637 3613/3613 3610/3610
f 3613/3613 2637/2637 2634/2634
g BMW_i8_15-body_a_003
f 3614/3614 3608/3608 3610/3610
f 3608/3608 3614/3614 3611/3611
f 3615/3615 3610/3610 3613/3613
----------------------------------------

f 5070/5070 5065/5065 5067/5067
f 5065/5065 5070/5070 5068/5068
f 5071/5071 5069/5069 3161/3161
f 3161/3161 3176/3176 5071/5071
f 5072/5072 5067/5067 5069/5069
f 5069/5069 5071/5071 5072/5072
f 5067/5067 5072/5072 5070/5070
f 3176/3176 5073/5073 5071/5071
f 5073/5073 3176/3176 3174/3174
f 5070/5070 5074/5074 5068/5068
f 3174/3174 5075/5075 5073/5073
f 5075/5075 3174/3174 3175/3175
f 5074/5074 5070/5070 5076/5076
f 5072/5072 5076/5076 5070/5070
f 5076/5076 5077/5077 5074/5074
f 5078/5078 5075/5075 3175/3175
f 3173/3173 5078/5078 3175/3175
g BMW_i8_15-body_a_006
f 5077/5077 5076/5076 5079/5079
f 5080/5080 5074/5074 5077/5077
f 5074/5074 5080/5080 5081/5081
f 5081/5081 5068/5068 5074/5074
f 5082/5082 5079/5079 5076/5076
f 5076/5076 5072/5072 5082/5082

(Guess I'll end up introducing a third pass to delete those groups again. )

[Andrakann]

But I've got 79 groups now; I'll have to check that.

BMW_i8_15 body_a.modelbin has 52 submeshes inside (without Shadow ones), so it's not a big fragmentation i think...

I'm checking gauges mesh of FOR_RangerT6_14, looks like UVs is good (just unscaled a little), but only one mesh is produced by "j":

5 materials found inside gaugeCluster_a.modelbin:
digitalgauge
gauge_001
paint_gold
screw_002
steel
And 5 Meshes (+ 2 Shadow meshes).
I uncomment all meshes inside gaugeCluster_a.obj, but it split out only this small (but detailed) thing:

I think your newer version of Make_H2O produce better result for splitting, i will wait till it's done

[Andrakann]

Tested gauges for CAD_ATSV_16:

UV is also right, but flipped vertically.

Lite texture in PNG (diff one is black): http://www.mediafire.com/view/0iw548p4m ... eedb43.png

[nick22savino]

could there maybe made a video tutorial for converting textures from swatchbin to dds?

[Andrakann]

could there maybe made a video tutorial for converting textures from swatchbin to dds?

Not me, sorry, maybe someone else do it, who's figured it out and have time for making videos...

Or maybe zwrtron share his tool.

[zwrtron]

So as you may noticed, I've developing Java texture conversion tool (together Tado Hmn) to convert textures from .SWATCHBIN to DirectX10 DirectDraw-Surface .dds, surprisingly its called 'SWATCHBIN2DDS".

As of now, according to @Andrakann 's great texture conversion guide, the tools is currently able to do following:
• As java can only read file bytes, we were forced to write our own, in-built hexidecimal editor from scratch!
• Collect data from SWATCHBIN file required to create new generic dx10 dds header.
(texture width, height, compression, mipmaps, data start)
• Writes collected data to generic dx10 dds header loaded as an instance to the tool.
• Cuts data apart from SWATCHBIN according to collected data-start value index to the end of data flow.
• Generates .dds image to the directory with SWATCHBIN containing bytes from newlty generated dx10 dds header instance and cutted (data-only) bytes from SWATCHBIN file.
• can convert all SWATCHBIN files from folder to DDS in one go.

- currently only standard resolution type textures are supported: 64^2, 128^2, 256^2, 512^2 ....
- has no UI at moment so...

But however, the tool is not ready to be released as BETA yet, because we need to discover differences between DX10 dds headers as mentioned by Andrakann in this post:

For DX10 it's position is 1Ch, but there's other changes always present:

Bytes at positions 6Ch and 6Eh, plus unknown counter at pos. 15h.

Maybe here you can get some clues...

So if anyone could provide some informations, please pm me.