XeNTaX

Mega THANKS!

v0.21 is up
new feature "point cloud":
press "p" or "shift p" to change point size

The v0.21 H2O format changed slightly. So you can't use it with elder versions of the hex2obj.
hex2obj v0.21 can read elder H2O and will convert them to v0.21 when saving them.

I have a error with the latest version of hex2obj in dante inferno models.

in the version 0.2x with mixed mode all meshes works perfectly in the option HF_no including all uv correctly, but now with the latest version the same config don't work (only on hf_uv I can export meshes but without uv) and I can't export meshes with uv because only work in hf_no

this is a capture from 0.2x version



( the result are in a previous post )

this is the result in the latest version



here is the model

http://www.mediafire.com/download/ec7mu ... 8/0202.rar

this happens in all models

is possible to fix?

thanks for your help

my bad - I didn't comment out a test line for kao kanguroo
thx for reporting!

Also fixed a clipping bug for uv values >1.0
reported by o0DemonBoy0o.

fixed with v0.22 (view start post)

UVs of DarkSiders 2 (PC) models:



H2O files (hex2obj ver. 022 required):

Deadlord:
0x25D11 28497
Vb1
52 99
0x46787 6396
020100
0x33BB3 12

Darkwar:
0x1E5EB 32655
Vb1
52 99
0x44A61 7623
020100
0x2E509 12

(Someone might try out the last one with a texture file to check whether the overlapping uvs matter.)

I'm pretty sure I have asked this before, but can this be used to extract models from PCSX2 savestates?

The above H2O files are for models of the PC version.
Models of console versions are different. The data alignment is big endian.

For the other parameters you'll have to try it out. Guess they are different, too.

(Startaddresses will be different; maybe face indices count and vertex count are identical.)

And last not least you should know the difference between an address
and a data byte.

Ok i am not always certain on this especially if i am working on a very small file.

I assume that an address usually has the same value int,uint,short and ushort. this seems to be the case often and it is usually a number less than file size.
This is how I identify address for the most part

Please educate me

This is what i am currently working on

JohnHudeski wrote:

And last not least you should know the difference between an address
and a data byte.

Ok i am not always certain on this especially if i am working on a very small file.

So why?
Think of a binary file of 4 data bytes: 05 06 07 08
The address "is a counter" to help you access the bytes: address 0x0000 points to 05,
address 0x0003 to 08.
The addresses themselves are not contained in the binary file - they are just a kind of helper used by applications for example.

shakotay2 wrote:using hex2obj (view link in my sig):

luci_PB.JPG

other submesh:
0x72FA0 471
Vb0
0x0
0x73350 179
020000
0x0 255
(copy previous 6 lines into an empty txt file and save it as luci_mask.h2o for example
then load model and h2o into hex2obj)

hex2obj is intended for a quickcheck only, to get the full model a script would make sense.

It seems the 2 sub meshes you provided are one of the few that use that vertex format.
For example, one your submeshes uses this format

while most others use

which results in

and not something like in your post

http://puu.sh/aZjXg.7z
for the files

What you found is not submeshes. Vertex data blocks with a preceeding pattern like this: FF 40 01 65 xx
are assumed to be animation data (maybe position or rotation tables).

edit: ok, obviously I was wrong. The blocks contain mesh data, but it's split into groups of 24 vertices, hell knows, why

Also the test.obj you present does not seem to be created from luci.pb I spoke of
here: viewtopic.php?f=16&t=11580&p=95322&hili ... 318#p95322.

But thank you for the hint. Although you are the first one to mention such a problem there might be more people having met it.
I'll consider to cover this in the next update maybe at the end of time, ehm year.

shakotay2 wrote:What you found is not submeshes. Vertex data blocks with a preceeding pattern like this: FF 40 01 65 xx
are assumed to be animation data (maybe animation or rotation tables).

Also the test.obj you present does not seem to be created from luci.pb I spoke of
here: viewtopic.php?f=16&t=11580&p=95322&hili ... 318#p95322.

But thank you for the hint. Although you are the first one to mention such a problem there might be more people having met it.
I'll consider to cover this in the next update maybe at the end of time, ehm year.

