[Magil]

Recently I have been fiddling with Chrono Cross models and trying to find if it is possible to convert a normal 3d model into the game's native model format.

I will not go into details, let's say the game uses similar structures to current 3d softwares, that is vertices, faces, vertex groups and bones(or joints, whatever you name them). Each vertex can be connect to up to two joints, and the final position of the transformed vertex is decided by interpolating using the weights of the two. The only big difference is, the game uses two position values for those vertices that are connected to two joints.

The logic is like this (V = finaly vertex position, Vo = original vertex position):

Code: [Select]

V = Transform1(Vo1)*Weight1 + Transform2(Vo2)*(1-Weight1)
But in other 3d softwares, it is like this:

Code: [Select]

V = Transform1(Vo)*Weight1 + Transform2(Vo)*(1-Weight1)
So if I understand correctly, if there's only one Vo, it is not possible to calculate Vo1 and Vo2, or do I need extra informations to do that?

[Zoinkity]

Are all the parts for these things positioned via a matrix stack by chance, or minimum a stack of offsets for each part relative its parent?

[Magil]

Though I don't know what a matrix stack means, but I think it is the latter, each joint can have its parent joint and the transforms are all relatvie to its parent.
Edit* As for the animations, each frame is relative to the "skeleton" (aka the T pose, http://i.imgur.com/SL3SHJj.png).

I don't know why there are two positions for a vertex, perhaps it has something to do with whatever develop tools they were using.


Edit*

I already managed to create animations using the joints: https://storage.googleapis.com/utunnels1.appspot.com/ccmodelviewer/list.html
However, to reverse the process I need to break down the vertices back into their original two-value format.

Without the joints forming a skeleton, the mesh roughly looks like this(no, that is not how I do in the final product): http://i.imgur.com/8CANVZW.png
And this is how the skeleton looks like (blender doesn't have joints, so I use small bones instead): http://i.imgur.com/SL3SHJj.png

[Zoinkity]

Ah, sorry.
If the whole part is offset then it makes sense that each is positioned using a stack of offsets or matricies.  What they would be doing then is only modifying this table whenever the part is moved.  It's a pretty common scheme since you only have to modify where the instance is drawn, not the model itself.

A matrix stack is a sort of tree of matricies used to position/size/rotate/modify parts relative to their parents.  Basically, if you imagine everything within the part being in a sort of box, these boxes would be multiplied by the matrix to both move all the vertices to the correct locations plus resize them in case they're at a different scale.  You can also do fun stuff like distorts with them.  Was worth asking since they're common in N64 models and at least some PC formats.
If each entry modifying the part's position happens to be made up of 9 to 16 entries, you're dealing with a matrix.

They might not be using matricies, but from the looks of that model they draw each part starting at (0,0,0).  There's some kind of repositioning involved, even if it's a simple (x, y, z, rot) vector.

[Magil]

Thanks for telling me the informations.

Actually I don't know how the game deals with it after the model is loaded, but the transform values in the model are like arrays of 6 fixed point values in the order of rotationx, rotationy, rotationz, translationx, translationy, translationz. It is more like what you see in a blender transform editor, other than matrices.

I don' t how other psx games do with their models, is it common to have a mesh splitted into parts then "weld" the vertcies that belongs to two groups? It sounds so strange to me.

[ETG]

I don't know how much this would help, and I apologize if it is something that you already know, but I can tell you what little I know.

First, keep in mind that 3d for artists is different than 3d for programmers. To an artist there are joints, bones,constraints, etc, but to a programmer there are matrices. So what is a matrix? Basically it's a mess of numbers that you can do some fancy stuff with. 3d graphics only use a subset of set theory and linear algebra, so there is much, much more to this than the relatively little that you need to know (aka: don't get discouraged if you feel in over your head, especially if you look this up on Wikipedia or such.)

Matrices can easily move, scale, and do complex rotations on vectors, vertex positions, normals and everything else that can be expressed as an array (so computers are naturally good at this.) You can even combine several transformation matrices  together and apply it to data all at once just by multiplying. There is one issue you need to know, matrix multiply isn't commutative like regular multiply is. So [A] * [C] does not equal [C] * [A], which means to undo a transformation you have to figure out the inverse of the matrix and multiply that to the matrix. Luckily modern exporting APIs will have functions to do all that and most everything else you might need built in.

What an artist sees as a skeleton is really a stack of matrices where each transformation is applied to the previous one for that set of verts. This is how you get the parent-child relationships and all the local/global movement goodness to happen.

Again I apologize if this is unhelpful, known information.

Now you seem to be saying that the vertices are all duplicated? I don't know why they would do that (collision volumes? Not sharing verts for different faces? Shading reasons? Filler?) but if they are just duplicates, for whatever reason, they should be treated as just additional verts to proccess.

Oh and don't worry too much about how the game works the information, just feed it the proper data and it should be able to handle it. Or maybe it won't and you'll find some limitations you weren't aware of before.

[Magil]

Ha, thanks. Yeah, I know the basis.

Now you seem to be saying that the vertices are all duplicated?

Well, I mean there are two sets of position values for those vertices that are influenced by two joints. And no,  they are not identical, the two values are different.
For example, those vertices on the shoulder are influenced both by upper arm and upper body.  You can say one set of values are for the arm and the other for the body, after the game done calculating them, use their weight values to combine the two and you get the final positions of the verts.

Not sharing verts for different faces?

I don't think so. They have plenty of faces that share verts, for example, two sides of a robe. This can't be done in blender, but in game, it is accepted.

[ETG]

Are you saying that each frame of animation is a cloud of verts that show where each vert should be during that keyframe? That sounds like vertex based animation. Yes you can blend them together just like you said. It's just like in blender when you paint weights on the verts to attach them in varying degrees to bones. The difference is how it's computed.

But you say there is also rotational and translation data in the model too?  Maybe it's a hybrid system where the bodyparts are assembled with one transformation, but animated with vertex animation. But one of the benefits of vertex animation is that you can bake in all the detail you want, so I don't know why it is dynamically combined at runtime, unless it is a way to weld bodyparts together?

Do keep in mind that I know nothing about the PSX specifically, just a little about the subject in general.

[Zoinkity]

It's actually remarkably common to split models into a bunch of parts.  I've never really poked around PSX before, but it's very common in N64 games and some PC titles.  The major advantage is that when you're moving parts around this can (hopefully) automagically move all the children the same way, so the whole thing looks like a cohesive model instead of a bunch of random parts (ala Star Fox).  There's also much less overhead doing it this way.

Nice that array is so small ;*)  Usually these stack; the position data for the parent moves everything to that position, then each part's own position moves it and its children, and likewise the children's positions move them and all their children.

After that, they might be merging one set of edge pixels from one part to positions in the next.  Hard to tell exactly without a binary for reference, but there would be some indicator and usually a part+vtx reference or something like that.

[Magil]

Are you saying that each frame of animation is a cloud of verts that show where each vert should be during that keyframe?

No, vertices are still transformed by joints (rotation and translation).  You know in blender this is called vertex group, a vertex can belong to two groups and thus can be affected by two bones. In the game, it also works like this, just the vertex has two different values for corresponding groups. Don't know why though.

so I don't know why it is dynamically combined at runtime

That I don't know. It is just how the model works. Maybe the game converts the models and animations into more GPU friendly format. But that is a blackbox irrevelent to current topic.

Nice that array is so small ;*) 

Ha, again it is just the model format, I believe the game will also convert them into whatever it can use to calculate the matrices.

I guess, this is how different parts are splitted (sorry I'm bad at drawing, the left part is a limb and the right part is the body, the green part is the vertices affected by two bones):



The game just transforms the two parts, then merges the green parts together using the weight values on the vertices.

[ETG]

Sounds like you're right.  Having the parts overlap like that would mean there isn't any holes that open up at the seams, you still get the bendy bits moving like non-robots, there's no nonsense of trying to identify which verts match up with the others, and it can be automated by the exporter too.