New GLA Discussion

[Tempust85]

Moving the previous discussion to here.
 

The idea here is to add more bones to the existing JKA GLA so we can have more detailed animation & perhaps cloth-like movement without adding in new physics. Now existing JKA models will work with this new GLA via a conversion table done in the code, similar to how JK2 models are converted for JKA use. These converted models however will not be able to use the new bones unless they are re-rigged.

 

 

@@Archangel35757: True, that's fine for only the JO/JA face bones... but,
In my opinion the cloth bones need to be it's own skeleton and GLA (bones for tabbards, capes, cloak, robes, etc.) that can be bolted onto the _humanoid.gla in the same way @eezstreet is planning to do with the new facial.gla. This will avoid bloating the humanoid skeleton with unnecessary bones and keep things cleaner. That's how I recommend doing it.

We can simply import the animations and let the 3ds Max ClothFX react to the underlying humanoid animation and bake that into the cloth bones. And then compile a cloth.gla file with Carcass. Playing a humanoid anim will trigger the corresponding cloth anim.

 

Simpler and easier to have all the bones needed in one GLA. Your way would be more clean, but less practical. Every modeller would have to have their cloth meshes in a separate GLM for your bolt-on idea to work, not to mention the extra work on coder(s) to implement "bone merging" (this is what source calls it).

[Archangel35757]

Moving the previous discussion to here.

 

The idea here is to add more bones to the existing JKA GLA so we can have more detailed animation & perhaps cloth-like movement without adding in new physics. Now existing JKA models will work with this new GLA via a conversion table done in the code, similar to how JK2 models are converted for JKA use. These converted models however will not be able to use the new bones unless they are re-rigged.

 

 

Simpler and easier to have all the bones needed in one GLA. Your way would be more clean, but less practical. Every modeller would have to have their cloth meshes in a separate GLM for your bolt-on idea to work, not to mention the extra work on coder(s) to implement "bone merging" (this is what source calls it).

 

"...These converted models however will not be able to use the new bones unless they are re-rigged..." --you mean re-weighted to the new skeleton bones, right?  It's just the root.xsi file that would need updating for legacy models.

 

 

Well, my thinking was that if some maps/missions and character outfits don't call for:  cloaks, robes, or capes ...then that's less bones and transform space to have to compute; but, this is where @@eezstreet or @@Xycaleth could tell us which method is "lighter-weight" on the engine.  Yes, having all the cloth or armor bones in the JKE skeleton would be less work.  The new JKE facial bones will be in the same character rig as well... and artists will skin their head meshes to them; but they will need to simply do an "export-selected" on their head mesh so it correlates with the new facial.gla.

 

I also think @@eezstreet or @@Xycaleth should tell us if there is a maximum bone limit-- it may all just be memory dependent-- and thus they have to draw the line somewhere.  I think there should also be some independent bones for shoulder armor... so that armor like this will deform properly:

 

 

We need to start chatting again on Skype.

[eezstreet]

There is no maximum bone limit. There's a fixed amount of memory that is used for animation. You might hit that limit, but if you do, it's an easy matter of raising the memory cap or compressing the data to use less memory.

 

I disagree that having all possible bones in one GLA is the best solution. Take the Reborn for example. It has a crotch flap and hood which should be animated separately. Kyle for instance doesn't have any room for additional bones. Jan might have an animated ponytail. However...rodians only have three (?) fingers and a totally different face structure from humans. Grans have meaty paws. It would be nice to be able to make more precise hand animations for these characters for sure.

 

Yes, perhaps it might be feasible to have these extra attachments in one extra mega skeleton, but it makes more sense to be able to swap parts of one skeleton with another.

 

In order for this to work, the GLM would be rigged to a temporary skeleton which represents the merged _humanoid with merged bones.

[Archangel35757]

@@eezstreet -- SoF2 has hands in a separate GLM.

[TheWhitePhoenix]

@@DT85, I'd like to thank you and @@Archangel35757 for doing so much work for Jedi Academy Enhanced. I know that you're more busy with MBII these days, but you really are awesome for also finding time to focus on this too. So thanks, dude.

[Archangel35757]

@ -- Thanks... but I'm not associated with MBII.

[eezstreet]

@@eezstreet -- SoF2 has hands in a separate GLM.

Those are for the first person viewmodels.

[TheWhitePhoenix]

@ -- Thanks... but I'm not associated with MBII.

