The interpolation tool from GPv2 is being ported to GPv3 (PR link). This tool has a selection-based mode, which allows users to select pairs of strokes to interpolate in edit mode.
Porting the feature to GPv3 requires a replacement for this selection mechanism. Below are a few options we have considered so far, feedback would be welcome.
The existing .selection attribute for curves is not sufficient since the tool needs to know the order of selection. The selection order needs to be known across a full layer, for use with multi-frame selection where different frames can be interpolated.
The tentative solution in the current PR is to store a selection list in the layer runtime data (code). This works, but it has potential issues:
The list can grow indefinitely. (*)
Only gets reset when strokes are deselected. In particular it doesn’t reset on topology changes, leading to invalid selection indices (range is checked on apply, but should still be avoided).
Only gets updated on click-select. Other selection operators (box, lasso) don’t have dedicated GPv3 operators that could know and record this info.
(*) Technically a curve could be selected multiple times, although this requires deselecting it first, which will clear the selection.
A better solution may be to store selection order in a Curve domain int attribute. A selection_count on the layer would be incremented with each selection, writing the current value to the curve attribute. A list can be constructed from this by gathering and sorting all selected curves from the same layer.
This is more in line with existing attribute workflows and avoids hidden data in the runtime. It’s still dependent on the existing click-select operator though and has the same problem with (lack of) invalidation.
Since this selection feature is designed specifically for the interpolation tool it might make sense to implement it as a modal operation, if that’s possible. This could also be used to draw overlays to visualize the curve pairing, which is currently hidden until the tool is used.
The tool would perform click selection as part of its modal keymap, but instead of writing to selection it stores to a temporary order attribute. This attribute can be discarded after the tool is done, which also avoids the issue of stale data after topology changes.
I think an int attribute makes sense, and perhaps it’s worth making the editing of that more explicit and the storage persistent? It seems like information that could be used again, and if it’s an int attribute it stays relatively valid under topology changes.
Similar to face sets. Not sure if it should be a specific thing like an “interpolation set”, or a more general “curve set” that may have other uses.
So you could select the curves from both frames, and then run an operator to assign them to the same set. To help users understand the workflow, that operator could be shown in the tool settings or status bar when the interpolation tool is active.
I’d be hesitent to turn this into an attribute. It’s not meant to be persistent data. The selection order in GPv2 was only added to improve the workflow for the interpolation tool, basically to allow the user to define stroke pairs (which stroke to interpolate from and which stroke to interpolate to). Turning this into a persistent data doesn’t make much sense to me.
IMO, this should be a feature that’s part of the tool. Selection might be one way to define pairs, but I can imagine plenty of other methods like some automated method, or a combination of both, where the user can tweak the output of an automated pair generation.
In this case, I would expect that these pairs are runtime data that’s only created while the tool is used.
What is the downside of making it persistent? To me it seems tedious to have to set up this information again if you want to tweak the interpolation multiple times between the same frames, or between a different set of frames.
Even if this only exists while the interpolation tool is active, it still seems logical to use an int attribute. That’s the most straightforward way for built-in or add-on operators to work on the data while the tool is active. How else would it be stored?
I’m not sure I understand what you mean by this. If it’s about saving the stroke pair selection that you made, I don’t think that’s useful. This data can pretty much only be used once anyway.
From the artists that I have worked with, interpolation is mostly done using stroke index odering. Selection ordering is too tedious to be useful in the case where you have a larger number of strokes, I haven’t seen it being used much at all. Making that data persistent doesn’t make it better. It would be much better if we worked on improving this workflow in general. E.g. better visualizations for what stroke is interpolated to where, better tools for picking these pairs that don’t require a mode switch etc.
Like Lukas suggested in point 1. as layer runtime data.
I guess it could also be stored temporarily as an attribute, but I don’t see the benefit of that over a plain vector/array.
If this functionality is not used much and stroke index ordering is preferred, I guess the question then is why have the functionality at all? Maybe make it more convenient to edit stroke index order for the interpolation tool if needed? I can’t really judge this. It just kind of sounds like the selection order is something that was quickly hacked in because it was convenient at the time but not necessarily optimal, and now that the data design changed it’s no longer a good fit.
Regarding storage. If you make both selection and interpolation work as a single modal operator it can work to have it as its own temporary data. But if not, activating a tool doesn’t restrict any edits to the data, so you then have to worry about data invalidation. And if it’s stored as a (temporary) attribute it’s simpler to make sure at least things don’t crash when something edits the topology in between.
Yes I think that summarizes the situation quite well.
We could drop this feature for now and come up with a better solution later. We’ve been doing this for some other things as well that just don’t fit with the new design. Ideally we’d have a temporary replacement, maybe it’s not that bad if we don’t have one for this release and have something much better in the next.
I also assumed that this selection feature was essential and the primary way of interpolating curves. It sounds like it’s not actually used very much after all.
I won’t mind removing the ability to interpolate selected curves. The code handles both cases the same way, it should be easy to add back selected curve interpolation if/when a better mechanism is available to provide the necessary information.
So just reading through the notes there are a few u ca. see how’s might work. All have there merrit that lend themselves to different kinds of animation.
Just and FYI it would be good to have interpolation accessible in all modes based on the selected grease pencil object.
Drawing interpolation - creates new drawings (GP Old behavior).1.1 Interpolated drawing can be staged and a different colour so that they can be processed again and again.
Point interpolation - that operates similarly to AnimAll Addon.2.1.This should also have the ability to turn an interpolated frame into a drawn frame. When converting the frame to a drawn frame this means the point count could change. So the question is what happens to the tween data?
When a user wants to take an interpolated tween frame and turn it into a “drawing frame” this would involve creating not one but 3 extra frames.
The 3 frames that would be created would be a “Before” & “After” frames of the “Drawing frame”. The Before & After frames act as “Hold Frames”. This means the “Hold Frames” can be sculpted/ edited and keep there interpolation.
[2:39 PM]
2.2. When converting an Interpolation point frame into a drawing frame the code should check the timeline to see if there are is data before or after the current frame that is being worked on. This will determine if 1, 2, 3 frame need to be created
2.3. If the drawing point count changes then the current becomes a Drawing Frame.
Our AniMix Addon on Blender market works similarly to the described method using Blender curves. We also extended the same functionality to every object in Blender except grease pencil.
The next most important thing we bumped into after all this was “selecting data” for manipulation. There were a bunch of things that needed to be considered so that animators were animating and not selecting all the time.
I remember to click-dragging for island selection was a biggy. This was done using the lasso selection tool
