Let's talk about tags

[Psyk0Sith]

If you haven't already, you should fudge around with the pivot point itself and not touch the tag geometry.

[minilogoguy18]

I'll try but none of the player tags have the same local transforms (pivot) so I don't think it would make a difference.

 

EDIT: @@Psyk0Sith no go, doesn't make sense especially when my tags match the base ones, might be something else.

[Archangel35757]

I found this in mdx_format.h file (for Ghoul2 tags/bolts):

 

//triangle side-ordering stuff for tags...

#define iG2_TRISIDE_MIDDLE 1

#define iG2_TRISIDE_LONGEST 0

#define iG2_TRISIDE_SHORTEST 2

 

...but I haven't found yet how it's used. I'm still travelling and only have my cell.

 

My interpretation would be vertex 1 is the right angle corner, 0 defines long edge, and 2 the short edge...

 

Edit: Or it could define the vertex corner number opposite the specified edge.

@@Xycaleth, @@eezstreet, @@mrwonko???

[minilogoguy18]

I have no idea what that means, all I've found that is concrete is that local transforms mean nothing and vertex order mean nothing.

 

 

+Z is the backside of the polygon just so there is no confusion.

[Archangel35757]

I have no idea what that means, all I've found that is concrete is that local transforms mean nothing and vertex order mean nothing.

 

 

+Z is the backside of the polygon just so there is no confusion.

It's the required vertex ordering for the triangle. What are the vertex numbers for your tag? Can you edit photo to show the vertex #'s?

[Archangel35757]

@@minilogoguy18 - would you please show a screenshot of your bolt's pivot in relation to the pivots of the foot and lower leg bone?

[minilogoguy18]

@@Archangel35757 I tried both things you're suggesting and neither worked. My ordering wasn't "right" originally and so I redrew the polygon so that it would be the way you say is right, it changed nothing. I also made the transforms of the foot bone match the bolt, no change either.

[Archangel35757]

@@minilogoguy18 - Your local pivot is wrong.

 

I imported the AT-ST in 3ds Max using the Softimage dotXSI4Max import plugin (which keeps all pivots in XSI coordinate system) and also imported it using ModTool... both results show that the local pivot for the tag should have +Y forward (pointing at toe), +X (left, when looking forward from behind), and +Z down.  See screenshots:

 

In 3ds Max:

 

In ModTool:

[minilogoguy18]

My pivot is the same, the pivot doesn't mean anything, I've changed it so many times with no change in pivot in ModView. The edges seem to be all that matter. My tag matches the base model.

[Archangel35757]

@@minilogoguy18 -- Ok... so after further research, I believe that it uses the tag geometry itself and not the tag's node transform matrix (as you have come to find thru trial and error). The long edge (not the hypotenuse) represents the +X axis, the short edge represents the +Y axis. The cross product of these two edges produces the +Z axis and I believe the face normal should point along the +Z axis.

 

 

In this regard, they are similar to bones-- which use +X along the bone's length...

...Before you start rotating your tag geometry, I would like you to simply try flipping the face normal and see if that corrects your opposite foot rotations. If flipping the normal fails then you'll have to rotate the tag geometry itself to sort it out. I would not rely on how the tag geometry was imported by Softimage or any other 3D package-- because they could be wrong (meaning they used the local transform and disregarded the tag geometry layout-- which may not correspond to the local transform).

[Archangel35757]

@@minilogoguy18 - How about an update? Issue now resolved?

[minilogoguy18]

I'm starting to think that it's something else, I've changed the tags all around and there is no effect even though in Modview the axis have changed. I unchecked the "keep Motion bone" box in ModView and it seems to change it but the animations get all skewed so I think I need to look at either moving the Motion bone off the floor or removing it without skewing the animations and it may solve this.

 

Well tried that, didn't work and for whatever reason removing the Motion bone completely messes everything up even though it isn't a parent to anything.

 

@@Archangel35757, could you possibly dig around the code and maybe shed some light on some things?

 

