Author Topic: [Dissidia] Models - Viewer and Extractor Tool by MrAdults (2009-04-08)  (Read 151353 times)

Ukurere

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #100 on: 2009-03-31 17:26:34 »
    Uh, longpost. The opposite of a double post, I guess.

    MrAdults, your description of Vertex Arrays includes a VertHdr, which has WORD
unknown[2] and int numVerts. That unknown, in my experience, contains the vertex format.
Now, I say this with a little hesitation, because you specifically said that "the vertices actually have nothing to do with the PSP GPU format". But  unknown seems to correspond directly to VTYPE from Yet Another PSP Doc. And in these non-Dissidia GMOs, I've seen nothing of "shared vertex data", as the weights and normals were right there in the vertex array.

If this isn't the case for Dissidia's GMOs, then I suppose I'm not helping you much. But at some point I think we will have to decide whether the QhimmWiki page should document only Dissidia's GMO files, or whether it will document the GMO file format, one that is used in a number of PSP games.

(These games include: Castlevania: Dracula X Chronicles, Jeanne D'Arc, Gitaroo Man Lives!, and Exit. And it's somewhat possible to transplant GMO files from one game into another, with very, uh, interesting results!)

====

Warning! Everything I've found is from other PSP games (mostly Gitaroo Man Lives), so despite being the same file format, it might contradict in a few places and will certainly contain stuff that Dissidia's GMOs don't have.
Also, I have a weird convention for documenting file formats (it seems everyone and their grandma has their own way of doing it), and I'm not very good at explaining things. Once someone starts putting stuff in the QhimmWiki article, I'll join in and try to follow whatever convention is being used there.

0x000B - "Shared Vertex Data"? Well, you did say it was purely speculative. Nope, from what I've seen in other games, this is an Animation.
  • There is a 0x80B1 chunk which (I think) has the animations start and end frames as float32s, e.g. (0.0, 32.0).
  • Then a 0x80B2 chunk with a float32 value, no idea what it does.
  • Then a great many 0x80B3 chunks, each one linking a Bone to one or more"Animation Nodes" (more on that later). Each contains:
[list=1]
  • 4 bytes: reference to a bone [XX 02 10 04] where XX is the bone (starting at 0)
  • 4 bytes: Animation Node type, so far I've seen:
  • 0x47 = Position/Rotation/Scale matrices
  • 0x48 = Rotations with quaternions
  • 0x4B = XYZ positions
  • 4 bytes: uh, 0
  • 4 bytes: reference to an Animation Node [XX 00 0C 00], where XX is the Animation Node (starting at 0). The Animation Nodes are subchunks of this Animation.
To use both quaternion rotations and XYZ positions, there would be two 0x80B3 chunks-- both would have the same bone, but each would link to a different Animation Node.

  • Then come the Animation Node subchunks themselves.
0x000C - "Animation Node" (or a better name if you have one)
(Oh crap, I really hope Dissidia GMOs contain this kind of Chunk, because I didn't see it on your page.)
As I mentioned before, these are subchunks of an Animation. They contain entries that I will call "frames" (or, again, a better name if you have one). A frame contains a time (or, uh, something that looks like a time), and also contains either a Position-Rotation-Scale matrix, a quaternion for rotation, or a XYZ position. (Or perhaps some other method of animation.)

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #101 on: 2009-03-31 18:28:07 »
It would be nice if things were so, but it appears you are mistaken. :) If you use that "unknown" value as a VTYPE descriptor, you'll notice the offsets are incorrect, and none of the vertices have normals in accordance with VTYPE spec. That's actually the first thing I tried doing with that data, which is why I ended up marking it "unknown". But feel free to see if you can get that vertex data rendering as per VTYPE specs, it's always possible I'm missing something.

Edit: Oh, I spoke too soon! Apparently the offsets for the VTYPE actually are correct, if you re-align the vertex header. However, none of the vertices appear to have normal offsets. Can you send me some GMO's from other games to see if they can be rendered with the same method? I own DX:Chronicles, but have neither the immediate ability or a strong enough will to rip content from my actual disc. :)
« Last Edit: 2009-03-31 18:47:56 by MrAdults »

