XeNTaX

shakotay2 wrote:As you can see it's very simple code. So I'd suggest to learn C (or any other programming or script language).
Up to then you might try out this tool (for ps3 only) to create the H2O files for you:

MakeH2O-bins-Ben10UA.zip

Thanks a lot mate! It works fine for almost all *.ps3 files. But as you've said, it requires knowledge about model analysis. So I still need to learn the basic before I can handle such thing as making an automatic tool.

Bigchillghost wrote:Since 4532*44(dec) equals 0x30af0, subtract it from 0x1b3b00 we get 0x183110. Then why should the correct address be 0x182fe0?

i never do any of that math unless i'm writing a script , don't over-think it,
i just locate a pattern and follow it to the beginning or end and record the offsets and length.

Bigchillghost wrote:And I'm still confused about the FVFsize and UV pos. How can I know the vertex block size is 44 bytes and get the correct UV pos? Is that acquired by trial 'n error? Or are there other ways to do that?

FVFsize is just the number of bytes holding data for each vertex.
http://www.toymaker.info/Games/html/fvf.html
in your hex editor just expand the right side column width until you see
the bytes line up into a vertical pattern then check for a found pattern.
UV pos is always trial n error with me, unless there is some source specs around to look at.


also in g_hm.ps3 for that character the number of vertices is stored at 0x182e04
and the number of face indices is stored at 0x182e0c both in big endian 32bit integers.

AceWell wrote:i just locate a pattern and follow it to the beginning or end and record the offsets and length.

The question is how am I supposed to locate the correct pattern? That is, how can I know whether it's the pattern I'm looking for?
I've noticed that the pattern of g_ad.ps3 is B4 01 58 1D 00 00 00 00, while the one of g_hm.ps3 is B4 01 C8 13 00 00 00 00. Are their patterns always start with B4 01, with the latter four bytes as 00 00 00 00 in this case (or universally) ?

AceWell wrote:also in g_hm.ps3 for that character the number of vertices is stored at 0x182e04
and the number of face indices is stored at 0x182e0c both in big endian 32bit integers.

With the correct pattern found, it's easy to get the face indices counts as well as the one of vertices, coz they seem always in the same position right before the pattern's offset.

AceWell wrote:in your hex editor just expand the right side column width until you see
the bytes line up into a vertical pattern then check for a found pattern.

What do you mean by "vertical pattern"? Is it something like this?

Bigchillghost wrote:I've noticed that the pattern of g_ad.ps3 is B4 01 58 1D 00 00 00 00, while the one of g_hm.ps3 is B4 01 C8 13 00 00 00 00. Are their patterns always start with B4 01, with the latter four bytes as 00 00 00 00 in this case (or universally) ?

This should not be referred to as patterns (I feel guilty ), since it's different from the ones, AceWell spoke of.

B4 01 is more some kind of signature bytes or markers to identify "magic tables" containing counts and (maybe) offsets. (But since me seems to be the only one who uses these terms you can ignore them. )

B4 01 is the sequence I used in the Make_H2O tool combined with other checks (bytes to be zero, vertex count, FI count == values that makes sense?).

Nobody can tell you if it's always B4 01, I guess. But it obviously works for many models.

shakotay2 wrote:This should not be referred to as patterns (I feel guilty ), since it's different from the ones, AceWell spoke of.

Whoops, I thought a pattern was a piece of sequence differed from file to file, since you said it was some assumed pattern in your previous post. So what exactly does it means when it comes to a pattern? Is it a structure how archives are built just as its name implies?

Feel free to create your own "theory of patterns".

What I tried to say was that there's a difference between the patterns (structures) to find FVF sizes which AceWell spoke of and the byte sequences to identify "magic tables".

Nothing more and nothing less.

