The frame variable of the, for example SJoint::RotationKeys[index], is a f32, however in pretty much all the animations I've worked with, the frame times could very well be u32.
IIRC irrlicht does not add data to those key arrays after the mesh is loaded the first time, and interpolates the two most adjacent keys if the required key is not found anyways.
Besides, it's pretty hard hitting a granularity of 0.1 (a tenth) of a frame in playback (even at 30 fps) so it doesn't help save on calculations most of the time anyway.
As for precision, you should be able obtain it by adding those precise keys into the set and decreasing the animation speed.
Anyway, I'm working on an animation system (that should also support blending) and I wanted to use irrlicht's meshloader to export the keys from ms3d and x files, so that's why I'm asking.
Why is ISkinnedMesh::SJoint::*Keys::frame a float ?
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
The current frame of the animation system is also an f32 value, so having those as floats everywhere seems to make sense. Don't know how the mesh formats handle them. The reason why it was changed to f32 in the new animation system is that e.g. playing an animation very slowly will easily bring up fractional frames. and having a change at frame 2.25 with the usual 30fps speed seems more natural than a change at frame 9 with a speed of 120fps.
Well, I seem to have managed to finally rip animations through irrlicht from an X model to a file; also managed to get the transformations to work (somewhat) properly and have displayed an animation both with and without an animation mask.
Now I have to see exactly where my math went wrong (IIRC irrlicht requires that IBoneSceneNode transformations be relative ones).
PS: I still USE irrlicht, but the skinned animation system is pretty limited so I decided to make my own.
Now I have to see exactly where my math went wrong (IIRC irrlicht requires that IBoneSceneNode transformations be relative ones).
PS: I still USE irrlicht, but the skinned animation system is pretty limited so I decided to make my own.
What I'm working on right now is not supposed to ever break the API at all since it's an animator.
and somewhere in your character class or (for very simple games) in the main loop:
This function should also (theoretically) accept weighed blend trees (I wrote the code but haven't yet tested this since it requires coding a blend tree by hand, and I have more important issues at hand, see below.)
Right now I still haven't finished working on the transformation from world-space to object-space (the root bone still does not translate properly).
Code: Select all
IAnimatedMeshSceneNode* node = smgr->addAnimatedMeshSceneNode( mesh );
ISceneNodeSkinAnimator *skinAnimator = createSceneNodeSkinAnimator( node );
skin::animation::CAnimationPlayer *test_anim = skinAnimator->addAnimation( "./test.anm" );
// you can also define masks
CBoneHierarchyMask* upper_mask = skinAnimator->createMask("rknee 0.3 lknee 0.3");
node->addAnimator( skinAnimator );
Code: Select all
if( test_anim )
skinAnimator->renderAnimation(test_anim, upper_mask);
Right now I still haven't finished working on the transformation from world-space to object-space (the root bone still does not translate properly).