Animations require keyframes for everything

[wijnen]

In Blender, animated values are interpolated between two keyframes for that value, without regard for keyframes for other values. In contrast, M.GRL uses a shared timeline with events for all properties when any keyframe for any property is present.

To fix this, two things are required. The first is that M.GRL must handle events when the preceding and/or following property is missing. My pull request #216 takes care of that. The second is that Blender's interpolation at keyframes for other properties must be recorded. Example:

location_x has keyframes at (0, 0), (50, 5) and (100, 25). location_y has a keyframe at (50, 0) and (150, 10).

The jta will contain four "updates" items, one for each of 0, 50, 100, and 150. Location_y will be set in the items for 50 and 150, but not in the one for 100. This means that with my pull request, the interpolation will happen between 100 and 150 (and without my pull request, location_y will be ignored completely). This is incorrect. Instead, the exporter should add an update for location_y at (100,5). If that is in the jta, everything will work.

As a workaround, this can be done manually in the Blender file, before exporting.

[Aeva]

Ok, so the PR is now merged. Can you send me a simple animation that demonstrates the second case (eg would break in m.grl in its current incarnation)?

The way m.grl is meant to work here is that for a given key frame some (but not necessarily all) properties will have an update and this update should have both a start value, an end value, and a duration. The property will then be assigned a driver function so that it can be solved at render time.

So, suppose an object has keyframes for "location_x" on frame 10 and 100, and keyframes for "location_y" on frames 20 to 200, they both should be animated correctly despite not lining up with one another. And if not, well, then that is a problem :)

Sorry if I'm not follow correctly - I'm quite sleepy as I write this

[wijnen]

The assumption in the code is that the record specifying the end position of the event immediately follows the record that specifies the start. So if location_x needs to change between 10 and 100, but there is a keyframe at 20 for location_y, it doesn't know what end value to use for location_x at 10. With the PR, it will see the value at 100 when handling the record at time 20, so it will start the animation then. That will work, but it isn't what you would expect. I attached a Blender file which should demonstrate it, but for some reason it doesn't export any events into the jta file. The exporter probably uses similar logic to what was in the javascript and ignores all events. That's also a bug, but it's arguably the same bug. test.blend.zip