[XBOX] OTOGI 1 & 2 char, item, maps ? (.dat & .mdl)

[finale00]

It probably isn't too useful to just see what they are. It's likely related to a couple of the values in the header.
I mean, I really don't see a pattern just by staring at a couple of those unk2's.

I think I figured out why there are multiple vertex values.

The header stores them like

Code: Select all

int numIdx #easy
int numVerts1 #60 byte vertices
int numVerts2 # 64 byte vertices
int numVerts3 # 72 byte vertices
int numVerts4 # 

It's likely to do with the fact that some meshes have weights while others don't or something, and the ones that don't have weights don't need to use a 72 byte vertex.

The indices are also stored that way. So if you have 3 separate vertex buffers for each vertex type, you'll have three index buffers.

But the index count in the header is the total number of indices; not really sure how to split it up even though they are stored sequentially.

So the two immediate issues so far are

1: unk2 struct
2: properly splitting up face buffer/ numIdx per mesh group

[zaykho]

It probably isn't too useful to just see what they are. It's likely related to a couple of the values in the header.
I mean, I really don't see a pattern just by staring at a couple of those unk2's.

Yes but by knowing them I can compare them.

Code: Select all

unk2
--------------
Play0,weapon = 96,96,160,112

Play1,weapon

*List is updating*


W0
----------------



EDIT:

It's likely to do with the fact that some meshes have weights while others don't or something, and the ones that don't have weights don't need to use a 72 byte vertex.

I know that some weapons use a "cloth" that floating in the air when you move your character, I have uploaded some jpg what the complete form of the weapon.

[finale00]

Ok there are offsets to all of the data sections in the header, so unk2 is not too important since we can just jump directly to materials and stuff LOL

There's no offset to unk2 section, so unk2 might be related to unk1.

Ignoring unk2, there still isn't an obvious way to split up the index buffer.
After that, figure out where the texNum is referenced in the material, then figure out how to assign the material to the faces.

[zaykho]

Ok there are offsets to all of the data sections in the header, so unk2 is not too important since we can just jump directly to materials and stuff LOL

There's no offset to unk2 section, so unk2 might be related to unk1.

Ignoring unk2, there still isn't an obvious way to split up the index buffer

Well, I'm lost...........

I will need to practice more, sometimes I find something, but its more lucky way......

[finale00]

I've updated the outline in my first post.
If you go to the index buffer and start scrolling down, you'll see that it starts from 0 and increases...but then it goes back to 0 again and then increases.

I want to know how to determine how many indices to read before it restarts.
Look at the hair or the player models.

Here is what I mean



It might be in unk2

I've also figured out the rest of the offsets.

[zaykho]

Ok i'm looking it

[finale00]

Otogi 1 is similar in that it has offsets to everything as well but it's a different format.
A lot of the structs are the same though.

[zaykho]

Otogi 1 is similar in that it has offsets to everything as well but it's a different format.
A lot of the structs are the same though.

Ok.

how many indices to read before it restarts.

I don't understand exactly, do you want I count all octets before it restart ?
(if yes, do you have some tips, because counting every octets its little boring lol)

Or how many restart ?

[finale00]

Here's an otogi 1 item

I don't understand exactly, do you want I count all octets before it restart ?
(if yes, do you have some tips, because counting every octets its little boring lol)

Or how many restart ?

If you look at the hex image, I've highlighted three 0's.
All of the indices from the highlighted 0 to the next is part of the same mesh.

The first group has a lot of indices. The second group has less indices than the first (much less). The next group is out of view but there isn't much there either.

I need to know how many of those there are in each group.

[zaykho]

Wow this the flame staff, if I remember :p

The first group has a lot of indices. The second group has less indices than the first (much less). The next group is out of view but there isn't much there either.

I need to know how many of those there are in each group.

Ok, so by indices you mean Octets:

A9 00 AA 00 AA 00 AB 00 = 8 octet right ?

or you mean groups:

A9 00 AA 00 AA 00 AB 00 = 3 groups ?

[finale00]

Each face is a triangle.
Each index is a short.
3 indices per triangle.

2 bytes per index
So 6 bytes per face.

You might need to search for index counts or face counts.

When I say face group, I just mean a set of n faces forming a single mesh.

[zaykho]

hair\c011_hair.mdl

2 groups:
------------------
497 - indices (~165 Faces)
290 - indices (~96 Faces)

Does it right ?

[finale00]

NumIdx * 3 is always == num Triangles

I just noticed that the faces do not necessarily correspond to the vertex groups.

For example, I would expect

vert1 (60 bytes) => face 1
vert2 (64 bytes) => face 2
vert3 (72 bytes) => face 3

But one of the players I'm looking at has

vert1 => face 2
vert3 => face 1

So...I'm not really sure how it works.
It's most likely defined somewhere but I don't know where.

[zaykho]

So...I'm not really sure how it works.
It's most likely defined somewhere but I don't know where.

.xbe ?

[finale00]

It should be in the model.