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

[Archangel35757]

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.

 

Save out one the of the animations from your imported FBX file, where you find the jitter most noticeable when you convert it back to GLA.  You can save it out as a .XAF and select the pertinent frames... and send it to me please.  Converting to GLA will always result in a loss of accuracy.

[DT.]

I'll upload my max file, so you have the exact scene I'm using:

 

https://www.dropbox.com/s/g4o9udpqrmvjr7p/both_saberslamdown.rar

 

Max 8 file. Everything is layered.

[Archangel35757]

@@DT85 -- Thanks!  File downloaded.  I'll take a look at it tomorrow...

[Archangel35757]

@@DT85-- is your filename the exact same name of the animation in the animation.cfg sequences?

[Archangel35757]

So this is just a quick look... I hid everything but the character's right hand that is slamming the lightsaber down on the table.  I then aligned a camera to the right hand bone and moved it away on its local axis so as to see the hand nulls.  The camera is linked with the right hand and so the animation plays in a "fixed" frame of reference.

 

http://youtu.be/ICdxGwRUuFM

 

I take it these jittery white nulls are the ones imported from JO GLA -> Noesis -> FBX -> 3ds Max, is that correct?  I'll have to study this more tomorrow.

[DT.]

Yeah that's the jittering. I managed to clean it up somewhat, but still doesn't fix it entirely. Not even a bake onto the 'game nulls' produces a clean version in modview.

[Archangel35757]

@@DT85 -- I wonder if this has anything to do with the Frame 0 not being the root pose-- like the exporter is expecting. I thought the first two frames of every animation were suppose to be the root pose, no?

 

Now that I'm more comfortable with the source code and SDK's... I can change this "Frame 0" expectation and just get the SkinPose TM... if necessary.

 

EDIT: However, I read this in the Dragon User Guide, which seems to support my earlier statement:

"…Ok, now the tricky part is that you'll need the very first frame of animation to be empty -- it technically doesn't matter, but you need to understand that this buffer needs to be there because other animators, using packages like XSI and 3dsMax, weren't able to keep the skeleton intact when exporting to GLA and merging, unless they had made the first frame of their animations the base pose, otherwise the animation could not be successfully merged in with GLAmerge. Dragon does maintain the skeleton's structure, but uses the same merging program as everyone else."

This evening I'll insert the root pose on frame 0/1 and re-export to see what happens.

[DT.]

For animation, only frame 0 is the root pose. You then set the start frame to 1 so you don't get the root pose at the beginning of the animation. Otherwise, animating in Max for JKA would be useless.

[minilogoguy18]

In Softimage the root pose can be wherever you want, as long as it's at the beginning of the animation.

 

If you watch my animation tutorial video you'll see that I'm actually using frames -2 and -1 for the root pose. I don't believe the compiler takes into count the frame number from the software or dotXSI file, just the frame count which no matter what number the frame is in Softimage the first frame is always going to be 0. When I export of course I only export -1 to wherever the animation ends and compiling the GLA BEFORE MERGING it with the _humanoid.gla it shows the root pose as frame 0 in ModView.

 

If you compile say the AT-ST using the source files you can compile them in a different order and the frame numbering will no longer match the animation.cfg file since it only takes into account the amount of frames and order in which the sequences are arranged in Assimilate. Even though if you import those files into Softimage the dotXSI files retain the frame numbering from the software.

[Archangel35757]

For animation, only frame 0 is the root pose. You then set the start frame to 1 so you don't get the root pose at the beginning of the animation. Otherwise, animating in Max for JKA would be useless.

But in the animation you sent me... you don't have the root pose on frame zero-- unless I'm zoning out?

[DT.]

It is on frame 0, but the timeline is set to start from frame 1.

[Archangel35757]

@@DT85 -- I'm studying your scene... would be nice if we could chat on MSN

[Archangel35757]

@@DT85 --  In your 3ds Max scene file, when I link a free Camera to your rhand bone and hide your jittery JO nulls, etc., leaving only the Game Nulls... and play the animation so I can see the motion of the hand/finger bones in a relative frame of reference-- the only jitter I see is your rhang_tag_bone (because you have it position constrained to the jittery, imported JO null).  Around frames 30 to 45 there is some un-natural motion in your finger and thumb bones... (but this is in your original scene) as shown in this preview (recorded at 10 FPS to make it easier to compare):

 

http://youtu.be/Qj3oFcgimeY

 

