I didn't even know the output can in fact replace the viewer emission node, but it seems to work indeed.
Not having the viewer node dangling around does improve the usabilty. I also tested with node groups, and there it seems to work even better. the old viewer node polluted the node tree there, so I like this a lot better!

I think it makes a lot of sense and it seems to work fine.

It works fanatastic. Only thing is, I would put the "Image from Plane Marker" to the Plane Track Properties, where one would assign an image to the marker anyway.
Icing on the cake would be, if the newly generated image would be assigned to the plane track image automatically.

This is intended. That way you can for example better aim a light to your scene by looking through it like a camera.

This is a known issue and will hopefully be solved soon (-ish). Talked to @Sergey Sharybin (sergey) about it last weekend.

Sounds very reasonable to me.

I very much like this proposal and think it could solve some usabilty issues!
Feedback from others would be appreciated though. @Sean Kennedy (hype) thoughts? :)

Just a note (and I already discussed this with @Simon Lenz (Amudtogal)):
I like very much where this is going.
What I would still like to test is a different way to draw the splines:

• Currently the default is Outline. I would like to see how it looks if we only see the pure colored spline, maybe even with thickness slider.
• Eventually the "outline" can be toggled with checkbox?
• Back in the days the "Smooth" setting was added, to make it pussible for users with newer graphics cards to have smooth splines. But now that option should not be necessary anymore and splines should just always be drawn smooth.
• Maybe instead of coloring the active spline white we could draw the active spline a little bit thicker and/or the not active splines with less saturated colors.

In D12776#335006, @Sergey Sharybin (sergey) wrote:

@Sebastian Koenig (sebastian_k), even with manual color assignment I am still not convinced it is great to give option between seeing alpha channel as a fully opaque pass and a color which is not affected by feather with a blending factor. Wouldn't it be better to have ability to color the alpha (so it's not white, but a custom color) and always allow blending factor (can do it for both combined and alpha channel modes) ?

In D12776#334926, @Sergey Sharybin (sergey) wrote:

Not so much sure from a user design perspective. Assigning colors at random has issues of (a) possibly choosing worst visible color for the footage (b) not themeable. A palette approach similar to bone groups could solve some things.

I am not sure. A palette seems a bit like an overkill for it.
Having random colors (especially if they do not start with blue or green) would be quite useful to quickly see the single elements. And if a mask should in fact interfere with the footage, the user can always quickly change it.
Also, other compositing packages work in a very similar way: new masks shapes get a new random color by default.
Maybe we could have a setting in the Mask Display panel to choose if splines should be drawn with mask layer color or in white or black.
But I'd be curious to hear @Sean Kennedy (hype)'s opinion on this.

To me it also doesn't seem to be that useful to see non-blended non-feathered result of a mask. I imagine that adding feature like "Single Layer View" to allow easily/quickly make it so only splines form the active layer are visible and rasterized will work much better.

Also not sure about this.
In practice I would always want to see all mask layers. *If* I don't want to see one, I'd disable the visibility of it.
However, there is another aspect similar to this:
While working I found it super annoying to always accidentally activate other mask layers, because they are all selectable all the time.
One solution for it would be to only allow tweaking curves of the active spline. And handles of the other masks would be hidden, which would also reduce visual clutter. Having to disable selectabilty of each mask layer by hand is quite tedious.
Maybe double clicking the spline of another mask layer could then activate it?
But maybe that's also a separate design task...

@Sergey Sharybin (sergey) This is already implemented, so I guess this can be closed.

I think this is intentional, as the world background can very well have values larger than 1. Afaik it is not just color but also light energy. An HDR can also have color values far above 1 (the sun for instance), so it makes sense to allow high color values as well.

In D10198#333846, @Sergey Sharybin (sergey) wrote:

In D10198#333811, @Sergey Sharybin (sergey) wrote:

For solving the TODO I've left behind I'd go with something like P2479.
@Sebastian Koenig (sebastian_k) Can you test that it works the same as the current branch?

I tested the patch and indeed it works the same as tracking_branch. What exactly does it do though?

