[Dissidia] Models - Viewer and Extractor Tool by MrAdults (2009-04-08)

  • Thread starter Thread starter koral
  • Start date Start date
Status
Not open for further replies.
MrAdults, do you mind adding an option to flip the textures to Mesh2rdm when you export? All the UV maps are flipped when i export to SMD, so it'd be a lot easier :D
Just a suggestion. :D
 
Thanks for adding Drac X Chronicles support. Been waiting for that ;)
 
There seems to be a problem with the latest Mesh2rdm. When trying to Convert any map in dissidia, Mesh2rdm crashes when it tries to "Combine Meshes". Is this a bug? i've managed to Get it to work on other versions...

EDIT: Now it seems dumping any dissidia model results in them being all rigid and boxy in 3DSmax. and they have a weirder stance than before...
Did you do something that screwed up dissidia models? is this an easy fix?
 
Last edited:
That's just what the base pose happens to be. You can re-pose them if you want. But if you want to export the old pose without skeletal data, you can use -noskel on the command line.
 
Thanks, but what about the error when dumping areas?
ANd by boxy, i mean like, for instance his arms, instead of being cylidrical like our arms, they're more of a pentagonal prim, if you see where i'm coming from. rigid edges? i'm bad at explaining....
 
There was a crash with the new skeletal export when exporting non-weighted models with skeletons (e.g. level models), fixed here:
http://www.richwhitehouse.com/index.php?content=inc_projects.php&filemirror=mesh2rdmv202.zip
But I'm afraid I have no idea what you mean regarding boxiness. This is what I get:

Looks fine to me. As mentioned, Squall is in that pose because it happens to be the first frame reference pose for his model. You can just move his shoulder bones a little and he'll be in the same base pose as before.
 
Thanks for the fix :D
And, if i still cant get it to work, ill show you a screenshot of the boxyness later.
 
The "boxyness" is either because the normals are screwed up, or because there are duplicate vertices everywhere.
Try welding all vertices (<0.01 or something) then do an "AutoSmooth" on all the polygons.

And thankyou for the info Ukurere, I need to stop moping around and get back to the wiki-work!  :-D
 
I don't get any problems with "boxyness". I just use smoothing groups, works fine.
 
Just to remind everyone. Those who have asked for wiki access have gotten it.
 
How exactly do you end up spending this much time in front of a hex editor, equipped with, seemingly, a good amount of rendering/geometry knowledge, and not have programming experience? What are you, some kind of hardcore scripter? ;)
Click to expand...
Eh, I should have said relative inexperience. I haven't made anything major, nothing 3D either.

Bad news, I can't seem to find any working SMD import plugins for Blender-- huh, spoke too soon, guess I'm not restricted to OBJ files anymore. Yay! Strangely, models from Gitaroo Man Lives seem to have inverted normals (which takes like 3 seconds to fix in Blender :P). I wonder if there any other games with this issue, and if there is any way to tell in advance.
(Now don't get the impression that I actually know how to use Blender-- I'm bumbling and stumbling around that program like a drunken Flatlander.)

Now, below this line...
These are slightly more detailed descriptions of the 0x80?? chunks from this post. Except that some of them are incomplete or unknown or blah blah blah.

================
All(?) chunks are padded to a multiple of 4 bytes.

Little-endian unless otherwise noted:
int8, int16, int32 -> signed 8/16/32-bit integer
uint8, uint16, uint32 -> unsigned 8/16/32-bit integer
float32 -> 32-bit floating point decimal
word -> 2 bytes
dword -> 4 bytes


0x8012 - File name (always texture?)

  • A null-terminated string padded to 4 bytes.

Sometimes this isn't accompanied by file data, and even if it is, the file type might not match (e.g. texture.tga might be followed by GIM file data)