I need to know what the "$flatten" command does in the PCJ list in Assimilate does

What is the perpose of the "Motion" bone

 

I at least know that the PCJ list does something as far as preserving parent/child relationships with bones, without using it the skeleton has no hierarchy and all the bones will just be child to skeleton_root.

[Archangel35757]

The Carcass v2.2 help command at DOS prompt tells you what each command does.

 

I did dig around and I also talked with @@Xycaleth and another Russian coder who developed a valid MD3 exporter.

 

Consensus:

The compiler is using the tag's edge lengths to determine the orientation matrix (exactly as the last image I posted above).

 

You need the motion bone. The game engine uses it to manipulate the model. I'll have to dig up my notes for more details. @@DT85 also has great knowledge of the motion bone.

 

@@Xycaleth, me, and Rich Whitehouse had a great discussion of PCJ joints awhile back-- iirc, it stands for Programmable Control Joints. They allow manipulation/compressing of the hierarchy for interpolation purposes-- @@Xycaleth?

 

Does the stock AT-ST behave like this?

 

Are the tranforms for the foot bolt's parent objects correct?

 

Maybe you need to reset transforms on some of the objects? @@Psyk0Sith - not sure how to do this in ModTool.

[Xycaleth]

The PCJ stuff is purely for optimisation purposes. It doesn't have any affect on the resulting transformations.

[Archangel35757]

The PCJ stuff is purely for optimisation purposes. It doesn't have any affect on the resulting transformations.

...but will you explain it in layman's terms, please?

[minilogoguy18]

What's the point of resetting the transforms of the tags? The local transforms mean nothing when it comes to the game handling the axis of the tag, it's all about the edges.

 

Of course the bolt_r_foot parent's are correct, it's the foot mesh itself which we all know must be 0,0,0 which it is.

 

I've done everything suggested in this thread and nothing has change anything, even flipping the normals of the tag. While in ModView it does change the axis of the tag it doesn't however alter how it interacts with the terrain, seems to only act as simple collision.

 

Like I said, it may not even be tag related but something else, but I just don't know what.

 

I kinda figured the PCJ stuff out through testing my _humanoid rig a while back as well as other models that had custom skeletons. Entering certain bones into the PCJ list preserves the hierarchy, otherwise all the bones will just child to model_root in ModView with no real hierarchy. I do want to know how to access the help in carcass, never knew how to do it because I need to know what the "$flatten" command does, been using it blindly without knowing it's purpose.

 

I think what Xycaleth means is that unlike in modeling software where transforms change based on parent child relation they do not in the MDX format. You probably only need to preserve hierarchy structure in certain things that use UPPER and LOWER blending.

 

You say the motion bone is needed? The base AT-ST only has it in the XSI files, not in the GLM.

[Archangel35757]

@@minilogoguy18 -- I meant that you should check the foot & tag's ancestors' transforms since it would inherit parent transforms. Do you have anything in their hierarchy that was mirrored? etc.

 

Maybe you need to re-export all your animations with fixed tags now? Fixing only the root.xsi may not be sufficient...

[Xycaleth]

...but will you explain it in layman's terms, please?

I can't remember the exacts details, but it goes something like this. PCJs are solely meant as an optimisation for computing the transforms of individual bones. In general, the bone hierarchy you see in your modelling software is the same bone hierarchy you get in the GLM/MDX format. From what I can guess, you can choose to flatten parts of the bone hierarchy in your .car file, and I think this is evident from the finger bones which are actually children of the elbow (I think?) instead of the wrist.

 

I think (a very big think) this optimisation is done mainly for IK, where you don't necessarily want to deal with all the bones at the extremities, so you parent them to a bone higher up the hierarchy.

[Archangel35757]

@@Xycaleth-- does the engine do IK on skeletons? I didn't think so... Perhaps another way of explaining is that it bakes the transforms into, e.g. the fingers, and then removes intermediate bones-- such as those X-rotation bones (lower fore-arm, etc)?

 

