Open m-7761 opened 4 years ago
m-7761
commented
4 years ago Note, a big benefit of this change is skeletal animation can deform joints in pretty funky ways... I have a feeling frame animation can be used to counteract that funkiness, and it's much easier to keep the timestamps equal by combining into one animation, and it removes ambiguity of what the tools do in animation mode. (The ambiguity outside animation mode remains, but is easier to reason about.)
m-7761
commented
3 years ago Update: I'm a few days away from finishing this https://github.com/zturtleman/mm3d/issues/149 Edited: For the record I've not removed skel/frame animations but added a new kind so that you can think of them as "restrictions" on this more basic animation type. The wording is kind of complicated, but I called the new kind Complex Animation Mode. When making a <New Animation> I called its option "Indeterminate (Both)" and changed the group heading to "Animation Mode" instead of Animation Type. (Note, the data model is merged but the user interface is unchanged.)
I'm restructuring the vertex animations and it made more sense to me to treat the point data exactly like the joint data... i.e. use the Keyframe object to store the points.
What comes up is if the points switch over to using an API like joints use, which makes more sense now that Scale is added... animating points feels more like a skeletal animation other than they don't influence vertices/points.
Likewise the question arises then should vertex animations be able to animate joints also? But isn't that functionally identical?
In practice in a game I would want to combine the frame animation with a vertex animation like COLLADA does, so I wonder if keeping them separate artificially is helpful, since it would just require a feature to combine them in the editor to be able to preview your work.
When you combine the animations you just apply the frame animation to mesh and then the skeletal animation to that. COLLADA even lets you nest them, but that's because it treats the morphs as blending two meshes together, so it makes more sense to blend the outputs of skeletal animations. (This is actually how frame animations tend to be implemented today in hardware, since you can do it in a shader by doing 50% of each to interpolate half-and-half.)
I know it seems like a headache, but if the facilities are improved it starts to look like the more sane way. And like I say, it's pretty nonsensical to hold to the current way. The difference is more of an implementation detail. Like you can just think of the vertices as points too. Or you can think of material properties like points that can be translated or rotated or scaled. Most animation packages do support this, and if more objects (cameras and lights) are added it doesn't really make sense to keep everything into two disconnected APIs.
Anyway, I'm working on this right now, so I will have to make a decision, but least changed case I just make up some temporary APIs.
P.S. I think another benefit of merging is it removes the ambiguity in animation mode of if you are editing the base model or the animation frame whenever you edit something. I wouldn't want to have to select
<None>to switch modes. My plan to control what the clipboard does was to use Insert since it's close to the other animation controls I'm using (Pause/ScrollLock) and Insert is related to the clipboard. So it could be a way to switch in and out of animation mode (i.e. insert changes to the underlying model) without losing the animation pose you're working on. By merging this Insert mode would be easier to understand.(EDITED: I think the temporary API I prefer is to change setSkelAnimKeyframe to setKeyframe and use a Position argument that just behaves differently for joints and points until the systems can be merged. There are too many APIs anyway.)