[Request] Wipeout HD/Fury

[o0DemonBoy0o]

Well that's about as much as I can figure out. I can't think of anything else to try.
Hopefully this is all figured out soon as the models in this game are really nice looking.

[shakotay2]

cool colors! Like it.

Here's a Make_H2O.exe for Wipeout - tested with Feisar only.
(As you know you'll need Hex2obj_0.24x.exe for correct uvs.)

Make_H2O-Wipeout.zip

Four H2Os are corrected by Hex2obj and the resulting obj files renamed to .objx.
Simply rename them back to .obj. (Too tired to check that problem.)

(Read the How-to-use file!)

edit: seems to work with Feisar only. Other model was displayed, well, "§$%&!

Main issue seems to be that the FVF type isn't recognized correctly, since 0AE0 refers
to a FVF (VB) size of 18 instead of 14 for the other model. (made a 2nd exe for the 'other' models)

Another one is a superfluous FI start address spoiling the order. edit: done

[shakotay2]

the sample from the first post:

other.JPG

H2O files:
http://www.uploadmb.com/dw.php?id=1433708887

use them with hex2obj as explained in attachment of previous post.
(rename .objx to .obj)

[o0DemonBoy0o]

Thanks.
The only other thing I can think of is maybe the ship.vex file. It looks like it has information on bones as well as the objects.

Here is the one for Feisar to look at.
https://www.dropbox.com/s/3ms8wjpec9eo0ad/ship.vex?dl=0


Edit:
The program works great and saves a bit of time, though sometimes it will get the start of faces wrong.
In another model I tested it had the start of faces as 0x25c40 instead of 0x26300
I'm guessing it searches for 00 00 00 01 00 02 instead of going to the offset here?



Just something I thought I would point out.

[shakotay2]

[...]and saves a bit of time

a bit?
Seems you've got a faster method for these corrections by Make_H2O:

Code: Select all

0. -32, last addrFI (act.): 5700 (5700), vStart: 14c0 CORRECTION vertex count (944->937)!
1. 196496, last addrFI (act.): 3c580 (3c580), vStart: 6c80 --
2. 173312, last addrFI (act.): 3c580 (3e400), vStart: c5f0 --
3. 150752, last addrFI (act.): 3c580 (3ff80), vStart: 12050 --
4. 127280, last addrFI (act.): 3c580 (42400), vStart: 178a0 --
5. 103808, last addrFI (act.): 3c580 (43980), vStart: 1d450 --
6. 80624, last addrFI (act.): 3c580 (44e00), vStart: 23000 --
7. 57440, last addrFI (act.): 3c580 (46900), vStart: 28a90 --
8. 33984, last addrFI (act.): 3c580 (48480), vStart: 2e510 --
9. 10368, last addrFI (act.): 3c580 (49a00), vStart: 340c0 --
10. 16, last addrFI (act.): 3c580 (4ac80), vStart: 39cf0 CORRECTION vertex count (576->571)!
11. -48, last addrFI (act.): 4bd80 (4bd80), vStart: 4b5d0 CORRECTION vertex count (144->138)!
12. -32, last addrFI (act.): 4c300 (4c300), vStart: 4c050 CORRECTION vertex count (40->36)!
13. 7136, last addrFI (act.): 53a00 (53a00), vStart: 4c540 --
14. -64, last addrFI (act.): 53a00 (55c00), vStart: 51e20 CORRECTION vertex count (400->396)!
15. 32, last addrFI (act.): 57200 (57200), vStart: 564c0 CORRECTION vertex count (240->234)!
16. 80, last addrFI (act.): 57c80 (57c80), vStart: 57a20 no corr.
17. 32, last addrFI (act.): 57f00 (57f00), vStart: 57dc0 no corr.
18. 64, last addrFI (act.): 5b500 (5b500), vStart: 58070 CORRECTION vertex count (744->742)!
19. 32, last addrFI (act.): 5ee80 (5ee80), vStart: 5c940 CORRECTION vertex count (528->525)!
20. 16, last addrFI (act.): 64f80 (64f80), vStart: 5fae0 CORRECTION vertex count (984->980)!
21. 39456, last addrFI (act.): 75500 (75500), vStart: 65fc0 --
22. 15984, last addrFI (act.): 75500 (76b80), vStart: 6bae0 --
23. 0, last addrFI (act.): 75500 (78000), vStart: 71690 CORRECTION vertex count (888->887)!
24. 48272, last addrFI (act.): 8a600 (8a600), vStart: 78ee0 --
25. 24800, last addrFI (act.): 8a600 (8bf80), vStart: 7e970 --
26. 1472, last addrFI (act.): 8a600 (8d480), vStart: 84520 --
27. -80, last addrFI (act.): 8a600 (8ec80), vStart: 8a020 CORRECTION vertex count (88->83)!
28. 48, last addrFI (act.): 91880 (91880), vStart: 8ef40 CORRECTION vertex count (584->581)!
29. -32, last addrFI (act.): 92800 (92800), vStart: 92270 CORRECTION vertex count (104->98)!
30. 98768, last addrFI (act.): b1900 (b1900), vStart: 92ca0 --
31. 71152, last addrFI (act.): b1900 (b2f00), vStart: 99720 --
32. 43872, last addrFI (act.): b1900 (b4100), vStart: a0310 --
33. 16432, last addrFI (act.): b1900 (b5880), vStart: a6d90 --
34. -112, last addrFI (act.): b1900 (b6c80), vStart: ad8d0 CORRECTION vertex count (752->745)!
35. 112, last addrFI (act.): b9780 (b9780), vStart: b78d0 no corr.
36. 64, last addrFI (act.): bbb00 (bbb00), vStart: b9c80 no corr.
37. -64, last addrFI (act.): c0a00 (c0a00), vStart: bc000 CORRECTION vertex count (864->859)!
38. 41968, last addrFI (act.): d2b00 (d2b00), vStart: c1bd0 --
39. 14512, last addrFI (act.): d2b00 (d3e80), vStart: c8710 --
40. 80, last addrFI (act.): d2b00 (d5200), vStart: cf250 CORRECTION vertex count (656->654)!

(well, forgot about auto correction of hex2obj. Seems I've wasted time with the formulae... )

I'm guessing it searches for 00 00 00 01 00 02 instead of going to the offset here?

yep. Updated the download link above.

[zaykho]

Always loved those wipeout model, nice guys !

[modes]

thanks for the infos

my problem is in the maxscript fast complet

problem next model of object in the maxscript.

problem ship pose for the objects.

shakotay2 thanks for the hexobj programm this programm is very very nice thanks

[o0DemonBoy0o]

Hey shakotay2, Make_H2O crashes on some of the ships. Here are a couple examples
https://www.dropbox.com/s/zwytulqqi5xpe ... s.zip?dl=0

I can't seem to find out why it crashes on these and not others.

[shakotay2]

Hi o0DemonBoy0o,
thanks for reporting.
From a first glance I can see that for goteki.rcsmodel for example
a wrong FVFsize is chosen (18 instead of 22). (Despite the crash 15 H2O files are being created.)

Determining the type is a little bit confusing as you can see from this code snippet:

Code: Select all

           switch (FVFtype[cnt]) { // 0AE0-> FVF= 18 statt 14 bei Feisar!
                    //case 0x0C00:
                case 0x09C0: strcpy(lines[2], "22 18") ; lastFVF= 22 ; break ;
                    //case 0x0AE0:
                case 0x0A50: strcpy(lines[2], "18 14") ; lastFVF= 18 ; break ;
                    //case 0x0B70:
                case 0x0AE0: strcpy(lines[2], "14 10") ; lastFVF= 14 ; break ;  // set to 0AE1 for 'other'
                case 0x0: break ;                                   // leave last type
                default: fprintf(stream, "ERROR with H2O%d: unknown FVFtype %x\n", cnt, FVFtype[cnt]) ;
            }

There's 3 possibilities to circumvent this:

• find the type byte in the model if any (very time consuming)
• let the customer choose manually from 14, 18, 22 (very ugly)
• find a cool formula (nice thing, not easy to invent, but my most preferred method)

ok, "a simple formulae" thingie didn't work (vertex blocks of two submeshes glued together for example, weird)

So I decided to introduce a user editable parameterfile: WipeOut.txt- hope, you'll love it.
There's a word flag I used to decide which FVFsize to use. Works in most cases.

For unknown FVFtypes a size of 18 is used as default (doesn't work always).

You may expand the WipeOut.txt by further entries.
But don't touch these three entries: 0xFF14, 0xFF18 and 0xFF22. NEVER.

From the pic you maybe can see that for triakis the flag 0x0a90 has to be added
in the 0xFF22 section (FVFtype=22)

because of this line in the MakeH2O_log.txt file:
> CHECK H2O14: unknown FVFtype a90
14. 1120, last addrFI : 74200 , vStart: 72a80 (FVFsize: 18) --
(which had set a default FVFsize of 18 for unknown types, see above)

goteki.JPG

Here's the WipeOut.txt from the zipped file:
0xFF14
0x08C0
0x0AE0
0x0AA0
0x1370
0xFF18
0x0000
0x0A10
0x0A50
0x1490
0xFF22
0x0980
0x09C0
0x0A90
0x1400

and here's the "special one" for triakis where the 0x0000 entry was moved:
0xFF14
0x08C0
0x0AE0
0x0AA0
0x1370
0xFF18
0x0A10
0x0A50
0x1490
0xFF22
0x0000
0x0980
0x09C0
0x0A90
0x1400

Not sure about the handling of 0x0000. Maybe using the FVFsize of the previous submesh in this case is the better choice?

(Did not check previous models with this exe version so keep that one from earlier in this thread.)
Make_H2O-WipeOut.zip

Watch out for objx files. Rename to .obj and adjust vertex count and/or FVFsize if required.

(Keep in mind that the concerning H2O file number can be found in the first line of an obj file created by hex2obj.)

(Use File/SaveAs Mmesh to create the obj files and the load_multi_obj_blender2.49.py (or...2.69.py) script to load them.)

And, as you know you'll need Hex2obj_0.24x.exe for correct uvs. Yeah, I know, that's totally ugly;
I'd like to make a max script for this in my next life...

[o0DemonBoy0o]

Thanks again. I think I might have found a solution for the FVFtype that seems to work on most if not all ships.

Looks like all we had to was not use those numbers as identifiers but go to that address itself.
goteki for example, if you go 0x0980, 0x0a10, 0x0aa0, you will get XX 16, XX 12, and XX 0E which is thier FVFsize.
And yeah if it's 0x0000 the using the FVFsize of the previous submesh seems to work out just fine.

Also does Make_H2O have a limit on how many h2o files it can make? I wanted to try extracting a stage but those can have hundreds of meshes.

[shakotay2]

Thanks again. I think I might have found a solution for the FVFtype that seems to work on most if not all ships.

Looks like all we had to was not use those numbers as identifiers but go to that address itself.

cool finding!
(Wish you had told me this before I introduced that awful WipeOut.txt file. )

Also does Make_H2O have a limit on how many h2o files it can make? I wanted to try extracting a stage but those can have hundreds of meshes.

It's limited to 99 submeshes which I thought to be sufficient for normal models.
Guess 1999 submeshes would be enough for stages, won't it?

[o0DemonBoy0o]

I just found that out today after looking though some of the models again.
I'm not sure why I didn't see it sooner. I've also seen model with FVFsizes of 10 and 26.
for 26 the UV pos is 22 but i'm not sure about 10.

As for the stages, the largest one has around 2630 submeshes.

[shakotay2]

new version of Make_H2O for Wipeout:
Make_H2O_Wipeout.zip

(untested: FVFsize:10, uv-pos:6; 26/22;
maximum submesh count: 3000)

(Wipeout.txt isn't used anymore.)

[modes]

here is my maxscript not complett pleas help complette script.

thanks all

[josema0890]

Hi guys, first of all sorry if I revived an old post, today I was trying to extract the tracks from WHD Fury (moa therma) following your steps, but I ended with a pile of "garbage" (I think i ended up with "this" because i didn't found the face index, or mb because is a big object with multiple meshes) so i ended up taking a little help and upload the track file asking for your good guidance.

And ty for your guide on how to do it with the feisar ship, so far i got it looking nice with quixel suite and i want to make a wipeout with UE4 for free to enjoy it on our pcs

Here is the rcsmodel file: https://www.dropbox.com/s/t3bgnunlrgyse ... model?dl=0
And here is the pic of the Livery