Here is the actual #jacoders conversation

with the meister himself:

 

<Archangel35757> why is it necessary to create a list of player controlled joints in Assimilate?

<@@Xycaleth> o_O

<Rich> Flattening, it's a potential optimization

<@@Xycaleth> flattening?

<Rich> It flattens out joints in the hierarchy to minimize the number of transforms

<Rich> But that would mess with hierarchical transforms at runtime for, say, the ragdoll

<Rich> So you have to specify PCJ's to avoid it flattening them there

<@@Xycaleth> hmk

<@@Xycaleth> OH

<@@Xycaleth> THATS WHAT A PCJ IS

<@@Xycaleth> FFFFFFFFFF

<Rich> heheh

<@@Xycaleth> i swear i've searched a billion times for 'pcj' on google and came up with nothing

<Rich> It's actually programmer controller joints and not player controller joints, traditionally

<Rich> In the raven terminology at the time

<Archangel35757> So we don't need them at all?

<Rich> You don't need to worry about it for generating new GLA's, no

<Archangel35757> but using them in the .CAR file (input to Carcass) doesnt appear to change the bone hierarchy in ModView..

<@@Xycaleth> bone hierarchy is created in 3ds max etc, isn't it?

<Rich> The option was added for JA ragdoll because we needed to prevent flattening

<@@Xycaleth> i'm still not clear on what flattening is :/

<Rich> Like a finger is a child of the hand, normally

<Rich> Which means transforming the skeleton at runtime has to transform the hand, then transform the finger from the hand's transform

<@@Xycaleth> yeah

<Rich> Flattening makes it so they are both children of root, so that the animation data contains only root-relative transforms for each

<Archangel35757> @@Xycaleth - yes. heirarchy built in 3dsMax exported to dotXSI.

<Rich> Which means you don't need to transform the hand, arm, torso, etc. to transform the finger

<@@Xycaleth> ah ok

<Rich> The finger's transform is in root-relative space already

<Archangel35757> you can see some GLA's that have fingers as children of the forearm bone or upper arm bone and not the hand (as it is in 3dsMax)

<@@Xycaleth> hmk

<Rich> For ragdoll it probably flattens everything up to various points

<Rich> Because only a few of those bones really need to be controlled outside of the anim data

<Archangel35757> so this info is embedded in the GLA?

<Rich> And everything under the hierarchy being manipulated can still be flattened

<Rich> The info itself doesn't exist at runtime

<Rich> It translates into flattening the hierarchy in the skeleton

<@@Xycaleth> brb

<Archangel35757> @Rich - when?

<@@Xycaleth> when carcass is run i assume

<Rich> There is only one place that data exists - the GLA. So when the GLA is generated.

<Rich> Yeah, I'd assume carcass as well

<@@Xycaleth> it's an optimization for generating the GLA. it doesn't affect game runtime

<@@Xycaleth> if i understand correctly

<Archangel35757> ok... so it is a way to simpilify the heirarchy at the time the GLA is created.

<Rich> Basically it just flattens the skeleton hierarchy in the GLA to prevent some overhead of more nested transforms in the hierarchy at runtime, yeah

<Rich> It wouldn't be viable if we had some intelligent animation compression scheme that stored parent-relative deltas, cause precision would go to hell

<Rich> But the data is basically all flat in the GLA already and doesn't intelligently utilize range or deltas, so it all works out the same for precision

<Archangel35757> doesnt seem to be used for JO but I do recall scratching my head as to why fingers and hand are siblings under a forearmX bone etc.

<Archangel35757> for JA... if I recall

<Archangel35757> on my cell. no access to PC

<Archangel35757> @Rich, so Noesis has a mechanism to select a list of FBX animations and a root.FBX file and compile the FBX animations into a GLA in the order the files are selected/listed

<Archangel35757> ?

