XeNTaX

I used to extract the GT PSP models using ninja reaper, every model has two meshes, one for the body (textures), and the other one for reflection, also at the moment of apply textures some UVs had issues and had to correct the UVs manually

@shakotay2, I see that the issues with polygons crosses the entire model are still present. Is this another problem you don't know how to solve or you just don't care much about it at the moment?

I don't care, I don't know...
(well, I hope it's a matter of how the faces are built)

The formula used basically is like such (loop):
f a a+1 a+2
a += 1 ;

Result:
f 1 2 3
f 2 3 4
...

But when you compare to those in the 3ds files created by the bms script there's some differences.

Maybe auto generated triangles strips will do better. As you can see here:

shakotay2 wrote: ↑Sun Oct 10, 2021 1:38 pm

Say
f 1/1 2/2 3/3
f 2/2 4/4 3/3
f 3/3 4/4 5/5

or
f 1 2 3
f 2 4 3
f 3 4 5
f 4 6 5
...

well, finally, I decided to create a Make_H2O version for Gran Turismo 4.
Credits go to FurryFan for his Gran Turismo 4 quickbms script. (I've added creation of uvs to the tool, which were missing. But, many are weird, still. See notes in zip file.)

(There's other posts where I described how to use the Multi mesh feature of hex2obj, File/SaveAs Mmesh)
Most important: hex2obj has to be switched to "Strip" and "Fake" here to successfully use the H2O files (from Make_H2O) for obj creation.
. Tested with one 32 MB eeMemory.bin file only, so don't blame me, if it doesn't work for others.

You may use "Remove Doubles" from the meshes (in blender, for example). Didn't notice any advantage, though.

H2O file _143 (_43.obj), rearBumper a), wrong uvs:

0x0 3
Vb1
12 99
0x145c2d4 62
021000
0x145c4bc 8

uvs correction (maybe), replace last line by
145C6C0 12

Address is after signature [40C0 count 68], count is 0x3E= 62 here (same as vertex count)

rearBumper parts which seem to be "ok", _75 and _76 (_140.obj, _141.obj):

0x0 3
Vb1
12 99
0x14462E4 50
021000
0x144679C 8

and

0x0 3
Vb1
12 99
0x1446964 62
021000
0x1446F3C 8

thanks @shakotay2, I'm trying to understand the process.
rn I'm getting the list of OBJX files:


If I rename them into OBJ and try to import into blender v2.74 I get this error:


I woud suggest you to use original gt4 files of cars because they are basically the same binary files that included to eeMemory.bin but with own header. here's the files: https://drive.google.com/open?id=1ya_uo ... Tx7C3vSRcd
FurryFan's bms script work with original files the same way it work with eeMemory.bin and extracts the same 3ds object.

Tosyk wrote: ↑Mon Oct 18, 2021 6:28 pm thanks @shakotay2, I'm trying to understand the process.
rn I'm getting the list of OBJX files:

Please read my previous post again:

shakotay2 wrote: ↑Sun Oct 17, 2021 9:28 pm...
Most important: hex2obj has to be switched to "Strip" and "Fake" here to successfully use the H2O files (from Make_H2O) for obj creation.

(And don't forget to delete/move all obj files of a maybe previous run.)
-----------------------------------------

Tosyk wrote: ↑Mon Oct 18, 2021 6:28 pmFurryFan's bms script work with original files the same way it work with eeMemory.bin and extracts the same 3ds object.

Without uvs.

btw: Make_H2O... ignores the eeMemory header (if any). (So does hex2obj.)

Known problems are the face indices, maybe they are indexed?
.

thanks! seems like a found why I couldn't follow you instructions. it's because I see this when I open h2o:


Anyways. I did everything and get the objects. Some of them has UVs, but most are mess unfortunately. Here's best matches:

another one:


Most of the object's UVs are like this:


I tried this method with 'pk0100_out\00006008.car' file of original gt4 game (link) and was able to get only a tire in different LODs but seems like all of their UVs are fine:

Tosyk wrote: ↑Tue Oct 19, 2021 11:21 pmAnyways. I did everything and get the objects. Some of them has UVs, but most are mess unfortunately.

"Some of them?" Well, comments like these tend me to stop my investigations. It's more than 100 out of 165 uvs which are not a mess.

Also it seems that ..._72.obj (derived from _172.H2O, yes _172) shouldn't have uvs as a simple calculation and "check of eeMemory.bin in hexeditor" shows:

vertices at 0x1464a50 - 0x1464774 = 0x2DC (block size)
(732/12= 61 verts)
Then signature 80C03D6E, 3D=count, 61*4=244= 0xF4
0x1464a50+8 + 0xF4= 0x1464B4C
so no uvs block here before
next vertex block at 0x1464B78

Make_H2O_GranT4.exe doesn't "realize" that there's no uvs. That's the reason why it creates H2O files then which make hex2obj show parts of vertex data as "messy uvs".

I didn't want to sound ungrateful. I appreciate for your help! Its' just a complicated stuff for me. Here' what I get from the h2o:
https://drive.google.com/open?id=1Hrvuz ... Ety0NT09En

I'll try to complete the process one more time today.

Hey, glad I found this topic.

After reading all of you guys talk about I still don't get it how to do it, yes, I wanted to extract the GT4 car models too but I don't know about coding, only know about 3D Modelling. Where and how should I start to extract Gran Turismo 4 car 3d models?

I want to extract them only for reference to learn how they create a low poly car with good such good shading, shape, and textures.