Paint Tracking - stroke/tracker relationship

[allklier]

Using the new paint improvements in 2024 and loving the point tracker.

Re-watched @Jeff’s tutorial on that (part 4). One thing that I haven’t fully decoded, and wonder if anyone knows: What’s the mapping between paint strokes and trackers?

Option 1: There is just a single tracker per node, applied to all strokes
Option 2: There is just a single tracker per node, and only applied to selected strokes during tracking
Option 3: There can be multiple trackers per node, one each per stroke selection/tracking pass

I have a feeling it’s not #3, even though that would be awesome. So if you’re dusting some product and need more than one track, you need to use multiple paint nodes?

And if you need to just track a few strokes, but not all, you’re better off having one node for untracked strokes and another for the tracked strokes?

The example use just a single pairing, so you can’t decipher it from there.

[Jeff]

Hey there Jan. Great observation and great point- the answer to your question isn’t super clear because it gets a little deep.

I just did some tests and I think I understand how it works, although it’s a little hard for me to explain, so I’m going to just spew things out. It’s definitely not explicitly any of the options you listed, but a variation on 3.

You CAN have multiple different tracks inside of a single node, but you need to go about it in a slightly different way than you may be used to in action with axes. When you enter the paint tracker with a stroke / series of strokes selected, and complete some tracking, that tracking data is applied to the stroke / selected strokes. That is that part that’s obvious and outlined in the tutorial. Here’s what happens next:

If you go back into the tracker, you’ll notice that the data is still loaded regardless of if you keep the same selection or create a new selection of strokes.

• If you go back into the tracker you used earlier and keep the same selection (strokes already with tracking data) and exit the tracker without doing anything, nothing happens.
• If you go back into the tracker you used earlier with a NEW selection (strokes without tracking data) and exit the tracker without doing anything, the tracking data is loaded onto the new selection.
• If you go back into the tracker you used earlier for a selection that has tracking data, and reset the tracker, it does not delete the tracking data.
• If you go back into the tracker you used earlier, reset the track, and do a new track, that new track is applied to your selection.

Tracking data inside of the paint node’s tracking module does not persist on a per-stroke basis, but rather, the tracking module is more like a scratch pad that holds the most recent track and sends the data to the selected stroke(s) whenever you enter / leave the module. If you know that you might want to track something, then track something else, and later want to modify the first track, you should consider saving the first track out so you can load it back in later. Since there’s no schematic, there’s essentially one “axis” that holds the tracking data, and it is applied to the selected strokes when you exit the tracker.

Sorry it’s not a simple answer, but let me know if you need more clarification. BUT! I’m sure if the devs were here they would possibly say something like this is the first iteration of paint tracking in Flame and if you have feedback on what’s working or not working for your use cases, throw a feature request up on the feedback portal and it will get logged.

[allklier]

Hey @Jeff. Thanks for taking them time for this detailed explanation. Makes complete sense and tracks with what I experienced, but didn’t piece together the ‘scratch pad’ analogy that is apt.

I noticed that gong back in there was existing data that would seemingly be applied, as evidenced if certain strokes would have the yellow line in the tracking data or not.

I guess some care has to be taken that you always start tracking from the same frame if you use relative positioning, as otherwise the anchor can create unexpected things if you add existing tracking data to a new selection.

It gets quite complicated quickly, and there really isn’t any place this can be visualized, like some of the schematics. It’s workable if you have like 2-3 different tracks in a node, but if you do a major cleanup that may have 20-30 different tracks for different points it becomes chaos.

Thinking of how this works in Si, maybe a future version of this feature could have a schematic view that keeps track of individual axis objects (like gMask Tracer has) each with their own ID. Then in the stroke list you can assign them to one of these axis objects, similar to how you edit frame start/end. That would persist the tracking data, you could label them, and potentially even fix a track as needed.

I’m sure this feaure will evolve further.

[Nick]

Just an appreciation post. I started using the paint tracker today to take care of some minor cleanup, and am loving this tool. Very handy and quick.

[Jerem]

Thanks for your explanation Jeff it gets more clear ! I Couldn’t figure out how to apply different tracks to one single paint node, good to know that’s possible.

At the moment I’m used to creating many paint nodes / tracking them separately and combining them all at the end before my render.

[Josh_Laurence]

Thanks @Jeff for the explanation! Maybe it’s me, but one thing I haven’t seen mentioned is this node seems optimized. It’s feels a lot faster and more responsive to use and so far, even when I go to town on a cleanup, it doesn’t struggle the way it used to.

And there’s another nice option in the node - you can animate tracking adjustments after tracking - and see the results live. I use the Offset X,Y fields to fine tune placement of the strokes on the canvas and fix drift.

[Jerem]

As an optimization for future updates, maybe a simple way to make this more organized and visible could be to give strock color in the edit tab, so we know same group color is the same track.

Also love your idea @allklier !!

[allklier]

I think it’s worth clarifying how this works, piecing together @Jeff’s explanation and my experience since.

Each paint stroke has a number of animation channels, including a position x/y. This is stored on a per stroke basis.

Even though in the UI this is labeled ‘Axis’, there doesn’t appear a separate persistent Axis object attached to the stroke. Instead there is a single hidden Axis object that exists for the entire node. When you enter the tracker, it is this hidden Axis object that you are tracking (which is also why the most recent tracking data pop back up when you re-enter the tracker).

When you return from the tracker UI, the position x/y data from this hidden Axis object is copied into the position x/y channels of all selected strokes. But it’s a one-time copy, not a link.

When you select a different set of strokes, reset that hidden Axis object, and do a new track, the refreshed data gets copied to the now selected strokes.

This hidden axis object is what Jeff aptly called a scratchpad, because that’s exactly how it acts.

As a result of this Axis object being recycled and there not being a link, there is no way of keeping any information. The best that could be done is keeping kind of a tracking generation/version number that starts at 1 and gets incremented every time the Axis object tracking data gets changed. Then in the stroke edit tab it could simply show this generation/version number, so you know which set of tracking data it currently occupies. But this would be purely informational, and possibly of limited use.

While this single temp Axis object concept was an efficient way of implementing it, and somewhat genius in that way, it is counter to the way Axis objects are used almost everywhere else, which makes it a bit of outlier/source of confusion. I think long-term, maintaining persistent axis objects with links to groups of strokes would be a an improvement both for consistency, and also making it easier to manage/refine tracking data. It would also open the option to track with two points to populate the scale channels in the stroke.

PS: Should also amend Jeff’s wording. He wrote ‘Tracking data does not persist on a per-stroke basis’. That’s a bit ambiguous as a statement. It’s true that the tracker itself does not persist on per stroke basis. But the tracking result data, specifically the position x/y does persist by the way of copying it into the strokes position channels.