koral

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #102 on: 2009-03-31 19:04:26 »
Those are interesting findings Ukurere (I love the PSP doc you linked to BTW, thanks!  :-D)
 
My two pennies:

As far as the Quimm-Wiki goes, I would want to keep the information Dissidia specific, because Dissidia is a FinalFantasy / Square(Enix) game, which is what Quimm seems to be all about.
(I do not speak for all the Quimm Wiki mods here though, this is just my own opinion).

If the additional chunks would help to better parse and understand the Dissidia GMO files then I would have no objection to adding the info there, otherwise it would only serve to further confuse.
There are plenty of other wikis on the net (Xentax comes to mind) which could do a better job to house the "universal" GMO format, although a new seperate page could be dedicated to it on the Quimm-Wiki too.
You never know if a new PSP Final-Fantasy game might use those extra chunks.

But that is if the GMO formats can be confirmed as being the same in Dissidia as those other games.
I will let you and MrAdults decide that :wink:

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #103 on: 2009-03-31 19:24:52 »
Yeah, I agree, it doesn't make that much sense to wholly document a universal PSP storage format in the Dissidia section, particularly because it's both too much info, and could also need to be referenced multiple times (if other FF PSP games come out using the same format).

I have also only spent a collective few days actually digging into these GMO's, but it sounds like you've been working on them for quite some time, Ukurere. Have you documented your findings anywhere? I would be interested in implementing full skeleton/animation support in mesh2rdm, if you have already documented that data for us. :) However, I do still have a hard time believing that there are not indexed normals in the models. I haven't played Dissidia, but surely they have some manner of dynamic character lighting, at least for effects?

Edit: I thought perhaps they were storing normals in color arrays, perhaps to utilize the smaller bit stride, but nope. Interestingly, all of the character models do have color data in their verts, despite not having normal data, but that data is always just 255! However, the maps do make use of baked in vertex colors, and they look rather sexy I must say.
« Last Edit: 2009-03-31 19:48:04 by MrAdults »

Aurenasek116

  • *
  • Posts: 155
    • View Profile
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #104 on: 2009-03-31 19:45:20 »
It would be nice to have GMO support for other PSP games, especially Dracula X Chronicles (It also has some models that would be lovely to rip), aswell as possibility to extract the models with weighting data.

About the above screenshot, that's how exactly it looks ingame :P So far it's best graphics game for PSP, atleast in my opinion.
« Last Edit: 2009-03-31 20:30:34 by Aurenasek116 »

koral

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #105 on: 2009-03-31 22:27:50 »
That looks nice!  :-D
I must remind myself to try vertex-colours on the CC location-models too

Ukurere

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #106 on: 2009-04-01 19:14:19 »
Well first a confession, I haven't seen any Dissidia GMOs yet, but I will try to get my hands on them soon. My friend has Dissidia so it should be fine, but if anyone feels like putting up a few models, go ahead (but keep it small, I've got dialup at home -_-). A mix of complex and simple models would be nice.

Also, I haven't documented my findings anywhere except on my computer and in my head (and I've backed it up too, yay. The computer, not my head.). I'd much, much rather have a chance to present things in a more readable way. If for some reason I'm unable to continue, I'll give my notes in all their badly formatted glory. (You might find an Earthbound quote in there. Boing!) Funny story sort of: for a long time I was calling these XG files because that's the file extension Gitaroo Man Lives used for them. Well, it turns out they were just using the old filenames from the PS2 version, but the files themselves were very much GMO. So my notes refer to "xgcodes" and whatnot. (Real XG models are another story for another time, muahaha.)

So, before I go on to anything else, I want to talk about chunk types.

We've got 2 kinds of chunks here. For now I'll call em Main Chunks and Mini-Chunks, but there has to be some better name for them.

Main Chunks: These are ones with the 16-byte chunk type (e.g. Texture is 0x0A)
From what I can tell, these have 2 kinds of headers, not all that different. Each header is at least 16 bytes.

Type A Main Chunk header (as I will call it) has:
  • 2 bytes: Main Chunk type (e.g. 0x0A)
  • 2 bytes: size of this header in bytes (16 or greater)
  • 4 bytes: size of this Main Chunk (including header)
  • 4 bytes: A repeat (size of this header)
  • 4 bytes: Another repeat (again, size of this header)
  • Then if size of this header is greater than 16, there is room for a null-terminated name padded to 4 bytes.
