Biped origin

[yrupik]

Not exactly a bug, but when I export a Biped, the origin (0,0,0) of the AWD mesh is centred where the root bone was located, in it's pelvis. It would be a lot more useful (and normal) to have an option to located the origin at the bipeds feet, so the mesh could be more easily positioned on the ground without having to take it's height into consideration. I'm using the latest 2014 64 bit version of the plug-in. Thank you.

[80prozent]

Hi yrupik Yeah, that is a known restriction. Here is how you can achive the effect you want:

• add 2 dummy-object to the scene. place both at (0.0.0)
• name one dummy "master", one dummy "new-root"
• make the "new-root" child of the "master".
• position you old root-bone, so the biped's feet are at (0,0,0)
• make old root-bone child of the "new-root"
• copy the AWD-Skeleton-modifier from old root-bone to "new-root"
• make sure the the skinned mesh is in Skin-pose-mode.
• set the skinned mesh to (0,0,0). it will look like the skinning is wrong, but as soon as you move the playbar back and forth, 3dsmax should update the bind-pose, and the skinning should appear correct again.
• make the skinned mesh child of the "master".

whenever i say (0,0,0), i mean set all properties to default position (pos, rot, scale) in local-space (parent-space).

Once you have included this 2 extra-objects, you will be able to control the mesh position exactly as you suggested. The extra "master" dummy could be removed on loading (listen for the asset-completle-events). It is only needed to make sure, that root-bone (new-root) pos/rot/scale is the same as for the mesh.

I know that sounds like lot of steps, but actually its quite fast, once you understand the setup/system.

I will mark this as enhancement, as i still have hope that there is a better solution, that i havn't found yet. For now, the setup explained above, should work.

Hope that is any help

cheers

Robin

[yrupik]

Hi Robin. Thank you very much for providing this; your solution has allowed me to move forwards. However, this method (unless I've done something wrong) doesn't appear to be compatible with translation animations, like walking; the character I'm animating starts to slide backwards half way though it's loop cycle, so they finish off where they began. I was already having problems with translation animations, so will translate my animations in code for now until a better solution is found.

Thanks again for the help,

Yan

[80prozent]

Hi again if you can send me a example 3dsmax, i can have a better look at the issue.

You know about the stitchFinal property on animClips ? if stitchFinal ==true, the last frame of your animClip will be replaced with the first frame. so if you have a animClip with only 3 keyframes, this might be the solution.... To check if that is indeed the problem, just make shure, that all animClips have stitchFinal=false (in away3d);

[yrupik]

I've figured out where I was going wrong. Using the method described above, I hadn't realized that I needed to modify my animation so that the master dummy was used to position the mesh on the x,z plane; the biped's old root bone can still be used for y animations, however. Luckily, this was a relatively easy modification and I'm only mentioning it here to prevent others from making the same mistake. Also, I discovered that if you don't attach the mesh to the master dummy, then the dummy doesn't get exported.

However, I am still experiencing a problem with translation. At a random point during an animation, the biped's translation seems to slow down for a moment. It's only quite subtle, but results in horrible, jerky animation when looped. The weird thing is, the glitch seems to start at a different, random point every time I load it into away builder. I was also experiencing this problem before I used the method mentioned above, so I'm not sure it's directly related. I've created the simplest awd and 3ds max 2014 file to demonstrate this glitch; these can be downloaded form: http://www.yrupik.plus.com/AnimGlitchExample.zip

To reproduce it:

1. Load the awd file into away builder.
2. Use the slider to play the animation back and forth (the play button prevents translation).
3. The glitch lasts for around 100 frames on the counter, and can sometimes be a little difficult to spot.
4. Sometimes the glich happens right at the start or end of an animation and is even harder to spot, so you many need to reload.

Cheers, Yan

[80prozent]

hey yan

i am sorry to say this: You can NOT rely on AwayBuilder for precise debugging of your animation.

AwayBuilder has several bugs for playing back animationClips.

I was trying to fix some of this some days ago, but for now i ended up with worse stuff than before...because the Away3d 4.2 refactor is going on right now, i decided to wait for Away3d 4.2 to be finished before looking into AwayBuilder again... If you use AwayBuilder a lot, i might be able to send you a version i compiled, that fixes some of the annoying AwayBuilder bugs. (but not the animation-playback...)

One AwayBuilder - bug for playing back anim, is definitv the varying start positions of the clips. you can never be shure, that the slider-positions is acctual the clip-playback-position. I hate that :)

