You could try that. Have a control on the animation that deforms the mesh accordingly.
There are some basic classes in the engine to make pose animation something real, but it’s not functional.
Someone once tried this and actually almost manage to make it work. I took over his/her work but fumbled with the folder and deleted it (yeha I know…).
The implementation was actually capable of importing an ogre pose animation into the engine and play it (pretty much what you want I guess).
But an outstanding limitation of the implementation (mostly due to ogre xml file format) was that normals animated information were missing, resulting in bad lighting while the mesh was animated.
I’ll try to find the source again and give you heads up if I find it.
<span style=“text-decoration:line-through;”>Thanks for the answer. If I do controls, I can attach them to the models for sure and save the model as j3o with the control. But I’m not sure where to store the animation metadata… Is there a limit how much metadata I can store on the model?
If my VertexAnimationControl extends Control could just read these like animate(“walk”) and get the metadata “walk” from the model?</span>
I managed to revive the code from the thread you gave me. Only thing I really changed was the findGeom() method in the PoseTrack.java to find the mesh indicated by the mesh index. What to do with the normals? I was under the impression that they don’t exist in neither Blender nor my format. Should they be recalculated on the fly by JME?
I had some problems with only writing up the changes to animation track. I didn’t write key poses either. I wrote every vertice on every frame. Otherwise it didn’t work quite well. Could have bee my code also.
Is there any change you @nehon or somebody from the JME team (who knows their business, unlike me) could maybe develop the Pose animation in the engine?
Here, first of, a 600 frame (30 FPS) vertex animation:
You said on another thread:
you have an animation over 100 frames
Let’s say you have 3 Poses in your animation pose1, pose2, pose3.
pose1 is at frame 0
pose2 is at frame 50
pose3 is at frame 100
The PoseFrame for frame 10 would have poses reference pose1 and poses reference pose2.
then (given you have a linear interpolation) weight would be 0.2f (10/50) and weight would be 0.8 ((50-10)/50).
I followed this. Except PoseFrame for me was startPose, endPose and one weight. I couldn’t understand how to make it work otherwise. So every PoseFrame takes one weight per pose pair. And instead of calling Pose’s apply, it just interpolates between the poses for each pose pair and updates the vertex buffer. For each frame. It seems to work very nicely, even when playing backwards. So I don’t recognize any loop holes in this system
In my models (well, Bullfrog’s) I have multiple partial key frames all over. I don’t know if this is normal or not. But seems efficient. Say, a 250 vertex model, frames 0 and 6 are key frames for 77 vertices. Frames 2 and 128 are key frames for 20 vertices etc.
The code is available on the GitHub link above. I have no objection if you choose to incorporate it (modified or just like that) to JME for good. The animation code is still a bit dirty. It is mostly the resurrected code. But even it I think had some unnecessary code (like too much geometry references etc).
The stuff is very nicely preserved. For a 1999 release, only the texture resolutions (biggest is 128x128) give it away. With modern resolutions it is starting to show. Polygon count is not that great but the cartoonish style hides it really well. Just by anti-aliasing + phong it looks better than with the original engine. Few added texture maps and it is a new game
Oh yes, the format, the poses are not references. They are real poses, there would be even no need for the interpolation. Since every PoseFrame caries the actual poses, they might as well be interpolated already. The hierarchy is awkward for referencing. That would mean the poses would actually be on the PoseTrack level? The API maybe could remain the same and the optimizing could be done later? The Poses could check equality from the arrays they contain. I don’t know. What do you think?
PS. That last animation, file sizes:
Original file: 212kb
Every frame fully stored: 12mb
Current implementation: 2 571kb
Thanks. I could do a specific solution for my needs, but if you have a vision and how it should be in general that it would possibly serve future monkeys’ needs, it would be great. I could try then to implement it.
For the Poses, I already create them in such way that they are unique. They just get duplicated when creating the PoseFrames.