Type A headers are used for most Main Chunks, the exceptions so far being Vertex Array and Animation Node. Right after this header you should run into your first 0x80?? chunk.

Type B Main Chunk header has:
  • 2 bytes: Main Chunk type (e.g. 0x07 for Vertex Array)
  • 2 bytes: size of this header in bytes (16 or greater)
  • 4 bytes: size of this Main Chunk (including header)
  • 4 bytes: A repeat (size of this Main Chunk)
  • 4 bytes: size of header + 16
  • Then if size of this header is greater than 16, there is room for a null-terminated name padded to 4 bytes.
As said before, Type B headers are used with Vertex Array (0x07), "Animation Node" (0x0B), and maybe other Main Chunks that I have not encountered yet. Right after this header comes another header of 16 bytes (might explain the "size of header + 16" up there?). While it's different for different chunks, the header should somehow tell the size of each entry and the number of entries in the table of whatevers. Then after that comes the table or list or whatever of data. (If the table's size isn't multiple of 4 bytes, it's zero-padded to 4 bytes before starting the next Main Chunk.)


Mini-Chunks: These are the ones that start with 0x80 (e.g. Mesh Material Info is 0x8061).
These occur as, um:
  • 4bytes: mini-chunk type (e.g. 0x8061)
  • 4bytes: total size of this mini-chunk
  • then some data. So if mini-chunk size is 12, 8 bytes are taken by chunk type and size, leaving only 4 bytes for data.

P.S. Ack, I ran out of time, so I'll have to put up non-Dissidia GMOs later. Any volunteers out there can use Jaeder Naub to check your ISOs for GMO models. No one has made a comprehensive list of which games do or don't contain GMO models, so now's our chance.

P.S. mini-chunk 0x8014 has shown up under Sub-File (0x03), Bone Info (0x04), and Mesh Surface (0x05). It's the only one I've seen show up under more than one different type of Main Chunk, and I don't know if it's really that big a deal or not.

Aurenasek116

  • *
  • Posts: 155
    • View Profile
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #107 on: 2009-04-01 19:24:05 »
Just go to 1st or 2nd page, don't remember exactly which one was it, and you'll find my upload with all dissidia gmo files.

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #108 on: 2009-04-02 13:48:27 »
I don't know if there's really a need for distiction amongst header "types", Ukurere, as the header size field in the chunk indicates the necessary handling there. At least, my parser handles all chunks universally with this method, and it works out fine. That "size of header + 16", if it's the same one I'm thinking of, was just a hack because it was written before I switched to universal chunk handling, and was discerning data in each of the chunks manually. Or something like that. I'd have to go back and look through what I wrote again. :)

And on that note, I got a hold of some Dracula X GMO's and ended up writing my own GMO ripper (after finding that Jaeder Naub seemed to have issues ripping a few of the data files for some reason), and the GMO's are in more or less the same format. I had to add some additional handling for strip geometry indices and some other interesting things that don't exist within Dissidia GMO's, but it was relatively trivial:

(I know it's a little bit off-topic, I promise not to post anymore non-Dissidia pictures :))
Interestingly, the Dracula maps don't store textures within their GMO's, they just store texture references in the texture chunks without a texture data chunk. Most likely due to the massive size of their maps, they have in-engine texture streaming and grab the textures from elsewhere within the resource files as needed.

And the changes I made for Dracula fixed the two missing triangles in Onion Kid's hair. :)

Given that this is such a wide-spread format, I guess I'll go ahead and find the array bone references and discern the bone data and add full skeletal export, as it seems a worthwhile quest for current and future games that use this format. However, Ukurere, if you've already documented that stuff, I would certainly appreciate you posting the necessary data here to save me some trouble. :)

koral

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #109 on: 2009-04-02 14:29:34 »
This is great news!  :-D
So should we assume then that these GMO files are all the same, or are there any obvious differences that you have spotted?

I am asking because it might be a good idea to keep only one GMO file spec in the Quimm-wiki, namely the universal one.
The Dissidia page would then link to that, and highlight clearly only those chunks the game uses.

The pictures might be OT, but the GMO discussion is right at home :wink:

It looks like the DX map models also use vertex-colour shading, while the characters dont.

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #110 on: 2009-04-02 14:37:45 »
Yep, we should definitely have a shared GMO section, as the formats are fundamentally the same. The biggest difference seems to be in what passes for texture data. There are lots of different formats in Dracula (including the exact same 16x8 chunk interlaced 256x256 images from Crisis Core), and while the GIM header is the same size and has similar members, it actually does not appear to be the same. The weirdest thing is that the width and the height on the images are always 256 and 1, and the first number is still 256 even for 64x64 images. I didn't investigate too thoroughly, but it looked like there was no actual correct member in the header chunk to dictate the image dimensions reliably across all textures. That seems very strange, so I must be missing something. But it's definitely quite different from the Dissidia GIM chunk data header.

Edit: Oh, and the palette and pixel data are reversed too for some reason. Palette data often seems to come before pixel data in memory.

koral

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #111 on: 2009-04-02 14:43:32 »
Probably a quirk of the editors and exporters these different companies use  :-P
Those fake-256 dimensioned textures sound weird. Maybe they only use the sizes from the first texture loaded within a set?
Pallete and pixel data ordering shouldn't matter if offsets are present.

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #112 on: 2009-04-02 14:45:21 »
The set thing doesn't appear to be the case, as most of my references for this only actually have one texture in the model (character models).

The thing with the ordering is, the offset that usually points to palette data points to pixel data instead of palette data in these files. :) There may be a flag that's set between Dissidia and Dracula to know if that's happening, though. I haven't directly compared the two yet.

Ukurere

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #113 on: 2009-04-02 18:58:39 »
Re: Dissidia model uploaded: Ack, did no one hear me say "dial-up"? Wait, never mind, my sister is going to her friend's house, and she can get it for me there.

Hey people, what are you using to convert GIM files? How about GimConv 1.20? (included in Sony's, uh, PS3 theme creator I think?) It should take care of all the GIM files. I think the interlaced 16x8 chunk ones is from some setting (pixel order?) set to "fast" (as opposed to "normal"). And I think a Japanese GIM/MIG doc I came across once said there was both a "real" picture size and "viewable" picture size.
Aha, found the Japanese GIM doc page! http://pspdum.my.land.to/psp/gim.html (Google Translate seems to handle it okay.)

Funny thing about palette and pixel data: I tried to put an image into Gitaroo Man Lives by converting it with GimConv. Even though this newly made GIM had the palette data in a different spot than the original GIMs (top instead of bottom, or, uh other way around?), it still loaded.

Oh, as for skeletal stuff and all that, I'll see what I have and get it a little more organized. (It will probably be included in another longpost along with a bunch of other stuff. Tomorrow, I guess.)

P.S. I guess GIM files are used on both PSP and PS3, am I right? So... (muahaha...) might it be possible that GMO files are used on the PS3 as well? (Heck, I don't know, and right now I don't know how to find out either.) Just something random to throw out there, I guess.
« Last Edit: 2009-04-02 19:20:56 by Ukurere »

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #114 on: 2009-04-02 19:15:41 »
I'm not using anything, I'm just looking at the data and interpreting it in my code as needed. :) I'd never even heard of GIM files before I started on this format. But that document looks like an excellent source of information, thanks! I'll use it to cross-check the values I'm seeing.

I've actually already located the bone reference indices and the bone data itself seems rather straightforward, so I might already be done by the time you make your post. ;) I haven't decided if I'm going to push through for animation support or not, although it does seem fairly straightforward as well. It depends on whether all games generally use the same animation format. I suppose I could still use some GMO's from other games that aren't Dissidia/Dracula X to verify that.

Edit: I can say from experience that PS3's do not expect data anywhere near the form of the PSP for the purposes of alignment and storage, so PS3 GMO's would probably be pretty radically different. :) Although it's possible that the general chunk structure is still used somewhere in PS3 land, since the array association used by GMO's does lend itself well to static index/vertex buffer storage.
« Last Edit: 2009-04-02 19:21:37 by MrAdults »

koral

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #115 on: 2009-04-02 20:20:55 »
Funny thing about palette and pixel data: I tried to put an image into Gitaroo Man Lives by converting it with GimConv. Even though this newly made GIM had the palette data in a different spot than the original GIMs (top instead of bottom, or, uh other way around?), it still loaded.