(While for FVFsizes a good method is to divide the size of the vertices list by the vertex count.
Thing is that often it's unclear where the vertices list to end especially for half floats or words.)

shakotay2 wrote:While for FVFsizes a good method is to divide the size of the vertices list by the vertex count.
Thing is that often it's unclear where the vertices list to end especially for half floats or words.

So even doing a calculation is not always working. Then what's the pattern AceWell spoke of?
It really drives me crazy to still be stuck at finding the correct vertices startaddr, or anything hex2obj needed to perform its task. Maybe these so-called patterns would have some common features which could make it easier to find some in different files.

Bigchillghost wrote:Then what's the pattern AceWell spoke of?

this post explains what i was talking about for patterns
viewtopic.php?p=120284#p120284

find the pattern, i find it easier to see on the text side
set the text column width to reveal a vertical pattern to see where it starts
follow that pattern to where it starts and you have your offset to test for
set the FVFsize in Hex2obj to the number of bytes you expanded the text column
test for point cloud to see if it is vertex data
play with endianess and float/short/halffloat until the point cloud makes sense

then you can look for face indices which look like a scrambled alphabet on the text side
then go to the hex side and put your cursor where you think that pattern starts and check
that offset in Hex2obj, worry about the precise step1 count last.

i just use HxD and windows calculator in scientific mode, nothing special

Bigchillghost wrote:So even doing a calculation is not always working. Then what's the pattern AceWell spoke of?
It really drives me crazy to still be stuck at finding the correct vertices startaddr, or anything hex2obj needed to perform its task. Maybe these so-called patterns would have some common features which could make it easier to find some in different files.

yeah - I really like that spirit!
Unlike many others you really want to know what you're doing.

I always wished to have a full "set of rules" how to analyse 3D model data.
Again this discussion showed me the importance of finding structures (or patterns, whatever ).

Btw, once the FVF size is found creating/searching point clouds may be a good idea for a successful proceeeding.
So if you see a sphere for example you very likely hit the normals list in the 3D data.

shakotay2 wrote:yeah - I really like that spirit!
Unlike many others you really want to know what you're doing.

Well, I have to know that if I want to extract a mesh successfully myself.
So that's nothing since I know I cannot always rely on others. But as a beginner, I know measly about this field and therefore I may
ask a lot of questions, which may seem ignorant to the experienced.
Howerer I sincerely appreciate that people like you and AceWell explained them patiently and I'm glad I've met you guys!

AceWell wrote:this post explains what i was talking about for patterns
viewtopic.php?p=120284#p120284

find the pattern, i find it easier to see on the text side
set the text column width to reveal a vertical pattern to see where it starts
follow that pattern to where it starts and you have your offset to test for
set the FVFsize in Hex2obj to the number of bytes you expanded the text column
test for point cloud to see if it is vertex data
play with endianess and float/short/halffloat until the point cloud makes sense

then you can look for face indices which look like a scrambled alphabet on the text side
then go to the hex side and put your cursor where you think that pattern starts and check
that offset in Hex2obj, worry about the precise step1 count last.

i just use HxD and windows calculator in scientific mode, nothing special

Awsome! With the images I easily understood your method however there always could be some problems for me like this:



Neither the addr of the symbol > (0xdf3e8) nor the one ot the ? (0xdf3e4) is the vertices startaddr, so I tried the one of the = (0xdf3e0) conbined with other possible FI startaddrs. I also found the addrs where FI count & vertices count are stored, the sequence no more starts as B4 01 though. And then I got this from g_ra.xbx: The first mesh I extracted aha. Of course it wasn't done at a go, and therefore I need to practice more to really get the hang of it.

Cheers!

Also another successful test of g_wh.ps3:

Bigchillghost wrote:Also another successful test of g_wh.ps3:

yeah, see, there was a problem with the H2O-Maker. Also fixed the last submesh (quick fix only, may fail).
(A +/- 1 correction of the vertex count might be required because sometimes the value in the ps3 file
is different from the calculated one.)

(exe file only. Dlls from the post of 20th Dec, 3:19 pm, required)

Bigchillghost wrote:Neither the addr of the symbol > (0xdf3e8) nor the one ot the ? (0xdf3e4) is the vertices startaddr, so I tried the one of the = (0xdf3e0) conbined with other possible FI startaddrs.

yeah the repeating bytes aren't necessarily going to be a start address for the vertex block,
only use that pattern to trace back to where it begins. after you adjust the column width it
is usually clear to see where the pattern begins and ends then you can start checking offsets.

AceWell wrote:i updated my previous post with a zip file containing a better bms and
Noesis python script to handle both PS3 or X360 textures

I've also successfully extracted some meshes from another Ben 10 related game, Cartoon Network Punch Time Explosion XL.
The textures' headers also start as 0x90 43 40 00, which can be splited by your bms script. However when I converted them to dds
in Noesis, the python script didn't work well. Seem these textures are different from those in Ben 10 UA.



Since I know quite a little about textures data analysis, I'm not able to fix them. Could you please update the python script so as to
support them?

Samples here.