Jump to content

Home

I've done custom GLA animations


CortoCG

Recommended Posts

ME? refuse? Lies. It's all a conspiracy.

 

Now go and get me that proper skeleton please :)

 

And for those who are interested:

 

- the skeleton in the SDK has wrong bone hierarchy, and misses some bones that the original skeleton had.

 

- If anyone is interested to create a proper skeleton, based on the data that he will be given (exactly, mind you), please PM me and I will get back to him as soon as possible

 

- Without that skeleton, the work we have done is quite pointless, as obviously animations with different hierarchy of bones are useless to import.

Link to comment
Share on other sites

  • Replies 123
  • Created
  • Last Reply

Hey what's that you're always missing a modeller???? I'll take personally :p .

 

Btw, ASk, you'll have to figure out what Raven guys did with the _humanoid.gla's bone hierarchy, cause it makes non sense at all. For ex. ltarsal should be ltalus' child, ltalus --> ltibia, ltibia --> lfemurX, lfemurX --> lfemurYZ, lfemurYZ --> pelvis...

 

But as we saw in the _humanoid.gla the all those bones are children of pelvis directly: ltarsal -->pelvis, ltalus --> pelvis, ltibia --> pelvis, and so on.

 

MY best guess is that Raven rearranged all bone/anim data in the compiling process, perhaps I'm missing something in the assimilation process. If anyone know what do they do all the buttons and commands in carcass PM me.

 

Concerning that "FACE" bone, I can create it, but without the right

bone structure after the compiling process is useless.

Link to comment
Share on other sites

No, the _humanoid.gla has skeleton data concerning children and number of children and indexes of them that each bone has. I was deciphering it's structure when I decided it wasn't entirely relevant and moved on to the Frames, then we realized that the Compressed Global Bone Pool was most important.

Link to comment
Share on other sites

Basically yes

the GLA comes with a block that describes the skeleton :/

 

It could be a skeleton that did not make sense. remember, they used a motion capture plugin, so the bones are arranged as the sensors were.

 

 

Other than that, the log is following the exact format that is defined in the .h file....it *could* be storing only the children, so if pelvis has lfemur as a child and lfemur has ltibia as a child it is described as pelvis having them both as children, however this is unlikely :/

Link to comment
Share on other sites

To see the bones in order that they are in (without hex editing the GLA), put a default _humanoid.gla in the same directory as carcass.

 

At a dos prompt, run

carcass -dump _humanoid.gla

It'll list your bones and tell you how many children they each have. Modview lists them like this in a 'tree' format, I think.

 

I haven't done enough digging in this dirt to know if it is fertile :)

Link to comment
Share on other sites

I have a question about the skeleton...do you think that the gla file could use a custom made skeleton?, but that skeleton wouldnt have the current proportions.

 

I started modelling a Kaminoan for fun and it seems that the only way to make it JK2 compatible would be to create a new skeleton.

 

The feet and hands would have to be in roughly the same place i think, just longer arms and legs.

 

I tried to move the hands for Yarael Poof, it did work, but he wasnt grabbing the hilt at the "new hands".

 

The problem was mainly the left hand, the right hand had the tag to place the hilt correctly.

 

EDIT:

It'll list your bones and tell you how many children they each have. Modview lists them like this in a 'tree' format, I think.

You can also see the hierarchy in max, with each parent/children clearly defined.

Link to comment
Share on other sites

Wudan: My prog gave the exact same output. Only more info, since that one only displayed number of children, and I outputted the names, origins, etc

 

 

Psyk0Sith: the Skeleton needs to match exactly the data that I give. Meaning that the bones need to be in the exact hierarchy and order, and origins...well if my prog outputs them correctly, then they should have the same origins

Link to comment
Share on other sites