So there must be a flag within the GIM texture data itself then?

Ukurere

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #116 on: 2009-04-03 00:01:24 »
  • File Start [0x0002]
       
    • Sub-File [0x0003]
           
      • Scale and Bias [0x8015]
      • [0x8014]
      • Bone Info [0x0004]
                   
        • [0x8014]
        • Reference to Parent Bone/Object? [0x8041]
        • Big list of Bones refs. [0x8044]
        • List of 4x4 Matrices (goes w/ 0x8044 list) [0x8045]
        • [0x8048]
        • [0x804B]
        • [0x804C]
        • Ref. to a Model Surface [0x804E]
      • Model Surface [0x0005]
                   
        • [0x8014]
        • Mesh [0x0006]
                         
          • Ref. to a Material [0x8061]
          • List of Bones from the 0x8044 list (for weights!) [0x8062]
          • Ref. to a Vertex Array, primitive type, etc [0x8066]
        • Vertex Array [0x0007]
                         
          • <table of verts>
      • Material [0x0008]
                   
        • [0x8081]
        • [0x8082]
        • Specular, I guess [0x8083]
        • [0x8085]
        • Environment mapping (shiny reflection!) [0x8086]
        • Texture Reference / "Layer"? [0x0009]
                         
          • Ref. to a Texture [0x8091]
          • (somehow related to 0x8081?) [0x8094]
      • Texture [0x000A]
                   
        • Texture filename [0x8012]
        • Texture data [0x8013]
      • Animation [0x000B]
                   
        • start & end frames? [0x80B1]
        • [0x80B2]
        • Bone ref., Anim Node type, & Anim Node ref.[0x80B3]
        • "Animation Node" [0x000C]
                         
          • <table of, um, animation frames I think>
For now Texture Animation [0x000F] isn't included because I haven't seen Dissidia's GMOs yet, though hopefully I'll have them soon.

More detailed info in a future post (or maybe I'll appended to this one if many people have posted by then).

P.S. I'm uploading some GMO files over dialup, they'll appear right in this post sometime this century :P
Okay! Only a few per game.
Gitaroo Man Lives contains .XG files... lies! They are GMO files in disguise! (U1.XG seems to use XYZ positions + quaternions, the others use Position-Rotation-Scale matrices I think)
Jeanne D'arc
Exit

P.P.S. MrAdults, have you thought about making import/export plugins for Blender? (Although I guess the format you convert to can probably be imported anyway.)
« Last Edit: 2009-04-03 00:23:47 by Ukurere »

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #117 on: 2009-04-03 03:41:30 »
Thanks for putting those files up, they're a good reference. And thanks for putting that info up so quickly! It meshes well with my info. Those 4x4 matrices in 0x8045 are actually base pose matrices, and they compliment the quaternions and translations for each bone in the 8048 and 804B chunks. Those quats/translations are parent-relative bone orientations for a different seemingly random pose, and the 4x4 matrices are post-transformed modelspace orientations. However, if you were to directly export with the reference bone list, you would lose all of the bones in the hierarchy without verts weighted to them. So the correct thing to do is actually treat those quat/trans orientations, once transformed in a hierarchy, as your base pose matrix. You can multiply those modelspace matrices against the inverse of the original 4x4 base pose matrix to get a set of matrices that will transform your vertex positions into your new base pose. Then you can export a full skeleton with matching base pose vertices.

It might also be possible to just override the matrices in the quat/trans-derived pose with the provided reference matrices where possible, and have it work out. But that seems rather prone to error, given how very random those quat/trans matrices are. They're actually quite reliable in Dissidia models, but Dracula models have them all over the place.

I guess this about seals the deal for skeletal export, it seems to be working across the board even on the new GMO's you put up. GIM support is still being problematic though. I need to tackle that to get all of the Dissidia map textures loading right, so I guess I'll try to just implement it 100% to spec with that GIM doc.

P.P.S. MrAdults, have you thought about making import/export plugins for Blender? (Although I guess the format you convert to can probably be imported anyway.)
Nope, have you? :) Seems rather pointless to me though, Blender already has SMD import, which includes weights and skeletal data.