The luci.pb I sent you is the same file you inspected
I just showed that I couldn't find the same vertex format in other files. (dante.mb was shown in the picture, I just cut out everything that isn't MD00)
Anyhow, it can't be animation data since that is stored in a different sub section, not to mention that there are what appear to be face indices before that section. (maybe object rotation?)
Though I appreciate any help on the format, I'm in the progress of writing a maxscript but I can't seem to figure out why some submeshes don't import correctly.
http://puu.sh/b0SnH.png

could create some kind of shape from one of these "FF 40 01 65" blocks but I'd be surprised if they were submeshes:

# luci.pb, 0x3a28c
v 262.475433 -34.607494 10.095575 #0.691020
v 273.074280 -34.477058 11.986241 #0.588228
v 274.774658 -16.777943 24.374386 #0.518328
v 258.630157 -20.561417 31.541214 #0.797540
v 266.773254 40.229134 -31.604902 #1.000000
v 284.299347 41.799557 -33.064724 #0.696589
v 282.078308 7.121356 -49.990219 #0.667359
v 267.915253 9.591877 -50.425503 #1.000000
v 284.648926 24.336975 17.159489 #0.501431
v 284.143158 42.091068 -4.402791 #0.553018
v 260.396851 43.782570 -0.711370 #0.887914
v 276.705994 4.036054 38.239998 #0.598411
v 276.107239 24.883558 18.408924 #0.521426
v 257.199982 28.299408 25.966925 #0.834648
v 280.521790 -22.747824 -41.224007 #0.640933
v 268.247284 -21.261124 -44.381378 #0.877450
v 279.442352 -35.459770 -22.864286 #0.593812
v 267.881348 -34.769627 -22.370853 #0.715667
v 284.299347 41.799557 -33.064724 #0.696589
v 266.773254 40.229134 -31.604902 #1.000000
v 257.834045 5.909945 42.739517 #1.000000
v 302.369415 -2.246298 29.822830 #0.432970
v 295.715424 -26.835712 13.557502 #0.475808
f 1 2 3
f 4 1 3
f 5 6 7
f 5 7 8
f 9 10 11
f 12 9 13
f 14 13 11
f 9 11 13
f 7 15 16
f 8 7 16
f 15 17 18
f 16 15 18
f 10 19 20
f 11 10 20
f 4 3 12
f 21 4 12

shakotay2 wrote:could create some kind of shape from one of these "FF 40 01 65" blocks but I'd be surprised if they were submeshes:

# luci.pb, 0x3a28c
v 262.475433 -34.607494 10.095575 #0.691020
v 273.074280 -34.477058 11.986241 #0.588228
v 274.774658 -16.777943 24.374386 #0.518328
v 258.630157 -20.561417 31.541214 #0.797540
v 266.773254 40.229134 -31.604902 #1.000000
v 284.299347 41.799557 -33.064724 #0.696589
v 282.078308 7.121356 -49.990219 #0.667359
v 267.915253 9.591877 -50.425503 #1.000000
v 284.648926 24.336975 17.159489 #0.501431
v 284.143158 42.091068 -4.402791 #0.553018
v 260.396851 43.782570 -0.711370 #0.887914
v 276.705994 4.036054 38.239998 #0.598411
v 276.107239 24.883558 18.408924 #0.521426
v 257.199982 28.299408 25.966925 #0.834648
v 280.521790 -22.747824 -41.224007 #0.640933
v 268.247284 -21.261124 -44.381378 #0.877450
v 279.442352 -35.459770 -22.864286 #0.593812
v 267.881348 -34.769627 -22.370853 #0.715667
v 284.299347 41.799557 -33.064724 #0.696589
v 266.773254 40.229134 -31.604902 #1.000000
v 257.834045 5.909945 42.739517 #1.000000
v 302.369415 -2.246298 29.822830 #0.432970
v 295.715424 -26.835712 13.557502 #0.475808
f 1 2 3
f 4 1 3
f 5 6 7
f 5 7 8
f 9 10 11
f 12 9 13
f 14 13 11
f 9 11 13
f 7 15 16
f 8 7 16
f 15 17 18
f 16 15 18
f 10 19 20
f 11 10 20
f 4 3 12
f 21 4 12

I guess they are after all, since for example luci.pb has 119 objects, and almost all of the meshes seem to be starting with FF 40 01 65
Why would they look so fucked up though

just combine the pieces (23, 24 or 13 vertices for example): Sadly I'm not interested in these models so I won't waste more time on this.