<Rich> You're asking if Noesis will combine animations for you too? You could use the .animlist format, assuming that still works, it's basically just a text list of FBX files. They would then all get baked into a single GLA. Or just concatenate the FBX's on export.

<Rich> Er, a text list of animation files, which can be FBX, or anything else

<Rich> You might be overlooking the importance of the animation.cfg for what it sounds like you're trying to do, though

<Archangel35757> the animation.cfg is an output of Carcass when setup from Assimilate, right?

<Rich> Maybe, I don't really recall

<Rich> But it defines the individual sequences

<Rich> You're probably after having those sequences defined based on the individual input files

<Archangel35757> yes. Modview can create one frome the frames file

<Rich> Yeah, which is probably not what you want

<Rich> But if it is, then that's fine

<Archangel35757> the sequence of animations that is loaded by ModView

<Archangel35757> the game uses the GLM/GLA and an animations.cfg and an animevents.cfg file, right?

<eezstreet> animations.cfg defines the start of each frame and the length of those frames

<eezstreet> and the animation that that frame sequence corresponds to

<Archangel35757> Assimilate /Carcass create those files during a compile. All I'm saying is it would be good if during a FbX --> GLM/GLA compilation

<Archangel35757> that there was a way Noesis would spit those out as well with perhaps another text file as input?

<Rich> You could pretty trivially write a python script or a native plugin to do that I guess, depending on how you want to do it

<Rich> If you want to manage it from the anim sources themselves and define each input file as a sequence

<Rich> Or pull sequence names out of the FBX's

<Rich> Which FBX does support, but you don't necessarily want to use

<Archangel35757> FBX --> GLM/GLA is viable for any package to use.

<Rich> Huh?

<Rich> I just meant, in FBX terminology you have "takes" which I'm just calling sequences, you can use take names as sequence names

<Rich> Or you can consider each FBX file its own sequence and name the sequence after the file

<Archangel35757> using Noesis to compile GLM/GLA from FBX files is critical to future of this modding community

<Rich> A lack of Noesis represents a clear and present danger to national security

<Archangel35757> like done today... one FBX file for an animation.

<Archangel35757> While 3dsMax & Softimage users can output XSI files (as well as FBX)... Maya, Blender, etc. can not

<Archangel35757> so we need FBX --> GLM/GLA using Noesis is needed

<Rich> FBX->GLM+GLA is quite viable, I mean, I've used it, and I've done GLA->FBX->GLA which is probably an overlooked path because it means people can modify all those existing anims and add new frames for existing GLA's that don't necessarily have available anim source

<Rich> If you're just hung up on the animation.cfg thing, that's a pretty easy thing to solve, and just depends on how you want to do it

<Rich> How you want to do it really depends on the expectations people have when they're generating these FBX's

<Archangel35757> reusing legacy GLA files will have in them the inherent bone jitter. we will need to remake the entire GLA

<Rich> In a lot of ways having a single FBX with all the take names would be nicer

<Rich> But I bet people are trying to feed tons of individual files

<Archangel35757> ...most likely. trying to duplicate XSI --> Carcass workflow.

<Rich> Well, I mean, the point there is to be able to modify existing GLA's, there's no real reason to go GLA->FBX->GLA otherwise, but to your point, you could certainly "deconvert" a new fixed GLA

<Rich> But that would also be silly because you're double-quantizing

<Archangel35757> right. At best use it to extract an animation as a guide to remake it

<Rich> Although given the quantization ranges, GLA->FBX->GLA *should* be fairly lossless

<Rich> You could always generate a gold-standard gla/cfg set

<Rich> Then convert that back to fbx and just build new anims on it as desired

<Rich> Or you can write a python script to spit out the cfg from a bunch of fbx filenames and/or take names

<Archangel35757> that's what is handy with assimilate (which we have the source for)

<Archangel35757> ...if we could still use Noesis to read the .CAR file to build the GLM & GLA from the given list of FBX files that would be great.

