Archangel35757

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

Raven didn't use Crosswalk-- it didn't exist at the time. They exported from Softimage|XSI or perhaps 3ds Max 5 and using the Raven Max5 dotXSI exporter-- which I have and will also test out. Look at the bone hierarchy of JO Kyle and JA jedi_hm -- and you'll notice that the hierarchy is different... maybe this is a factor? @@DT85 -- I intend to analyze everything I can . I have a cleaned JO/JA Null skeleton I can send you if you like...

@@Boothand -- merge in the lights.xsi file that was included with the XSI Viewer to add lights to your scene and make it easier to see.

I believe you'll find a ShaderED manual in the SoF/SoF2 SDK assets... called SoF2_Shaders.doc which talks about using ShaderED2.

wait... I'm confused :wacko: You're saying you have a cleaned-up set of JKA nulls from importing the JKA root.xsi file? ...you did this using Max8 and the borked dotXSI importer? Or did you do this in Max 5 and the Raven importer (it's the only importer I would trust)? ...And you've then imported and constrained the JO GLA nulls to these JKA nulls? So you're not using a CS Biped anymore? Further, you imported these JO GLA nulls from a .GLA file (that has lost accuracy due to being converted to half-precision)? Have I understood you correctly? Out of curiousity, why don't you try exporting using Crosswalk and bring this into Mod Tool via Crosswalk? ...and see if the jittering is still present. Here's another interesting Google find: http://forums.relicnews.com/showthread.php?272018-Importing-animation-issue So this is a similar case of going from half-precision back to single-precision and trying to apply this animation back onto a CS Biped. So the first file at the top of the anim_list is what is used as the hierarchy template: FACE_TALK0 (if I recall correctly?)... but then they didn't have your fixed-up Assimilate code that now respects the order in which animations are added... and so I'm just saying that the new root.xsi file should be the first one added so that the bone hierarchy is based on it. So, everything is on the table for investigating this jittery bone issue.

Yes, that is one of the possibilities... but it could also be other things. For another example of bone jitter see here: http://forums.cgsociety.org/showthread.php?t=1101737 ...and this fellow didn't mention exporting to dotXSI-- or exporting at all for that matter. But here's a case of "Dem jittering bones" when exporting to dotXSI back in 2007: http://forums.cgsociety.org/showthread.php?t=529802 ...so this fellow was using a CS Biped and the Crosswalk plugin... so if it's with the exporter then it's been in there all along-- and carried over to Crosswalk. :blink: Also, there are some instances where using Position/Orientation Constraints and enforcing "Keep Original Offset" can cause problems... and I understand DT is using a Null skeleton constrained to a CS Biped. I've already stated that some of the released dotXSI files don't all have the same identical bone hierarchy. Carcass.exe uses the first file in the animation list as the hierarchy template... so I'm not sure how that would affect things during the GLA process-- if it isn't using your root pose as the hierarchy template. But DT mentioned he sees this jitter from the dotXSI imported into Mod Tool. Some precision/accuracy is lost by the very nature of converting from single-precision to half-precision... and there's nothing that can be done about that unless the programmers re-write the Ghoul2 format specification to be single-precision. So... I have to systematically analyze all possibilities and follow the process of elimination-- it could be a combination of things and not just attributed to a single item.

@@DT85 -- Would you be willing to send me your null/biped skeleton? Unanimated in the root pose? And I would imagine that the half-precision GLA conversion would amplify the jittering you're seeing. DT also states, as one would suspect, that the jittering is worse/most notable at the end of bone chains (hands/ fingers, perhaps facial bones, etc.). @@DT85... so when you compile this animation-- are you using the original _humanoid.gla to compile against? Or are you creating your own skeleton (new .GLA)? And if you're making a new skeleton (.GLA file) then would you post the content of your model.car file so I can see which file Carcass is using to build the skeleton hierarchy. Thanks!

Yes, but it's the first file at top of list that is used to build the hierarchy. You could try the original dotXSI Exporter The dotXSI importer is broken as well-- since the resulting nodes retain their XSI coordinate system-- thus the scene you started with in 3dsMax and exported and then re-import has a 90° x-axis rotation on every node. I also don't want to rule out a few other things. So I plan to investigate a few things...

While I know that a savvy user could create this file in any 3D app, I thought ShaderED was the de facto tool, no?

There may be a couple things going on... but one thing I recently discovered is that the released dotXSI animations don't all have the same bone hierarchy-- especially out in the arms... and this could possibly be a factor since a bone inherits the transform of it's parent. Therefore, using @@DT85 's new Assimilate version... it's impprtant to make sure ROOT.xsi is always the first animation... Because carcass uses the first file to make the bone hierarchy. Also, I need to investigate nulls bound to a CS Biped versus a Max Bone rig. I intend to make some data plots of the animation data and overlay.