Ukurere

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #118 on: 2009-04-03 20:01:30 »
So, skeletal animation is :-D
But can the SMD format support vertex animations? (or morph target animations or whatever it's called?) I haven't yet encountered it myself, but I'll bet that's what Dissidia GMOs use for facial animations.

I don't exactly get what you're saying about the seemingly random quats/translations. So 4x4 base pose matrices + "random" quats/translations = the "real" base pose? In that case, I'm curious how the original base pose looks compared to the new one, what's the difference?

Re: Blender plugins: Yea, I was thinking about it myself, despite my programming inexperience :P (hey, experience has to come from somewhere). After all, how are people going to export their own GMO models :-D? Of course this whole documentation thing has to happen first.

I meant to include more info on those 0x80__ chunks in this post... though maybe it's just as well, since between now and my next post I'll (finally!) have a chance to look at Dissidia's GMO files.

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #119 on: 2009-04-03 21:33:36 »
So, skeletal animation is :-D
But can the SMD format support vertex animations? (or morph target animations or whatever it's called?) I haven't yet encountered it myself, but I'll bet that's what Dissidia GMOs use for facial animations.
I haven't looked for morph targets, but the non-combat models have verts weighted to bones all over their faces, so I doubt they use morph targets. It would be rather redundant given the sheer number of facial bones.

I don't exactly get what you're saying about the seemingly random quats/translations. So 4x4 base pose matrices + "random" quats/translations = the "real" base pose? In that case, I'm curious how the original base pose looks compared to the new one, what's the difference?
The "random" pose is probably the first frame of animation (used to delta off of for further animation chunks), but that isn't really the point - the point is that the 4x4 base pose does not contain all bone orientations for the base pose, it contains only bones with verts weighted to them (e.g. ones in the reference list, which is not a complete skeletal list). Hence, it's necessary to do what I said in order to get a matching full skeleton and base pose to export a model that can be posed as the original rig was. You could simply export only the reference bone list, but you would lose bones in the hierarchy, which could conceivably give you less control over the posing.

Re: Blender plugins: Yea, I was thinking about it myself, despite my programming inexperience :P
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? ;)

By the way, using that doc you linked, I resolved all of my issues with GIM's. The whole reverse-order palette-pixel thing was easy to detect, seeing that the GIM header was actually broken up in sections, each of which have their own ID and offsets to the next section. Thanks again for the link.

Edit: New mesh2rdm (v2.0) here:
http://www.richwhitehouse.com/index.php?content=inc_projects.php&filemirror=mesh2rdmv20.zip
This version has skeleton/weight export to SMD, with the full original skeleton intact. It also fixes all of the texture issues with the Dissidia models, and renders the maps and such with vertex colors. And it probably does other things I've forgotten about.
« Last Edit: 2009-04-04 01:32:15 by MrAdults »

BlitzNCS

  • *
  • Posts: 889
  • Master of nothing in particular
    • View Profile
    • My Youtube
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #120 on: 2009-04-04 14:00:01 »
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

MrAdults

  • Guest
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #121 on: 2009-04-04 15:00:44 »
I noticed that too, I figured it was an SMD import bug or something. Maybe it's SMD standard to coincide with the Max UV Y flip or something. Who knows. Anyway, here you go:
http://www.richwhitehouse.com/index.php?content=inc_projects.php&filemirror=mesh2rdmv201.zip
Added a -flipuv command line option, which will resolve the problem without having to modify textures.

BlitzNCS

  • *
  • Posts: 889
  • Master of nothing in particular
    • View Profile
    • My Youtube
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #122 on: 2009-04-04 16:10:55 »
sweet, thanks a lot :D

Aurenasek116

  • *
  • Posts: 155
    • View Profile
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #123 on: 2009-04-04 23:56:24 »
Thanks for adding Drac X Chronicles support. Been waiting for that ;)

BlitzNCS

  • *
  • Posts: 889
  • Master of nothing in particular
    • View Profile
    • My Youtube
Re: Dissidia Models - Viewer and Extractor Tool by MrAdults
« Reply #124 on: 2009-04-05 00:43:44 »
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 Edit: 2009-04-05 13:06:52 by NeoCloudstrife »