<eezstreet> hm...i have a bit of a logic problem for you folks

<Archangel35757> or give Neosis the .CAR file as another input?

<eezstreet> why? that's over complicated

<eezstreet> just make one FBX file

<eezstreet> and alternatively you can make a tool to read the FBX and export an animations.cfg from that

<Archangel35757> then that makes it pretty difficult to insert a new animation.

<eezstreet> are you talking about having the entire GLA as one FBX file?

<eezstreet> or what exactly

<Archangel35757> in my opinion it would be simpler to have individual FBX files...

<eezstreet> for what, exactly?

<Archangel35757> similar pipeline as today

<eezstreet> why does it need to be 1:1 with the pipeline that we have now?

<eezstreet> much easier to create one giant FBX, export animations.cfg from that, and then create the GLA

<Archangel35757> it is easier to add new animations if they are single files-- one anim per file. Rather than force everybody to load up and modify a monster scene with all animatio s

<eezstreet> then don't. merge all the FBXes into one giant one and send that into noesis

<eezstreet> although yes it does take one extra step for the artist to do this

<eezstreet> so technically you would be right, it would be easier if noesis could do it

<Archangel35757> again, easier to create a single animation starting on frame 1 instead of figuring what frame you should srart and end on... then try and move all subsequent frames to insert it.

<Archangel35757> so Noesis should take X number of specified FBX animation files and a root.FBX file and given a text file (from Assimilate? ir made by hand) compile the files and spit out the GLM, GLA, animations.cfg, animevents.cfg

<Archangel35757> ...in a perfect world

<Archangel35757> with one animation per FBX file

<Archangel35757> comments? throw rocks?

<eezstreet> i like root beer

<Archangel35757> i like Ginger Ale... but @Rich... do you see benifit of one anim per FBX file?

<Archangel35757> ... w.r.t. the artist(s)

<Archangel35757> artists can be working on individual animations in their package of choice and not have to work with one monster 21k+ frames of animation and try to insert a new anim and move subsequent keys will be a nightmare.

<Archangel35757> let Noesis stitch together all of the FBX animations and use the Assimilate file to know each animation's start and stop frame #'s to tally them up in the overall animations.cfg

<Archangel35757> by stitch I mean string them together and convert to GLA

<Rich> Either way, if you want to parse the FBX for take names, or parse multiple FBX files for take names, you can just write a python script to load them up, accumulate frame numbers and counts (which noesis would give you via script having already evaluated the scene nodes), and spit out the cfg

<Rich> There are a good number of example scripts that show how to load data like that

<Rich> If you rely on me doing it, you'll be waiting for a very long time, cause I've been sitting on a massive noesis todo pile for months now

<Archangel35757> I'm thinking Assimilate can still do it. And Noesis could take that .CAR file

<Archangel35757> and use it?

<Rich> You'd have to write a script for that too, but I don't see why you'd want to keep assimilate involved at all if it doesn't need to be

<Archangel35757> Noesis needs to know somehow the order of files, no?

<Rich> Not particularly, sequence order doesn't matter, frame order does

<Rich> Sequences just references frames

<Archangel35757> but they point to the individual anim file that that has thise X number of frames.

<Rich> Sure, that's what the .animlist is for

<Archangel35757> ok.

<Rich> There are dozens of ways to skin the cat

<Rich> You'll just be waiting a long time if you want me to skin it for you

<Archangel35757> I guess I need to go thru an example and see what issues/questions I have.

[Xycaleth]

@@Xycaleth-- does the engine do IK on skeletons? I didn't think so

Yes

[Archangel35757]

Yes

When? For ragdoll only?

 

@@minilogoguy18 -- see the readme file distributed with Carcass v2.2.

[Xycaleth]

When? For ragdoll only?

 

@@minilogoguy18 -- see the readme file distributed with Carcass v2.2.

For ragdoll, for rancors when they grab players. Possibly other situations but that's all I can think of off the top of my head.

[Archangel35757]