0x8013 - File data (always texture?)

  • uint32 filesize, followed by the file data itself. (Nitpick: Although chunk is padded to 4 bytes, the uint32 filesize doesn't have to be a multiple of 4.)


0x8014

  • unknown - contains 6 float32s

Has been seen under 0x0003 Sub-File, 0x0004 Bone Info, and 0x0005 Model Surface

0x8015 - Scale and Bias

  • Uh, whatever MrAdults said on his blog page.


0x8041 (reference to parent bone?)

  • dword [00 04 10 XX] where XX is the index of the parent(?) bone (as listed in the current Sub-File, starting at 0).


0x8044 - a big list of bones (help naming please)

  • u32 numBones, followed by that many bone references. Each bone reference is a dword [00 04 10 XX] where XX is the index of the bone (as listed in the current Sub-File, starting at 0).


0x8045 - Base Pose Matrices



0x8048

0x804B
0x804C

0x804E - Reference to Model Surface

  • dword [00 05 10 XX] where XX is the index of the Model Surface (as listed in the current Sub-File, starting at 0).


0x8061 - Reference to Material

  • dword [00 06 20 XX] where XX is the index of the Material (as listed in the current Sub-File, starting at 0).


0x8062

  • uint32 numWeightedBones (always between 1 and 8), followed by that many uint32s. Each uint32 refers to a bone from the bone reference list in 0x8044.


0x8066 - "Reference to Vertices" / "Vertex Kick" / (help, I need a name!)
(or "Mesh Index Data" according to MrAdults)

  • begins with dword [00 07 10 XX] where XX is the index of the Vertex Array (as listed in the current Model Surface, starting at 0).


0x8081

  • unknown - contains 2 uint32s/int32s


0x8082

  • unknown - contains 4 float32s


0x8083 (specular?)

  • contains (4 float32s, uint32)


0x8085

  • unknown - contains 4 float32s


0x8086 - Environment Mapping

  • contains a single float32 (I don't know what effect the float32 has)


0x8091 - Reference to Texture

  • dword [00 0A 20 XX] where XX is the index of the Texture (as listed in the current Sub-File, starting at 0).


0x8094

  • unknown - contains 3 uint32s/int32s


0x80B1 (animation frames?)

  • 2 float32s - first one is always(?) 0, second one would be the ending frame? (It's matched for the few I checked, but this needs double-checking)


0x80B2

  • unknown - contains a float32


0x80B3 Bone-to-Animation-Node linker thing / (help, give me a name!)
Each of these links a Bone to a Animation Node, so there will be a lot of these. In the case of quats and XYZ positions, you'll find two of these referencing the same bone, each time getting linked to a different animation node.

  • dword [00 04 10 XX] where XX is the index of the Bone (as listed in the current Sub-File, starting at 0).
  • uint32 Animation Node Type:  47 = matrices, 48: quaternions, 4B: XYZ positions or whatever they're called.
  • dword 0
  • dword [00 0C 00 XX] where XX is the index of the Animation Node (as listed under the current Animation (0x000B chunk), starting at 0).


======
BONUS
This isn't a 0x80?? chunk... This is what appears under chunk 0x000C, aka Animation Node. (Remember my constant warning, "May Not Apply To Dissidia GMOs".)
(I wanted to tidy this up... but then I realized if I do that, this will never get posted. Not in this century, anyway.)

After the standard chunk header:

  • This begins with a 16 byte header: dword unknown1, uint32 numWords, uint32 numEntries, dword unknown2.

unknown1 seems somehow related to the size and type of this Animation Node...
numEntries is, well, the number of entries in this Animation Node.
numWords is the number of words per entry (word just means 2 bytes). XYZ positions get 3, quaternions get 4, matrices get 16.

  • Then it is followed by numEntries entries. Each entry is made of 2+(2*numWords) bytes. I guess each entry contains:

word time
word stuff[numWords]
I don't know what format time uses. stuff is a XYZ position, quaternion, or matrix.
 
Yeah, I noticed the Gitaroo Man models you put up had a reverse winding order. I looked around for a little while for some kind of flag on the model, surface, mesh, or vertex array that would indicate a winding order or something, but didn't find one. I didn't run into any unknown chunks in those models either. It's quite possible that their engine simply uses reverse face culling. I could add a backwards facing fix command line option to mesh2rdm, but as you said, it's a pretty easy fix once you import the model into any modeling program. I'm currently not bothering to use normals from the GMO source even if it has them, eiither, mainly because I didn't care since none of the Dissidia models contained normals. :) The normals in the exported model are just generated based on the averaged face normal for a given vertex (or a number of other things depending on your export options), which is why they are backwards for those Gitaroo Man models (since the faces are flipped).

I've tried quite a few games with GMO files now, but Gitaroo Man is the only one with flipped faces so far. However, there are some models in Dracula that aren't reversed, but look like they should be two-sided for some surfaces. I thought this may be a material flag, but that doesn't appear to be the case. Naturally, I also looked for hints in the model/surface/mesh/array chunks, but didn't see anything. Given that it's surface-selective, though, it really seems like there should be something in the GMO itself to indicate two-sidedness. Unless the engine just has no face culling for the whole object, which would seem strange and wasteful.
 
I have created a new PSP section in the Wiki, and also a new page for the GMO-format (to which the Dissidia page now also links): http://wiki.qhimm.com/PSP

Ukurere, I noticed you have wiki access too?
Please feel free to dump all your finding there if you wish, my GMO writeup was originally geared towards Dissidia so I may have missed a lot of the specifics of the "universal" format.
I am sure you will do a better job of documenting it :-D

If anybody here knows of any more PSP-games which use GMO models (check using GitMO) then either PM me or Ukurere and we will update the list in the wiki.
No need to spam this topic  :wink:
 
I *said* you guys had access :P You only notice now?

Geez. I'm so underappricated :P
 
I *said* you guys had access :P You only notice now?

Geez. I'm so underappricated :P
Click to expand...
Ummm do I know you?
LOL
I think they weren't paying attention, or couldn't afford to at least.

Cyb
 
Yay, working on Wiki article (preview here) ...aaaand having fun messing around with character poses! I love it! (I wonder how many years it takes to get good at 3D modeling/animation... eh, I've got time :D)

MrAdults, I've got some questions for you if you don't mind:

  • First off, is it okay with you if I use stuff from your forum and blog posts for the wiki article? Or, what I mean to ask is, how much copying & pasting can I get away with? Most stuff I'll end up paraphrasing, but there are chunks that already stand fine on their own for the article.
  • Just to make sure, 0x8041 is confirmed to be the parent bone? (
  • For 0x8015 Scale and Bias, instead of just multiplying a coordinate by Scale, you multiply UV coordinates by Scale*2.0 and vertex positions by Scale*2.0/65535.0 -- why is that?
  • Um... bones that have vertices weighted to them-- what would you call them? "Bones that have vertices weighted to them" is a little wordy, and I don't know if "weighted bones" makes any sense or not.
  • 0x8066 Mesh Index Data... you've mentioned triangle strips, so I guess that means you've revised this chunk since your big blog post (which makes no mention of them). Can you give us an update on that? I've got some info on it as well, but it includes some big leaps of faith which, if they're wrong, are better off not being out there and confusing people (not to mention needlessly bruising my ego :P).


P.S. halkun is so awesome my head exploded just reading his name
There, that's better :) I think
 
Last edited:
  • First off, is it okay with you if I use stuff from your forum and blog posts for the wiki article? Or, what I mean to ask is, how much copying & pasting can I get away with? Most stuff I'll end up paraphrasing, but there are chunks that already stand fine on their own for the article.
Click to expand...
Sure, copy-paste as much as you like. Although a little thank you with link to my web site somewhere for all my hard work would be nice. ;)

  • Just to make sure, 0x8041 is confirmed to be the parent bone? (
Click to expand...
Yep, no doubt about it. However, rather than being 1 byte, the index is 4096-based - if the bone count exceeds 255 the full WORD bit layout is changed appropriately. No idea why this is the case for so many index values in GMO files.

  • For 0x8015 Scale and Bias, instead of just multiplying a coordinate by Scale, you multiply UV coordinates by Scale*2.0 and vertex positions by Scale*2.0/65535.0 -- why is that?
Click to expand...
As you might've guessed, that was just some sloppiness in where I was re-scaling non-float coordinates after interpreting them. I've since cleaned my own code up as well, which makes how those scale-and-bias values are used less confusing to the reader:
Code: [Select]
Code: 
 for (int i = 0; i < totalArrays; i++) {  gmoIntAr_t *ar = &allArrays[i];  for (int j = 0; j < ar->numVerts; j++)  {   gmoIntVert_t *v = ar->verts+j;   if (uvScales)   {    v->uv[0] = v->uv[0]*2.0f*uvScales[2] + uvScales[0];    v->uv[1] = v->uv[1]*2.0f*uvScales[3] + uvScales[1];   }   if (posScales)   {    v->pos[0] = v->pos[0]*2.0f*posScales[3] + posScales[0];    v->pos[1] = v->pos[1]*2.0f*posScales[4] + posScales[1];    v->pos[2] = v->pos[2]*2.0f*posScales[5] + posScales[2];   }  } }
  • Um... bones that have vertices weighted to them-- what would you call them? "Bones that have vertices weighted to them" is a little wordy, and I don't know if "weighted bones" makes any sense or not.
Click to expand...
I would call them vertex-referenced bones. After all, the bones themselves aren't weighted, the vertices are weighted to them. ;) But "weighted bones" is fine too, people use the phrase regularly, as incorrect as it may seem.

  • 0x8066 Mesh Index Data... you've mentioned triangle strips, so I guess that means you've revised this chunk since your big blog post (which makes no mention of them). Can you give us an update on that? I've got some info on it as well, but it includes some big leaps of faith which, if they're wrong, are better off not being out there and confusing people (not to mention needlessly bruising my ego :P).
Click to expand...
I had documented primType as a full int in my spec. However, the first 2 bytes of it actually seem to be responsible for dictating the index format. If the first byte is 3, it's triangles, if it's 4, it's quads. I have never seen any other value. If the second byte is non-0, it's "unindexed".

In the case of unindexed, there are no index values. However, there is 1 WORD where the start of the index list would be, which is the starting vertex index for the whole primitive. For both quads and triangles, you then plot indecies for the primitive from the base vertex index using the same index number as per usual.

Additionally, for quads, the stride can be > 4 for both indexed and non-indexed. I have never seen a model do the same with triangles (e.g. have a stride that is not 1), but it could be possible, in which case the same methodology would be applied. The correct way to handle strides > 4 is to index the first 4 values as per usual, and treat the rest as a single-index triangle strip. For each additional index, add a new set of 3 indices, using the current index in addition to the last 2 indices. So, if the stride is 5, you end up with 7 indices. If the stride is 6, you end up with 10 indices.

Edit: Spelling/clarification, sorry, just woke up. :)
 
Last edited:
Status
Not open for further replies.
Back
Top