WIP Dem bones, dem bones, dem jittery bones...

[minilogoguy18]

Look at the headers in the dotXSI files, they all were exported from Softimage|XSI version 2 and they're all dotXSI 3.5 files.

[Tempust85]

Not all, only the JKA animations. The JO animations are 3.0. But still Mod Tool should export the same as XSI 2.0 yeah? I also got jitter when I compiled using a Mod Tool exported animation. All I can think of is that Raven were using a different carcass, a better version.

[minilogoguy18]

But I've exported animations with no jitter, ever.

 

It could be the formatting, have you properly set the FPS in Mod Tool to export out at the same frame rate that the animation was exported in? They all have different frame rates.

[Archangel35757]

Jittering was never present in 3ds Max, and it's not present in Mod Tool (using crosswalk). Jittering is in modview or when I import the .XSI animation into Mod Tool/3ds Max which was exported using your .XSI exporter. Doesn't matter if I bake the JO animation onto the 'game nulls' or just leave it constrained, I get the same result inside modview. I always get jittering in some form with any animation I make. I think it's either the XSI format or ultimately the Ghoul2 format compressing the shit out of everything.

 

Does your exporter write out position keys when there aren't any keyed in Max? I'm grasping at straws here to find out what's going on.

 

The exporter samples the animation every frame and writes out the transform (position, rotation, scale) for all exported objects for every frame of animation. Except for CS BIPED, the code originally only exports out position data only for the root biped object (along with rotation)... and all children only get rotations exported out... check me on this by looking at your SRT and FCurves... you requested I add export of position data on Biped Xtra Objects-- which was accomplished using the keyword we came up with. But if you're removing helpers (i.e., only the CS Biped) then this seems moot.

 

You will get some loss of accuracy (perhaps some jitter...) just be the fact that we go from single-precision to half-precision. But I want to do all I can to find the cause and solve this.

 

Does Crosswalk export out the Basepose template? Or does it only export the SI_Transform SRT-xxxx template? When you get your animation in ModTool via Crosswalk... try exporting it out as dotXSI 3.0 and then see if it jitters... also look to see if it writes out the Basepose template? Thanks! :unsure:

[Archangel35757]

Not all, only the JKA animations. The JO animations are 3.0. But still Mod Tool should export the same as XSI 2.0 yeah? I also got jitter when I compiled using a Mod Tool exported animation. All I can think of is that Raven were using a different carcass, a better version.

So when you exported out from ModTool-- you were using a virgin ModTool animation with @@minilogoguy18 's rig? And was the jitter the same amplitude as from Max?

[Tempust85]

No I was using XSI nulls from Max. It could be the FPS thing minilogoguy mentioned. Speaking of which, does your exporter take note of what the FPS is in Max?

[Archangel35757]

No I was using XSI nulls from Max. It could be the FPS thing minilogoguy mentioned. Speaking of which, does your exporter take note of what the FPS is in Max?

Yes.  You can look at the original export code you have.  Aside from my fixes for checking for IK or constraint animation, it's basically the same... look in CdotXSIMapper::PlotOneCurve.

 

You'll see that they get the start frame and end frame using built in functions and the FPS is taken into account by the GetTicksPerFrame() function. TimeValue class is in ticks.  So dividing by TicksPerFrame gets you the Frame #.

 

So they iterate on frame numbers to sample the controllers.  One thing I noticed when building my ROFF Exporter is how I think 3ds Max SDK would recommend you actually iterate on the Timevalue but count on the frames.

 

So the Softimage programmers did this:

for (int f = l_iStartFrame; f <= l_iEndFrame; f++)
{
        t = f*GetTicksPerFrame();
        ivalid = FOREVER;
        
        l_pValues[index++] = f;

        //
        // get local transformation matrix
        //
        Matrix3 localTM;
        
        //Check if node is under IK Control (M. Lawler)
        if ( l_pController->ClassID() == IKCONTROL_CLASS_ID )
        {
            /* pmat = in_pNode->GetParentTM(t);

            IIKControl *ikNode = (IIKControl *)in_pNode->GetInterface(I_IKCONTROL);

            Control *l_pFKController = NULL;
            
            l_pFKController = ikNode->FKSubController();

            l_pFKController->GetValue(t, &pmat, ivalid, CTRL_RELATIVE);

            localTM = pmat; */

            localTM = GetLocalTM ( in_pNode, t );  //M. Lawler- just use LocalTM

        } else {
        
            localTM = GetLocalTM ( in_pNode, t );
        }
      .
      .
      .
}

Whereas, when I was researching other max animation plugins for the ROFF exporter, all those coders used:

    for(k = 0, t = l_start; t <= l_end; t += GetTicksPerFrame(), k++)  //l_start and l_end are TimeValues
    {
        tm = node->GetNodeTM(t);
        tm.NoScale();
        pos[k] = tm.GetTrans();
        MatrixToEuler(tm, ang, EULERTYPE_XYZ);

        .
        .
        .

    } 