For ragdoll, for rancors when they grab players. Possibly other situations but that's all I can think of off the top of my head.

Interesting, could we bolt on another GLM model (say a cloak) and put it in "Ragdoll" mode for cheap clothFX? I digress...

[minilogoguy18]

@@Archangel35757 like I keep saying, you gotta forget about transforms on tags, they mean nothing, you can alter the tags transforms any way you want in SI/Max/Max/Maya/Blender but as long as the tag is the same in terms of edges it will always have the same axis in ModView/game.

 

Also, my tag axis match exactly with the base AT-ST in ModView which is why I'm leaning away from this being a tag related issue.

 

You also seem to not know my workflow, I do not export a root.XSI and then each animation separately then compile them into 1 file with Assimilate. I found out a long time ago that it was unneccesarry. All I do is export a root.XSI file and just manually write out my animation.cfg file to define all the sequences and it works just fine. The only real advantage I see to exporting each sequence separately is so that Assimilate will write the animation.cfg file automatically which to me isn't worth all that extra work. I'm doing it how Rich is saying to do it with FBX, 1 file, compile then just manually write an animation.cfg file.

 

I also knew about that IK was possible with MDX but for simplicity I just kept things FK that was being driven by a IK shadow rig, waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay easier and waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay more control. Anyone who is animating the skeleton that the game is using is a fuckin dummy and I'll tell it to their face in front of their own mama. Not a single project I've done has a single keyframe on anything that is going to the game, it's all plotting, the devils magic.

 

I would very much like to talk to Rich about a lot of things as far as animation, not to toot my own horn or anything but I've done a lot more than anyone in this area. Most people are using very primitive ways of doing this like dragon and just animating a simple FK skeleton into a simple pose.

 

I'd like to split a lot of this into a new topic because this also interests me, like say starting with post #43.

 

I also just fired up the game (JK2) and watched the base AT-ST, it of course behaves the same BUT it floats above the ground a bit where mine I messed with the offset in Assimilate to get it to sit on the floor, maybe the tags are beneath the ground causing the flipped behavior?

 

EDIT

 

Holy fuckin shit, @@Archangel35757 you were right all along with the foot bones, it is their transforms that control it BUT it does not change the tag transforms which means that the tags are just simply to compute collision but the bone controls how the feet interact with the uneven terrain. I totally missed this because even though I tried it before I was rushing since I was compiling files over and over again mainly messing with tags I didn't copy over the GLA file to the PK3, only the GLM. I also couldn't just match the transforms with the base model that I have imported into the scene because as you know the parent bones affect the children so it was just some trial and error but doing this has shown me the relative axis from Softimage to GLM/GLA.

 

To get proper working feet in ModView your axis should be as follows...

 

+Z=UP

+Y=LEFT

+X=FORWARD

 

Translating that from Softimage to MDX it would be...

 

Softimage    MDX

      +Y           +Z

      +X           +X

      +Z            -Y

 

These are LOCAL transforms, NOT GLOBAL. (Doubt anyone other than you will care since only you know SI->Max transforms)

 

It's finally fixed, I'll have to update the file tonight. I still wanna get some more threads like this started, like the things that many don't know about Assimilate/Carcass. Despite some thinking it can be replaced with noesis for now it's still useful and it would be great if some more functionality was added to it.

[Archangel35757]

@@minilogoguy18 -- I was not talking about tags... I'm the one (and Xycaleth) who told you it uses the edges to determine the tag's matrix (see pretty picture in past posts). I was talking about meshes and bones.

 

EDIT:

I'm a little confused by your axis comparsions...

 

MDX = Ghoul2 (...which ModView displays; and the Ghoul2 coordinate system matches 3dsMax-- +Z up, +Y into screen, +X right). The dotXSI coordinate system matches Softimage (+Y up, +Z out of screen, +X right).

 

...more Carcass functionality? Do tell... (in a new thread).

 

I'm glad you sorted it out.