The MBII mention was at DT specifically. And you're welcome.

[Tempust85]

Still a damn shame the full source for SoF2 isn't released.

 

Either way, it would have to be all animated in one scene file to make sure all GLAs are synced. How soon can we get code support for GLA merging?

[eezstreet]

Still a damn shame the full source for SoF2 isn't released.

 

Either way, it would have to be all animated in one scene file to make sure all GLAs are synced. How soon can we get code support for GLA merging?

Well, I can see what I can do when I have a sample, as was the case with ghoul2 viewmodels Although in this case the sample is going to be quite difficult I imagine to generate.

 

As a side note, it might be a good idea to make an animation system where you can swap out specific animations on a per-playermodel basis. Like, jedi_trainer/special.gla might have some fancier looking taunts or something. Basically just a GLA with a few animations but the same hierarchy.

[Xycaleth]

Maybe you want to look into having a gla per animation. Then have some sort of mapping in a config file from animation name to file per model. I think something like that would be much more flexible than having everything in a monolithic file?

 

Or, to keep the existing gla file, let each model define some overrides per animation and then each new animation could be in its own file. So, say you add a new sit animation for Jedi model, you would have a new gla file with just the new sit animation and a config file saying what you're overriding.

 

I think it's pretty much what eez mentioned now I read his post again...

[Archangel35757]

Maybe you want to look into having a gla per animation. Then have some sort of mapping in a config file from animation name to file per model. I think something like that would be much more flexible than having everything in a monolithic file?

Or, to keep the existing gla file, let each model define some overrides per animation and then each new animation could be in its own file. So, say you add a new sit animation for Jedi model, you would have a new gla file with just the new sit animation and a config file saying what you're overriding.

I think it's pretty much what eez mentioned now I read his post again...

I will say that we do need a mechanism to easily add new animations to the humanoid characters that use the _humanoid.gla. Perhaps it can be as simple as putting new GLA and corresponding CFG files in the humanoid folder and the games loads all compatible GLA's found.

[Tempust85]

Such a system would allow multiple animation mods to be used.

 

Also, a sample should be easy enough to get going. I'll split the Main GLA into segments such as head, lower body and upper body for you to bolt together in code. I'm thinking for the head bolt we can use cervical bone, for upper body use lower lumbar. So you'd have the lower body which will have the upper body bolted onto it at lower lumbar and the head will be bolted onto the upper body at cervical.

[Archangel35757]

@@DT85 - why break up the body? The head should be sufficient. Instead, why don't you compile and give him the cloth bones (your robe, cloak, etc.) 3dsMax ClothFX experiment instead. That'll give him plenty to code/validate.

[eezstreet]

@@DT85 - why break up the body? The head should be sufficient. Instead, why don't you compile and give him the cloth bones (your robe, cloak, etc.) 3dsMax ClothFX experiment instead. That'll give him plenty to code/validate.

Because there's no models that are rigged to use cloth bones.

[Tempust85]

Right now, it's just a sample. By no means do we HAVE to have the segments I mentioned in the finished product. There are alot more bones on the upper body vs the head, so I'd like to add the upper body to thoroughly test the bone merge code. Need to make sure all bones right down to the fingers animate correctly. If the code does the upper body & lower body merge perfectly, then we shouldn't see any issue whatsoever in other bone merging.

[Tempust85]

Now because cloth sim doesn't behave and is a right bitch to get to loop, I'm hand-animating anything cloth. Still working on a clear method before any actual work begins, but so far I'm using spring constraints to make the ends of the cape bones flow a bit. So far, the cape bones are 8 in total.

[Archangel35757]

Now because cloth sim doesn't behave and is a right bitch to get to loop, I'm hand-animating anything cloth. Still working on a clear method before any actual work begins, but so far I'm using spring constraints to make the ends of the cape bones flow a bit. So far, the cape bones are 8 in total.

Not every animation loops, right? you are likely considering the walk/run animations? do you know how many of them loop?

[Tempust85]

If I were to have a guess, i'd say at least half of the animations would loop. Either way, I find it's actually faster for me to hand animate than to sit there and fiddle with cloth settings and baking etc.

[Tempust85]

https://dl.dropboxusercontent.com/u/16660487/Cloth%20Test.avi

 

 

Hand animated, with the exception of the left and right nulls at the bottom being spring constraints to give a flow effect.