Also noticed adding point inbetween of "aligned" vertices creates vertex at the mouse position and slides handle. Feels unnatural, but not sure what the ideal solution is. Maybe create point with handles pointing at the neighbors somewhere 1/3 way (so that we don't have such singularity situation) ?

You are totally right, this is very annoying. Instead of sliding the handle it should slide the vertex instead. In practice what I'd want is more like an auto-handle. Same goes for Aligned Single. Currently it slides the single handle, but I would think a behavior similar to adding an auto-vertex would be more useful.

I just tested the patch and can confirm it's working. Great!

Masking Tools are now also working in the Image Editor.
So @Sergey Sharybin (sergey) , is there any chance this can still go in for 3.0? What is the correct procedure for it?

• Merge branch 'master' into tracking_tools
• Masking: Add masking tools to image editor

So here's the current status of the Clip Editor:

• Keymap: Give mask tools a generic name
• Wip: start on image editor mask tools
• Merge branch 'master' into tracking_tools
• Merge branch 'master' of git.blender.org:blender into tracking_tools
• Merge branch 'master' of git.blender.org:blender into tracking_tools
• Merge branch 'master' into tracking_tools
• Merge branch 'master' into tracking_tools
• Tracking Tools: Only show toolheader in Clip View
• Merge branch 'master' into tracking_tools
• Merge branch 'master' into tracking_tools
• Clip Editor: Add Clip Tools to Footage Settings
• Merge branch 'master' into tracking_tools
• Merge branch 'master' into tracking_tools
• Merge branch 'master' into tracking_tools

Wow, what a weird bug. But I can confirm this. On top of that, when I render with GPU and OptiX, I get render errors at the world origin. Happens in 2.93.1 and current master (rBeea65cbd425d0e06dc1436fe36cebb69f4c12e12). The render errors only occur with OptiX, the slowness no matter which render device.
I have attached the blendfile.

Apparently my last attempt to update the diff failed, so here is another try.

I have updated the patch so that it works in the 3.0 branch.
It definitely needs some polishing, but at least it is working for the most part.
Ideally we would continue in a branch though.

Since the goal of this patch is to prepare for the new UI, I think it's fine to commit.

I have mixed feelings about this.
The scale value is mostly used to adjust the scale of objects after object tracking. In practise you set the value by picking two markers and hit "set scale" in the orientation panel, or simply drag the scale slider, or both.
In the current solution the user immediately sees the effect of this action on the scale value in the same panel. With this patch however the effect of the "set scale" button takes place on the opposite side of the editor (well, and of course the 3d view).
The scale value is more like a tool that the artist can use to match the object size and position to the scene. So with this patch the tools to control the scale are spread across two opposite sides of the editor.
On the other hand, once the user has multiple tracked objects and has to adjust both scale values in order to orient them both in the correct spot in 3d space, it is now easier to quickly switch between the objects and adjust their scales without having to switch them in the sidebar on the right and then tweak the scale value in the toolshelf on the left.
However, once we switch to active tool system we have to find a solution where to place the orientation tools anyway. And chances are that the orientation panel will move to the sidebar or some menues anyway.
So, for the old UI I would be against this patch, but for the new system this could work.

@Daniel Salazar (zanqdo) good catch! however, there is a problem with your approach, which I have (hopefully) addressed here: https://developer.blender.org/D11715

Well, Persistent Data didn't really exist in 2.79. Up until 2.92 it was Persistent Images, but now it also caches the BVH or something like that, so I suppose that is messing with the tiles ordering or so.

In T86948#1136404, @Stephen Swaney (stiv) wrote:

Doing a "ulimit -n" on my Linux box shows a limit of 1024 open files.

very interesting, thanks! gonna check on windows tomorrow.

Alright, must have been leftovers in my presets folder in my building directory. Probably something has been changed recently or so. Anyway, this can be closed now! :)

In T86591#1131299, @Germano Cavalcante (mano-wii) wrote:

The video was not packed in the blend file (File -> External Data -> Pack All Into .blend).
Can you provide the video used so that we can check and confirm?

Please provide more information about what exaclty is not working, ideallly with a blendfile that demonstrates the issue. I tried the bool tool and it is working.