See the difference?  I'm not sure if this is a factor or not...  if there is any error in going from the original Timevalue to frames and then re-getting "t" as:

 

t = f * GetTicksPerFrame();

 

After I get all other fixes in place... I could try to change all these to use the same iteration method I used in my ROFF exporter (but this would entail a systemic change because it's done throughout)... in the end it seems the two iteration methods should be equivalent.  The way I did the ROFF iterators seems standard for the .3ds and .ASE exporters as well... :wacko:

[Archangel35757]

Ok... so today I spent time making an simple animation in Max5 and doing the same in Max6... I opened the Max6 .max file up in 3ds Max 8 only to export to dotXSI 6.0 using Crosswalk.  I then compared all the resulting animations in XSI Mod Tool... and made screenshots of the FCurves in Mod Tool.

 

I simply put a Wave Controller on the lhumerus and lradius bones.  For the lhumerus bone I made the sine wave on the Z-axis (this is equivalent to Y-axis in Softimage).  For the lradius bone I made the sin wave rotation on the Y-axis in 3ds Max (this is equivalent to -Z axis in Softimage) ...so bear this in mind as you look at the data plots.

 

Comparison for lhumerus:

 

Original 3ds Max animation curves (X and Y are zero):

 

 

Mod Tool result using my exporter (the solid red line at ~9 is position-- ignore it):

 

 

Mod Tool result using Max5 Raven Exporter:

 

As you can see the results from my exporter and the Raven dotXSI exporter are pretty much identical (disregarding window stretching). 

 

Mod Tool result using Max8 and Crosswalk v2.6 plugin (dotXSI 6.0 format):

 

So notice that using Crosswalk, the FCurves retain their 3ds Max Coordinates... whereas in a proper Coordinate System Transformation the 3dsMax Z-axis, should have become the Softimage Y-axis.  Also, observe that even though the Z-axis above matches the original 3ds Max output... the X and Y axes now have sinusoidal variations... and not zero like the original 3ds Max output.

 

Now, does this mean the animation from Crosswalk is wrong?  Certainly not.  Because Raven unfortunately decided to use a format that stores rotations as Euler Angles-- rather than staying with Quats... like I explained here:

 

So for those unfamiliar with matrices... the rotation values are stored in the 3x3 sub-Matrix above (disregard the far right column).  The bottom row is the World Position (or Translation).  Scaling is stored along the diagonal.  So Euler Angles are not unique for a given transform-- there are multiple combinations of X, Y, and Z rotations that can convey the same World Space orientation.  So even though the Crosswalk curves look different.  The object animates exactly the same in World Space.  (But I'm glad my exporter matches Raven's ).  Furthermore, Euler Angles are susceptible to Gimbal Lock, or flipping, when certain axes cross over either 90° or 180° axes... Quats do not exhibit this behavior.

 

 

Comparison for lradius:

 

Original 3ds Max animation curves (X and Z are zero):

 

 

Mod Tool result using my exporter (recall Y-axis becomes -Z axis in Softimage):

 

...Softimage SRT FCurves are equivalent to Parent Space, but 3ds Max curves always show Local Space-- which explains the -3.15 offset of the Z-axis in ModTool.

 

Mod Tool result using Max5 Raven Exporter:

 

Same results as my exporter above.

 

Mod Tool result using Max8 and Crosswalk v2.6 plugin (dotXSI 6.0 format-- disregard window stretching):

 

So even though the Crosswalk dotXSI 6.0 Euler Angles are different thru the animation-- the object still appears to have the same world orientation/position as ModTool plays the animation... as I explained earlier.

 

So from this, it appears my dotXSI exporter matches the output from the original Raven dotXSI exporter.  I still need to recreate this animation natively in Mod Tool and export to dotXSI 3.0 for additional comparison.

 

Stay tuned...

[minilogoguy18]

Something I forgot, just set the fCurve interpolation to linear on the animation sequence you're having the jitter problems with, it may fix it. I don't think that JA likes spline interpolation.

 

I haven't seen Max's interface in nearly 10 years but there's the stolen from Softimage animation fCurve editor, after stealing tools from Maya and Softimage they still can't make a decent program without buying someone else out.

[Archangel35757]

Something I forgot, just set the fCurve interpolation to linear on the animation sequence you're having the jitter problems with, it may fix it. I don't think that JA likes spline interpolation.

 

I haven't seen Max's interface in nearly 10 years but there's the stolen from Softimage animation fCurve editor, after stealing tools from Maya and Softimage they still can't make a decent program without buying someone else out.

 

@@DT85 is working in 3ds Max for making animations-- not Softimage or Mod Tool... and there is an option in the 3ds Max curve editor (which has existed since before Max5-- not sure when you purport they "stole" it...   ) ...which allows you to set the Curve interpolations.  However, the exporter doesn't export animation keys-- rather, it samples the animated transform matrix on every frame and writes out the data.

[Archangel35757]

@@Xycaleth & @@eezstreet -- Even though it appears my dotXSI Exporter output matches the original Raven Max5 Exporter output... would there be any benifit/value to developing & incorporating the code (I have a sample to go by...) for an Euler Filter?

 

From Wikipedia:

In computer graphics, an Euler filter is a filter intended to remove discontinuities from animation data sets in which rotation is expressed in terms of Euler angles. These discontinuities are caused by the existence of many-to-one mappings between the Euler angle parameterization of the set of 3D rotations. This allows the data set to flip between different Euler angle combinations which correspond to a single 3D rotation, which, although remaining continuous in the space of rotation, are discontinuous in the Euler angle parameter space. The Euler filter chooses on a sample-by-sample basis between the possible Euler angle representations of each 3D rotation in the data set in such as way as to preserve the continuity of the Euler angle time series, without changing the actual 3D rotations.

[Xycaleth]

The pose data isn't represented in Euler angles (I don't think?) so it's not applicable in this case.