Now, when I export your Nulls using my dotXSI exporter, and re-import it back into 3ds Max 8 using the Softimage Max6 dotXSI Importer... one of the issues here, is that the Softimage Importer fails to do a proper coordinate transformation back to the 3ds Max coordinate system-- even though the nulls appear to be in the proper 3D space and animate correctly... the nulls retain their XSI coordinate frame of reference (incorrectly oriented by a 90 deg rotation in the X-axis).  But likewise linking a Camera to the rhand bone and playing this file in 3ds Max still appears to match your original scene... as shown in this preview (recorded at 10 FPS to make it easier to compare):

 

http://youtu.be/JR18g3NufDI

 

So if you agree with this comparison, I don't think the new dotXSI Exporter is adding jitter to animations.  However, I did discover two anomalies, while attempting to do an "Export Selected" with your scene.  I had only the Game Nulls selected, but it exported out the JO Nulls as well.  Thinking this might be related to the checkbox for "Export unsupported objects to Nulls", when I unchecked this box and tried to export out your game nulls, it only exported out the skeleton_root and model_root.  So I need to investigate these two issues.

 

Another thing I found is that when I try to merge the exported dotXSI file back into your original scene the entire Null skeleton had a slight bias offset in position-- I'm thinking this is likely related to re-importing the file using the borked dotXSI importer.

[DT.]

The animation (exported with your plugin) plays fine in Mod Tool, so I think this is just a failing of Ghoul2 or perhaps carcass.

[Archangel35757]

Well, that's good to hear. A few more questions to @@DT85 and @@minilogoguy18 regarding basepose in animations...

 

Correct me where I go wrong, but... I thought the Basepose is two keyed frames in the root pose; and that Frame 0 and Frame 1 were suppose to be the keyed root pose... so then your animation would actually start on Frame 2, no?

 

@@minilogoguy18 -- I get what you're saying about you having these two frames on -2 and -1, my exporter expects the root pose to be on Frame 0 (I may look into eliminating this requirement)... and when you export to dotXSI, you should export from Frame 1 to End, yeah?

 

So for the two cases ( [1] compile new skeleton with Carcass, [2] merging a single anim with GLAmerge ) should the root pose be retained in the first frame of the dotXSI? Or is the workflow different for these two cases? Please elaborate in your responses. Thanks!

[DT.]

It's never been 2 frames for the root pose, only the first frame. Would be best to leave the exporter as grabbing the root pose from frame 0 as I'm pretty sure Ravens plugin also does this.

 

I haven't used the glamerge method in a very long time. You export the animation the same way with either method I would think, it's only the GLA end result that is reached differently.

[Archangel35757]

It's never been 2 frames for the root pose, only the first frame. Would be best to leave the exporter as grabbing the root pose from frame 0 as I'm pretty sure Ravens plugin also does this.

I haven't used the glamerge method in a very long time. You export the animation the same way with either method I would think, it's only the GLA end result that is reached differently.

But ModView shows the root animation as two frames... @@minilogoguy18 uses two frames... I'll experiment after work today.

 

@@DT85 -- delete the position constraint and try using a link constraint on your rhang_tag_bone to your rhand bone... this should eliminate its jiggering.

[minilogoguy18]

I can export any frame range I want. For my _humanoid rig the root pose is -1 after export, 0 to whatever is the animation. Carcass gives a rats ass what the frame number in Softimage is, it just sees how many frames there are and makes the first one frame 0 despite what it was in Softimage.

 

IMHO, I think you personalized the exporter a bit too much, if anything you should be trying to emulate exactly the behavior of the Softimage dotXSI exporter, that way you know you wont run into problems. Open up Softimage some time, I know you have it installed and look at all the dialogue options and how it outputs a file.

 

In short, if it ain't broke, don't fix it.

 

You should be making it do everything Softimage does to the T, no exceptions.

 

About the 2 frames thing, Carcass will NOT ACCEPT a 1 frame animation, at all. The root pose is only added to a animation using ASK's GLA Merge tool, IF YOU BUILT A GLA USING ASSIMILATE THE ROOT POSE CAN BE ANYWHERE YOU WANT IT TO BE!

 

This is why it's a very bad reason to let your exporter write out where the root pose is expected since ONLY ASK's GLA Merge tool requires the first frame to be the root pose, after merging the tool DELETES THAT FIRST FRAME, it's just there for referencing or calculating,  only he would know for sure.

[Archangel35757]

...IMHO, I think you personalized the exporter a bit too much, if anything you should be trying to emulate exactly the behavior of the Softimage dotXSI exporter, that way you know you wont run into problems. Open up Softimage some time, I know you have it installed and look at all the dialogue options and how it outputs a file.

 

In short, if it ain't broke, don't fix it.

 

You should be making it do everything Softimage does to the T, no exceptions.

 

