Archangel35757

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?

@@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.

Do the texture UV coordinates need to undergo a coordinate transformation?

He can try to do retargeted animation which allows him to input offsets IIRC.

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

Can't you just add the logic code for what you are shooting & hitting and based on that tell it what kind of damage to do?

You have to mirror the bones like psyk0 said... but you could first try to save out your animations as XAF files and reapply them after you have fixed the skeleton.

@@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!

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.

..but shouldn't it do damage to droids?

@@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:

@@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.

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...

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:

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?

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:

Huh? Can you clarify... So now the jittering is gone? Was this using: 3dsMax -> Crosswalk -> ModTool ??? Did you change your skeleton? With your old workflow is the jittering still present in MODView? "Throw me a bone..." https://www.youtube.com/watch?v=qZRAIJ6adWw ...thought this was funny-- since we're talking about bones. Hope everyone finds it funny as well.

Ahhh... I remember that now-- I had no intention of releasing it. Just using it for dotXSI plugin development.

@@DT85 -- what, if any, animation interpolation settings are you using in MODView? Also, is the jittering present when you use Crosswalk to go straight to Softimage ModTool?

@@DT85 -- just compile against the JO root.xsi (making new skeleton) and put it first in your list-- so it's the first file listed in your .car file... hmmm, I forgot about "face" node which is parent to all facial bones in JKA.

http://jkhub.org/index.php?app=downloads&module=display&section=screenshot&record=23123&id=1811&full=1

What's wrong with @@Psyk0Sith 's Malak model (which includes both a Jedi and Sith skin file)???

When reapplying your skin envelope you must click on the button to match bones by name first before pressing Ok button.

It was included with the zip file for the xsi viewer. Save out each of your animations (see Max help docs). Fix your model scale... then reapply your animations using retargeting animation feature (see 3dsMax tutorials). You might also try saving out your skin envelope weights as a .envelope file (option available under skin modifier), then segment your mesh, fix your xform problems and reapply your skin envelopes. Refer to Max docs & tutorials.