If I understand you correctly, you do not enter an offset in the footage settings, but change the start frame of the clip.
In that case, yes, you are right, this behaves a bit weird.
The little green lines down in the cache area appear in the correct spot, but the numbers in the Keyframe A, Keyframe B fields are off.
During testing I have prepared a file that demonstrates the issue.

I think a toggle could work nicely, similar to the RGB buttons. In the center is current frame, left and right are prev/next. But where to put them...

I have tested this a few times and find it a great addition to Blender's tracking tools.
It seems to be very reliable and stable, and super useful too, especially when repositioning tracks after a feature has been occluded.
But it is also very helpful to see the start and end reference, because it makes it very obvious if the tracker has slid off during tracking.
It gets more fuzzy when using affine or perspective tracking, because the preview deforms with the feature, so even though the tracking might be fine and the reference point is the same, the previews could show different images due to the deformation that happens during tracking. With the way the preview works right now that might be unavoidable though. I wouldn't consider this an issue for the time being.

This is interesting. I can indeed reproduce that behavior with your file. However, if you go to a different workspace and create a compositor there, the backdrop reacts to color management just fine. Your compositing workspace seems to be broken somehow, but I have no idea how. Maybe @Jeroen Bakker (jbakker) has an idea?

I cannot confirm that, it works here, both in 2.93 and in 2.92. Can you post a blendfile where it happens?

I have tried with the Fabrik movie and Tears of Steel from the DVD. I have tracked some markers and then scrubbed and clicked like crazy, also reloaded the footage, but couldn't make it go off sync. So it seems to be fine.

Without the footage and without any markers in the blendfile it is impossible to figure out why the file might be crashing. Could it be that your memory is full? How much RAM do you have? Does it also crash if you only track one single marker?

Oh, that is a misunderstanding indeed. I thought "drag selection" refers to move the selection, not "drag a selection box". :)
Yeah, that is a todo then :)

Uhm, no, this is supposed to work. And it also does work here. (b4147aeeab7d, Linux)
I create a mask, click on the white dot in the center and can move the mask with it.

You are right, this is different than before. But this is not really bug, but rather a change in behavior. Lock to Selection now also works in Masking, where it locks the view to the selected markers, but not with the completely broken behavior as in 2.91 and before, but rather in a way that actually works. Part of this change is that the view follows the active selection, but without centering the view. That way it is less jumpy and less distracting.

In T81662#1108879, @Robert Nederhorst (rnederhorst) wrote:

In T81662#1108669, @Robert Nederhorst (rnederhorst) wrote:

I have used multiple images for projection. Example : Frame 1 and Frame 200 have different angles from the tracked camera. Faces visible on frame 200 are different than on frame 1. So I want to use frame 200 image to paint from the frame 200 camera. Same with frame 1 camera/image. This allows me to blend images together on to the geometry.

Sure, I do that as well, but this is not the issue here. In terms of datablocks, technically it is still the same Background Image on frame 1 and 200, e.g. a movie or image sequence, just a different frame.

In T84769#1100664, @Sean Kennedy (hype) wrote:

If you leave the default cube in the scene, it does not move it to the foreground collection. If you delete the default cube, it will create a cube in that foreground collection.

Thanks for the hint, this should be fixed now. Instead of always creating a new collection, it will rename the default collection to "foreground", if there really is only 1 collection in your scene.

Should the Backdrop in the node view be automatically turned on when using the Nodes checkbox? I don't ever use the Backdrop anymore, but if most people do, I guess it would make sense to leave on.

I still use it. I didn't touch that setting, would leave it for now.

Checking both Nodes and Shadow Catcher with in both cycles and eevee, there weren't any nodes added for shadows. I haven't used Eevee enough to know if that's necessary, but for Cycles, should there be some nodes? Also, should Indirect be turned on for the "shadow catcher" collection?

No, the cycles setup uses the Shadow Catcher option. You don't need any nodes for that, it works via Alpha Channel. Not really fancy and not that much controls, but it's an easy setup.