About the 2 frames thing, Carcass will NOT ACCEPT a 1 frame animation, at all. The root pose is only added to a animation using ASK's GLA Merge tool, IF YOU BUILT A GLA USING ASSIMILATE THE ROOT POSE CAN BE ANYWHERE YOU WANT IT TO BE!

 

This is why it's a very bad reason to let your exporter write out where the root pose is expected since ONLY ASK's GLA Merge tool requires the first frame to be the root pose, after merging the tool DELETES THAT FIRST FRAME, it's just there for referencing or calculating, only he would know for sure.

With all due respect, when it comes to this 3dsMax dotXSI exporter source code, and your thinking I've personalized it too much-- you don't know what you're talking about. My motto has always been to deviate as little as possible from the original source code-- to fix only what is broken. However, it had a number of issues and shortcomings that needed to be fixed. Some only being discovered during beta testing. The changes I've made were necessary for it to function properly... and create a valid dotXSI 3.0 file.

 

The only personalization is the new "About" dialog. Remember-- the Softimage Company wrote this plugin. They didn't include writing out the basepose templates-- which was one of the things needing to be fixed (among many others) to make a valid file for Carcass. But your point is taken about "Frame 0", where I based that solution on other Max exporters, and I had already stated that I was considering changing the code to remove this restriction. 3dsMax is not Softimage... and the code was written as a Max plugin, by Softimage programmers, using the XSIFTK. And CustomPSets are a Softimage dotXSI export feature... which Raven used to contain the necessary data to automatically create a .Skin file-- which has also been fixed now-- I didn't even delete their bits of Max3 code #defines that are still in there.

[DT.]

GLAmerge really isn't needed anymore though, we have the full source to JKA's animations. I prefer the carcass & full compile method tbh, less dicking around. Frame 0 doesn't get written out unless your scene starts from frame 0 and not frame 1 so it's basically operating like Softimage in that part at least.

[Archangel35757]

GLAmerge really isn't needed anymore though, we have the full source to JKA's animations. I prefer the carcass & full compile method tbh, less dicking around. Frame 0 doesn't get written out unless your scene starts from frame 0 and not frame 1 so it's basically operating like Softimage in that part at least.

The plugin code looks only at Frame 0 for basepose transforms. I can change this to get the skinpose transforms that are stored in the node when you either apply the Skin Modifier or (if no skin) alternatively set the skinpose under the Character tools-- and I do agree with @@minilogoguy18 that this is a better design... and I can still use "Frame 0" as a last check fallback for the case when there's no skin modifier, or they failed to set the skinpose-- and make this clear in the user instructions.

[Archangel35757]

The animation (exported with your plugin) plays fine in Mod Tool, so I think this is just a failing of Ghoul2 or perhaps carcass.

 

@@DT85 -- I really need to chat with you... also, I fixed the "Export Selected" feature (again... for the final time) so now only selected objects get exported ( my last fix only did this for geometry or bones-- so I removed the check by node type so that all nodes go thru the "isSelected" check.  Also, I figured out why I was getting the offset when re-importing the dotXSI... it seems that the importer shifts the animation back down to Frame 0  so I had to select all the keys and shift them back to Frame 1. 

 

So can you get on MSN shortly?  Thanks.

[minilogoguy18]

What about making it work so that it quits adding a node to the top of the hierarchy? IMO that sounds like a pain and if export selected truly works it shouldn't add anything, only export what is selected.

 

I would also like to never use GLAMerge but every time I've tried to compile a new _humanoid.gla using the source it always failed, maybe I did something wrong.

[Archangel35757]

What about making it work so that it quits adding a node to the top of the hierarchy? IMO that sounds like a pain and if export selected truly works it shouldn't add anything, only export what is selected.

Well, that's just how the Softimage programmers made it... they did the same with the importer-- where they create an XSISceneRoot when you import a dotXSI. It's a lot more complicated to remove than it seems. Export Selected does work... BUT, it will always put a root node on top-- that's why I added a feature to allow you to rename it as "model_root". I plan to leave that aspect of their original code alone.

 

But in my advanced character rig I plan to use "export selected" because I will have a Character Assembly Node at the root of my hierarchy, and I don't want extraneous bits in my dotXSI output, and the exporter will put the "model_root" node on top still.

 

I would also like to never use GLAMerge but every time I've tried to compile a new _humanoid.gla using the source it always failed, maybe I did something wrong.

Not sure, I've never tried it... perhaps @@DT85 could help.

 

EDITED the first part of my response.

[DT.]

The provided model.car isn't written for the carcass that is available to us, so it will give errors when trying to create additional animations from the one .XSI file. Just needs some slight modifications, I can send you my fixed model.car if you like.