Qhimm.com Forums
Final Fantasy 7 => FF7 Tools => Topic started by: koral on 2009-03-17 23:16:52
-
PLEASE NOTE
MrAdults is no longer a member of the Quimms community, because of certain members in this forum who did not care for his contributions, nor care for his opinions.
Had any decent Moderation intervened, things may have not escalated to such drastic measures.
For any who wish to learn more of the whys and hows, read this topic and make your own conclusions:
http://forums.qhimm.com/index.php?topic=8554.0
As a consequence of his departure, do not expect anymore help or any more updates here.
---------------
Original post: 23 May 2009
This is the where all discussion regarding viewing and extracting models from the PSP game FF Dissidia should be discussed, to keep everything nice and easy to find.
If anyone has anything interesting to share, or some potential data files worth looking at, then please post about them here.
Have a nice day :-D
Dissidia Wiki: http://wiki.qhimm.com/Dissidia
GMO Specs: http://wiki.qhimm.com/User:Ukurere
EDIT: 29 March 2009
MrAdults single-handedly decoded the entire GMO model format and his tool can view and extract Character and Location models!
Link to blog: http://www.richwhitehouse.com/index.php?postid=33
(http://img14.imageshack.us/img14/7533/dissc.th.jpg) (http://img14.imageshack.us/my.php?image=dissc.jpg)
Tool and what's-new/how-to-use here:
http://www.richwhitehouse.com/index.php?postid=33
It seems to work fine with environmental models and stuff too. There is one bug that I only just noticed, which is that sometimes pure static geometry that is symmetrical will get half of itself culled out. I believe they use a surface flag to indicate those surfaces and re-render them with inverse axis coordinates, to save on vertex space. But, I haven't gotten around to finding that flag yet. The only one of the characters that are affected from what I've been able to tell is Bartz. His cape must be "static" for some reason, maybe it's because there's special code handling to animate the verts or something. But generally, since characters are point-weighted, that optimization can't take place on them.
I think that's everything. Enjoy. :)
This fixes that command line switch, and in models with multiple sub-models, you can push enter in preview mode to cycle through them.
And finally, there is a new release (v1.93) of mesh2rdm up now, here:
http://www.richwhitehouse.com/index.php?content=inc_projects.php&filemirror=mesh2rdmv193.zip
As it turned out, lots of surfaces still weren't showing up, like some clothing bits and chains hanging off of characters and weapons. I think I've cleared up pretty much all of the problems now, except for a messed up texture here and there.
The format specification (as much as is currently known) has been documented here http://www.richwhitehouse.com/index.php?postid=34
Thankyou MrAdults! :-D
EDIT: 08 April 2009
Ukurere has shared his past experiences working with the GMO model files (the same ones in Dissidia) and working with MrAdults, is Wikifying the complete format here:
http://wiki.qhimm.com/User:Ukurere
:-D
And some pointers about EXTRACTING MODELS using MrAdults mesh2rdm tool:
I use Start -> Run -> Cmd and do all operations this way.
In cmd simply navigate to the path where you have mesh2rdm. Hope that helps.
Aurenasek already mentioned it, but you can use the Start->Run menu and enter "cmd" (without quotes) to bring up a command prompt. Then cd to your model directory where you have a copy of the gmo and mesh2rdm.exe and run it with the desired parameters. You may have to seek out a DOS command reference if you aren't used to using a command prompt, though. :)
I'm using a .bat file that I edit for every file I want to export, here it is if you want to use it:
mesh2rdm File003761.gmo Kefka.smd -dissskip 1 -texpre Kefka -rotate -90 0 0 -scale 1.0 -smdout
That line will export you god form kefka ;P
-
Neo has all the charactes textures, i guess thats a start..
-
Well, actually, a fried of mine (Who, coincidentally, knows Qhimm himself) is pretty talented at all this extracting and exporting stuff.
If you want, I can ask him to Extract the models for us, and get all the textures. the models, obviously, wont be viewable unless a viewer is available though.
Some texture samples:
(http://i182.photobucket.com/albums/x74/beefpwnage/cloud-3.png) (http://i182.photobucket.com/albums/x74/beefpwnage/sephiroth.png) (http://i182.photobucket.com/albums/x74/beefpwnage/Weapons.png)
-
I wonder if the models are also stored in native PSP GPU vertex list format. If they are, figuring them out could be a pretty fast process, with the info koral and I have uncovered on the Crisis Core models.
-
There are actually a few textures I had in mind when I suggested this to koral...(via PM)
I particularly like the Ultima weapon model, Kuja, maybe Squall's SeeD uniform...
I can't remember all of them... but mainly those.
-
Well, i guess i'll have a chat with carey then, see if he can get some models for you guys to have a look at :wink:
-
Cool, thanks NeoCloud! Looking forward to it :-)
-
If anyone is interested in trying to make a viewer I could send a few Dissidia models, since like I've stated before in crisis core topic, I have no idea of coding :P
-
No promises for the immedate future, as I'm still recovering from my Silent Hill format binge, but sure. Feel free to send them on over.
-
Let me pack them up then and upload, I'll send you a PM with link as soon as it's done uploading.
PS. Want all model files or just a few random ones? All of them are around 240 megs unpacked. (Which means they most likely contain texture data)
-
The more the merrier. :) But if you have trouble uploading that much data, feel free to just put up as many as you like.
-
Actually I was afraid you might not want too many :P So I guess we both share the same opinion on this - GET'EM ALL.
I'll post link here then as soon as it's done uploading, my network is a bit overloaded at the moment so it will take around 30 mins or so.
-
Yes, I only need a few specifically, but the more we can get the better.
-
Okay, here it is:
http://files.filefront.com/Dissidia+All+GMOrar/;13514791;/fileinfo.html
-
I guess i'll take a look at 'em too. my limited knowledge of everything might come in handy xD
EDIT: Immediately i can see that models start with bone labels...
Then model segment labels? I can see stuff like "p_one100" and "p_one100_wep0" I'm guessing This means i'm in the model for an FF1 character, considering I know cloud's model is called "p_sev100"...
EDIT2: yeah, models have "P_xxxyyy" "P_xxxyyy_wep0" and "P_xxxyyy_wep1" labels. now i've never even played dissidia, but from what i understand, each version of a character has a player model, and 2 weapons (that limit break thing)
EDIT3: then it does something like 2 bytes being "XX 10" and then 2 bytes being "04 00", and this repeats for a while. "XX" seems to be rising every time it comes round, but not in any order O.o
I'm probably just pointing out the obvious here, but i wanna know if anyone can make sense of this.
EDIT4: after this, theres loads of data, and loads of them have this "approximately 00 00 80 3F" thing going on. now after THAT, the bone labels start up again. and after THEM, body parts are labeled ("hair", "cheek" stuff like that)
-
I did hex through them and I can confirm they contain mesh, skeletal and texture data. The lines starting with GimConv are probably texture headers seeing as default texture format used in dissidia is .gim.
That's all that I can tell since coding is not my thing.
-
near the bottom I noticed a lot of instances of "f_curve" going on... I'm not sure what it is, but it sounds like either an animation queue or some type of solid modeling function (as opposed to polygonal) which seems to make no sense...
It could be a stored method that is called when the player slashes a wall and the slash damage sprite needs to be bent to fit the shape of the wall... no real plausible ideas though...
-
I did hex through them and I can confirm they contain mesh, skeletal and texture data. The lines starting with GimConv are probably texture headers seeing as default texture format used in dissidia is .gim.
That's all that I can tell since coding is not my thing.
actually, Each Model segment has 2 textures, neither of which are .gim
Texture files are stored uncompressed as both TGA and TM2
...i think, anyway.
-
Now if the CrisesCore debug-menu wasn't distracting enough... :lol:
Thankyou for uploading the files Aurenasek116, I will have a look at them sometime.
Just cannot resist the temptation :-D
PS: I edited the first post now to make it a little friendlier.
-
I won't say I don't have my own interest in that, so no problem there. I crave so much to get Kefka and shove him into JK3 :P
-
Thanks for putting those up, I've got them now. Will have a look later on.
-
Take your time, nobody's rushing :P
-
I had a quick look at the files too, and they are abosultely nothing like the (nice and simple) CC models, so we are going to have to start from scratch with this one :-P
The data seems to be quite well organised, and all the different components are uniquely named, which makes things a little bit easier.
I thought I saw some "xx.tga" ascii too, but I didn't think PSP could decode TGA files? They might represent some other kind of Dissidia-specific format.
Aren't GIM files suppsed to be equivalent to GIF, as in animated textures? I remember seeing them used for PS3 themes and stuff, so it feels out of character for them to be used as normal textures. Probably they are just for things like blinking and mouth moving animations.
The actual vertex data might be same as CC (probably should be too) but it wouldn't be smart to jump right in without trying to understand what else is in those files and what the file header says about offsets.
There might be no need for offsets, because we could skip to the named sections directly in most cases, they sound like they might be the same in most of the other files too.
It's a whole new can of worms :-D
-
Trust me, GIM is short for Generic Image (Or atleast that's what I was told), I'm using a simple converter written by kind people of alucard.cc which converts dissidia gim files into png/tga/dds or whatever other format you want, so we can be 100% sure those are textures.
If you want, I could put up a package with tools written by people of alucard.cc (Mainly by a guy named Vash - credits go to him) so you could use them :)
-
O.o weird, apparently they're just uncompressed tga images in the model files...
perhaps he was wrong then...
but then how would you explain the .tga labels? or the tm2 ones?
-
I think it's same as with Atrac audio format, in atrac case it's simply wav but wrapped in new header to make it look like if it was new format. I don't know really, I can be wrong.
Also here are the Dissidia tools coded by Vash, it has a GIM extractor aswell as other stuff which you can have a look at, maybe it will be of any use.
http://rapidshare.com/files/213186921/Dissidia_Tools.rar.html
Rapidshare link for now since FileFront is doing some maintance.
-
Just had a look myself. Looks like a nice big batch of straight-up-uncompressed bone matrices near the beginning of the file, so that's good. I would have at least expected some quat compression, but I'm not complaining. :) First thing to do is probably locate offset bits for the image location since it's a known piece of data. Wherever that offset is, there are probably more offsets to other meaningful mesh data.
Edit: Alright, I've been working on it over the past few hours. The file is broken up into chunks, and I've figured out how to ID the chunks, be they bone data, meshes, or textures. Mesh data is a more complicated matter. I'm using the crystal model as a simple test case.
(http://richwhitehouse.com/pubimg/crystal.jpg)
Strangely, it draws the verts properly as a raw triangle list, but there is a data segment right before the verts that looks very much like triangle strip indices. However, trying to use that index list does not look correct in any way, so I'm not sure what the point is. It can't be a list of weight indices, because the crystal doesn't need to be weighted (since from what I can tell it only has a single root bone, and if every index were the same that would be obvious).
Vertex data is also not stored at all in native PSP GPU format. Vertex positions are offset from the beginning of the list before UV coordinates, which is not an accepted hardware format. However, vertex formats do vary wildly from model to model. I'm probbaly skipping over a format descriptor somewhere along the line.
As a side note, the very large files appear to be purely skeletal animation data with no mesh data at all. But many of the character model chunks also include some skeletal animation data.
-
That's a nice piece of work, but the fact about models not being in native PSP GPU format saddens me. I hope it is possible for you/koral or both to find a solution and hopefully make the models be extractable.
-
I seem to be able to reliably grab vertex data from all of the models now, including all surfaces and surface sub-meshes.
(http://www.richwhitehouse.com/pubimg/squallcloud.jpg)
Next thing is to determine a reliable offset for the UV coordinates and other specific vertex data based on the vertex tag. I believe I've found the tag, it just doesn't correspond at all to the PSP hardware's encoding scheme. But it's probably still the key to determining the vertex layout. In any case, I still haven't even bothered to handle ripping the images, so I'll have to get that done sometime before I move onto testing UV's.
-
Holy crap
its been what, a day? and you've already almost figured out model data!?
Wow, you realy win dude :O
Epicness, i will keep up with this thread :D
-
wow, that was really quick! :-D
I haven't looked much at these files myself, so sorry I can't be of much help.
You said the vertices were not in PSP-GPU format, which is quite surprising, but what then did you mean by the "tags"?
Some sort of container mechanism for meshes in this game?
But great progress so far, I hope you will fill us in on some specifics soon!
or maybe a model viewer would be a better alternative :wink:
-
This is trully professional work, great job there. You sure work lightning fast.
-
It looks as though they are both holding their normal and EX mode weapons from that shot, maybe we'll be able to tell once we get some UV's figured out...
-
UVs without texture-maps are useless :lol:
I dont know much about TIM or GIM files, but I do know that we will have to manually parse and extract the textures for a proper kind of model-viewer.
Some further observations:
- there appear to be NO obvious offsets at the begging of the files, so the files have to be parsed like X, B3D, 3DS (etc) data, reading and skipping chunks depending on thei "chunk-tags"
- there are "16-mesh" file chunks which are probably 16-bit indexed geometry
- ".tga" chunks, which are soon followed by "MIG 00 1PSP" ascii text, possibly a formal sort of header for the data.
- the Texture data itself seems to be a long list of unpalleted RGBA list (initial impressions)
- "camera" chunks are probably found only in files which are levels/locations/maps
- "arrays" chunks are plentiful and confusing
- "r-box" chunks are most likely bounding-boxes in animated models
- "lambert" chunks are probably generic material properties.
I didn't set-out to fully document these files, but I can't seem to help myself :-D
-
About that MIG stuff Koral, Vash said it's simply GIM.
-
Yep, I was actually going to liken them to 3DS myself. :) Those array chunks have vertex info in their chunk headers, and that's where I believe I've found the vertex tag. However, I'm purely guessing that that's what it is. But it seems that it changes in correlation with the vertex stride, so I'm guessing I can use it to get component offsets too.
I'm still unsure what the data in the mesh chunk is. It seems to have an offset to the corresponding array, and usually a series of what looks like triangle indices. But none of the array data is rendered with indices! And, those values always number up to numVerts in the array, so it's hard to imagine what they could possibly be other than triangle indices or weight indices (which they seemingly can't be, as I already mentioned). That data is very mysterious, although it evidently is not needed to render the models.
I have no idea what a GIM file is. But if it's straight-up RGBA, sounds easy enough. I'll get to work on that soon-ish.
Edit: Got textures loading, they're 8-bit paletted 32-bit RGBA with width/height and offset to palette in the chunk header. But it looks like that mystery data is triangle data after all, because even though the model's holes are filled in drawing it without indices, it becomes apparent that the triangle UV's are being stretched incorrectly, so the texture map on the model looks all cut up and only correctly offset from the first triangle vert.
By the way, koral, do you plan to make a viewer for these models? I'm going to write up a format spec eventually either way, but if you're planning to actively work on this, I'll make more effort to document my specific format findings and exact offset locations and so on.
-
You guys are absolutely amazing you know that? :-D It's interesting and facinating to watch you guys decode the data. But let's not stop the conversational flow for praise just yet, carry on!
-
I wasn't planning to make a new viewer/extractor for these files.
If you provided some specs and stuff then I could always include the format into the CC-Viewer sometime in the future, but if your mesh2drm tool will support these files anyway, then there would be no need for you to document your findings at all.
I am sure everyone will be happy to use your tool to view/extract the models.
Right? :?
But lets not jump the gun. :wink:
You say there are some weird issues going on with the vertices/indices. Seems like it may be somehow related to the bone weights, but that shouldn't affect UVs?
Weird
-
There turned out to be all kinds of issues. Meshes indirectly reference textures through materials, so I had to utilize the material chunks to get textures working. Then it turns out that there are quads as well embedded within the mesh indexing stream, and finally the part that still plagues me, the UV's are scale-and-biased, or maybe just scaled. Since the UV's are shorts, it makes sense to have a per-surface scale-and-bias value to reduce texel precision errors from the range loss. But since that factor varies from model to model (and maybe mesh to mesh, to a lesser degree), I need to find it to handle UV's properly. I've been looking for quite some time now and I just can't figure out where it is.
(http://www.richwhitehouse.com/pubimg/dismodel.jpg)
I had to manually multiply his UV's on U by 4.0 to get him to look correct. :) Squall takes a 3.0 multiply on U, while Kefka takes a 4.0 on U and 1.5 on V, but some models like the Tonberry look just fine without any scale-and-bias. Once I figure out how that scale is stored, it should be ready for a release.
In addition, you can see that the U on the buster sword's UV is flipped. This is especially interesting, because the buster sword is all one surface and all one mesh, but the hilt still looks correct! I thought this might be a material property of some sort, but it doesn't seem to be, especially since a mesh can only reference one material. This in particular is very confusing. It could mean that my scale-and-bias factor theory is wrong, and something compeltely different is going on with the UV's.
-
Great progress :-D
So its just a case of unpredictable UVs? There should be a logical explanation somewhere, it isn't usually an issue in most cases.
The example with the buster-sword in particular: what comes to my mind is possible polygon-flipping, either the vertices are indexed incorrectly (unlikely, seeing as the mesh looks perfect) or the UVs are indexed to incorrect vertices.
I would love to help you try find the bias and scaling factors within the files themselves (if they exist at all) but I don't know which files are which. :oops:
If you can tell me the filenames for the characters you have already mentioned (Squall, Kefka, and the guy above, Bartz from FF5 isn't he?) then I will try hunt for the values.
-
Whoa, I just e-mailed you, and you had already replied here by the time I got the e-mail off. :) I don't think the sword is an indexing error, because if I just use -U, it looks good, and if the index were off by 1, it would result in warped coordinates on a uniformly stretched surface like that. But, then again, I could be missing something there that would allow bad indexing to cause this. It could also be that the texture map is laid out such that the proper inverse bias could still allow the hilt to look correct while flipping the sword back around. That seems the most likely explanation, but I haven't yet studied the map in combination with the UV values to find out. I'm hoping I will find the magical scale-bias value and it will just fix itself. :)
Here are some of the character files:
Squall: File000854
The dude in the pic (I think he's some kind of special character in Dissidia, as he has everyone's weapon on him): File000899
Kefka: File001123
Tonyberry: File000895
The figures I gave to get the UV's for them are probably not exact, I just eyed it. Also for reference, the UV's are in the vertex array (which typically contains vertices of either size 14 or 16), and they are always the last two shorts of each vertex. Converting them to floating point UV's is a matter of f/65535.0f, but that 65535 could turn into another value for the scale-and-bias too, instead of it being a multiply factor. I've tried searching Squall for floats in the general 2.9-3.1 range, and shorts ranging from 21545 to 21945, but haven't found anything promising. I've also sniffed around all the headers for the surfaces, suface sub-meshes, and surface vertex arrays, and their tails (which seem to be non-existent, the next mesh/array always starts right after the triangle/vertex list, respectively).
If you need any help figuring out the chunks, let me know. For reference, here are the chunk types I've documented thus far:
0x0004 - Bone info
0x0005 - Surface (contains meshes and vertex arrays)
0x000a - Texture (each texture is in its own chunk)
0x0008 - Material list
0x000B - Mysterious, I think it may be arrays of data for bone indexing and/or vertex weights.
0x000F - Texture animation, for blinking characters and such. This could conceivably contain data needed to fix the UV's, but probably not. However, I haven't investigated it too much yet.
0x8015 - Unknown, seems to be a list of floats, but I don't think any are useful for the UV correction.
My chunk structure is as such:
WORD chunkType;
short unknownB;
int chunkSize;
-
I was just passing through and noticed your post :lol:
Thankyou for the info
Based on what you have said about the UVs being shorts (of such immense values) I have to agree with you that there may be more to the numbers than just the UVs.
And we also dont know if the PSP would use a peculiar mechanism to shrink the values down so they can be used for rendering.
Have you tried bit-shifting the shorts instead of straight divisions? That may yield some kind of natural offsets, or perhaps leave a spare bit or two
I am just making random guesses here, I cant look into the files myself right now, sorry
-
Have you tried bit-shifting the shorts instead of straight divisions? That may yield some kind of natural offsets, or perhaps leave a spare bit or two
Yeah, I had the same thought about bit shifting, but nothing there seemed to make sense. However, I may have dismissed chunk 0x8015 too quickly, as I believe these floats may have a relation to the UV scaling after all. There seems to be two different 0x8015 chunks in each file, and the second one seems to have what looks like texel centering data. It will take some more looking into to determine if they're what we're looking for.
I am just making random guesses here, I cant look into the files myself right now, sorry
No worries, I'm grateful for your input regardless. :) And there's no rush. I'm sure it's a small matter of time now til we've got this format in the bag.
Edit: A smaller matter of time than I thought!
(http://img12.imageshack.us/img12/2735/dissdone.th.jpg) (http://img12.imageshack.us/my.php?image=dissdone.jpg)
That second 0x8015 contains the exact data I was hoping for! 4 floats in the form of U-Bias, V-Bias, U-Scale, V-Scale. But they're scaled based on 0.5 instead of 1.0, so I was scanning the files for the wrong value ranges all along. :) And, it did indeed fix the buster sword case as well. I'll have the mesh2rdm release up later on today, most likely.
-
Awesome!! :-D
If you ever feel in the mood to document your findings then I can add the spec into the Quimm Wiki for future reference.
But I dont think most people care about how its done as long as they have a way of extracting the models via a tool :lol:
This was all your show MrAdults, full props to you and your hard work!
:-D
-
@MrAdults
That 'The dude in the pic' is Barts Klauser from FF5. ;) Anyway, the progress seems to be pretty fast. :-D
-
That's a great piece of work, once you release I'll make in-game sprite based Kefka using Dissidia model as base (Since Dissidia one is based on artwork which I don't like mainly because of face). And yes, that char you described as unknown is Butz Klauzer (In japanese version) also known as Bartz Klauser (in english). I do have PSP and Dissidia and the reason why he has weapons of all other heroes is because his fighting style is Mime job, where he copies attacks and weapons of other heroes.
-
Oh yeah, that makes sense, since he's from FF5 where everyone could do anything via jobs. Although I remember his hair being bushier. ;) I'm still waiting for the North American release to play the game.
I'll write up a full spec in the coming days, koral. Documenting it will probably take a little while, as there is quite a lot of info required just to get a model rendering, so I'll just chip away at it in my leisure time. I could just send you the source module to handle the files, too, although it is roughly 10 times more horrifying and needlessly complicated than my Crisis Core module, so I would not wish to inflict that harm upon you. :-D
-
Well, all Dissidia characters are based on Amano's artworks, not their igame looks. His ingame sprite did indeed have different hair but on Amano's drawings it was like this.
-
Tool and what's-new/how-to-use here:
http://www.richwhitehouse.com/index.php?postid=33
It seems to work fine with environmental models and stuff too. There is one bug that I only just noticed, which is that sometimes pure static geometry that is symmetrical will get half of itself culled out. I believe they use a surface flag to indicate those surfaces and re-render them with inverse axis coordinates, to save on vertex space. But, I haven't gotten around to finding that flag yet. The only one of the characters that are affected from what I've been able to tell is Bartz. His cape must be "static" for some reason, maybe it's because there's special code handling to animate the verts or something. But generally, since characters are point-weighted, that optimization can't take place on them.
I think that's everything. Enjoy. :)
-
Cerberus next plz :-P
I'm surprised at how fast this was done, nice job!
-
Thanks for the download link, the fact it can view locations is stunning aswell. I'd like to add that on your screenshot Lunar Whale is clearly visible in the moon level, however ingame, it never can be seen. I know that since I've checked multiple times roaming around the level just now on my PSP and it's clearly not there. Could it be content that was blocked from final version of the product?
EDIT
Tonberry also never appears in the game as 3D model, only 3D models that appear are main chars and villains, Cosmos and Chaos, nothing else (Other than locations that is) Summons and monsters like Tonberry appears in the game as 2D sprites from original sprites or artworks.
EDIT2
Aerith model is there aswell, what the heck? o.O
EDIT3
Why do the EX-Mode weapons appear untextured??
EDIT4
I went through all the models and it seems that actually NONE of characters EX-Modes models are here, neither their alternate models. (In the game, each character has EX-Mode, something like Limit Break, aswell as alternate costume, for Cloud it's Advent Children outfit and so on)
-
That's interesting, I didn't know those models weren't actually in the game. Maybe they're secret characters?
I noticed the untextured weapon models too, but textures for them don't actually exist in the model, I don't think. But they do have materials. I'd have to see a screenshot of them or something, but maybe they use procedural texturing and a blend mode? I don't obey any of the blend flags or anything for materials in the viewer, so that could explain things.
-
Nope, the secret chars are Shantotto and Gabranth (FF11 and FF12 chars). I'd know if there were any secret chars since I have pretty much whored everything out of Dissidia (Already have over 145 gameplay hours lol) I think they simply forgot to cut the crisis core leftovers out.. Or they were testing something.
And here's a few screenshots of EX Modes and alternate outfits which also seem to not be showing up here...
Squall:
http://images3.wikia.nocookie.net/finalfantasy/images/2/29/Dissidia_Squall_Leonhart_ex.png
http://images2.wikia.nocookie.net/finalfantasy/images/0/00/Dissidia-SeeDSquall.png
Kefka:
http://images1.wikia.nocookie.net/finalfantasy/images/7/7e/Dissidia_Kefka_Pallazzo_ex.png
http://images1.wikia.nocookie.net/finalfantasy/images/5/56/Kefka_Alternate_Form.jpg
Cloud:
http://images4.wikia.nocookie.net/finalfantasy/images/8/8a/Dissidia_Cloud_ex.png
http://images3.wikia.nocookie.net/finalfantasy/images/f/f2/CloudAlt.jpg
Sephiroth:
http://finalfantasy.wikia.com/wiki/Image:Dissidia_Sephiroth_ex.png
http://finalfantasy.wikia.com/wiki/Image:Sephiroth_Alternate_Form.jpg
The filenames speak for themselves so I guess I don't need to describe what is what.
-
Very weird, I just double-checked Squall and made sure every chunk/byte of his file is accounted for, and there's definitely no extra skins or mesh data for these Ex modes. All of those duplicates of the Squall model seem to only include different skeletal/animation data, too. No unknown chunks are parsed.
Maybe the ex skin/mesh data is in another batch of files or something. Are you sure the rip is complete?
-
Woohoo! That wraps up another Final Fantasy game!
(and its my 100th post, go me, go me! :lol:)
I have updated the first post to reflect MrAdults work. :-D
But I had absolutely no idea about all those "hidden" characters and models, that is an incredibly interesting find! :-o
If only CC had something more mysterious about it. Its a little dissapointing.
Aurenasek, is it possible that there are more model files somwhere else, besides these files you uploaded here?
-
Those are ALL .gmo files that are in the game. I just decompiled whole .iso again just to make sure. Maybe they could be in other files...
If you could support me with some FTP or free webhosting that allows large files I'd upload whole decompiled iso so you could check up on the files.
I'm asking for that since FileFront bankrupted and they are closing on 30th.
-
What you could try doing is running that texture extractor over the GMO's and other types of files, and see if it can get anything that mesh2rdm can't. You could also try running mesh2rdm over non-gmo extension files, but it won't work unless the full file chunk structure is intact. I don't know how the existing texture extraction tool(s) work, but if they don't need the gmo structure, they might be able to help find which other files have more character data in them.
-
Hmm good idea. I'll seperate all filetypes into their own folders and then run the GIM extractor on them, hopefully I'll manage to isolate the format where textures of Ex-Modes and alternates are.
-
There are quite a number of breaks in the file-numbers, actually every other file (per-character).
Could you confirm if those "missing" files were extracted properly Aurenasek? Even if they had a different file extension. Maybe upload a handful of them on rapidshare?
Because what has me preplexed is why are there so many different GMO files per-character?
Are there multiple story-events with each new character, or are they simply LOD variations?
-
There are lots of story events in the game, half of the time you'll spend on watching cutscenes (in main story mode), so that's why there are so many seperate GMO's most likely, each having different animation set or maybe even skeleton.
As for the missing files, that's how the game is made. I can canfirm for bloody 9001th time that everything extracted properly. I don't understand why do you people not trust me :/ It's annoying.
EDIT
Bad news, the Gim extractor works only on the .iso itself, I tried running it over gmos and other files and it simply didn't work, so I guess that's when problems start.
Or maybe I'm too stupid to make it work with other types of files, I really don't know. Maybe someone else could try using it over the GMO's I uploaded?
-
I've just realized that those huge GMO files contain sub-models! I previously thought that they were entirely animation data. It looks the sub-models are parsed exactly like the ones in the individual model files, and I'm already finding some of the new costumes. It shouldn't take too long to hammer it out, so I'll go ahead and finish this up and put up a new release before I call it a day.
-
Phew, you just saved me trouble of uploading 630MB of data. Rest are AT3 and PMF files so I decided to skip those on the spot (PMF = Video, AT3 = Audio)
You're great MrAdults, or should I say Rich? :P
-
Sorry if it souded like I was accusing you for being stupid, but its not you that I dont trust.
I dont trust the extractor. :wink:
I might have to get my hands dirty with this and see what the ISO itself contains. A friend of mine has dissidia, so soon I will have all the data I need.
I apologise once again for potentially offending you Aurenasek116.
EDIT
not again, just as i was finishing my post, you come along :-P
That is great news MrAdults!
-
It's ok Koral, but I wouldn't be so harsh on tools next time, Vash is as much good coder as you and Rich, he coded a lot of decompilers and extractors for PS2 and PSP games.
-
Huge oversights is just a pitfall of trying to reverse-engineer content for a game you've never actually played, I guess. :-D But anyway, I'm sure koral didn't mean to say Vash is a bad coder, we were just exploring all the possibilities. And all coders make mistakes. :)
(http://img8.imageshack.us/img8/8375/seedo.th.jpg) (http://img8.imageshack.us/my.php?image=seedo.jpg)
We are good to go now, I think. I ran through all of those later big files and they all seem viewable with all of the alternate costumes. You can get the new version here:
http://www.richwhitehouse.com/index.php?content=inc_projects.php&filemirror=mesh2rdmv191.zip
-
Sorry for doubting you too Vash! :wink:
I will let you and MrAdults tie up the loose-ends here, I have spammed here enough already
:-)
EDIT:
again!?
Gawd, I dont know what to say!
Fantastic! :-D
-
And once again I have to report something. Great job on getting the alternate costumes showing up, but EX-Modes still aren't here, atleast not for all characters.
There's no winged sephy, no God form kefka, no neo-exdeath and so on. Could you please have another look at it MrAdults, if you have time that is?
Sorry for being so annoying on this, but I'm simply really very interested in Kefka's God form.
-
Actually, there are multiple sub-models in some of the files, but I only parse one for the viewer. I thought I had it so you could optionally extract the second one with a command line switch, but I didn't test it, and apparently it's broken. :) I will fix it and get a new one up for you later.
-
Hmm, actually I haven't tested using the new command for submodels because I didn't realize you added it, but if you say it's broken then I'm not even going to.
-
http://www.richwhitehouse.com/index.php?content=inc_projects.php&filemirror=mesh2rdmv192.zip
Ok, I'm really going to take a break now. :) This fixes that command line switch, and in models with multiple sub-models, you can push enter in preview mode to cycle through them. I tested that this works to get to Kefka's God form, so I hope you are appeased now. ;)
-
Wow, Mr Adults (or should i call you rich?)
You Really know what you're doing! i take it you do this for money?
I'm Really impressed at your epic skill! Thanks a lot!
-
From what I gathered he didn't do the crisis core and dissidia stuff for money but seeing as he worked on big gaming projects then it's obvious how he earns money, he's a great coder and everyone should treat him like that.
Sorry for talking a bit in 3rd person MrAdults :-P
This version of mesh2rdm works perfectly, finally god Kefka model in my hands :> Thanks again.
-
He is just a game developer, very much like me :-)
We happen to have a deep understanding of how games are made and how the data from the many files are expected be parsed in, so it is quite natural for us to find the relevant information from other game formats.
Please remember that with CC the data was not encrypted or compressed, so I had an easy time trying to find what I was looking for.
And with Dissidia, Aurenasek116 (via the epicness of Vash) provided the exact model files, so it was even more straight-forward.
It has been far easier for us to get these models viewed than it usually would be (think of the woes of FF7-FF12 and you will get some idea).
Luck was on our side, that is for sure :lol:
But MrAdults is a lot quicker and better coder than me, there is no doubt about that!
And I have updated the first post for clarity. :wink:
-
:0 wow, thanks a lot guys
Anyway, i'm a little stuck as to how to get mesh2rdm working properly. opened on its own, it just serves as a list of the functions it has. opened with a model, it serves a preview wondow. But i can't seem to get to anywhere where i could input the "command line" stuff. any help there? i wanna export as .obj and make use of the new feature :D
-
I use Start -> Run -> Cmd and do all operations this way.
In cmd simply navigate to the path where you have mesh2rdm. Hope that helps.
If that won't help though, I could make a few .bat files for you, just tell me what exactly do you need :)
-
File000854.gmo- File000874.gmo Squall
File000877.gmo - File000889.gmo Ultimecia
File000895.gmo Tonberry
File000896.gmo Crisis core aeris
File000899.gmo - File000917.gmo Bartz
File000920.gmo - File000930.gmo ex-death
File000937.gmo - File000951.gmo Cecil
File000954.gmo - File000962.gmo Golbez
File000969.gmo - File000985.gmo Zidane
File000988.gmo - File001000.gmo Kuja
File001010.gmo - File001027.gmo warrior of light
File001029.gmo - File001041.gmo Garland
File001049.gmo - File001055.gmo Rosa?
File001079.gmo - File001094.gmo Cloud
File001097.gmo - File001103.gmo Sephiroth
File001110.gmo - File001121.gmo Terra
File001123.gmo - File001129.gmo cefka or however you spell it lol
File001136.gmo - File001152.gmo Tidus
File001155.gmo - File001163.gmo Jeckt
File001170.gmo - File001184.gmo Onion knight
File001187.gmo - File001195.gmo Cloud of darkness
File001202.gmo - File001216.gmo Firion
File001219.gmo - File001229.gmo Dark emperor
File001235.gmo Cloud
File001237.gmo Zidane
File001243.gmo Tidus
File001250.gmo Cloud of darkness
File001252.gmo ???
File001256.gmo Bartz
File003766.gmo Cloud
File003767.gmo Cloud AC
File003768.gmo Cloud blue
File003771.gmo Sephiroth
File003772.gmo Shirtless Sephiroth
File003773.gmo Sephiroth Blue
Here's some models i found, i'll update the list later on.
-
Make sure to include multiple names for the .gmo's that contain multiple models (Press Enter while in viewer to see if there is any other model)
-
List updated, note File000896.gmo It's Crisis core aeris.
If anyone can help with the characters that i dont know, that would be appreciated.
-
the pressing "enter" thing doesn't seem to do anything... and I've done it on just about every model...
Have we still not found a way to view EX models?
EDIT:Bah! never mind... didn't realize there was a newer version than what I had...
-
I made a full filelist with descriptions, I tried to make it clean too, I know ultima espio was already working on one but seeing as it wasn't full, I decided to post my own, here it is:
File000854.gmo to File000874.gmo - Squall
File000877.gmo to File000889.gmo - Ultimecia
File000891.gmo to File000893.gmo - Chapter 8 Crystal
File000895.gmo - Tonberry
File000896.gmo - Aerith
File000899.gmo to File000917.gmo - Bartz
File000920.gmo to File000930.gmo - Ex-Death
File000932.gmo to File000934.gmo - Chapter 5 Crystal
File000937.gmo to File000951.gmo - Cecil Paladin and Dark Knight
File000954.gmo to File000962.gmo - Golbez
File000964.gmo to File000966.gmo - Chapter 4 Crystal
File000969.gmo to File000985.gmo - Zidane
File000988.gmo to File001000.gmo - Kuja
File001002.gmo to File001004.gmo - Chapter 9 Crystal
File001006.gmo to File001008.gmo - Unknown Weird Object
File001010.gmo to File001027.gmo - Warrior of Light
File001029.gmo to File001041.gmo - Garland
File001043.gmo to File001047.gmo - Chapter 0 and 1 Crystal
File001049.gmo to File001055.gmo - Cosmos
File001057.gmo to File001059.gmo - Wild Rose
File001061.gmo to File001071.gmo - Writing Feather
File001073.gmo to File001076.gmo - Elixir
File001079.gmo to File001094.gmo - Cloud
File001097.gmo to File001103.gmo - Sephiroth
File001105.gmo to File001107.gmo - Chapter 7 Crystal
File001110.gmo to File001121.gmo - Terra
File001123.gmo to File001129.gmo - Kefka
File001131.gmo to File001133.gmo - Chapter 6 Crystal
File001136.gmo to File001152.gmo - Tidus
File001155.gmo to File001163.gmo - Jecht
File001165.gmo to File001167.gmo - Chapter 10 Crystal
File001170.gmo to File001184.gmo - Onion Knight
File001187.gmo to File001195.gmo - Cloud of Darkness
File001197.gmo to File001199.gmo - Chapter 3 Crystal
File001202.gmo to File001216.gmo - Firion
File001219.gmo to File001229.gmo - Emperor Palamecia
File001231.gmo to File001233.gmo - Chapter 2 Crystal
File001235.gmo - Cloud
File001237.gmo to File001241.gmo - Zidane
File001243.gmo to File001245.gmo - Tidus
File001247.gmo - Wild Rose
File001250.gmo - Cloud of Darkness
File001252.gmo - Ex-Death
File001254.gmo - Firion
File001256.gmo - Bartz
File001258.gmo - Terra
File001260.gmo - Squall
File001262.gmo - Tidus
File001264.gmo - Jecht
File001266.gmo - Ex-Death
File001268.gmo to File001286.gmo - Unknown Weird Object
File003526.gmo - Good Statue Pedestal
File003527.gmo - Warrior of Light Statue
File003528.gmo - Firion Statue
File003529.gmo - Onion Knight Statue
File003530.gmo - Cecil Dark Knight Statue
File003531.gmo - Bartz Statue
File003532.gmo - Terra Statue
File003533.gmo - Cloud Statue
File003534.gmo - Squall Statue
File003535.gmo - Zidane Statue
File003536.gmo - Tidus Statue
File003537.gmo - Shantotto Statue
File003538.gmo - Garland Statue
File003539.gmo - Emperor Palamecia Statue
File003540.gmo - Cloud of Darkness Statue
File003541.gmo - Golbez Statue
File003542.gmo - Ex-Death Statue
File003543.gmo - Kefka Statue
File003544.gmo - Sephiroth Statue
File003545.gmo - Ultimecia Statue
File003546.gmo - Kuja Statue
File003547.gmo - Jecht Statue
File003548.gmo - Judge Gabranth Statue
File003549.gmo - Evil Statue Pedestal
File003550.gmo - World Map Enemy Statue 1
File003551.gmo - World Map Enemy Statue 2
File003552.gmo - World Map Enemy Statue 3
File003553.gmo - World Map Enemy Statue 4
File003591.gmo to File003630.gmo - Various Map Objects
File003632.gmo - Hero Statue
File003634.gmo - Villain Statue
File003635.gmo - Treasure Chest 1
File003636.gmo - Elixir
File003637.gmo - Summon Crystal
File003638.gmo - Treasure Chest 2
File003639.gmo - Treasure Chest 3
File003645.gmo to File003656.gmo - Map Skyboxes
File003706.gmo - Warrior of Light/Knight of Light (Press Enter to Switch Model)
File003707.gmo - Warior of Light/Knight of Light Alternate Costumes (Press Enter)
File003708.gmo - Crystal Ghost Warrior of Light
File003711.gmo - Garland
File003712.gmo - Garland Alternate Costume
File003713.gmo - Crystal Ghost Garland
File003716.gmo - Firion/Master Firion (Press Enter)
File003717.gmo - Firion/Master Firion Alternate Costumes (Press Enter)
File003719.gmo - Crystal Ghost Firion
File003721.gmo - Emperor Palamecia/Emperor of Hell (Press Enter)
File003722.gmo - Emperor Palamecia/Emperor of Hell Alternate Costumes (Press Enter)
File003723.gmo - Crystal Ghost Emperor Palamecia
File003726.gmo - Onion Knight/Ninja/Sage (Press Enter)
File003727.gmo - Onion Knight/Ninja/Sage Alternate Costumes (Press Enter)
File003728.gmo - Crystal Ghost Onion Knight
File003731.gmo - Cloud of Darkness/Final Cloud of Darkness (Press Enter)
File003732.gmo - Cloud of Darkness/Final Cloud of Darkness Alternate Costumes (Press Enter)
File003733.gmo - Crystal Ghost Cloud of Darkness
File003736.gmo - Cecil Dark Knight/Paladin EX Weapons (Press Enter)
File003737.gmo - Cecil Dark Knight/Paladine EX Weapons Alternate Costumes (Press Enter)
File003738.gmo - Crystal Ghost Cecil Dark Knight/Paladin (Press Enter)
File003741.gmo - Golbez/Golbez Shadow Dragon (Press Enter)
File003742.gmo - Golbez/Golbez Shadow Dragon Alternate Costumes (Press Enter)
File003743.gmo - Crystal Ghost Golbez
File003746.gmo - Bartz
File003747.gmo - Bartz Alternate Costume
File003748.gmo - Cystal Ghost Bartz
File003751.gmo - Ex-Death/Void Ex-Death (Press Enter)
File003752.gmo - Ex-Death/Void Ex-Death Alternate Costumes (Press Enter)
File003753.gmo - Crystal Ghost Ex-Death
File003756.gmo - Terra/Esper Terra (Press Enter)
File003757.gmo - Terra/Esper Terra Alternate Costumes (Press Enter)
File003758.gmo - Crystal Ghost Terra
File003761.gmo - Kefka/God Kefka (Press Enter)
File003762.gmo - Kefka/God Kefka Alternate Costumes (Press Enter)
File003763.gmo - Crystal Ghost Kefka
File003766.gmo - Cloud
File003767.gmo - Cloud Alternate Costume
File003768.gmo - Crystal Ghost Cloud
File003771.gmo - Sephiroth/One Winged Sephiroth (Press Enter)
File003772.gmo - Sephiroth/One Winged Sephiroth Alternate Costumes (Press Enter)
File003773.gmo - Crystal Ghost Sephiroth
File003776.gmo - Squall
File003777.gmo - Squall Alternate Costume
File003778.gmo - Crystal Ghost Squall
File003781.gmo - Ultimecia/Griever Ultimecia (Press Enter)
File003782.gmo - Ultimecia/Griever Ultimecia Alternate Costumes (Press Enter)
File003783.gmo - Crystal Ghost Ultimecia
File003786.gmo - Zidane/Trance Zidane (Press Enter)
File003787.gmo - Zidane/Trance Zidane Alternate Costumes (Press Enter)
File003788.gmo - Crystal Ghost Zidane
File003791.gmo - Kuja/Trance Kuja (Press Enter)
File003792.gmo - Kuja/Trance Kuja Alternate Costumes (Press Enter)
File003793.gmo - Crystal Ghost Kuja
File003796.gmo - Tidus
File003797.gmo - Tidus Alternate Costume
File003798.gmo - Crystal Ghost Tidus
File003801.gmo - Jecht/Final Aeon Jecht (Press Enter)
File003802.gmo - Jecht/Final Aeon Jecht Alternate Costumes (Press Enter)
File003803.gmo - Crystal Ghost Jecht
File003806.gmo - Shantotto/Cobra Set Shantotto (Press Enter)
File003807.gmo - Shantotto/Cobra Set Shantotto Alternate Costumes (Press Enter)
File003808.gmo - Crystal Ghost Shantotto
File003811.gmo - Gabranth/Judge Gabranth (Press Enter)
File003812.gmo - Gabranth/Judge Gabranth Alternate Costumes (Press Enter)
File003813.gmo - Crystal Ghost Gabranth/Judge Gabranth (Press Enter)
File003816.gmo - Chaos
File003818.gmo - Chaos/Full Power Chaos (Press Enter)
File003820.gmo - Chaos/Full Power Chaos (Press Enter)
File003823.gmo to File003859.gmo - Maps
File003862.gmo - Star Skybox
File004000.gmo to File004044.gmo - Unknown Objects
-
Wow, Mr Adults (or should i call you rich?)
You Really know what you're doing! i take it you do this for money?
I'm Really impressed at your epic skill! Thanks a lot!
Yep, what koral said. :) I mostly do free-lance programming/game dev contracts for financial income, myself.
Please remember that with CC the data was not encrypted or compressed, so I had an easy time trying to find what I was looking for.
And with Dissidia, Aurenasek116 (via the epicness of Vash) provided the exact model files, so it was even more straight-forward.
It has been far easier for us to get these models viewed than it usually would be (think of the woes of FF7-FF12 and you will get some idea).
Luck was on our side, that is for sure :lol:
It's lucky that asset compression for models is a fading trend in this generation, it makes things that much easier for us. :) Particularly for the PSP where the contiguous read times are actually quite good, and compressing your assets tends to actually net you a loss in load times from decompression. Coupled with the fact that the media has a higher capacity than you'd probably ever need to use for a game on a platform with its specifications, there's not much reason to compress geometry data.
But MrAdults is a lot quicker and better coder than me, there is no doubt about that!
Oh, nonsense. ;)
:0 wow, thanks a lot guys
Anyway, i'm a little stuck as to how to get mesh2rdm working properly. opened on its own, it just serves as a list of the functions it has. opened with a model, it serves a preview wondow. But i can't seem to get to anywhere where i could input the "command line" stuff. any help there? i wanna export as .obj and make use of the new feature :D
Aurenasek already mentioned it, but you can use the Start->Run menu and enter "cmd" (without quotes) to bring up a command prompt. Then cd to your model directory where you have a copy of the gmo and mesh2rdm.exe and run it with the desired parameters. You may have to seek out a DOS command reference if you aren't used to using a command prompt, though. :)
And finally, there is a new release (v1.93) of mesh2rdm up now, here:
http://www.richwhitehouse.com/index.php?content=inc_projects.php&filemirror=mesh2rdmv193.zip
As it turned out, lots of surfaces still weren't showing up, like some clothing bits and chains hanging off of characters and weapons. I think I've cleared up pretty much all of the problems now, except for a messed up texture here and there. I'll be starting on the file spec now.
-
Nice to see this update, however most of those details mentioned must have been very minor (Except for Bartz cape which was obvious).
Do you plan on ever trying to figure out the weighting data? If not, then it's not a problem anyway since I actually prefer to pose models manually with vert selection, allows me for more precision.
-
Yeah, it was all pretty subtle stuff, except for a few glaring flaws (like the Bartz cape, and the wings on normal Kefka were busted).
I don't plan to proceed in figuring out the weighting data, though I do have a pretty good idea of where it is, as well as the bone indices used for each mesh and the bones themselves. So I'll include all that I've observed there in the format spec. After that, koral may or may not decide to finish up my work there. :) I personally don't have much desire to pose the models, though. I'm mainly interested in weighting them to existing skeletons as well.
-
MrAdults, you seem to know what you're doing with Model Formats, and i'd really like help with a hack i'm currently working on for KHIIFM+
Could i PM you to ask you quite a complicated favor? i'd really appreciate it, but i dont mind if you're busy.
-
I don't know if I'll be able to accommodate you, but feel free to PM away.
-
this program is very cool :-D
but I've some questions
1. How do you export the dissidia .gmo(s) to .smd / .obj / any importable files into milkshape ? I tried to write the -smdout / -objout things but it doesn't work :oops: , or where does I write it ?
2. When converted to .smd / .obj , does it have animations ?
PS : It's my first post here , congrats me :-D
-
Hey there and welcome to Qhimm :P
I replied to your question on Rich's website but in case you haven't read there, here it is again..
I don't have any problems with exporting o.O
I'm using a .bat file that I edit for every file I want to export, here it is if you want to use it:
mesh2rdm File003761.gmo Kefka.smd -dissskip 1 -texpre Kefka -rotate -90 0 0 -scale 1.0 -smdout
That line will export you god form kefka ;P
And no, neither Dissidia nor Crisis Core models extract with animations. Crisis Core ones extract with weighs so you can move the skeleton and pose the model but Dissidia models don't, since Rich didn't really focus on getting Dissidia skeleton exported, which isn't really a problem anyway if you know how to use 3d software :P
-
Thx :-D
btw , I still have the problem using it
well , I tried
but nothing happened >.<
here's how I do it :
1. Open my notepad
2. Copy the mesh2rdm File003761.gmo Kefka.smd -dissskip 1 -texpre Kefka -rotate -90 0 0 -scale 1.0 -smdout
3. Save as mesh2rdm.bat
4. Put in the mesh2rdm folder
5. Copy Kefka God model / File003761
6. Drag the File003761 to the mesh2rdm
Did I do something wrong :??
btw , is the way to extract FF7CC models is the same with extracting dissidia models ?
I used Koral's Viewer and export it to .obj , but I can't see any bone in Milkshape :oops:
-
I don't think OBJ supports weighted skeletal structures...
-
Yeah, OBJ doesn't support vertex weights. You'd have to export to .smd with mesh2rdm to keep the weights and skeleton intact. However, mesh2rdm only supports weights/skeleton for Crisis Core models. I did not implement support for Dissidia model weights/skeleton.
I responded to your post on my web site as well, but to answer again:
Yeah, what Aurenasek said will work fine. It sounds to me like you're still just drag-dropping the GMO over mesh2rdm instead of running the batch. You need to execute that mesh2rdm command in a directory with both File003760.gmo and mesh2rdm.exe.
-
blender support?
-
Blender has working smd import/export via scripts. As does pretty much everything.
-
I have created a new Wiki page for Dissidia here: http://wiki.qhimm.com/Dissidia (http://wiki.qhimm.com/Dissidia)
It's rather empty right now, but it should fill up sometime or other.
I wasn't sure exactly how Aurenasek116 got the extraction files, or if I should mention Vash's tools and their website in the wiki.
Would it be OK for me to do that, or is it fine the way it is?
Pretty much off-topic, but I have also begun to wikify the CC [!]-model files: http://wiki.qhimm.com/FF7:CC/Model_Formats#File_Structure
MrAdults, could you confirm for me if it matches your findings, or if I have missed any information?
I have totally avoided the PSP-GPU decoding specifics for the meantime because Dissidia will likely confirm or contradict it, and I dont want to keep editing stuff, meh :lol:
-
Looks good, from what I recall, koral. And here's my draft of the Dissidia file spec:
http://www.richwhitehouse.com/index.php?postid=34
You'll notice that the vertices actually have nothing to do with the PSP GPU format or the way Crisis Core stored its verts. In fact, the vert list even seems to have another index to reference common vertex weights and normals, although I have not completely confirmed that (just speculating based on the data I've seen). I did a little bit of experimenting with getting the blend modes and stuff working from the materials, too, but haven't quite figured it out completely yet. I thought I had it, but it seems like some surfaces on the moon map are additive when they shouldn't be. Perhaps I'm not doing multiple passes correctly. But in any case, I'm gonna take a break from it for a while. I'll let you know if/when I start back up on it in case you're working on it too, so we don't attack the same problems at once. :)
-
I got the tools from alucard.cc forums, koral.
They are public forums for game hackers (mainly consoles) but I doubt Vash would be angry if you added them to the Wiki page.
I also wanted to put up a table on the wiki with all file formats found on Dissidia .iso but it seems the wiki won't let me register :/
-
That's because you have to message me with a username/email address/and password to add you.
-
Or if you could just PM me the info so I can wikify it for you. :wink:
But if you do change or add anything yourself then please do let me know, I have a long task ahead of me wikifying MrAdults GMO specs (which is extremely awsome BTW, crisp and clear to read and understand)
I wont be doing anything with this format for a while, because I am currently creating a new Viewer tool independant of Irrlicht's renderer.
Its a nice rendering engine, but it makes things impossibly difficult to manage sometimes, like the GUI stuff and polygon-sorting for correct transparency rendering.
I may be picking up on an older game soon too :lol:
-
I may be picking up on an older game soon too :lol:
I'm guessing ergheiz?
:P i saw the thread in game tweaking.
-
:-D
I have just started the laborious process of wikifying MrAdults specs (trying not to copy-paste it all), and moved things around a little for better organisation.
I also created a new "Miscelenous Findings" section because I remembered that there were actually a number of interesting findings, the most obvious one being the inclusion of Aeris and Tonberry.
I wonder if they also have their animations intact? It would be interesting to see if they could be somehow loaded up in the game.
Maybe there is a Debug-Menu in this game too? :wink:
-
any chance of ripping Dirge Of Cerberus models ? :-D
-
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 (http://hitmen.c02.at/files/yapspd/psp_doc/chap11.html#sec11.5.15). 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.)
-
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. :)
-
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:
-
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.
(http://www.richwhitehouse.com/pubimg/moonmap.jpg)
-
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.
-
That looks nice! :-D
I must remind myself to try vertex-colours on the CC location-models too
-
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.
-
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.
-
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:
(http://www.richwhitehouse.com/pubimg/drac01.jpg) (http://www.richwhitehouse.com/pubimg/drac02.jpg) (http://www.richwhitehouse.com/pubimg/drac03.jpg) (http://www.richwhitehouse.com/pubimg/drac04.jpg)
(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. :)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
- 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]
- 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]
- 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 (http://www.mediafire.com/?ltxmwwoxkmq) 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 (http://www.mediafire.com/?ncvbq1tsbdq)
Exit (http://www.mediafire.com/?0mh2jyj9mjx)
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.)
-
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.
-
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.
-
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.
-
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
-
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.
-
sweet, thanks a lot :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?
-
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:
(http://img6.imageshack.us/img6/4798/exportmap.th.jpg) (http://img6.imageshack.us/my.php?image=exportmap.jpg) (http://img6.imageshack.us/img6/1759/exportsquall.th.jpg) (http://img6.imageshack.us/my.php?image=exportsquall.jpg)
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? ;)
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 (http://forums.qhimm.com/index.php?topic=8290.msg100586#msg100586). 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
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 (http://wiki.qhimm.com/User:Ukurere)) ...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
-
The proper graphics term is "weighted bone"
-
- 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.
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? (
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?
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:
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.
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).
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. :)
-
Hey I was wondering if someone can help me.
-
Thanks for the answers, now I need to sit back and digest the info, think about how to change the article...
[Offtopic: previous post by SOLDIERBOY looks like he meant to post in a different thread. So take that into account when responding, I guess.]
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. ;)
Yes, of course I'll give you credit where I'm able to. If I were, say, putting up your info on a personal web page, I'd have your name/website more or less emblazoned across the whole thing. But I'm not sure how well that works for a wiki article. I'll think of something.
v->pos[0] = v->pos[0]*2.0f*posScales[3] + posScales[0];
Okay, but now I'm curious why *2.0 is in there. Is that just The Way Things Are?
(when primType=4 and stride>4, **** happens)
Um, so let me get this straight... if stride=6, that gives me 10 indices: 4 indices for quad + 3 indices for tristrip + 3 indices for tristrip?
And if stride==1, do I just forget about quads and treat it as a triangle strip?
(Side note: I haven't ever seen stride==2 or 3 for quads, and I assume you haven't either. Right?)
And that brings me to another thing: Do we call primType 4 "quads" or "triangle strip" (or both), and why the does it mix them together like that?
-
Yeah, the scale is such that 0.5 means "leave it as is" which I first observed when looking at the scale-and-bias relative to the UV coordinates. The positional scale relative to the given bias dictates the same thing in order to end up with the correct model origin. I suspect it's just the product of the initial formula used to generate the scale and bias values, as I see no real reason relating to modelview/texture matrix transforms that the value should be normalized to 0.5.
I have never seen stride 1, 2, or 3 for quads. If it were 1, presumably that would dictate to use the index list directly with no stripping and draw it as quads (much as the stride 1 triangles are treated). Have you actually seen 1, and if so, could you throw a model using 1 my way? :)
I think the reason for using a triangle strip with a quad base, if that's what's going on, is simply that it's more flexible. For example, with a full-blown quadstrip, you could have to have 2 additional indices for each strip bit instead of 1.
It's also possible (perhaps even more likely) that even stride 4 "quads" are still just triangle strips (after all, both would potentially have the same winding and number of indices - and a single-triangle strip with a "stride" of 3 wouldn't exist in known cases, because it would be redundant and just present as a normal triangle index list), but that would make the assumption that stride 1 "quads" don't exist. Both ways of looking at the data would in theory give the same results (with the given assumption in place), so it's just a matter of how you wish to interpret the data, I suppose. My code does leave the open-ended assumption in place that a stride-1 type-4 can exist and handles it as such, which is really what led to the whole "quad" line of thinking.
-
All this information is passing completely over my head :lol:
But do keep up the great work Ukurere and MrAdults!
I am trying to keep a running commentry of the major news in the first post of this topic, it is the least I can do! :-)
And I have also added a little section on using mesh2rdm, as some people have had difficulty with the command-prompt side of things.
Maybe I should call it "Aurenasek116's mesh2rdm 101"
:-D
-
Sorry it took me so long, but this is what i meant about the boxy-ness.
It wont go away, no matter how many smoothing and welding modifiers i apply to it!
(the texture discolourations are supposed to be there)
(http://i182.photobucket.com/albums/x74/beefpwnage/Squarebox.png)
Crisis core models dump fine, so maybe it's a problem with my Laptop?
-
No, nothing wrong with your laptop or anything, there is something up with the actual polygons.
Dont apply "modifiers", just select all the polygons (ctrl+A in poly-selection mode) then scroll down until you get to "polygon properties" then hit "Auto Smooth".
If that doesnt solve the problem, then either there are duplicate vertices or there are duplicate polygons.
Either way, a weld operation on the vertices should produce some results, so maybe you need to try even smaller thresh values?
-
anything under a threshold of like 50 says there arent any verticies within the threshold, and over that just ruins the model O.o
If i Detatch all the parts from the mesh using the part selection thing, auto smooth will work on those seperate parts. but then the bones will detatch and i can't change the weird arm positioning. its really weird, why wont the smoothing just work on the entire "SMDimport" object?
-
I have absolutely no idea. :?
I will try it myself and see what happens. What parameters did you use to export the model?
-
mesh2rdm File003766.gmo Cloud.smd -texpre Cloud -rotate -90 0 0 -scale 10.0 -smdout -flipuv
-
There are a couple things you can do to fix this. Add "-smoothnorm 0.001" to your command line and it should fix it on export. Or in Max, you can:
1) Select the mesh object(s), and go to Modifiers->Mesh Editing->Edit Normals
2) With the Edit Normals modifier selected on the Modifier List, hit ctrl+A to select all normals
3) Hit the "Break" button
4) Hit the "Unify" button
The problem is just that the model's triangles are all broken up without shared verts, and by default, mesh2rdm only averages vertex normals along triangles that actually reference a vertex.
-
Re: stride: Oops, I think I mixed up idxStride and numIdx there. So in that case idxStride isn't 1, it's 206.
By the way, what is the point of swapping idxStride and numIdx for different primTypes? I ask this because in the following picture, I changed primType without changing idxStride or numIdx, and it seems to handle it okay:
(http://i40.tinypic.com/15wxls4.png)
(idxStride=206, numIdx=1, verts are unindexed)
From left to right, this matches PRIM (primitive kick) in Yet Another PSP Documentation (http://hitmen.c02.at/files/yapspd/psp_doc/chap11.html#sec11.5.3):
0 - 000 Points
1 - 001 Lines
2 - 010 Line Strips
3 - 011 Triangles
4 - 100 Triangle Strips
5 - 101 Triangle Fans
6 - 110 Sprites (2D Rectangles)
It looks like each Sprite is made of 2 verts, which I guess makes sense. (Also, 7 = triangles, 8 = points, 9 = lines, ...)
P.S. Are anyone else's SMD textures looking all mucked up (even with -flipuv enabled)? Dissidia textures show just fine, but stuff from Castlevania and Gitaroo Man looks not quite right (and the UV layouts look a bit different). It doesn't affect OBJ models, so I'd assume my SMD import plugin is to blame, but I'd like to check here first.
-
Swapping them was necessary with my interpretation of the data. But as we've noted, the data can be interpreted in a number of ways with the same results. I'm not sure exactly what you're changing based on that picture, as I have no idea what Gitaroo Man looks like normally and have never played it. But if your changes work, congratulations. :)
Dracula models exported to smd work fine for me, at least all of the ones I've tested (including Dracula himself). I also use Max 9, however. If you'd like to give me a specific model, I can test it for you.
-
How do you do the bones so easy?
-
Eh, haven't been on for a while. I had (and still have) some real life stuff to attend to, so wiki article has been on hold... but don't worry, I don't like to leave stuff unfinished.
But as we've noted, the data can be interpreted in a number of ways with the same results.
I'll probably go with your way, then.
My SMD texture troubles... were the plugin's fault. I loaded the models into gmax and now they look fine. Well great, now I've got to learn to use gmax :P
How do you do the bones so easy?
You mean how did we find them? Um... what makes you think it was easy? Well maybe it was easy for MrAdults, seeing how he's a game programmer and all :P
-
Eh, haven't been on for a while. I had (and still have) some real life stuff to attend to, so wiki article has been on hold... but don't worry, I don't like to leave stuff unfinished.
I've been pretty tied up by various projects and things too. I still haven't gotten around to making a revised format spec. I may not need to, as between the two of us, we may already have all of the specs fleshed out enough for wikification. But it would probably be useful to you or koral in writing the wiki document anyway. So, I guess, let me know if it's important to you, and I'll put it higher up on my personal priority list. :)
My SMD texture troubles... were the plugin's fault. I loaded the models into gmax and now they look fine. Well great, now I've got to learn to use gmax :P
Ah, well, I guess that's "good". :) You could always report the issue to the plugin's author, and/or re-export from gmax to a blender-importable format. There's a nice and functional md5mesh exporter for gmax that might do the trick.
You mean how did we find them? Um... what makes you think it was easy? Well maybe it was easy for MrAdults, seeing how he's a game programmer and all :P
Well, it was certainly easy relative to other formats. :) We got very lucky with GMO, in that the data is all nicely organized into obvious chunk sections, and the bone data is plain as the eye can see, in a combination of raw matrices, quaternions, and translations. It could have easily been worse if the bones were delta compressed against their parent matrices, stored in range-compressed bit signal formats, or a variety of other data compression techniques that are typically employed for skeleton storage.
I do suspect SE won't be going with GMO for their main blockbuster titles, as a lack native range/delta compression in skeletal data seems like a big downside. Considering that skeletal data is huge in memory and the overhead for doing a matrix decompression at runtime is trivial (compared to the full skeletal transform cost), I'm guessing bigger-budget titles will want to employ proprietary techniques for that purpose. It's actually possible that such a technique is already employed in Crisis Core, as we never did get around to finding the bone data. I just managed to find the original skeleton hierarchy, and generated bones for the models based on hierarchy and vertex weights. :)
-
I will add GMO support into my RINOA viewer too, but I am happy with the information you and Ukurere have provided us with so far. :-)
Unless there were some really huge mistake in your blog-spec, or vital stuff which Ukurere hasn't (or wont) cover, then you really do not need to go out of your way to re-document it all again.
Are you sure that you haven't seen animation (matrices or deltas) within the CrisesCore model files?
I haven't looked for them yet, but I would expect that if the animations are not within the !-model files themselves, then they may be within those ATEL-event files (for NPCs) or some other data files altogether (for monsters and bosses).
-
I will add GMO support into my RINOA viewer too, but I am happy with the information you and Ukurere have provided us with so far. :-)
Unless there were some really huge mistake in your blog-spec, or vital stuff which Ukurere hasn't (or wont) cover, then you really do not need to go out of your way to re-document it all again.
Alright, cool. The indexing formats are the main thing that could really use some clarification. Other than that, I think everything has been covered enough for you to not run into any trouble when implementing support in RINOA. My post earlier outlining the tris/quads thing is workable, although looking back, I do think it's more likely that those quads should just always be interpreted as tri strips. All of the Dissidia models seem to use pure 4-index segments for those, which is another thing that led me to thinking they were quads. But other games, as we've discussed a little bit, do all kinds of different tri-strip-looking things with them.
Are you sure that you haven't seen animation (matrices or deltas) within the CrisesCore model files?
I haven't looked for them yet, but I would expect that if the animations are not within the !-model files themselves, then they may be within those ATEL-event files (for NPCs) or some other data files altogether (for monsters and bosses).
Not 100% sure if there's real bone pose data in those files, but from the looking I did, I definitely didn't see anything that looked like plain bone orientations. I think all of the pose data is probably in separate animation files - the model files are too small to have all of the animations for each of the characters, so I do know that at the very least, most of the frames must be in different flies. As to where they could be, ATEL files are as good as guess as anything. :)
-
Hello there. Sorry to revive the topic again but something came to my mind.
Is it in any way possible to replace the textures in models and then insert them back to the game files? Would be great since then I could reskin some things in Dissidia and still have it work with modified textures.
-
um, this topic hasn't been "dead", so technically you haven't revived it, so have nothing to apologise for :-D
It shouldn't be difficult to swap the texture-data with custom data (thanks to the chunked-data system), but there is no way we can "re-pack" it back into the original (PSP) data files, because we only worked with the GMO files you provided so we dont know anything about how they were extracted in the first place.
You should be asking Vash, no us! :lol:
-
Yeah I know, problem is Vash doesn't seem to be replying to PM's ever since he started working on Dissidia translation patch. I know that Rich coded GitMo which extracts GMO's so I was wondering if it's actually possible to write a tool which would work other way around - inserting the GMO's back in their places. Also since I have no coding knowledge at all, I don't know how to replace textures in the GMO itself...
Help will be very appreciated, thanks in advance.
-
Well, like koral said, that would be more Vash's area. You could probably manage to inject replacement GMO's over the original ones without any knowledge of the containing filesystem, if you kept the GMO the same size or smaller than the original one, which would just be a matter of a hex-edit copy-paste job. But even that wouldn't be for sure, since the filesystem retrieval may expect a fixed size and mess up somehow on the GMO parsing if there is garbage data at the end of the real GMO. But since texture data is not compressed and pretty fixed-size, you could at least directly overwrite those files in the main ISO if you kept the same bit depth and resolution, since that would maintain the exact data size. But you'd still have to have something to generate the GIM files (I know there are tools, including an official Sony one meant for themes, but I know nothing about any of them).
All of this is moot where I'm involved, though, as I don't even have an original Dissidia ISO to work with. :) And I don't have a lot of interest in re-finding what Vash has probably already found, unless he just wrote a bruteforce GMO extractor. But given the filenames, it looks like he went to the trouble of actually determining the filesystem specs.
-
Can someone please repost the models and tools Aurenasek116 listed on pages 1 and 2? The links are both dead... Thank you.
-
I've just made a new discovery - apparently Vash's tools were in fact missing quite a few GMO's in Dissida - around 100 or so. I'm still going through them, but I've found at least one interesting model that was not present in the Vash tool dataset:
(http://www.richwhitehouse.com/pubimg/newmodel.jpg)
GitMO (http://www.richwhitehouse.com/index.php?content=inc_projects.php&filemirror=gitmo10.zip) can be used to extract all of them. I guess we may need to re-catalogue the model list on the wiki. :)
Edit: I think this is new too, unless I missed it in the original batch:
(http://www.richwhitehouse.com/pubimg/newmodel2.jpg)
I recognize the area, but the throne and such is new. There are lots of other new models, but they're mostly tiny little bits of things that are hard to recognize out of context.
-
I don't remember seeing Chaos' model in there either... though it only just occurred to me...
I forget if Cosmos has an in-game appearance or not, but she definitely wasn't in the models.
-
The throne one was in the batch provided by me. It had all levels, including this one. Chaos Throne is one of 12 levels in the game :P
As for Cosmos, completly forgot about her. I also don't remember seeing her model in the files, seeing as she does make ingame appearance.
-
Alright, wasn't sure about the throne one. The former model definitely was not in your batch, though, Aurenasek. Having finally played Dissidia, it looks to be the model used when a fighter goes into a special ex attack/limit break. I thought Cosmos was in your batch, though, as I seem to recall stumbling upon her model. She's definitely in this new rip as well.
On a mostly unrelated note, Aurenasek, you said Vash was working on a translation mod, right? How's that coming along? :) I don't want to wait until a US release now that I've finally played it, but my Japanese is very poor, and stumbling through the menus is kind of tedious. ;) Not to mention, I'm missing a lot in the story dialog (though, so far, there really hasn't been much).
-
Yep, the first model is EX-Burst background.
As for Vash and translation, like I said earlier - Vash pretty much disappeared, nobody knows if he's still working on translation or anything, that's why I asked here ;P
I could translate stuff for you if you want though. (To be honest, would be even better if you could write a program or something to translate Dissidia, I could take care of translations themselves.).
Storyline cutscenes can be found subbed on YouTube.
-
I already gave an example on Rich's website, koral quoted it on the 1st page of this topic, just head there.
-
hmm
I have also made the text a teenie bit larger and slightly more clearer on the first page: http://forums.qhimm.com/index.php?topic=8290.msg99960#msg99960
My RINOA tool will also be able to support them in the future, but you have to use mesh2rdm for now. Sorry
-
He also posted on my web site, and I answered him there. He had a command line that was a mashup of random parameters that didn't really make sense, and was trying to drag gmo files onto batch files and doing other crazy things. Hopefully I set him straight.
I just generally assume if you are importing models and doing things with them and know enough to figure out a modeling suite, you probably know how a batch file works. But I guess that isn't true these days. Maybe they're making the modeling suites too easy to use. ;)
-
Yeah Adults told me how to fix it. It's working now, and those instructions in the first post aren't detailed enough for most people. You know some haven't even touched the cmd before. Anyway, I managed to import the object into blender. With the textures, but the UV layout seems to be messed up. Guess there is some command I gotta put into the bat file to fix it...hmmm :-P
The UV is simply upside down, you can either manually flip it verticaly in blender or use flipuv parameter in mesh2rdm :P
-
those instructions in the first post aren't detailed enough for most people.
Um, I dont mean to be rude, but there is something called "google" and there are literally millions of sites devoted to cmd and dos-prompt, the thing is stupendously antique (it was around during Windows 3.1 I think, perhaps earlier?)
I will not write a nice little tutorial using cmd on the first post because it is completely irrelevant, the pointers there (posted primarily by Aurenasek116) should be sufficient.
If you dont like cmd, just wait for me to add GMO (Dissidia model) support in RINOA. :-)
Other than that, good luck with trying to extract them :-D
-
*sneaks in*
you guys haven't posted for a while,
<_<
>_>
you guys better have not given up yet!, I got plans to create some new stuff for dissidia...
and your my only hope! Must....replace...cloud for...tifa...,must....replace...yuna for...tidus!
its in your hands you guys *sniff* All my hopes and dreams are up to you!
*fades away*
-
MrAdults will not be posting anything more here due to his departure from the forums, so I have ammended the first post to clarify what is to become of this topic and updates here (simply, there wont be anymore updates).
I know nothing about Dissidia anyway, so this topic can be considered dead (unless anyone wishes to share anything new about Dissidia file specs or GMO).
-
Mr. Adults Final Farewell (this message is not written by me, but by our very own Mr. Adults... who sadly has left this forum.)
"My reasons for leaving are pretty simple. There can be no joy in contributing anything productive to a forum where the moderators allow, and perhaps encourage, blatantly antisocial behavior.
In citing the specific example - Allowing a thread to exist, which singles out and harasses/humiliates a single member, is not acceptable. There is no excuse, most especially not "he started it!". I do not at all mind the existence of members which incite this garbage, nor do I mind anything they have to say to or about me. As some may notice, I'm well enough in gently dumping their poop right back on top of them. I do, however, wholly object to the moderation's support of the attack thread on fundamental grounds, and the acceptance of the threads and posts (some being even in otherwise productive forum areas) that led up to said thread.
So comes the sad realization that these forums are not a deserving place, at present time, for the product of any true efforts or laboring, if those in charge of the forums themselves cannot be trusted to uphold civil policy. I also feel that to contribute to the forums, now, passively encourages these poor ideals. I hold higher standards for myself, as well as any community I am a part of.
Should an administrator become aware of this and feel that the moderator(s) in charge have merely been incompetent and/or inappropriately influenced by social contacts, they are free to contact me on the matter. I'll otherwise be hanging my hat up on these forums and migrating to, well, more civil ones."
- Mr. Adults
-
(http://img155.imageshack.us/img155/4451/tsukasacrying.gif)
Worryingly, I can hardly disagree with a word that Mr. Adults says. My opinion about what I thought was a very mature, self-governing community has been changed a lot by what has happened over the past week.
I shan't be leaving myself; I'd like to say that this is because I want to make a point but feel that no-one will care how many contributors go, but it's really because I can't bring myself to leave as long as there is still good work being done here and I can help in whatever small way I can.
I hope that Mr Adults can find a forum where as much good work is done here but the moderation is more active and less partisan. Perhaps in such a place someone might be valued more for what they do for the projects than for their personal friendships with the people in charge. I also hope that, if he does, he tells us about it, so that we can all go there.
I fear, however, that such a place might not exist.
-
Yeah it's too bad he left, his mesh2rdm and general knowledge was a very welcome addition here. However, it is a bit ludicrous to think that on a FORUM where everyone is more or less free to be who they really are, that people will not butt heads and argue and act inappropriately from time to time. It's because of this that I feel Mr. Adults was being less than sensible by just up and leaving, mods or not.
This isn't a post about who was right or wrong, but instead about how him leaving only detracts further from the community. I can understand if the whole forum had gone to shit, but it was two people arguing. Is that really so serious as to warrant "hanging up your hat"?
Also notice everything is back to normal now, just thought I would mention that.
-
Also notice everything is back to normal now, just thought I would mention that.
As normal as things get on here.... :-P :-P
-
Yeah it's too bad he left, his mesh2rdm and general knowledge was a very welcome addition here. However, it is a bit ludicrous to think that on a FORUM where everyone is more or less free to be who they really are, that people will not butt heads and argue and act inappropriately from time to time. It's because of this that I feel Mr. Adults was being less than sensible by just up and leaving, mods or not.
This isn't a post about who was right or wrong, but instead about how him leaving only detracts further from the community. I can understand if the whole forum had gone to sh*t, but it was two people arguing. Is that really so serious as to warrant "hanging up your hat"?
Also notice everything is back to normal now, just thought I would mention that.
To "be oneself" is also to act as oneself would act. Thus, leaving the forum for whatever the reason, so long as one's personal morals dictate it, is perfectly normal.
To him, the "whole forum had gone to sh*t" possibly, by that one simple act. It is an easy thing to break trust.
He will be sorely missed, but I cannot say that his reasoning is not valid to him. I myself did not witness it at all, and cannot say I have an opinion on the event.
-
I think it's same as with Atrac audio format, in atrac case it's simply wav but wrapped in new header to make it look like if it was new format. I don't know really, I can be wrong.
Also here are the Dissidia tools coded by Vash, it has a GIM extractor aswell as other stuff which you can have a look at, maybe it will be of any use.
http://rapidshare.com/files/213186921/Dissidia_Tools.rar.html
Rapidshare link for now since FileFront is doing some maintance.
Aurenasek can u reupload this file since tha link is broken and i cant get tha tools.........??
-
can u reupload this.
-
Hello to all.
Someone might pass the models of Final Fantasy in .smd
Please.
A greeting and thanks :)
or if not sephiroth. smd please.
-
Sorry, ripping, and talking about ripping models from other games is against the rules now. So no-one can.
Welcome to the forums though. :-D
-
Yes, and the creator of the tool left these forums a long time ago...
-
Yes, and the creator of the tool left these forums a long time ago...
And is no longer taking questions or requests for Mesh2rdm.
-
Yes, and the creator of the tool left these forums a long time ago...
And is no longer taking questions or requests for Mesh2rdm.
Not even on his own website? :-o
-
Thats where he announced it....
-
Thats where he announced it....
I didn't see it, lol.
-
So, I'd take it your trying to stop support for it then? I was hoping to learn if there was a way to export it into a T pose :cry: