Animation model seems unorthodox, unusually restrictive

[m-7761]

It seems to me that the way the animations are set up is unlike an editor software. Normally key frames are not equidistant, and are not global. This feels too restrictive and destructive, since in order to import data it would need to be regularly sampled. I don't know if MM3D lets dummy frames exist, but if not setting up an animation must be like stop-motion work.

EDITED: I meant to say that this is not how Assimp works for example. There might be some wisdom to the simplicity of the system, but I think it's probably lossy in theory, if not in practice. I'm thinking about how to represent the animation UI differently. I wonder if it's a mistake to assume reproducing the existing functionailty is adequate. I think it needs to be possible to isolate individual elements (e.g. joints) to see how they are animated. It may be that there are hundreds of frames, but only a few key frames.

[zturtleman]

Only modified joints are saved in keyframes and sparse/empty keyframes work fine (in .mm3d and editor but not all model formats such as MilkShape3D .ms3d). Keyframe joints are green and interpolated / default joints are blue. Finding all keyframes for a specific joint in hundreds of frames would be hard, yeah.

Keyframes have to be equidistant in order to be directly exported to game model formats. I don't know what you mean by "global [keyframes]".

Vertex frame animations save all vertexes regardless of whether they change. No indication while animating. Yeah, stop-motion work to animate using and could be improved. (But since skeletal animation can convert to frame for export this should rarely be used.)

MM3D's animation support is a step up from MilkShape3D — a model editor software from the same era.

[m-7761]

I looked at MilkShape3D during my preliminary research. It was definitely inadequate.

Exporting is a completely different process... it's meant to prep data for a "run-time" that is not like editing software. Normally (look at Assimp) key-frames are stored at the level of the joint, and are just timestamped data. The animation interpolates the data independently for each component.

It can be difficult to represent that workflow in a UI. It's typically represented by displaying every single thing as a curve on a graph. I haven't dug into how the animation data is stored. It may be stored in the standard way. If so, it's just a question of how to best represent the data to users.

P.S. (Off-topic) Yesterday I spent a lot of time just staring at the animation UI trying to think of how to best redesign it. My sense was putting the current editing frame beside the frame count setting is a little confusing and invites accidentally changing the frame-count, or at the least hesitating every time over which is the right box to edit. So I arrived at the conclusion that the FPS, count, and loop settings should be moved into the animation window, out of the main window. I think to do that the list should be made into a table, and it should be possible to set the FPS for everything at once, so multi-select, and checkboxes for looping in the table.

It's taking me forever to produce a new version of MM3D. It will be a relief when it's finally finished. The initial phase that is. I also chose to move the media controls (Play/Pause) into the right side of the toolbar... not the icons, but where the parameters go. They can keep that area from collapsing in on itself, disturbing the layout (especially in full screen) and also serve as a permanent indication that the animation mode is in play. Since the sidebar controls can be minimized.

This scatters the animation stuff all over. But it's the best I could arrive at. That means the sidebar controls is reduced to the drop-down box, and a spinner box for setting the working frame. And I added a [...] button to open the animation window. More could be placed in this area, but I think it should not have anything that changes the parameters of the animation. I think that's actually a fault in the current design also.

[m-7761]

Keyframe joints are green and interpolated / default joints are blue.

Does Animation -> Set Rotation Keyframe and Set Translation Keyframe have anything to do with this?

Do those items do anything? Their code looks dubious. How do you control which frames are dummy/interpolated frames?

EDITED: Oh, I think Clear Animation Frame may do that? If so it doesn't belong in the Copy/Paste group. I haven't looked into it. But it seems plausible. If the "Set" options are the opposite, then it belongs in that menu group.

[zturtleman]

Yeah, Set Rotation Keyframe or move/rotate joint using tools to add keyframe and Clear Animation Frame to remove keyframe.

[m-7761]

On the usability end I think an approach that can help is to use the ticks to mark frames with actual animation keyframes, and put a snapping system in place. That reduces the hunt greatly.

Something like a nonmodal animation window could pick up the rest of the slack.

[m-7761]

I wonder if a way to have our cake and eat it too so-to-speak would be to allow the Frame setting to hold fractional numbers? And maybe offer both absolute or frame based time representations.

My instinct is this is an intuitive and simple interface, but that it can't be limited to whole value timestamps. I mean, you'd want to work that way probably, in a simple (low-poly) set up. But importing data won't work if it has to be sampled to the nearest whole frame. And a lot of data has no concept for "frames per second" and doesn't map timestamps to image frames.

[zturtleman]

Outside my area of interest to deal with.

[m-7761]

Solved: https://github.com/zturtleman/mm3d/issues/134