[Archangel35757]

The pose data isn't represented in Euler angles (I don't think?) so it's not applicable in this case.

You're mistaken. Rotations are stored in the dotXSI format using Euler angles. If you open one up in a text editor you'll see the SI_Transform template showing:

 

Scale-X

Scale-Y

Scale-Z

Rotation-X

Rotation-Y

Rotation-Z

Translation-X

Translation-Y

Translation-Z

 

The rotation values are Euler angles in degrees.

[Xycaleth]

Ah okay, I stand corrected I don't see any harm in trying it then.

[minilogoguy18]

I still think that whatever animation you were having jitter problems with you should try setting the fCurve to linear interpolation. I remember back in the day on I believe it was the ARC-170 model having the interpolation set to spline (default) caused the wings to rotate past the point where they were keyed at the end of the animation and move back to where they should have been. It wasn't really a jitter but it caused an over rotation that was predicted in another game engines mod tools (SWBF2) and since there is no animation documentation for this game I figured I'd try setting to linear and voila, fixed.

[Archangel35757]

@@DT85 -- would you save your 3dsMax animation (that exports as jittery) as .XAF format (CS Biped & all Nulls) and send it to me please? Thanks!

[Tempust85]

The jittery animation doesn't use biped. I'm using imported JO GLA nulls with JKA game nulls constrained to it. You'd need the entire max file, just a XAF won't cut it. I'll see what I can do later today.

[Archangel35757]

Then please send me your extracted FBX file that has the specific animation you pulled out of the GLA file.

[Archangel35757]

@@DT85 -- Would you please send me your FBX aninatuon you extracted from the JO GLA using Neosis? Thanks... I want to use the same file where you experience the jitter.

[Tempust85]

The file is huge and I have shit internet, so I recommend just converting the JO GLA with noesis yourself.

[minilogoguy18]

A word about Noesis, every game modder should have it.

[Archangel35757]

The file is huge and I have shit internet, so I recommend just converting the JO GLA with noesis yourself.

So you're not working with a single FBX animation but the entire GLA converted to FBX? I thought you extracted out a single animation as FBX.

 

So to be clear-- your jitter issues are only when working with this: GLA >> Noesis >> FBX file? ...which was then imported into 3dsMax, is this right?

[minilogoguy18]

Yeah you should expect issues when reverse engineering formats that a compiler puts out, I seemed to have missed the part when you mentioned it was converted in such a way.

[Archangel35757]

Yeah you should expect issues when reverse engineering formats that a compiler puts out, I seemed to have missed the part when you mentioned it was converted in such a way.

Well, the fewer the conversions the better... but the main issue is starting with a half-precision format (GLA) already having compression artifacts, and converting it back to a single-precision format (FBX).

 

I'm not quite sure what @@DT85 is trying to do... seems like he's wanting to recover all of the JO animations??? Maybe @@eezstreet or someone close to Raven guys could get them to release the dotXSI animations for JO (there's dozens of JO specific anims that were not released) and also the SOF2 anims???

 

I wonder... since Motionbuilder has tools for cleaning up MoCap data, if you could use it to first clean up/smooth the Noesis FBX data FCurves???

[Tempust85]

The thing is though, the jitter isn't present in 3ds Max or in modview (when viewing the base JO GLA). So something must be an issue in the export & conversion process. Would be extremely helpful to have JO anim source, would only take a few mins to compile them for JKA.

 

EDIT:

 

It also doesn't jitter when I export as an FBX and view it in noesis. Seems to me something's happening when it's being exported to XSI format or converted to GLA.