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

[SOLDIERBOY]

Hey I was wondering if someone can help me.

 

[Ukurere]

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?

 

[MrAdults]

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.

 

[koral]

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

 

[BlitzNCS]

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)

Crisis core models dump fine, so maybe it's a problem with my Laptop?

 

[koral]

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?

 

[BlitzNCS]

anything under a threshold of like 50 says there arent any verticies within the threshold, and over that just ruins the model
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?

 

[koral]

I have absolutely no idea.  :?
I will try it myself and see what happens. What parameters did you use to export the model?

 

[BlitzNCS]

Code: [Select]

mesh2rdm File003766.gmo Cloud.smd -texpre Cloud -rotate -90 0 0 -scale 10.0 -smdout -flipuv

 

[MrAdults]

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.

 

[Ukurere]

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:

(idxStride=206, numIdx=1, verts are unindexed)

From left to right, this matches PRIM (primitive kick) in Yet Another PSP Documentation:

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.

 

[MrAdults]

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.

 

[sorayahya]

How do you do the bones so easy?

 

[Ukurere]

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

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

 

[MrAdults]

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

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

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.

 

[koral]

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).

 

[MrAdults]

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.

 

[Aurenasek116]

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.

 

[koral]

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:

 

[Aurenasek116]

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.