Ok so in other words...if i wanted to create my own skeleton, using the same hierarchy as raven did (that's what i was going for) the bones size and alignment in max wouldnt matter because the origin of each bone is pre defined?

 

I know bone scaling works (i mean the bone in the glm file itself, not via a mod) so i thought that a simple re-scaling of the bones could also work...but again the saber griping will cause problems.

 

Another thing: anyone know if it's possible to move the meshroot/model root from its default origin? or will it be defaulted back in place by the gla or engine? (not sure what controls the "floor" plane).

Link to comment
Share on other sites

wow this thread needs to be made a sticky... unbelievable progress.

 

I'm looking forward to the day I can include custom animations with my models... if that will be possible.

 

Awesome work guys. If you need help (not much of a coder but I can model) ask away.

 

Cheers.

Link to comment
Share on other sites

Psyk0Sith: that means that the hierarchy is predefined.

I do not know if origins will make a difference, but since I believe that animations are only relative, they won't.

 

Just a sample of how the data looks

 

0x1 - pelvis:
FLAGS: 0x0
PARENT: index - 0x0, name - model_root
ORIGIN:
-0.000000 0.640000 0.000000 -0.000008 
0.000000 -0.000000 0.640000 0.385155 
0.640000 0.000000 0.000000 35.586601 
INVERSED ORIGIN:
-0.000000 -0.000000 1.562500 -55.604065 
1.562500 -0.000000 0.000000 0.000011 
0.000000 1.562500 0.000000 -0.601804 
NUMBER OF CHILDREN: 12
	Index: 0x2, Name: Motion
	Index: 0x3, Name: lfemurYZ
	Index: 0x4, Name: lfemurX
	Index: 0x5, Name: ltibia
	Index: 0x6, Name: ltalus
	Index: 0x7, Name: ltarsal
	Index: 0x8, Name: rfemurYZ
	Index: 0x9, Name: rfemurX
	Index: 0xa, Name: rtibia
	Index: 0xb, Name: rtalus
	Index: 0xc, Name: rtarsal
	Index: 0xd, Name: lower_lumbar

 

So basically, all these values (except ORIGIN's, which I do not trust, since I have no idea how floats are stored in binary and how they should be read) define the exact hierarchy of the skeleton.

 

By the way, I could use some help about reading the floats, I know that they take exactly 4 bytes per float, but I do not know how they are stored. :/

Link to comment
Share on other sites

Psycho, scaling the bones will render your model completely useless unless you compile that new skeleton into a new gla, that means you'll have to make new anims aswell. That's why you can scale up and down an NPC ingame but you cannot alter the bone proportions.

 

I tried to scale the skeleton to make another king of humanoid and got the same problems as you, the bone displacement made the model look like his skeleton wanted to get out of his body, something very funny. For the record, I tried something grose, perhaps Psycho's bone scaling were more subtle.

 

Concerning the floor plane, try moving up and down the mesh_root, model_root and skeleton_root. Cause the GLA file has the origin value compiled inside and cannot be altered. If you are making a new skeleton/anim for your model, that value can be set before compiling the new skel in the origin properties.

 

I accidentally created another thread with this message =P. Am I stupid or what?

Link to comment
Share on other sites

Originally posted by CortoMaltes

I tried to scale the skeleton to make another king of humanoid and got the same problems as you, the bone displacement made the model look like his skeleton wanted to get out of his body, something very funny. For the record, I tried something grose, perhaps Psycho's bone scaling were more subtle.

 

Well my bone scaling did in fact work (no weird mesh movements), Yarael Poof was scaled to his estimate size in max (about 1.4 in game) it worked because i resized the bones AFTER the weighting.

 

It looked fine...the only problem was the floor plane...he was walking through the ground, i didnt experiment much but maybe i should take a closer look.

 

I also did the same thing for Ki-Adi-Mundi's hands, the mesh was about 3X the original size and still deformed very well because once again i rescaled after the weighting was done.

 

Sorry if i'm a bit off topic with this, but i wanted to know the possibilities with the skeleton.

 

I will certainly attempt to create my own skeleton and see how it turns out...but this will take a while as i'm working on other projects.

 

Thanks for the help guys.

Link to comment
Share on other sites

Originally posted by ASk

By the way, I could use some help about reading the floats, I know that they take exactly 4 bytes per float, but I do not know how they are stored. :/

Floats are normally stored in a type of scientific form. I can't remember the details but you could probably find them with google.

Link to comment
Share on other sites

Originally posted by ASk

I was simply thinking that if I read the 4 bytes in the proper order (little endian -> big endian) then type casted them with (float) it would give me the correct value. Can someone support me on this?

 

I don't see why that wouldn't work, ASk... it's just a 4-byte series, so I'm guessing that taking the bits with sizeof(float) and casting them to a float should work just fine. Only one way to find out.... ;)

 

At any rate, here's a little information on the internal represenation of floats:

 

http://odin.prohosting.com/~ujdesk/floats

http://www.funducode.com/freec/Datatypes/datatypes1.htm

 

As a side note, floats are not stored internally in scientific notation. They're only displayed that way to the outside world when formatted as such (or in default formatting).

 

[edit]

That didn't come out right. I meant to say that they're not stored symbolically as scientific notation. They are indeed scientific notation based in their internal representation:

  • 1 bit for the sign
  • 8 bits for the exponent
  • 23 bits for the mantissa

At any rate, the articles explain it much better than I can... :rolleyes:

[/edit]

 

HTH.

Link to comment
Share on other sites

So, to sum this all up, now we have 2 new nuts to crack, then, right?

1. What do the origin values given in the mdxaskel structure mean?

2. What do the 14 byte arrays in the CompBonePool decompress in to?

 

I don't trust the origin values, either. They should be, if they really were origins, something like the 14 byte arrays, or maybe even the 24 bytes that the 14 bytes decompress in to, right?

 

Something doesn't add up. I'll look in to it, you'll see me tomorrow morning because I don't work Thurs and Fri :)

Link to comment
Share on other sites

Wudan: origins are stored in 3x4 float matrix, uncompressed. Not 24 bytes (24 bytes is the previous method of compression used) but 3*4*4 bytes = 48 bytes

 

As for uncompression, it uncompresses to rot and xlat, run it on a test data if you want.

mat[0,1,2][0,1,2] should be rot

mat[0,1,2][3] should be xlat (mind you this is from memory so look in the code for proper positions.

 

same for origins I believe.

 

The CompBonePool uncompresses to transformations that are performed on the bones. -> real animation data

 

Look in the hex dump and see.

Link to comment
Share on other sites

Didn't I already mention part of the bonematrix make up?!

 

inside of the game code it looks like this:

//racc - bone/bolt matrix data  
//Bolt vector origin (in game world terms) = matrix[0-2][0]
//Bolt vector orientation (in degree form) = matrix[0-2][3] 
typedef struct {
float		matrix[3][4];
} mdxaBone_t;

I haven't seen what the matrix[0-2][1-2] slots contain yet.

Link to comment
Share on other sites

check the file code/renderer/matcomp.c, function MC_BoneQuatDecompress()

 

Then you will see exactly what is stored where

 

The only problem now is the proper skeleton, the rest of the format, I can tell you exactly what part does what and where.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...