Anyway, i will have a look at your files, to check where the problem is ( exporter/ awayBuilder/ engine). Might take me 2-3 days, as i dont have much time in next days....

cheers

Robin

[yrupik]

Hi Robin,

Thanks for the quick response. It's too bad about AwayBuilder, it's turned out to be a bit of a red herring for me, though I still can't seem to get translating animations to loop smoothly even in my own code; It feels like there's an issue with the exporter. However, I understand the plug-in is still under development, and you guys are probably busy with some (very excellent) other stuff right now, so will probably wait till v1.0 before continuing. I've put together a very simple as3 project that demonstrates the issue and have updated the files in the link above to include this. You can view the compiled swf here: http://www.yrupik.plus.com/animtest/

Thanks for your help :)

Yan

[80prozent]

Hey again. I did not had time yet to look at your files....will do so later (after germany is world Champion. ...) Hope i can figure out whats the problem. In near future i will uplad the next update for the exporter, but this far i did not plan for any changes in the skeleton export...lets see...

Cheers

[80prozent]

ok - i had a look at your files.

Found a quite big bug in the exporter (your file should have exported with 27 frames, but instead only 8 frames was exported). Was a simple bug. I cannot share the fixed version yet, because other parts of the exporter are not working in this version right now. I think i can upload the fix in next 2-3 days. But even if there was a bug, it does not really make a difference for the looping problem. I uploaded your project with the fixed awd here. http://www.differentdesign.de/downloads/AnimGlitchExample_80pro.zip Also i made a minor change to the max-scene. I made the keyframe back to the skeleton-root joint. This is how i think it works best. the master is only used to position your skeleton and your mesh, while always having them at same scene position.

I checked there is a bug in the away3d engine, that seams to set a wrong totalDuration for a animationClip. (for your anim, the totalDuration should be 891, but away3d says it is 858 - exactly one frame to small - if 1 frame = 33ms). I could fix this in the engine, so the correct totalDuration is shown, but again this seams to make no difference in the looping of the animation.

Conclusion: There is a bug in the exporter, but this bug should be fixed in next 2-3 days. There is also a bug in the engine, but this doesnt seam to fix the looping problem also.

I will keep investigating this, as i think its crucial that this kind of animation works.

[80prozent]

ok I got it. http://www.differentdesign.de/downloads/AnimGlitchTest/ I updated the zip i uploaded in prev post. Problem was the interpolation of your key-frames. To produce a perfect loop with constant timing, interpolation between key-frames must be linear, nothing else. I selected the key-frames in the curve-editor, and set the tangents to linear. Now your animation plays as it should be.

I hope i can upload the fixed exporter real soon. The problem with the current exporter is, that the exporter will not export correct count of key-frames. However, it will compensate for the skipped key-frames by increasing the duration of the exported key-frames. So you should be able to use the current exporter, as long as you keep in mind that you might lose some detail on complex animations. For animations like your example-anim, the skipping of key-frames makes totally sense, as this animation could theoretically be exported with only 2 key-frames, without loosing any animation-data.

Hope that all makes sense and is of any help

Cheers

Robin

[80prozent]

hm when looking at the anim, i am not 100& sure, that the looping is 100% accurate. Definitv much better than before, but maybe there are still minimal timing problems ? idk. you tell me :)

[yrupik]

Hi Robin, Great work! The new animation looks pretty perfect to me. I'm not sure if I can see any timing issues (or if my laptop is just a bit too old), though will update some proper animations and will see how they look. This is certainly good enough for me to move forwards with. Thanks greatly for your help, and thanks for such an awesome library as away3d.

...Also, congratulations winning the world cup yesterday ;)

[80prozent]

Hey

Happy i could help.

yeah - not really interested in football (did not even watched the complete match yesterday...). Germany is pretty much football crazy. so its good to have the title. many peoples are happy now. thats cool.

because the current exporter-version has this bug to automatically skip keyframes on export, you might run into timing issues again. (it should not be, but i can not be sure) The exporter has the feature to set a skip-frame for each anim-clip. When exporting a clip, it should than skip the number of frames, while compensating for the skipped duration. The bug in the exporter is this: you define skip=0, so no frame should be skipped. But bug makes skip+=1 before export. (i think this was simple copy/paste mistake in one of last updates...did not notice, as the duration of the skip does not change with count of exported frames...) Than, while export, we have this: if (skip>0) skip+=1; so even if you have defined skip=0, it will end up to be set to skip=2.

anyway, the plugin will be updated soon (without this bug)