I tested this for a bit and find it quite useful, though indeed rather confusing.
I would get rid of the Corner Rounding checkbox. Instead just use the slider. If it is zero, no rounding is happening, but if rounding is required, the user only has to increase the slider without having to click on a checkbox.
The Value input is indeed doing something, as I found out while trying the last file in the comment from @Michael P. (forest-house) from January 6th 2017. So I guess it's needed.
The Edge output I guess is mostly for debugging? But does it have to be colored? The keying node has an edge output too, but that one is just a value output. Maybe we could use that here as well?
More problematic are the three edge detection methods. I can only comment from a user perspective, not sure if the code is doing anything in the background that I am not aware of.
I tested with colored and with bw images.

1. Value

When edgedetection is set to Value, the threshold parameter doesn't seem to do anything. If it is anything else than zero, no AA seems to be happening whatsoever. So when using Value ED I suggest to drop the threshold slider. Unless I am missing something here.

2. Luma and Color seem to be very similar, and using the 2 sliders does indeed do *something*, but from a user perspective it is really not clear if there is a useful difference and what exactly the sliders do. Maybe the two an can be unified somehow?

I suppose most users will probably use it to smooth masks and ID passes, so I suggest to make Value be the default setting, and the user would only need 1 slider for corner rounding.

@Sergey Sharybin (sergey) I'd vote against it, since I would rather put the solve panel in the header.
Solving is something that sometimes is being done over and over again, with varying settings, so it would be cumbersome to have it in the sidebar, because you ALSO have to have track and tracking settings accessible all the time. That's why I would rather put it into the header, as shown in this image https://dev-files.blender.org/file/data/myed7vsbwffz3zipu42b/PHID-FILE-pr7w637qcto5oxwcnlgc/mce_tracking.png from here: https://developer.blender.org/D10198 It's a similar button placement as the "run script" operator in the text editor.

we shall!

In D10265#257919, @Sergey Sharybin (sergey) wrote:

I tried to find a solution to the handles_as_control_point thing, but it doesn't really work. I mean, behavior itself with lock to selection seems fine, but now I cannot pan when nothing is selected. I guess this is something for a real developer! :)

• New Tool: add_marker_and_tweak. same as add_marker_slide, but that one is now only adding markers on click
• Merge branch 'master' into arcpatch-D10198

• Implement some masking tools, polish tracking UI
• Merge branch 'master' into arcpatch-D10198

• The extras popover panel was still missing

• Add marker tool works now! (kind of)
• Add properties for add_marker_slide tool
• Merge branch 'master' into arcpatch-D10198

@Sergey Sharybin (sergey) Hey man! I am making a bit of progress in the toolification of the clip editor. But I am stuck at getting the add_marker tool to actually do something. The tool shows up, but when I click nothing happens. Could you give me a hint on how to get this to work?

• Merge branch 'master' into arcpatch-D10198
• more attempts to make add marker tool work, no success
• Merge branch 'master' into arcpatch-D10198

• Add data source options for MCE annotation tools
• Also tried to implement the add_marker tool, but to no surprise this does not work yet.

• Merge branch 'master' into arcpatch-D10198
• Fix missing tool options in header.

ED_KEYMAP_TOOL was missing, and keymap name was wrong.
Now annotation and selection tools are working.
The tool settings are still missing though.

• Add clip tools to keymap
• The tools still do not work yet, but it seemed as if those steps would be necessary.
• Also, I never used arc diff before, so apologies if this messes up somehow.
• Merge branch 'master' into arcpatch-D10198

I don't think this is a good change. These things are separate because they are separate settings that do separate things.
The tracking settings operate during tracking. Only when you actually use the tool (as in, track forward or backwards), they have an effect.
The Track settings are properties of the track that affect solving and/or display. Let's keep it that way.
Unless it might be an idea to have the tool settings (former default tracking settings) also act as tracking settings, so to unify those. But I think that might violate the whole active tool design in Blender...

In D2771#255560, @Sean Kennedy (hype) wrote:

So for it to be "Sean-interpolation", you would leave "o" turned off and simply set keyframes around the area you want to adjust, then adjust and let the falloff to nearest keyframes happen linearly.

No, both are some form of proportional editing. So without turning on "o", moving a marker is just moving it on that frame.
When you turn on "o", it will adjust the track between keyframes (if there are any). Once you start scrolling, you will expand/shrink the falloff from current frame to surrounding frames beyond/below next available keyframe.